Triage a GitHub issue filed against skillsaw — classify it (bug, feature, docs, question, other), verify its claims against the codebase, enrich it with missing details, and post one structured triage comment. Use when triaging and labeling incoming issues, not to fix them.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Triage a single open issue on the skillsaw linter. Check what kind of
issue it is, check whether its claims hold up against the actual code, fill in
the details it is missing, review the evidence, and leave one triage
comment. This skill triages issues — never fix them here (that job belongs to skillsaw-issue-solver).
Read the detailed evaluation checklist for each classification in references/,
and read only the checklist for the class the issue falls into (progressive disclosure).
Keep this file lean and pull the checklist in on demand.
Run this for the issue number you were given:
gh issue view <number> --json number,title,body,labels,author,comments,createdAt
Read the title, body, and every comment before judging anything. Note the skillsaw version the reporter names (or none), and check any config, command, or file content they pasted.
Set exactly one primary class. When an issue spans two, pick the one that determines the next action and note the secondary in the comment.
| Class | The issue is… | Evaluation checklist |
|---|---|---|
bug | A claim that skillsaw behaves incorrectly — wrong violation, crash, false positive/negative, bad autofix | references/bug-evaluation.md |
feature | A request for new behavior — a new rule, flag, config option, output format, or tool/format support | references/feature-evaluation.md |
documentation | Docs are missing, wrong, or unclear (README, skillsaw.org, rule docs) — code behavior is not disputed | references/other-evaluation.md |
question | A usage/support question, not a defect or request | references/other-evaluation.md |
other | Duplicate, invalid, spam, out-of-scope, or needs-more-info | references/other-evaluation.md |
Write the class and a one-sentence rationale.
Read the checklist for the chosen class now (references/*.md) and work it.
Check whether the issue is accurate — do its claims match how skillsaw actually behaves?
src/ module, then verify it. A bug you cannot
reproduce, or that describes intended behavior, is not confirmed — always say so.Cite what you checked with file:line references and command output — never assert a conclusion you did not verify.
Add the details the issue is missing so it is actionable without a round-trip:
main.gh issue list / gh pr list --search).bug, enhancement, documentation, question, duplicate, needs-info, good-first-issue), but never apply them unless asked.Set exactly one recommendation — this is the headline of the triage comment:
| Recommendation | When |
|---|---|
| 🛠️ FIX — REPRODUCED | A real defect you reproduced or confirmed against the code (a genuinely wrong or missing doc counts here too). |
| ✨ IMPLEMENT — GOOD IDEA | An in-scope feature worth building into skillsaw core. |
| 🔌 PLUGIN | In skillsaw's domain but niche / single-vendor — belongs in a rule plugin, not core. Link skillsaw.org/plugins/. |
| ⛔ REJECT | Out of scope, not reproduced, works-as-intended, invalid, duplicate, or answered. |
Follow the class checklist to decide: a bug that reproduces → FIX,
one that doesn't → REJECT; for a feature, follow the domain gate in
references/feature-evaluation.md (out of domain → REJECT, niche → PLUGIN,
broadly useful → IMPLEMENT).
Read references/triage-template.md, then post it as exactly ONE comment:
gh issue comment <number> --body "$(cat <<'TRIAGE'
<rendered triage>
TRIAGE
)"
This skill is advisory: keep its output a recommendation for a maintainer. Post the triage comment on your own initiative, but never close, reassign, or label the issue yourself — always leave that to a human. Follow one exception only: a label action the invoking context directs — for instance, keep clearing an automation's own trigger label once you post the comment. Always carry that out.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Create a skillsaw rule plugin — a pip-installable Python package that adds custom lint rules to skillsaw. Walks through scaffolding the package, writing rules against the lint tree, testing, and publishing to PyPI. Use when a user wants to share skillsaw rules across repositories or publish them for others.
The English summary is being prepared. Showing the original description.
Survey the AI coding assistant and agentic tool ecosystem, assess skillsaw's competitive position, identify emerging patterns and missing capabilities, and produce a prioritized strategic report as a GitHub issue. Use when evaluating ecosystem trends and product gaps.
The English summary is being prepared. Showing the original description.
Fix skillsaw lint violations — apply deterministic autofixes, then resolve the remaining violations with targeted edits guided by `skillsaw explain`. Use when skillsaw reports violations, when asked to clean up lint findings, or after `skillsaw fix` leaves violations behind.
The English summary is being prepared. Showing the original description.
Use when skillsaw reports a likely false positive, misses an edge case, behaves incorrectly, or needs an RFE. Gather a safe report and, only with explicit user permission, create a feedback bundle or open a GitHub issue.
The English summary is being prepared. Showing the original description.
Pick up open GitHub issues from collaborators and create PRs to solve them. Use when triaging and resolving reported bugs or feature requests.
The English summary is being prepared. Showing the original description.
Use when modifying agentic contextual building blocks like skills (SKILL.md), slash commands, agents, hooks, plugins, marketplaces, and instruction files (CLAUDE.md, AGENTS.md, GEMINI.md, QWEN.md, Cursor, Copilot, Cline, or Kiro rules), tool configuration such as an OpenCode `opencode.json`, Muse Code hooks (`.muse/hooks.json`), a Grok Build `.grok/` project layer or a Google Antigravity customization root (`.agents/`, `.agent/`, `_agents/`, `_agent/` — hooks, MCP config, rules, registries and plugins), and committed project memory (`.agents/memory/`). Run skillsaw on the files you touched, apply autofixes, resolve remaining violations with `skillsaw explain` guidance, and re-lint until clean before considering the work complete.
The English summary is being prepared. Showing the original description.