メニュー
"Use when validating requirements against EARS notation patterns. Triggers on "EARS", "requirement review", "requirement quality", "shall statement", "REQ-ID"."
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
"Use when mapping business capabilities, identifying overlap or gaps across the enterprise, or aligning IT investments to business outcomes. Triggers on "capability map", "business capability", "domain map", "enterprise architecture"."
"Use when drafting Architecture Decision Records, evaluating alternatives, or documenting technical trade-offs. Triggers on "ADR", "architecture decision", "trade-off", "pick between", "why did we choose"."
"Use when a new engineer joins the team, when onboarding to an unfamiliar codebase, or when auditing whether the team has shared understanding. Triggers on "onboard", "context", "knowledge gap", "bus factor", "team understanding"."
Use when refactoring legacy code, extracting a service, or making behavior-preserving changes. Triggers on 'refactor', 'legacy code', 'strangler fig', 'characterization test', 'mikado method'.
Use when practicing test-driven development, writing a failing test first, or coaching red-green-refactor. Triggers on 'TDD', 'red-green-refactor', 'test first', 'failing test', 'write a test'.
Use when investigating slow queries, designing indexes, or reviewing execution plans. Triggers on 'slow query', 'explain plan', 'index', 'query tuning', 'N+1', 'table scan'.
SOC 職業分類に基づく
| name | EARS Validation |
| description | "Use when validating requirements against EARS notation patterns. Triggers on "EARS", "requirement review", "requirement quality", "shall statement", "REQ-ID"." |
| Pattern | Template |
|---|---|
| Ubiquitous | The <system> shall <response>. |
| Event-driven | When <trigger>, the <system> shall <response>. |
| State-driven | While <state>, the <system> shall <response>. |
| Optional | Where <feature is included>, the <system> shall <response>. |
| Unwanted | If <unwanted condition>, then the <system> shall <mitigation>. |
| Complex | While <state>, when <trigger>, the <system> shall <response>. |
REQ-NNN.source_legacy: pointing to legacy/natural-programs/*.NSN, legacy/adabas-ddms/*.ddm, or [GREENFIELD] + justification.| Defect | Example | Fix |
|---|---|---|
| Ambiguous | "The system should be fast." | "When a user submits a form, the system shall respond within 500ms." |
| Compound | "Login and send email." | Split into two requirements. |
| Untestable | "The system shall be user-friendly." | Replace with measurable UX metric. |
| Passive | "Login shall be supported." | "The system shall accept username/password authentication." |
### REQ-NNN (<pattern>)
<EARS statement>
**source_legacy**: legacy/natural-programs/<FILE>.NSN#L<start>-L<end>
_(or `[GREENFIELD] <justification>` when no legacy parallel)_
**Acceptance criteria**
- <criterion 1>
- <criterion 2>
**Traces from**: US-NNN, ADR-NNN
**Priority**: P0 / P1 / P2
**Status**: proposed / approved / implemented / verified
Reject any requirement missing REQ-ID, pattern classification, acceptance criteria, or source_legacy. The CI legacy-traceability job in .github/workflows/spec-quality.yml enforces this on every PR.