원클릭으로
debug-failing-test
Systematic process for diagnosing and fixing a failing test
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Systematic process for diagnosing and fixing a failing test
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
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.