Claude Skills by phmatray

Every lifecycle skill needs the same repo-specific facts — commit identity, build and test commands, the label taxonomy, the CI gates, the conflict hot-spots — and hardcoding them made each skill wrong in a second repository. The obvious home in a Claude Code plugin is another skill, since skills are what the loader already knows how to find. (Context lifted from `skills/profile-repo/SKILL.md`, "The profile is data, not a skill"; the committed-file half is #157.)

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 o...

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...

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 missi...

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...

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 P...

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 "...

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) i...

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 m...

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...

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é...

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 GitHu...

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 jama...