メニュー
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
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/SebastienDegodez/copilot-instructions --skill gherkin-gateコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| 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 |