ns-sdd-analyze-consistency について
ns-sdd ワークフローを使うチーム向けの、コーディング前に要件の整合性を確認するスキルです。機能、テスト網羅性、データモデル、API、目的との整合性を検査し、結果を requirements.md に記録します。
主な機能
- 01要件と技術スタックの整理
- 02機能と受け入れ基準の確認
- 03網羅性とデータモデルの問題検出
- 04整合性ステータスの記録
活用シーン
- 01スコープ確定後の要件検証
- 02タスク生成前の要件編集チェック
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/ns-sdd-analyze-consistencyを入力して読み込まれたか確認します。
同梱ファイルevals/evals.json
詳細
整合性の分析
実行前検証：コーディング前に計画と計画を照合します。
ハーネスの検出
../ns-harness/references/harness-discovery.md を参照してください。{harness_root}/rules/*.md からルールを読み込みます。最初に architecture-rules.md を読んでください。レガシーなルールとして、{harness_root} が存在しない場合にのみ .cursor/rules/*.mdc を使用します。
使用するタイミング
- Gate 2（
scope_confirmed）の後 - ユーザーが「要件を分析して」または「整合性を確認して」と依頼したとき
requirements.mdを手動で編集した後
前提条件
{product_root}/docs/versions/{version_san}/requirements.mdが存在すること
ワークフロー
Step 1 — 要件の索引化
requirements.md を読み、以下を索引化します。
- 主な目的
- 機能（タイトル、先行関係、受け入れ基準）
- NFR
- 宣言されたスタック
Step 2 — チェックの実行
各項目を ✅ OK | ⚠️ Warning | ❌ Blocker に分類します。
機能の完全性
| チェック | 失敗レベル |
|---|---|
| すべての機能にタイトル、説明、受け入れ基準がある | ❌ Blocker |
| 各機能に少なくとも2つの受け入れ基準がある | ⚠️ Warning |
| 先行関係に循環がない | ❌ Blocker |
| ルート機能（先行関係なし）が少なくとも1つある | ❌ Blocker |
| E2E が想定されるフロントエンド機能にテスト ID が記載されている | ⚠️ Warning |
テストカバレッジ
| チェック | 失敗レベル |
|---|---|
| バックエンド機能にユニットテストの基準が含まれている | ⚠️ Warning |
| UI 機能に E2E の基準が含まれている | ⚠️ Warning |
| グリーンフィールドではドメインより先にインフラを整備する | ⚠️ Warning |
データモデル
| チェック | 失敗レベル |
|---|---|
| 「Data model and APIs」セクションが明確にある | ❌ Blocker |
| 機能に含まれるすべてのエンティティがデータモデルに記載されている | ❌ Blocker |
| FK の作成順序が守られている | ❌ Blocker |
| フロントエンドでの利用を想定した API エンドポイントが宣言されている | ❌ Blocker |
整合性
| チェック | 失敗レベル |
|---|---|
| 機能が明示された目的を支えている | ⚠️ Warning |
| スコープ外の機能が含まれている | ⚠️ Warning |
ハーネスルールにスタック固有のチェックがある場合は適用します（Laravel/React のチェックは任意です）。
Step 3 — requirements.md にステータスを記載
行わないこと： consistency-report.md を作成しないでください。
requirements.md の末尾に、以下を追加する（または末尾に既存の ## Consistency ブロックがある場合は置き換える）：
## Consistency
**Status:** Approved | Reproved
**Date:** {date}
## Warnings
{Omit this heading when there are no warnings.}
- {warning}
## Recommendations
{Omit this heading when there are no recommendations.}
- {recommendation}
ルール：
- ❌ Blocker が1つでもある場合 →
Status: Reproved - Blocker が0件の場合 →
Status: Approved（警告や推奨事項があっても構いません） - ⚠️ が1つ以上ある場合にのみ Warnings を含める
- 任意の改善点がある場合にのみ Recommendations を含める
- 再実行時は、以前の
## Consistencyブロックを置き換え、重複させない
Step 4 — 次の作業を判断
- Reproved： チャットでユーザーに伝え（Blocker を簡潔に列挙）、停止します。タスク生成には進みません。要件を修正してから再実行するよう依頼します。
- 警告ありで Approved： 結果を伝え、今すぐ修正するか、そのまま進むかを尋ねます。判断はユーザーに委ねます。
- 警告なしで Approved： タスク生成に自動で進むことを伝えます。
execution_confirmedは暗黙的に確定したものとみなし、Gate 3 をスキップします。
重要なルール
requirements.mdの編集は末尾の Consistency ブロックの更新に限定します- 修正または明示的な免除がない限り、Blocker があればタスク生成に進めません
- 要件がない場合は、Gate 1 /
ns-sdd-requirements-generatorに誘導します consistency-report.mdは決して作成しません
統合
Gate 2 → ns-sdd-analyze-consistency → [Approved] → ns-sdd-task-generator
→ [Reproved] → stop; fix requirements
実装後：ns-code-reviewer が要件とコードを照合して検証します。これは補完的なものであり、代替ではありません。