메뉴
Use before writing any test or implementation task, when observable behavior needs to be captured in business language scenarios and approved by the user before code begins
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when implementing any feature or fix using TDD, before writing any implementation code
Use when domain logic leaks into API/Infrastructure, project references violate layer boundaries, or you need to decide between CQS (always), CQRS bus (complex domains), and DDD patterns (invariants and events).
Use when configuring Git hooks in .NET projects before team commits occur, to enforce commit message standards and code formatting automatically
Use when running mutation testing, killing mutants, verifying test quality, checking mutation score, or analyzing survivors after the test baseline is green
Use when writing tests from the outside-in, defining behavior before code, or any feature where tests should start from observable business behavior and let internal design emerge
Use when understanding project composition by language, measuring code change impact, or generating code statistics for CI/CD metrics
| name | gherkin-gate |
| description | Use before writing any test or implementation task, when observable behavior needs to be captured in business language scenarios and approved by the user before code begins |
Capture observable behavior in business language before any test or code is written. User approval is the mandatory gate.
Hard rule: No test, no task, no implementation until scenarios are approved.
Write 1-3 scenarios in Given/When/Then:
GIVEN [precondition in business language].
WHEN [action in business language].
THEN [observable outcome in business language].
Each scenario should be independent and verifiable in isolation. Cover the main success path and 1-2 key edge cases.
Scenarios must describe external observables only. Never reference implementation details:
| Forbidden | Allowed |
|---|---|
| Class names, method names | Business actions and actors |
| Repository, database, tables | Data in business terms |
| HTTP endpoints, status codes | Business outcomes |
| Internal state, variables | Observable system behavior |
❌ BAD: GIVEN the EligibilityPolicy has empty rules.
✅ GOOD: GIVEN no eligibility rules are configured.
❌ BAD: THEN the handler returns a 200 OK response.
✅ GOOD: THEN the request is accepted.
❌ BAD: WHEN I call POST /api/eligibility.
✅ GOOD: WHEN checking eligibility for the user.
This gate is not skippable — even for "small" features.
| Mistake | Fix |
|---|---|
| Skipping scenarios for "trivial" features | Write 1 scenario minimum — even simple features benefit |
| Implementation details in scenarios | Business language only in Given/When/Then |
| Proceeding before explicit approval | "ok" or "proceed" counts, silence does not |
| More than 3 scenarios up front | Start with main success path, add edge cases after RED |