Defame1297
60be7b3232
Only 12 of 39 skills carried metadata.version, and adoption tracked which plugin a skill lived in rather than any stated rule: core, gitea and lint were consistent adopters, bin and kyberforge were consistent non-adopters, git was split with one outlier. There was no documented convention, and skill-author's own bump logic was already written as if presence were conditional. metadata.version is now required on every skill. The 19 skills here that never carried one (bin, kyberforge, gitea-files) are seeded at 1.0.0, not 0.1.0 -- that value stays reserved for a skill's actual creation point under skill-author's existing convention. The skill-frontmatter pre-commit hook now fails a SKILL.md missing the field, the same class of failure as a missing name/description. Full rationale in the new ADR. The git-plugin skills that also need this field follow in the next commit, bundled with issue #113's rtk normalization since both touch the same files. Refs: #127 ADR: 0022 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EeH8SCbcrCAQrtymkNuhKP
triage
Move issues on the project issue tracker through a small state machine of triage roles.
What it does
Gives issue triage an explicit state model and a fixed set of moves. Every issue carries exactly one category role (bug, enhancement) and one state role (needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix); conflicting state roles are flagged to the maintainer before anything else happens. Unlabeled issues normally enter at needs-triage; needs-info returns there once the reporter replies. The maintainer can override at any point, and unusual transitions are questioned rather than executed silently.
A run does one of three things depending on what the maintainer asks for:
- Show what needs attention — three buckets, oldest first: unlabeled,
needs-triage, andneeds-infowith reporter activity since the last triage notes. - Triage a specific issue — gather context (including prior triage notes, so resolved questions are not re-asked, and
.out-of-scope/records that resemble the issue), recommend a category and state with reasoning, attempt reproduction for bugs before any grilling, run agrill-with-docssession if the issue needs fleshing out, then apply the outcome. - Quick state override — "move #42 to ready-for-agent" is trusted and applied directly, skipping grilling, after confirming the exact changes.
Two hard rules: every comment or issue the skill posts during triage must open with the AI-generated disclaimer, and the canonical role names above are not necessarily the label strings in the tracker — each is resolved against the tracker's live label set before it is applied, and a name with no counterpart there is reported to the maintainer as a gap rather than guessed at.
Composition
grill-with-docs is invoked at step 4 when an issue needs fleshing out; whatever that session establishes is carried into the triage notes so the work is not lost. The reverse direction also exists: diagnose names this skill as the place to send a reported bug that needs filing rather than debugging.
Usage
/triage
Then describe what you want in natural language — "show me anything that needs my attention", "let's look at #42", "move #42 to ready-for-agent", "what's ready for agents to pick up?".
Files
| File | Purpose |
|---|---|
SKILL.md |
The roles and state machine, the three invocation modes, the needs-info template, and how to resume a prior session |
AGENT-BRIEF.md |
Skill-root document, cited when an issue moves to ready-for-agent (and reused for ready-for-human): how to write a brief that stays durable for weeks while the codebase moves under it — describe interfaces and behavioural contracts, not line numbers |
OUT-OF-SCOPE.md |
Skill-root document, cited when an enhancement is closed wontfix and when checking for prior rejections: how the .out-of-scope/ knowledge base is laid out and what it is for — institutional memory, and deduplication against re-litigated requests |