phmatray

auto-dev

Burn down a GitHub issue backlog hands-off with a FLEET of N parallel workers — each drives one issue through `implement-issue` → `merge-pr`, then takes the next, so N stay in flight. The orchestrator ABOVE those skills: ordering, NON-overlapping areas per worker, CI waits, verified merge state (workers idle at "PR ready" without landing). Triggers: "implement issues small first then medium with 3 agents", "burn down the backlog", "run the auto-dev loop", "spin up a fleet of agents to clear open issues", « vide le backlog avec 3 agents ». Does NOT apply to building ONE issue (implement-issue), landing ONE PR (merge-pr), or filing ONE issue (create-issue).

create-issue

Create a fully-seeded GitHub issue — not a bare `gh issue create`: template-compliant, carrying a brainstorm → spec → implementation-plan trail so a contributor can pick it up cold. ALWAYS reach for this whenever the user wants to open, file, add, raise, log, or track a NEW issue / feature request / idea / ticket / backlog item — "track this idea", "make a ticket", « ouvre une issue pour X », « crée un ticket pour ça », or batches of several ideas at once. Also PLANS AN EXISTING raw issue via `--seed #N` ("give issue 42 a plan"). Does NOT apply to otherwise managing existing issues (commenting, closing, listing), or to standalone brainstorming with no issue to file.

debug-issue

Use the moment a user reports something broken or behaving unexpectedly — a bug, failing or flaky test, crash, exception, stack trace, regression, build break, or integration failure — and use it BEFORE the first command you would run to investigate, not just before the fix. That first look is where the symptom gets patched and the cause survives. It applies even when the report is thin ("this stack trace", "the deploy fails") and even when the next step seems obvious: gathering what is missing is the skill's own first step. Triggers on "fix it", "patch it", "find out why", "get to the bottom of it", « ce test est flaky, corrige-le », « ça marchait avant, maintenant ça plante ». Not for new code, features, error handling, refactoring code that works, CI/tooling setup, or reviewing code that already works.

deliver-issue

Take ONE idea or ONE planned issue all the way to a merged PR, hands-off — file or seed it with create-issue, build it with implement-issue, land it with merge-pr, each phase in a FRESH sub-agent context. Use when the user wants the whole chain run for a single item: "deliver issue 47 end to end", "take this idea to a merged PR", "run the full lifecycle on #12", « livre l'issue 47 de bout en bout », « de l'idée à la PR mergée ». `--stop-at ready` stops before the merge. Does NOT apply to many issues at once (auto-dev), to landing a PR that is already open (merge-pr), to only filing an issue (create-issue), or to building one you will merge yourself (implement-issue).

implement-issue

Turn an existing GitHub issue into a finished pull request — the actual coding. Use when an issue carries a `🛠️ Implementation plan` checklist and the user wants it BUILT: worktree, draft PR, task-by-task commits ticked on the live issue, review, ready-flip. Triggers: "implement issue 47", "knock out the tasks on issue 71", "execute the plan", "resume issue #X", « implémente l'issue 47 », « exécute le plan de l'issue », a bare issue link with "go build it" — including keeping the IN-FLIGHT PR mergeable (sync/conflicts with `main`) while it is still being built. Does NOT apply to planning a NEW issue (create-issue), landing a finished PR (merge-pr), or ad-hoc coding with no plan.

merge-pr

Land an open GitHub pull request. Use whenever the user wants to MERGE, land, ship, or close out an open PR: waits for CI, applies corrections until mergeable (red checks, conflicts with the latest `main`, unresolved review), squash-merges, triages follow-ups, and tears down the branch and worktree. Triggers: "merge PR 279", "land #281", "ship this PR", "get that PR merged once CI's green", "wrap up 279 and open follow-ups", « merge la PR 279 », « fais atterrir la 281 », a bare PR link with "merge it". Does NOT apply to opening or implementing a PR, to syncing one STILL BEING BUILT (implement-issue), to reviewing without merging (code-review), or to filing an issue (create-issue).

review-followups

Consolide et met à jour les suivis ouverts des migrations (next_steps/deferred des migration/report.json + backlog du kit). Use whenever the user asks what remains open across migrated repos, wants a status of pending decisions, says a follow-up item is done, or decides to close/abandon one — triggers on « fais le point », « qu'est-ce qui reste », « suivis », « c'est fait, coche-le », « on ne le fera pas », "what's still open", "status of the follow-ups", "next steps", "mark it done", "we won't do that one", /migrate-followups. Also run it at the end of every migration (phase 7).

review-sessions

Read the transcripts of PREVIOUS sessions and pull out the failures the kit itself caused — errors on kit scripts, gate denials, workers that died waiting, red kit suites — then cluster them by root cause, drop what main already fixed, and file what earns an issue through create-issue. Use when the user asks what went wrong in past runs: "review my previous sessions", "what went wrong in my last runs", "learn from the transcripts", « analyse mes sessions précédentes », « qu'est-ce qui a foiré dans mes dernières sessions ». `--dry-run` lists without filing. Does NOT apply to reviewing a diff (code-review), pruning open issues (triage-backlog), migration follow-ups (review-followups), or one live failure (debug-issue).

triage-backlog

Prune and re-decide an EXISTING GitHub issue backlog: verifies which open issues are already fixed or superseded, clusters the rest by root cause, proposes ONE disposition each and executes only what the owner confirms. ALWAYS reach for this when the user wants to prune, triage, groom, re-decide, or take stock of open issues, or says the queue never shrinks: "triage the backlog", "clean up the open issues", "what should we close?", « fais le tri dans les issues », « le backlog ne descend jamais ». Does NOT apply to filing a NEW issue (create-issue), building one (implement-issue), landing a PR (merge-pr), or migration follow-ups in report.json (review-followups).

migrate-legacy

Use when upgrading, migrating, or modernizing a legacy application — outdated target framework, out-of-support runtime, obsolete APIs, old packages, or legacy idioms. Triggers on "upgrade this app", "migrate to .NET 10", "modernize this codebase", "this project targets an old framework", « mets à niveau cette app », « migre vers .NET 10 », « modernise ce code legacy », /migrate, /migrate-assess, /migrate-verify. Drives a seven-phase, gate-verified pipeline (assessment → verified production) in which RoselineMCP performs all C# analysis and transformation.

profile-repo

Generate or load the per-repo profile (`.claude/skills/repo-profile.md`) that `create-issue`, `implement-issue` and `merge-pr` READ for the repo facts they would otherwise hardcode — commit identity, build/test/format commands, labels, merge style, conflict hot-spots. Use when no profile exists, to PORT those skills to another repository, or to refresh after the toolchain, labels or CI changed: "set up the repo profile", "configure this repo for the issue skills", "make these skills work in my other repo", "regenerate the profile", « configure le profil du repo », « fais marcher create-issue dans ce repo ». Does NOT file issues, implement code, merge PRs, or WRITE labels/templates/settings (setup-repo).

setup-repo

Bring a GitHub repository to the configuration the issue/PR lifecycle skills assume — label taxonomy, issue forms under .github/ISSUE_TEMPLATE/, repository settings (delete-branch-on-merge, squash-only merges, description, homepage), topics and the GitHub Pages source — deterministic and idempotent: `plan` prints drift, `apply` converges it. Use when a repo needs configuring or has drifted: "set up the labels", "create the issue templates", "set the repo description and topics", "enable GitHub Pages from docs/", "configure this repository the way the kit expects", « configure les labels du repo », « active GitHub Pages ». It WRITES what profile-repo only READS. Does NOT file issues, implement code, or merge PRs.