$npx -y skills add apache/magpie --skill issue-triageFor each open <issue-tracker> issue in the configured candidate pool, read the issue body and comments and classify the candidate disposition. On user confirmation, posts a triage-proposal comment that invites the project team to react. Read-only on tracker state — no workflow
| 1 | <!-- SPDX-License-Identifier: Apache-2.0 |
| 2 | https://www.apache.org/licenses/LICENSE-2.0 --> |
| 3 | |
| 4 | <!-- Placeholder convention (see ../../AGENTS.md#placeholder-convention-used-in-skill-files): |
| 5 | <project-config> → adopter's project-config directory |
| 6 | <issue-tracker> → URL of the project's general-issue tracker |
| 7 | (resolves from <project-config>/issue-tracker-config.md) |
| 8 | <issue-tracker-project> → project key within the tracker |
| 9 | <upstream> → adopter's public source repo |
| 10 | <default-branch> → upstream's default branch (master vs main) |
| 11 | Substitute these with concrete values from the adopting |
| 12 | project's <project-config>/ before running any command below. --> |
| 13 | |
| 14 | # issue-triage |
| 15 | |
| 16 | This skill is the **initial-triage discussion-starter** for issues |
| 17 | on the project's general issue tracker. For each open issue in the |
| 18 | configured candidate pool, it reads the issue body and comments, |
| 19 | applies the project's triage criteria, classifies the candidate |
| 20 | disposition, and — on the user's explicit confirmation — posts a |
| 21 | triage-proposal comment that invites the project team to react. |
| 22 | |
| 23 | The skill **never transitions workflow state, never closes, never |
| 24 | assigns, never edits any tracker field**. The disposition decision |
| 25 | belongs to team consensus; this skill opens the discussion that |
| 26 | produces it, and sibling skills apply the state change once |
| 27 | consensus lands. |
| 28 | |
| 29 | It composes with: |
| 30 | |
| 31 | - [`issue-reproducer`](../issue-reproducer/SKILL.md) — invoke when |
| 32 | the classification depends on whether the reporter's code still |
| 33 | fails on `<default-branch>`. |
| 34 | - [`issue-fix-workflow`](../issue-fix-workflow/SKILL.md) — invoke by |
| 35 | hand after the team agrees a triaged issue is a confirmed bug or |
| 36 | feature ready to fix. |
| 37 | - [`issue-reassess`](../issue-reassess/SKILL.md) — sibling for |
| 38 | sweep-mode work on the resolved or end-of-life pool (this skill |
| 39 | handles the unsorted-new pool). |
| 40 | |
| 41 | --- |
| 42 | |
| 43 | ## Golden rules |
| 44 | |
| 45 | **Golden rule 1 — read-only on tracker state.** This skill posts |
| 46 | discussion comments and nothing else. No workflow transitions, no |
| 47 | label mutations, no body edits, no project-board column moves, no |
| 48 | field changes. The skill's output is *text on the tracker that |
| 49 | invites reaction*; the team's reply drives state change, applied |
| 50 | later by sibling skills. |
| 51 | |
| 52 | **Golden rule 2 — every comment is a draft until the user |
| 53 | confirms.** Triage proposals are public(-ish) comments on |
| 54 | `<issue-tracker>`, attributed to the maintainer who invoked the |
| 55 | skill. Per the "draft before send" rule in |
| 56 | [`AGENTS.md`](../../AGENTS.md), every comment is drafted, shown to |
| 57 | the user, and posted only after explicit confirmation. The fact |
| 58 | that the user invoked the skill is **not** blanket authorisation — |
| 59 | the text of each comment is reviewed individually. |
| 60 | |
| 61 | **Golden rule 3 — six disposition classes, no more.** The |
| 62 | classification is a proposal, not a verdict; the team's reply may |
| 63 | escalate or de-escalate. The skill always proposes exactly one |
| 64 | class per issue — never two — because a two-class proposal stalls |
| 65 | the discussion rather than starting it. |
| 66 | |
| 67 | | Class | When to propose | Sibling skill / action | |
| 68 | |---|---|---| |
| 69 | | `BUG` | Confirmed actionable bug; reproduces or has compelling evidence | [`/magpie-issue-fix-workflow`](../issue-fix-workflow/SKILL.md) | |
| 70 | | `FEATURE-REQUEST` | Valid improvement or new-feature request; not a bug | Re-type as Improvement; route to project's roadmap | |
| 71 | | `NEEDS-INFO` | Missing repro steps, environment, version, or other actionable detail | Request info from reporter | |
| 72 | | `DUPLICATE` | Substantive overlap with an existing tracker issue (open or closed) | Link to canonical issue | |
| 73 | | `INVALID` | By-design, won't-fix per project policy, out-of-scope, or environment-specific | Close with rationale | |
| 74 | | `ALREADY-FIXED` | A commit on `<default-branch>` covers the report; the issue just needs closing | Close referencing the commit | |
| 75 | |
| 76 | **Golden rule 4 — never auto-escalate from a comment reply to a |
| 77 | mutation.** A reply on the tracker like *"agreed, close it"* is |
| 78 | ** |