github-issue-mentions-to-linear

GitHub issue mentions to Linear

Catches mentions of your product in GitHub issues and discussions and creates a Linear issue for each through a webhook relay, so your engineering team tracks community feedback in their existing workflow.

alertresult

What it does

  1. 1

    Step 1

    Register a catch with your product name as the query, github as the source, and a webhook destination pointing to a relay that creates Linear issues. Set min_prescore to 0.3 to filter noise from threads that only mention your product in passing.
  2. 2

    Step 2

    The relay receives the signed webhook payload with the results. For each result it calls the Linear API to create an issue with the GitHub thread title as the Linear issue title, the URL as a link, the excerpt as the description, and a label like "community" to distinguish it from internal work.
  3. 3

    Step 3

    Deduplicate by delivery_id. Each firing carries a unique delivery_id. The relay checks whether a Linear issue tagged with that id already exists before creating a new one. The SKILL.md includes a deduplication example using Linear’s custom fields.
  4. 4

    Step 4

    The relay can be a small function on any serverless platform, an n8n webhook workflow, or a GitHub Actions workflow triggered by a repository_dispatch event. The github_dispatch destination type sends the payload as a repository_dispatch event directly, which avoids the need for a separate relay.
  5. 5

    Step 5

    Test the full chain with POST /v1/catches/{id}/test. The sample payload reaches the relay, which creates a test Linear issue. Verify the issue has the correct fields before enabling the catch.
  6. 6

    Step 6

    This playbook ships as a SKILL.md in the dcouple/discatch-playbooks repo so skills.sh and agent skill directories pick it up.

Sources it watches

GHGitHub

Common questions

Why a webhook relay instead of a direct Linear integration?

discatch sends a generic signed webhook with its own payload shape. Linear’s API expects an authenticated GraphQL mutation with a specific schema. The relay translates between the two: it reads the discatch payload, extracts the fields it needs, and calls Linear’s issuCreate mutation. It is a small function, typically under 50 lines of code.

Can I use github_dispatch instead of a webhook relay?

Yes. Set the destination type to github_dispatch and point it at a repo with a GitHub Actions workflow. The workflow receives the event payload as the client_payload of a repository_dispatch event, extracts the results, and calls the Linear API. This avoids hosting a relay separately.

What GitHub content does this catch cover?

GitHub as a source covers issues, discussions, and READMEs across public repositories. The catch fires when your product name appears in any of those. Pull request descriptions and review comments are included when they are part of a discussion thread. Private repositories are not covered.

How do I avoid duplicate Linear issues?

Each firing carries a unique delivery_id. Store the delivery_id on the Linear issue as a custom field or in the description. Before creating a new issue, query Linear for an existing issue with that delivery_id. If one exists, skip the creation. The SKILL.md includes a working deduplication example.

Can I route to Jira or another tracker instead of Linear?

Yes. The webhook payload is the same regardless of what receives it. Change the relay to call the Jira REST API, the Notion API, or any other tracker’s API. The discatch side does not change; only the relay logic does.

What does this cost?

One alert unit per firing plus one result unit per item delivered. A catch at 15 minutes on one source with a specific quoted product name fires infrequently. Most intervals produce zero new results and cost nothing. The quote on each delivery says exactly what was charged.

Last reviewed by , founder, dcouple. Copy from docs/playbooks.md.