Menu
Systematic process for diagnosing and fixing a failing test
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Transform a plan (from session memory, a markdown file, or inline description) into agent-executable tasks in docs/IMPLEMENTATION.md following the project's established format. Use when the user says "add to implementation", "convert plan to tasks", "create tasks from this plan", "add a phase", or similar.
Check a PR for unresolved review comments, assess each one, apply fixes where needed, and resolve addressed threads via the GitHub API. Use this skill whenever the user mentions PR comments, review threads, unresolved feedback, or addressing reviewer suggestions — even if they just say "fix the comments", "close out the review threads", or "address the feedback".
Perform a thorough, project-aware code review on the current PR and post it to GitHub as a real review with inline comments via the GitHub API. Use this skill whenever the user says "review", "review this PR", "review my changes", "do a code review", "give me feedback on this branch", or "check my PR" — especially when working in a git worktree. Trigger even if the user just says "review" with no other context.
Implements a project task from docs/IMPLEMENTATION.md when the user says "implement task X.XX" (e.g. "implement task 1.11", "implement task 2.02"). Reads the task spec, sets up a git worktree on the correct branch, then implements the task end-to-end following project conventions. Use this skill whenever the user says "implement task", "do task", "work on task", or references a task ID like "1.07", "2.03", etc. in this project.
Process for safely adding or updating npm dependencies
Template and rules for writing PR descriptions
| name | debug-failing-test |
| description | Systematic process for diagnosing and fixing a failing test |
| disable-model-invocation | true |
Follow this order before changing any application code:
Reproduce in isolation Run only the failing test and confirm it fails reliably (not intermittently).
Read the full error output Do not skim — read the assertion failure, the stack trace, and any stderr output. Note the exact line number in the test and in the source.
Check for environment issues
.env.test?Trace the failure
Add a single console.log at the point of failure to inspect the actual value.
Do not add multiple logs at once — add one, run, interpret, then add the next.
Identify the root cause Is the test wrong (wrong expectation), the fixture wrong (bad test data), or the code wrong? Fix the right thing — do not change a test expectation just to make it pass.
Verify the fix Run the full test suite after fixing. If the fix touches shared utilities, check for regressions in related tests.