dev-skills

Judge whether a GitHub issue is worth building at all, and say so in a verdict comment. Weighs what the idea is worth against the permanent cost it adds — a migration, an endpoint, a module tab, more code to keep working — and lands on build it, narrow it, or decline it. Use before committing to an issue, especially a feature that would grow the system, and whenever the backlog is growing faster than the appetite to maintain it. Pass the issue number (e.g. "42"). Recommends only: it never edits, labels or closes the issue.

Turn a GitHub issue into a complete, tested pull request. Use when the user wants an issue implemented end-to-end: read issue N, branch, implement with tests, and open a draft PR that closes it. Pass the issue number (e.g. "42").

Apply reviewer feedback on a pull request: read the review comments, make the requested changes, reply to each thread, and push. Use when a PR has review comments to address. Pass the PR number (e.g. "42"); defaults to the PR for the current branch.

Review a pull request and fix it in a loop until it's clean ("LGTM") — runs code review, applies fixes, runs tests, and repeats until no findings remain and the build/tests pass, marking a draft PR ready once review is clean. Use when the user wants a PR brought to merge-ready automatically. Pass the PR number (e.g. "42"); defaults to the current branch.

Go from nothing to a merge-ready PR: propose a new issue, implement it as a tested PR, then review-and-fix until clean. Use to autonomously explore and ship an improvement. Pass the kind ("feature", "simplification", "removal", or "architecture", optionally with an area). Chains propose-issues -> generate-pr-from-issue -> polish-pr. NOTE: Claude chooses what to build with no human vetting of the idea — best for low-stakes / exploratory work.

Analyze the codebase and file a well-defined GitHub issue proposing the next step. Use when the user wants a feature idea, a simplification/cleanup, a proposal to delete the feature that has stopped earning its keep ("less is more"), or an architectural next step turned into an actionable issue. Pass the kind as an argument: "feature", "simplification", "removal", or "architecture" (optionally with an area to focus on, e.g. "feature rating module").

Resolve a GitHub issue end-to-end, or explain why it shouldn't be worked on. First vets whether the issue actually makes sense against the codebase, clarifying it when it is sound but too vague to implement and judging whether a feature is worth its permanent cost; then implements it as a tested PR, polishes it to merge-ready and merges it; if it doesn't make sense or isn't worth building, closes the issue with a comment describing exactly why and records the reasoning as a comment in the code when the reason is a durable property of the code. Use when you want an issue handled autonomously from triage to merge, however rough the issue is. Pass the issue number (e.g. "42"). Chains vet -> rewrite-issue (only when vague) -> evaluate-issue (only when it would grow the system) -> generate-pr-from-issue -> polish-pr -> merge.

Work through the repository's open-issue backlog: list the issues that are open right now and hand them one at a time to the resolve-issue skill (vet -> PR -> polish -> merge, or close with a verdict), oldest first, until every one is resolved or a cap is reached. Use when you want the existing backlog cleared autonomously rather than resolving a single issue by number. Optionally pass a max number of issues to resolve (e.g. "3"), default 5. NOTE: merges to main and closes issues without human vetting — use only where that is acceptable.

Review a diff read-only with fresh-context reviewer subagents: report verified findings, fix nothing. Works on a PR (pass the number, e.g. "42") or on the local branch/working-tree diff (pass nothing). Use it for a bug hunt on any diff, before or after opening a PR; polish-pr runs it every round.

Clean up a vague GitHub issue, or split an epic into actionable sub-task issues. Use when an issue needs sharpening before work starts. Pass the issue number (e.g. "42").

Continuously simplify the codebase, one change at a time, with minimal human involvement: propose a simplification issue, ship it as a tested PR, polish it to merge-ready, merge it, then re-analyze the now-simpler code and repeat. Use for an autonomous cleanup run. Optionally pass a max number of iterations and/or an area (e.g. "5 src/ui"). Chains propose-issues -> resolve-issue (vet -> PR -> polish -> merge, or close with a verdict), in a loop. NOTE: merges to main and closes issues without human vetting of each idea or PR — use only where that is acceptable.

Scan the codebase and bring the project docs (README.md, plus any feature docs such as docs/features.md and ARCHITECTURE.md where present) back in sync with how the code actually behaves and is set up. Use when docs have drifted, or as a deliberate "refresh the docs" pass. Optionally pass an area to focus on.