mcpField
D
doc-req

doc-req

github.com/vladm3105開発1753 回インストール1 日前に更新
リポジトリ

doc-req について

doc-req は、SDD ワークフローの第 7 層で、システム要件を REQ v3.0 形式の実装可能なアトミック要件に分解するスキルです。上流成果物の確認、累積トレーサビリティタグ、二種類の準備度スコアを重視し、後続の実装や仕様作成につなげます。

主な機能

  1. 01システム要件をアトミック要件に分解
  2. 02REQ v3.0 に沿って文書を構成
  3. 03上流成果物を確認し追跡タグを追加
  4. 04SPEC と IMPL の準備度を算出
  5. 05ID、閾値、フォルダー規則に準拠

活用シーン

  1. 01SYS 完了後に実装向け要件を準備
  2. 02要件に出典と追跡関係を付与
  3. 03REQ が層移行の準備度基準を満たすか確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/vladm3105/aidoc-flow-framework --skill doc-req

インストール後、Claude Code で/doc-reqを入力して読み込まれたか確認します。

詳細

doc-req

目的

**Atomic Requirements（REQ）**ドキュメントを作成します。SDD ワークフローのレイヤー 7 の成果物であり、システム要件を REQ v3.0 形式の、実装可能なアトミック要件に分解します。

レイヤー：7

上流：BRD（レイヤー 1）、PRD（レイヤー 2）、EARS（レイヤー 3）、BDD（レイヤー 4）、ADR（レイヤー 5）、SYS（レイヤー 6）

下流の成果物：IMPL（レイヤー 8）、CTR（レイヤー 9）、SPEC（レイヤー 10）、Code（レイヤー 13）

前提条件

上流成果物の確認（重要）

このドキュメントを作成する前に、必ず次を実施してください。

  1. 既存の上流成果物を一覧表示します。

    ls docs/01_BRD/ docs/02_PRD/ docs/03_EARS/ docs/04_BDD/ docs/05_ADR/ docs/06_SYS/ docs/07_REQ/ 2>/dev/null

  2. トレーサビリティタグでは、既存のドキュメントのみを参照します。

  3. 上流成果物の種類が実際に存在しない場合に限り、null を使用します。

  4. BRD-XXX や TBD などのプレースホルダーは絶対に使用しないでください。

  5. 不足している上流成果物は作成しないでください。該当する機能をスキップします。

REQ を作成する前に、次を読みます。

  1. 共有標準：.claude/skills/doc-flow/SHARED_CONTENT.md
  2. 上流 SYS：この REQ の基盤となるシステム要件を読みます。
  3. テンプレート：ai_dev_ssd_flow/07_REQ/REQ-MVP-TEMPLATE.md
  4. 作成ルール：ai_dev_ssd_flow/07_REQ/REQ-MVP-TEMPLATE.md
  5. 検証ルール：ai_dev_ssd_flow/07_REQ/REQ_MVP_SCHEMA.yaml
  6. 品質ゲート検証：ai_dev_ssd_flow/07_REQ/REQ_MVP_QUALITY_GATE_VALIDATION.md
  7. 検証スクリプト：./ai_dev_ssd_flow/07_REQ/scripts/validate_req_template.sh

このスキルを使用するタイミング

次の場合に doc-req を使用します。

  • BRD から SYS まで（レイヤー 1～6）を完了している
  • システム要件をアトミックな単位に分解する必要がある
  • 実装（レイヤー 8 以降）の準備をしている
  • SPEC 準備度スコア 90% 以上を達成する
  • SDD ワークフローのレイヤー 7 にいる

予約 ID の適用除外（REQ-00_*）

対象範囲：予約 ID 000 のドキュメントは、検証の完全な適用除外となります。

パターン：REQ-00_*.md

ドキュメントの種類：

  • インデックスドキュメント（REQ-00_index.md）
  • トレーサビリティマトリックスのテンプレート（REQ-00_TRACEABILITY_MATRIX-TEMPLATE.md）
  • 用語集、レジストリ、チェックリスト

理由：予約 ID 000 のドキュメントはフレームワークのインフラストラクチャであり、トレーサビリティや品質ゲートを必要とするプロジェクト成果物ではありません。

検証時の動作：ファイル名が REQ-00_* パターンに一致する場合、すべてのチェックをスキップします。

REQ 固有のガイダンス

1. REQ MVP 形式（必須セクション 11 項目）

重要：REQ MVP では、簡潔な 11 セクション構成を使用します。

ドキュメント管理（必須。番号付きセクションより前の最初のセクション）

コアセクション：

  1. 説明：アトミック要件 + SHALL/SHOULD/MAY の表現 + コンテキスト + シナリオ
  2. 機能要件：主要な機能 + ビジネスルール
  3. インターフェース仕様：プロトコル／ABC 定義 + DTO + REST エンドポイント
  4. データスキーマ：JSON Schema + Pydantic モデル + データベーススキーマ
  5. エラー処理仕様：例外カタログ + エラーレスポンススキーマ + サーキットブレーカー設定
  6. 設定仕様：YAML スキーマ + 環境変数 + 検証
  7. 品質属性：パフォーマンス目標（p50/p95/p99）+ 信頼性／セキュリティ／スケーラビリティ
  8. 実装ガイダンス：アルゴリズム／パターン + 並行処理／非同期処理 + 依存性注入
  9. 受け入れ基準：機能／エラー／品質／データ／統合を網羅した、測定可能な基準 15 項目以上
  10. 検証方法：BDD シナリオ + 単体／統合／コントラクト／パフォーマンステスト
  11. トレーサビリティ：累積タグを含むセクション 7 の形式（必須タグ 6 個）

注：変更履歴は意図的に REQ MVP から省略されています。

2. ドキュメント管理の必須要件（必須フィールド11項目）
フィールド形式例
ステータス承認済み／レビュー中／ドラフトApproved
バージョンセマンティック X.Y.Z2.0.1
作成日ISO 86012025-11-18
最終更新日ISO 86012025-11-19
作成者名前／役割System Architect
優先度レベル（Pレベル）High (P2)
カテゴリ種類Functional
ソースドキュメントDOC-ID セクション X.Y.ZSYS-02 section 3.1.1
検証方法方法の種類BDD + Integration Test
担当チームチーム名IB Integration Team
SPEC-Ready スコア絵文字を含む形式>=90% (Target: >=90%)
IMPL-Ready スコア絵文字を含む形式>=90% (Target: >=90%)
テンプレートバージョン3.0 必須3.0
3. 2種類のレディネススコア（SPEC-Ready + IMPL-Ready）

必須：各 REQ で両方のスコアを算出すること

SPEC-Ready スコアの計算式：

SPEC-Ready Score = (Completed Sections / 12) * 100%

IMPL-Ready スコア：実装アプローチのドキュメント化に向けた準備度を測定します

品質ゲート：レイヤーを移行するには、両方のスコアが >=90% である必要があります

ステータスとレディスコアの対応関係：

レディスコア必須ステータス
>= 90%Approved
70-89%In Review
< 70%Draft

注：スコアが2種類ある REQ ドキュメントでは、低い方のスコアを使ってステータスを決定してください。

例：

## Readiness Scores

**SPEC-Ready Score**: >=95% (Target: >=90%)
**IMPL-Ready Score**: >=92% (Target: >=90%)

**Section Status**:
- [x] 1. Description
- [x] 2. Functional Requirements
- [x] 3. Interface Specifications
- [x] 4. Data Schemas
- [x] 5. Error Handling Specifications
- [x] 6. Configuration Specifications
- [x] 7. Quality Attributes
- [x] 8. Implementation Guidance
- [x] 9. Acceptance Criteria
- [x] 10. Verification Methods
- [x] 11. Traceability
- [ ] 12. Change History (In Progress)

**Readiness**: READY for SPEC/IMPL creation
4. 要素 ID の形式（必須）

パターン：REQ.{DOC_NUM}.{HASH}（3つのセグメントをドットで区切る）

要素の種類コード例
機能要件01REQ.02.0101
依存関係05REQ.02.0501
受け入れ基準06REQ.02.0601
アトミック要件27REQ.02.2701

廃止されたパターン - 使用しないでください：

  • AC-XXX - REQ.NN.06.SS を使用
  • FR-XXX - REQ.NN.01.SS を使用
  • R-XXX - REQ.NN.27.SS を使用
  • REQ-XXX - REQ.NN.27.SS を使用

参照：ID_NAMING_STANDARDS.md - 相互参照リンク形式

5. アトミック要件の原則
  • 単一責任：各 REQ で定義する要件は1つのみです
  • 測定可能：受け入れ基準により、真偽の結果が得られます
  • 自己完結型：外部コンテキストがなくても理解できます
  • SPEC-Ready：SPEC の自動生成に必要な情報をすべて含みます（完全性 >=90%）
  • 法助動詞：SHALL（絶対要件）、SHOULD（推奨）、MAY（任意）
6. ドメイン／サブドメインの構成

場所：プロジェクトのドキュメントディレクトリ内の REQ/{domain}/{subdomain}/

ドメイン：api/（外部連携）、risk/（リスク管理）、data/（データ要件）、ml/（ML 要件）、auth/（セキュリティ）など

形式：REQ-NN_descriptive_slug.md

例：REQ-risk-limits-01_position_validation.md

タグ形式の規約（設計によるもの）

SDD フレームワークでは、相互参照に2種類の異なる表記体系を使用します：

表記形式成果物用途
ハイフンTYPE-NNADR、SPEC、CTR技術成果物 - ファイル／ドキュメントへの参照
ドットTYPE.NN.xxxxBRD、PRD、EARS、BDD、SYS、REQ、IMPL、TASKS階層型成果物 - ドキュメント内の要素への参照

主な違い：

  • @adr: ADR-033 -> ドキュメント ADR-033_risk_limit_enforcement.md を指します
  • @brd: BRD.17.0103 -> ドキュメント BRD-017.md 内の要素 01.03 を指します

累積タグ付け要件

レイヤー 7（REQ）：レイヤー 1〜6（BRD、PRD、EARS、BDD、ADR、SYS）のタグを含める必要があります

タグ数：6 個のタグ（@brd、@prd、@ears、@bdd、@adr、@sys）

形式：

## Traceability

**Required Tags** (Cumulative Tagging Hierarchy - Layer 7):
```markdown
@brd: BRD.01.0103
@prd: PRD.01.0702
@ears: EARS.01.2501
@bdd: BDD.01.1401
@adr: ADR-033, ADR-045
@sys: SYS.01.0101, SYS.01.0207

上流ソース：

下流成果物：

  • IMPL-NN（作成予定） - 実装アプローチ
  • CTR-NN（作成予定） - データコントラクト
  • SPEC-NN（作成予定） - 技術仕様

**Element Type Codes for Tags**:
- EARS: Type 25 (formal requirement)
- BDD: Type 14 (scenario)
- SYS: Type 01 (functional), 02 (quality attribute), 26 (system req)

## Threshold Registry Integration

**Purpose**: Prevent magic numbers by referencing centralized threshold registry.

### When @threshold Tag is Required

Use `@threshold` for ALL quantitative values that are:
- Business-critical (compliance limits, SLAs)
- Configurable (timeout values, rate limits, retry policies)
- Shared across documents (performance targets)
- Quality attribute-related (p50/p95/p99 latencies, throughput limits)
- Error handling configurations (circuit breaker, retry counts)

### @threshold Tag Format

```markdown
@threshold: PRD.NN.category.subcategory.key

例：

  • @threshold: PRD.035.perf.api.p95_latency
  • @threshold: PRD.035.timeout.circuit_breaker.threshold
  • @threshold: PRD.035.retry.max_attempts
  • @threshold: PRD.035.limit.api.requests_per_second
REQ 固有のしきい値カテゴリ
カテゴリREQ での用途キーの例
perf.*パフォーマンス受け入れ基準perf.api.p95_latency
timeout.*サーキットブレーカー、接続設定timeout.circuit_breaker.reset
retry.*再試行ポリシーの設定retry.max_attempts
limit.*レート制限、リソース制限limit.api.requests_per_second
resource.*メモリ、CPU の制約resource.memory.max_heap
マジックナンバーの検出

無効（ハードコードされた値）：

  • p95 response time: 200ms
  • max_retries: 3
  • rate_limit: 100 req/s

有効（レジストリ参照）：

  • p95 response time: @threshold: PRD.NN.perf.api.p95_latency
  • max_retries: @threshold: PRD.NN.retry.max_attempts
  • rate_limit: @threshold: PRD.NN.limit.api.requests_per_second

上流／下流成果物

上流ソース：

  • BRD（レイヤー 1） - ビジネス要件
  • PRD（レイヤー 2） - 製品機能
  • EARS（レイヤー 3） - 形式的な要件
  • BDD（レイヤー 4） - テストシナリオ
  • ADR（レイヤー 5） - アーキテクチャ上の決定
  • SYS（レイヤー 6） - システム要件（主要なソース）

下流成果物：

  • IMPL（レイヤー 8） - 実装アプローチ（任意）
  • CTR（レイヤー 9） - データコントラクト（任意）
  • SPEC（レイヤー 10） - 技術仕様
  • コード（レイヤー 13） - 実装

同種ドキュメント間の関係（条件付き）：

  • @related-req: REQ-NN - ドメインコンテキストを共有する REQ
  • @depends-req: REQ-NN - 先に実装する必要がある REQ

作成プロセス

ステップ 1：上流成果物を読む

分解対象であるシステム要件、特に SYS（レイヤー 6）に注目します。

ステップ 2：ID 番号を確保する

docs/07_REQ/ を確認し、次に利用可能な ID 番号を調べます。

ID 番号の付与規則：2 桁から始め、必要な場合にのみ桁数を増やします。

  • ✅ 正しい：REQ-01、REQ-99、REQ-102
  • ❌ 誤り：REQ-001、REQ-009（余分な先頭のゼロは不要です）

ドメインベースの命名：REQ-domain-subdomain-NN

ステップ 3：REQ ファイルを作成する

ネストしたフォルダーの規則（必須）：ドキュメントのサイズにかかわらず、すべての REQ ドキュメントでネストしたフォルダーを使用する必要があります。

保存場所の選択肢：

  • 標準：docs/07_REQ/REQ-NN_{slug}/REQ-NN_{slug}.md
  • ドメインベース：docs/07_REQ/{domain}/REQ-NN_{slug}/REQ-NN_{slug}.md
  • サブドメイン：docs/07_REQ/{domain}/{subdomain}/REQ-NN_{slug}/REQ-NN_{slug}.md

必要に応じたフォルダーの作成：ドキュメントを保存する前に、保存先ディレクトリを作成します。

# Create target directory (ALWAYS use nested folder)
mkdir -p docs/07_REQ/REQ-NN_{slug}/
# OR for domain-based structure
mkdir -p docs/07_REQ/{domain}/REQ-NN_{slug}/

重要：ネストしたフォルダー構造を使わずに、docs/07_REQ/ 直下へ REQ ファイルを作成しないでください。

ドメインの選択：プロジェクト設定または上流の SYS コンテキストからドメインを選択します。

  • 金融：risk/、trading/、collection/、compliance/、ml/
  • SaaS：tenant/、subscription/、billing/、workspace/
  • 汎用：api/、auth/、data/、core/、integration/

セクションファイル：大規模な要件（>50KB）では、セクションファイル形式 REQ-NN.S_section_title.md（S = セクション番号）を使用します。

ステップ 4：文書管理セクションを記入する

11 個の必須フィールドすべてと文書改訂履歴テーブルを含めて、メタデータを完成させます。

ステップ 5：11 個の必須セクションすべてを完成させる

重要：REQ MVP では、SPEC-Ready の準備率 90% 以上を達成するために、11 個すべてのセクションが必要です。

  1. 説明：アトミックな要件と SHALL／SHOULD／MAY の表現
  2. 機能要件：主要な機能とビジネスルール
  3. インターフェース仕様：API、エンドポイント、コントラクト、Protocol／ABC クラス
  4. データスキーマ：モデル、検証、制約、Pydantic／dataclass
  5. エラー処理仕様：エラーコード、復旧、例外定義
  6. 設定仕様：設定、フィーチャーフラグ、YAML 設定
  7. 品質特性：しきい値を含むパフォーマンス、セキュリティ、スケーラビリティ
  8. 実装ガイダンス：技術的アプローチ、パターン
  9. 受け入れ基準：測定可能な基準 15 個以上
  10. 検証方法：BDD シナリオ、テスト
  11. トレーサビリティ：累積タグ（6 個）

注：変更履歴は REQ MVP では意図的に省略されています。

ステップ 6：準備状況のスコアを計算する

完了したセクション数を数え、SPEC-Ready と IMPL-Ready の両方の割合を計算します。

品質ゲート：両方のスコアが 90% 以上である必要があります。

ステップ 7：累積タグを追加する

上流のタグ 6 個すべて（@brd から @sys まで）を含めます。

ステップ 8：トレーサビリティマトリックスを作成／更新する

必須：ai_dev_ssd_flow/07_REQ/REQ-00_TRACEABILITY_MATRIX-TEMPLATE.md を更新します。

ステップ 9：REQ を検証する
./ai_dev_ssd_flow/07_REQ/scripts/validate_req_template.sh docs/07_REQ/REQ-NN_*/REQ-NN_*.md

python ai_dev_ssd_flow/scripts/validate_tags_against_docs.py --artifact REQ-NN --expected-layers brd,prd,ears,bdd,adr,sys --strict
ステップ 10：変更をコミットする

REQ ファイルとトレーサビリティマトリックスをコミットします。

検証

検証チェック（全 20 項目）
チェック説明種類
CHECK 1必須の 11 セクションエラー
CHECK 2文書管理（11 フィールド）エラー
CHECK 3トレーサビリティ構造エラー／警告
CHECK 4レガシー（非推奨）情報
CHECK 5バージョン形式（X.Y.Z）エラー
CHECK 6日付形式（ISO 8601）エラー
CHECK 7優先度形式（P1-P4）警告
CHECK 8ソース文書の形式警告
CHECK 9SPEC-Ready スコアエラー／警告
CHECK 10テンプレートバージョン（3.0）エラー
CHECK 11変更履歴エラー／警告
CHECK 12ファイル名／ID 形式エラー
CHECK 13リソースタグ（テンプレート 2.0）エラー
CHECK 14累積タグ付け（6 個のタグ）エラー
CHECK 15上流チェーンの完全性エラー
CHECK 16リンク解決エラー／警告
CHECK 17トレーサビリティマトリックス警告
CHECK 18SPEC-Ready の内容警告
CHECK 19IMPL-Ready スコアエラー
CHECK 20要素 ID 形式への準拠エラー
検証ティア
ティア種類終了コード説明
ティア 1エラー1ブロッキング。コミット前に修正が必要です
ティア 2警告0品質上の問題。修正を推奨します
ティア 3情報0情報提供のみ。対応は不要です
コミット前フック

REQ の検証は、コミット前フックによって自動的に強制されます。

- id: req-core-validator
  name: Validate REQ core checks (validator, framework library)
  entry: bash ai_dev_ssd_flow/07_REQ/scripts/req_core_validator_hook.sh
  stages: [pre-commit]

- id: req-quality-gate
  name: Validate REQ quality gates
  entry: bash ai_dev_ssd_flow/07_REQ/scripts/req_quality_gate_hook.sh
  stages: [pre-commit]

- id: req-spec-ready-score
  name: Validate REQ SPEC-Ready score (≥90%)
  entry: bash ai_dev_ssd_flow/07_REQ/scripts/req_spec_ready_score_hook.sh
  stages: [pre-commit]

手動実行（コミットせずにテストする場合）：

pre-commit run req-core-validator --all-files
pre-commit run req-quality-gate --all-files
pre-commit run req-spec-ready-score --all-files

適用される品質ゲート：

  • ✅ REQ 構造への準拠（MVP の 11 セクション）
  • ✅ Approved ステータスでは SPEC-Ready スコアが 90% 以上
  • ✅ メタデータとタグ（req、layer-7-artifact）
  • ✅ 上流のトレーサビリティ（@brd、@prd、@ears、@bdd、@adr、@sys — 6 個のタグ）
  • ✅ 承認済み文書にプレースホルダーテキストがないこと
  • ✅ アトミックな要件（単一責任）
  • ✅ 測定可能な受け入れ基準（15 個以上）
  • ✅ Protocol／ABC クラスを含むインターフェース仕様
  • ✅ データスキーマ（Pydantic／JSON Schema）
  • ✅ エラー処理仕様
  • ✅ 設定仕様（YAML スキーマ）
  • ✅ @threshold タグを含む品質特性
  • ✅ 関連する REQ 間の相互リンク
自動検証
# Validate single file
./ai_dev_ssd_flow/07_REQ/scripts/validate_req_template.sh docs/07_REQ/REQ-NN_slug/REQ-NN_slug.md

# Validate all REQ files
find docs/07_REQ -name "REQ-*.md" -exec ./ai_dev_ssd_flow/07_REQ/scripts/validate_req_template.sh {} \;

# Cumulative tagging validation
python ai_dev_ssd_flow/scripts/validate_tags_against_docs.py \
  --artifact REQ-NN \
  --expected-layers brd,prd,ears,bdd,adr,sys \
  --strict
手動チェックリスト
  • 冒頭に必須フィールド11項目を含むドキュメント管理セクションがある
  • 必須セクション11項目すべてが完成している
  • SPEC-Ready スコア >=90%
  • IMPL-Ready スコア >=90%
  • Template Version = 3.0
  • セクション3：Protocol/ABC クラスを含むインターフェース仕様
  • セクション4：Pydantic/dataclass モデルを含むデータスキーマ
  • セクション5：例外定義を含むエラー処理
  • セクション6：YAML スキーマを含む構成
  • セクション7：@threshold 参照を含む品質属性
  • セクション9：受け入れ基準が15項目以上
  • 累積タグ：@brd から @sys まで（6タグ）が含まれている
  • 各要件がアトミックである（単一の責任）
  • 受け入れ基準がテスト可能で測定可能である
  • トレーサビリティマトリクスが更新されている
図の規約

すべての図で Mermaid 構文を使用する必要があります。テキストベースの図（ASCII アート、罫線文字）は禁止です。 参照：ai_dev_ssd_flow/DIAGRAM_STANDARDS.md および mermaid-gen スキル。

よくある落とし穴

  1. セクションの未完成：SPEC-Ready には11セクションすべてが必須です
  2. 新規セクションの欠落：セクション3～7は v3.0 で新設されています。省略しないでください
  3. 準備状況スコアの不足：SPEC-Ready と IMPL-Ready の両方で >=90% を達成する必要があります
  4. 非アトミックな要件：各 REQ は単一のテスト可能な単位である必要があります
  5. 累積タグの欠落：レイヤー7には上流のタグを6つすべて含める必要があります
  6. 曖昧な受け入れ基準：測定可能かつテスト可能である必要があります
  7. ハードコード値：マジックナンバーではなく、@threshold 参照を使用してください
  8. レガシーの要素 ID：AC-XXX や FR-XXX ではなく、REQ.NN.xxxx 形式を使用してください
  9. ステータスとスコアの不一致：ステータスは2つのスコアの低い方に合わせる必要があります

作成後の検証（必須 - 確認不要）

重要：ドキュメントの作成直後に、この検証ループをただちに実行してください。

自動検証ループ
LOOP:
  1. Run: python scripts/validate_cross_document.py --document {doc_path} --auto-fix
  2. IF errors fixed: GOTO LOOP (re-validate)
  3. IF warnings fixed: GOTO LOOP (re-validate)
  4. IF unfixable issues: Log for manual review, continue
  5. IF clean: Mark VALIDATED, proceed
検証コマンド
# Per-document validation (Phase 1)
python ai_dev_ssd_flow/scripts/validate_cross_document.py --document docs/07_REQ/REQ-NN_slug/REQ-NN_slug.md --auto-fix

# Layer validation (Phase 2) - run when all REQ documents complete
python ai_dev_ssd_flow/scripts/validate_cross_document.py --layer REQ --auto-fix
レイヤー固有の上流要件
このレイヤー必須の上流タグ数
REQ（レイヤー7）@brd, @prd, @ears, @bdd, @adr, @sys6タグ
自動修正アクション（確認不要）
問題修正アクション
@brd/@prd/@ears/@bdd/@adr/@sys タグの欠落上流ドキュメントへの参照を付けて追加
タグ形式が無効TYPE.NN.xxxx（3セグメント）または TYPE-NN 形式に修正
リンク切れ現在の場所からパスを再計算
トレーサビリティセクションの欠落テンプレートから挿入
検証コードの参照
コード説明深刻度
XDOC-001参照された要件 ID が見つからないERROR
XDOC-002累積タグが欠落しているERROR
XDOC-003上流ドキュメントが見つからないERROR
XDOC-006タグ形式が無効ERROR
XDOC-007累積タグチェーンに欠落があるERROR
XDOC-009トレーサビリティセクションが欠落しているERROR
品質ゲート

ブロッキング：はい - フェーズ1の検証がエラー0件で合格するまで、IMPL/SPEC の作成に進めません。

次のスキル

REQ の作成後は、次を使用します。

doc-spec（または必要に応じて先に doc-impl/doc-ctr）- 技術仕様（レイヤー10）を作成します

SPEC では次のことを行います。

  • この REQ を上流ソースとして参照する
  • 上流タグを7つすべて（@brd から @req まで）含める
  • YAML 形式を使用する
  • 実装契約を定義する
  • 実装準備状況100%を達成する

参照ドキュメント

REQ アーティファクトは REF ドキュメントをサポートしません。SDD フレームワークでは、参照ドキュメントは BRD と ADR タイプのみに限定されています。

補足ドキュメントが必要な場合は、次を作成します。

  • BRD-REF：ビジネスコンテキストとドメイン用語集
  • ADR-REF：技術参照ガイドとアーキテクチャ概要

関連リソース

  • テンプレート：ai_dev_ssd_flow/07_REQ/REQ-MVP-TEMPLATE.md（最優先の基準）

  • REQ 作成ルール：ai_dev_ssd_flow/07_REQ/REQ-MVP-TEMPLATE.md

  • REQ 検証ルール：ai_dev_ssd_flow/07_REQ/REQ_MVP_SCHEMA.yaml

  • REQ README：ai_dev_ssd_flow/07_REQ/README.md

  • 共通標準：.claude/skills/doc-flow/SHARED_CONTENT.md

  • セクション分割の参考資料（50KB を超えるドキュメント向け）：

  • 参考資料：ai_dev_ssd_flow/ID_NAMING_STANDARDS.md（セクションベースのファイル分割）

クイックリファレンス

REQ の目的：実装可能な、アトミックな要件

レイヤー：7

必須タグ：@brd、@prd、@ears、@bdd、@adr、@sys（6 タグ）

形式：REQ MVP（11 セクション）

品質ゲート：SPEC 準備度スコア >=90% かつ IMPL 準備度スコア >=90%

要素 ID 形式：REQ.NN.xxxx

  • 機能要件 = 01
  • 依存関係 = 05
  • 受け入れ基準 = 06
  • アトミック要件 = 27

廃止されたパターン：AC-XXX、FR-XXX、R-XXX、REQ-XXX

ドキュメント管理フィールド：必須 11 項目（テンプレートバージョン = 3.0）

ステータス／スコアの対応：>=90% 承認済み、70-89% レビュー中、<70% ドラフト

ファイルサイズの上限：50KB を超える場合はセクションファイルを使用

次のステップ：doc-spec（または任意で先に doc-impl/doc-ctr）

バージョン履歴

バージョン日付変更内容作成者
1.22026-03-06品質ゲートの検証に関する参考資料と pre-commit フックのセクションを追加System
1.12026-02-27REQ v3.0 形式（11 セクション、SPEC 準備度スコアリング）に更新System
1.02026-02-08YAML フロントマターの標準化を含む初期スキル定義System

コメント

Markdown 対応