메뉴
Use when the user asks to fix a bug, add behavior, or change behavior in a project that has a test framework, AND the change can be expressed as an observable input/output contract. Writes a failing test first, then makes the smallest change to pass it.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when the user asks to fix a bug, investigate an error, debug a crash, explain a stack trace, or make a failing test pass. Enforces reproduce → isolate → smallest fix → verify, instead of guessing a cause and patching code.
Use when the user asks to review a pull request, review a diff, review changes on a branch, or audit code written by a teammate or AI agent. Reviews the diff (not the summary) for unrelated changes, missing verification, behavior risks, and over-engineering.
Use when the user asks to add a new feature, add a new API/endpoint/page/component, implement a new capability, or extend existing functionality with new behavior. Forces a plan-before-code loop, scoping non-goals, and verifying the new behavior end-to-end.
Use when the user asks to understand, explain, trace, audit, or explore code WITHOUT modifying it. Examples — "how does X work", "where is Y called", "why does this branch exist", "trace the request flow". Stays read-only and does not produce a fix.
Use when a request is large, ambiguous, or spans multiple files/components and the user has NOT yet approved an implementation approach. Produces a verifiable plan via Plan Mode and a TodoWrite breakdown, then hands off to a more specific skill (bug-fix, refactor, feature-add) for execution.
Use when the user asks to refactor, clean up, simplify, modularize, deduplicate, rename, or improve the structure of existing code WITHOUT changing behavior. If the user wants new behavior, do not use this skill. Enforces small reversible steps and behavior preservation.
| name | acp-test-first |
| description | Use when the user asks to fix a bug, add behavior, or change behavior in a project that has a test framework, AND the change can be expressed as an observable input/output contract. Writes a failing test first, then makes the smallest change to pass it. |
| version | 1.0.0 |
Use this skill when the user asks to fix a bug, add behavior, or make a change that can be verified through tests.
The goal is to let tests describe the expected behavior before implementation details are changed.
Use this skill for:
Do not force test-first work when the project has no test framework or when the task is purely exploratory. In that case, document the missing test environment.
Before writing code, write down:
Prefer a test that fails for the right reason.
A good failing test is:
Avoid tests that only verify that a mocked internal function was called unless that is the actual contract.
Change only the code needed to make the test pass.
Do not:
After implementation:
If checks cannot be run, say so clearly.
Expected behavior:
- ...
Failing test:
- ...
Implementation:
- ...
Verified:
- ...
Not verified:
- ...
Do not change the test just to match a wrong implementation.
If the test reveals that the requirement is ambiguous or wrong, stop and ask for clarification.