doc-tasks

Name: doc-tasks
Author: vladm3105

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

リポジトリ

doc-tasks について

doc-tasksは、SDDワークフロー第11層でSPECをAIコーディングエージェント向けの構造化タスクに分解するドキュメントスキルです。タスク項目、依存関係、トレーサビリティタグ、実装コントラクト、検証手順を定めます。

主な機能

01SPECを実装タスクに分解
02フェーズと依存関係でタスクを整理
03タスクIDと必須項目を規定
04Mermaid依存関係図と工数集計を要求
05トレーサビリティタグと実装コントラクトを検証

活用シーン

01コーディングエージェント向けの実装TODOを準備
02SPECに基づく開発フェーズを計画
03TASKSの形式とトレーサビリティを確認

インストール

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

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

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

詳細

doc-tasks

目的

**タスク分解（TASKS）**を作成します。これは、SPECを実装可能な、AI向けに構造化されたTODOタスクに分解する、SDDワークフローのレイヤー11の成果物です。

レイヤー：11

上流：BRD（レイヤー1）、PRD（レイヤー2）、EARS（レイヤー3）、BDD（レイヤー4）、ADR（レイヤー5）、SYS（レイヤー6）、REQ（レイヤー7）、IMPL（レイヤー8）、CTR（レイヤー9）、SPEC（レイヤー10）

下流成果物：コード（レイヤー12）

前提条件

上流成果物の検証（重要）

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

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

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

トレーサビリティタグでは、既存のドキュメントのみを参照します
上流成果物の種類が実際に存在しない場合にのみ、nullを使用します
BRD-XXXやTBDのようなプレースホルダーは絶対に使用しないでください
不足している上流成果物は作成しないでください。該当する機能はスキップします

TASKSを作成する前に、以下を読みます。

共有標準：.claude/skills/doc-flow/SHARED_CONTENT.md
上流のSPEC：技術仕様（主要な情報源）
テンプレート：ai_dev_flow/11_TASKS/TASKS-TEMPLATE.md
作成ルール：ai_dev_flow/11_TASKS/TASKS_CREATION_RULES.md
検証ルール：ai_dev_flow/11_TASKS/TASKS_VALIDATION_RULES.md
検証スクリプト：./ai_dev_flow/scripts/validate_tasks.sh
実装コントラクトガイド：ai_dev_flow/11_TASKS/IMPLEMENTATION_CONTRACTS_GUIDE.md

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

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

BRDからSPECまで（レイヤー1～10）が完了している
SPECを実装可能なタスクに分解する準備ができている
実装計画（レイヤー12）の準備をしている
AIエージェント向けに構造化されたTODO形式が必要である
SDDワークフローのレイヤー11にいる

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

対象範囲：予約ID 000を持つドキュメントは、検証の対象から完全に除外されます。

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

ドキュメントの種類：

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

理由：予約ID 000のドキュメントは、プロジェクト成果物のようにトレーサビリティや品質ゲートを必要とするものではなく、フレームワークのインフラストラクチャ（インデックス、テンプレート、参考資料）です。

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

要素IDの形式（必須）

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

要素の種類	コード	例
タスク	18	TASKS.02.1801
タスク項目	30	TASKS.02.3001

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

TASK-XXX → TASKS.NN.18.SSを使用

T-XXX → TASKS.NN.18.SSを使用

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

修正例：### TASK-01: Implementationを### TASKS.02.1801: Implementationに置き換えます。

TASKS固有のガイダンス

1. AI向け構造化TODO形式

目的：SPECをAIコーディングエージェントが利用できるタスクに分解します。

形式：

## Tasks

### Phase 1: Project Setup (3 tasks)

**TASKS.01.1801: Initialize Project Structure**
- **Action**: Create directory structure per SPEC architecture
- **Files to Create**:
  - `src/controllers/data_validation_controller.py`
  - `src/services/data_validator.py`
  - `src/repositories/data_repository.py`
  - `src/models/data_request.py`
- **Dependencies**: None
- **Estimated Effort**: 30 minutes
- **SPEC Reference**: SPEC-01:implementation.modules
- **Success Criteria**: All directories and empty files created

**TASKS.01.1802: Set Up Development Environment**
- **Action**: Configure Python environment and dependencies
- **Files to Create**: `requirements.txt`, `pyproject.toml`
- **Dependencies**: TASKS.01.1801
- **Estimated Effort**: 1 hour
- **SPEC Reference**: SPEC-01:deployment.container
- **Success Criteria**: `pip install -r requirements.txt` succeeds

### Phase 2: Data Models (2 tasks)

**TASKS.01.1803: Implement DataRequest Model**
- **Action**: Create Pydantic model per CTR-01 schema
- **Files to Modify**: `src/models/data_request.py`
- **Dependencies**: TASKS.01.1802
- **Estimated Effort**: 1 hour
- **SPEC Reference**: SPEC-01:interfaces.data_models
- **CTR Reference**: CTR-01#/components/schemas/DataRequest
- **Success Criteria**: Model validates per schema, unit tests pass

2. 必須セクション

ドキュメント管理（必須 — すべての番号付きセクションより前に配置する最初のセクション）

主要セクション：

概要：タスク分解の概要
タスク階層：フェーズとタスクグループ
タスク：詳細なタスク分解（主要な内容）
依存関係グラフ：タスク間の依存関係を示す図（Mermaid図）
作業量の概要：フェーズごとの総作業量
トレーサビリティ：累積タグを含むセクション7の形式
実装コントラクト：セクション8（必須） — 提供・消費されるコントラクト

3. タスクの番号付け形式

形式：TASKS.{SPEC-ID}.18.{SEQ}（統一された要素ID形式）

例：TASKS.01.1803は、以下を意味します。

SPEC-01（SPEC-01_data_validation.yamlから）
要素の種類18（タスク）
シーケンス03（分解内の3番目のタスク）

利点：

タスクをSPECに直接リンクできます
プロジェクト全体で一意のタスクIDを使用できます
コミットで簡単に参照できます

4. タスクの項目（必須）

各タスクには、以下を必ず含めてください。

タスク ID：TASKS.{SPEC-ID}.18.{SEQ}
タイトル：簡潔な説明（5～10語）
アクション：実行する内容（命令形）
作成／変更するファイル：具体的なファイルパス
依存関係：他のタスク ID（または「なし」）
見積もり作業量：所要時間の見積もり
SPEC の参照先：SPEC 内のセクション（例：SPEC-01:implementation.modules）
成功基準：完了を確認する方法
任意：CTR の参照先：該当する場合はコントラクトへのリンク

5. フェーズ構成

一般的なフェーズ：

フェーズ 1：プロジェクトのセットアップ（インフラ、環境）
フェーズ 2：データモデル（スキーマ、モデル、検証）
フェーズ 3：ビジネスロジック（サービス、コアアルゴリズム）
フェーズ 4：API レイヤー（コントローラー、エンドポイント）
フェーズ 5：エラーハンドリング（エラーコード、ミドルウェア）
フェーズ 6：設定（環境変数、機能フラグ）
フェーズ 7：テスト（ユニット、統合、パフォーマンス）
フェーズ 8：デプロイ（Docker、CI/CD、監視）

6. 依存関係グラフ

Mermaid 図のみを使用してください（ai_dev_ssd_flow/DIAGRAM_STANDARDS.md により、テキストベースの図は禁止されています）。

## Dependencies Graph

```mermaid
graph TD
    T001[TASKS.01.1801: Project Setup]
    T002[TASKS.01.1802: Dev Environment]
    T003[TASKS.01.1803: DataRequest Model]
    T004[TASKS.01.1804: ValidationResponse Model]
    T005[TASKS.01.1805: Data Repository]
    T006[TASKS.01.1806: Data Validator Service]
    T007[TASKS.01.1807: API Controller]

    T001 --> T002
    T002 --> T003
    T002 --> T004
    T002 --> T005
    T003 --> T006
    T004 --> T006
    T005 --> T006
    T006 --> T007


### 7. Effort Summary

**Format**:
```markdown
## Effort Summary

| Phase | Tasks | Total Effort |
|-------|-------|--------------|
| Phase 1: Project Setup | 2 | 1.5 hours |
| Phase 2: Data Models | 2 | 2 hours |
| Phase 3: Business Logic | 3 | 4 hours |
| Phase 4: API Layer | 1 | 1.5 hours |
| Phase 5: Error Handling | 2 | 2 hours |
| Phase 6: Configuration | 1 | 1 hour |
| Phase 7: Testing | 3 | 3 hours |
| Phase 8: Deployment | 2 | 2 hours |
| **TOTAL** | **16** | **17 hours** |

**Assumptions**:
- Developer familiar with Python and FastAPI
- PostgreSQL database already provisioned
- OAuth service already available

8. 実装コントラクト（必須）

セクション 8 はすべての TASKS ファイルで必須です。実装コントラクトにより、依存する TASKS ファイルを並行して開発できます。

構成：

## 8. Implementation Contracts

### 8.1 Contracts Provided by This TASKS
@icon: TASKS-XXX:ContractName
@icon-role: provider

- **Contract Name**: [Interface name]
- **Type**: Protocol Interface | Exception Hierarchy | State Machine | Data Model | DI Interface
- **Consumers**: List of TASKS IDs that depend on this contract
- **Purpose**: Brief description

### 8.2 Contracts Consumed by This TASKS
@icon: TASKS-YYY:OtherContract
@icon-role: consumer

- **Provider**: TASKS-YYY
- **Contract Name**: [Interface name]
- **Purpose**: Why this TASKS needs this contract

### 8.3 No Contracts
If this TASKS provides no contracts and consumes no contracts, state explicitly:
"This TASKS document neither provides nor consumes implementation contracts."

コントラクトを作成する場合：

TASKS に下流の依存関係が 3 つ以上ある
複数の実装セッションで共有インターフェースを使用する
複雑な状態マシンまたは例外階層がある
並行開発が必要である

コントラクトの種類：

プロトコルインターフェース：メソッドシグネチャを定義する typing.Protocol
例外階層：エラーコードを持つ型付き例外
状態マシンコントラクト：有効な遷移を持つ Enum 状態
データモデル：Pydantic／TypedDict スキーマ
DI インターフェース：依存性注入用の ABC クラス

参照先：詳しいガイダンスについては、ai_dev_flow/11_TASKS/IMPLEMENTATION_CONTRACTS_GUIDE.md を参照してください。

タグ形式の規約（設計上の仕様）

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

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

主な違い：

@adr: ADR-033 → ドキュメント ADR-033_risk_limit_enforcement.md を指します
@brd: BRD.17.0101 → ドキュメント BRD-017.md 内の要素 01.01 を指します

統一要素 ID 形式（必須）

階層型要件（BRD、PRD、EARS、BDD、SYS、REQ）の場合：

必ず使用：TYPE.NN.xxxx（ドット区切りの 3 セグメント統一形式）
使用禁止：TYPE-NN:NNN（コロン区切り — 非推奨）
使用禁止：TYPE.NN.TT.SS（旧 4 セグメント形式 — 非推奨）

例：

@brd: BRD.17.0101 ✅
@brd: BRD.017.001 ❌（旧 3 セグメント形式）

累積タグの要件

レイヤー 11（TASKS）：レイヤー 1～10 のタグを含める必要があります

タグ数：8～10 個（最小 8 個、最大 10 個）

累積タグの要素タイプコード

成果物	要素タイプ	コード	例
BRD	ビジネス要件	01	BRD.01.0103
PRD	プロダクト機能	07	PRD.01.0702
EARS	ステートメント	25	EARS.01.2501
BDD	シナリオ	14	BDD.01.1401
SYS	システム要件	26	SYS.01.2601
REQ	原子的要件	27	REQ.01.2701
IMPL	実装フェーズ	29	IMPL.01.2901

最小（IMPL と CTR を省略）：

## Traceability

**Required Tags** (Cumulative Tagging Hierarchy - Layer 11):
```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.2601
@req: REQ.01.2701
@spec: SPEC-01

最大（IMPL、CTR、ICON を含む）：

@brd: BRD.01.0103
@prd: PRD.01.0702
@ears: EARS.01.2501
@bdd: BDD.01.1401
@adr: ADR-033, ADR-045
@sys: SYS.01.2601
@req: REQ.01.2701
@impl: IMPL.01.2901
@ctr: CTR-01
@spec: SPEC-01
@icon: TASKS-01:DataValidator  # if providing or consuming implementation contracts
@icon-role: provider  # or consumer

上流／下流の成果物

上流のソース：

BRD（レイヤー 1） - ビジネス要件
PRD（レイヤー 2） - 製品機能
EARS（レイヤー 3） - 形式要件
BDD（レイヤー 4） - テストシナリオ
ADR（レイヤー 5） - アーキテクチャ上の決定
SYS（レイヤー 6） - システム要件
REQ（レイヤー 7） - アトミック要件
IMPL（レイヤー 8） - 実装方針（任意）
CTR（レイヤー 9） - データコントラクト（任意）
SPEC（レイヤー 10） - 技術仕様（主要ソース）

下流の成果物：

コード（レイヤー 12） - 実装コード（src/ に作成）
テスト（レイヤー 13） - テストスイート

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

@related-tasks: TASKS-NN - 実装コンテキストを共有する TASKS
@depends-tasks: TASKS-NN - 先に完了する必要がある TASKS

検証チェック

ティア 1：エラー（ブロッキング）

チェック	説明
CHECK 1	ファイル名の形式が有効（TASKS-NN_slug_tasks.md）
CHECK 2	必須フィールドを含む YAML フロントマターがある
CHECK 3	ドキュメント管理テーブルが完全（8 フィールド）
CHECK 4	必須セクションが 8 つすべて存在する
CHECK 5	セクション 8（実装コントラクト）が 8.1／8.2／8.3 のサブセクションとともに存在する
CHECK 6	必須のトレーサビリティタグが 8 つすべて存在する
CHECK 7	親 SPEC の参照が有効で、ファイルが存在する
CHECK 8	要素 ID の形式に準拠（TASKS.NN.xxxx）

ティア 2：警告

チェック	説明
CHECK W1	スコープセクションに除外事項が記載されている
CHECK W2	計画に番号付きのステップが 3 つ以上ある
CHECK W3	SPEC の行参照がある
CHECK W4	受け入れ基準のチェックボックスが 3 つ以上ある
CHECK W5	受け入れ基準に BDD シナリオの参照がある
CHECK W6	@icon タグを使用する場合、@icon-role タグがある

ティア 3：情報

チェック	説明
CHECK I1	計画に所要時間の見積もりがある
CHECK I2	任意の @impl タグと @ctr タグがある
CHECK I3	ICON 参照が有効で、ファイルが存在する

作成プロセス

ステップ 1：上流の SPEC を読む

分解対象となる SPEC（レイヤー 10）の技術仕様を読みます。

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

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

ID 番号の付け方：2 桁で始め、必要に応じて桁数を増やします。

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

ID の一致：TASKS ID は通常 SPEC ID と一致します（SPEC-01 から TASKS-01）。

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

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

ファイル名：docs/11_TASKS/TASKS-NN_{slug}/TASKS-NN_{slug}.md

例：docs/11_TASKS/TASKS-01_data_validation/TASKS-01_data_validation.md

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

ステップ 4：ドキュメント管理セクションに記入する

メタデータとドキュメント改訂履歴テーブルを完成させます。

ステップ 5：概要を書く

タスクの分解方針を要約します。

ステップ 6：フェーズを定義する

タスクを論理的なフェーズ（通常は 8 フェーズ）に整理します。

ステップ 7：詳細なタスクを作成する

SPEC の各タスクについて：

TASK ID を割り当てる（TASKS.{SPEC-ID}.18.{SEQ}）
明確なアクション（命令形）を書く
作成／変更するファイルを列挙する
依存関係を特定する
作業量を見積もる
SPEC セクションを参照する
成功基準を定義する

ステップ 8：依存関係グラフを作成する

Mermaid の図を使用して、タスクの依存関係を可視化します。

ステップ 9：作業量の概要を算出する

フェーズごとの作業量の合計をまとめます。

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

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

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

必須：docs/TASKS/TASKS-00_TRACEABILITY_MATRIX.md を更新します。

ステップ 12：TASKS を検証する

./ai_dev_flow/scripts/validate_tasks.sh docs/TASKS/TASKS-01_*.md

python ai_dev_flow/scripts/validate_tags_against_docs.py --artifact TASKS-01 --expected-layers brd,prd,ears,bdd,adr,sys,req,impl,contracts,spec --strict

ステップ 13：変更をコミットする

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

検証

自動検証

# Quality gates
./scripts/validate_quality_gates.sh docs/TASKS/TASKS-01_*.md

# Task format validation
./ai_dev_flow/scripts/validate_tasks.sh docs/TASKS/TASKS-01_*.md

# Cumulative tagging
python ai_dev_flow/scripts/validate_tags_against_docs.py \
  --artifact TASKS-01 \
  --expected-layers brd,prd,ears,bdd,adr,sys,req,impl,contracts,spec \
  --strict

手動チェックリスト

図の標準

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

よくある落とし穴

曖昧なタスク：タスクは具体的で、実行可能でなければなりません
依存関係の欠落：タスクの依存関係を特定する必要があります
工数見積もりがない：計画には工数が必要です
SPEC参照の欠落：各タスクからSPECセクションにリンクする必要があります
成功基準がない：完了を検証する方法を定義する必要があります
累積タグの欠落：Layer 11には上流のタグをすべて（8～10個）含める必要があります
Section 8の欠落：Implementation Contractsセクションは必須です
テキストベースの図：依存関係グラフにはMermaidのみを使用してください
レガシーのタスクID：TASK-XXXやT-XXXではなく、TASKS.NN.18.SSを使用してください

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

重要：ドキュメントの作成直後に、この検証ループをただちに実行してください。検証に合格するまで次のドキュメントに進まないでください。

自動検証ループ

LOOP:
  1. Run: python ai_dev_flow/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_flow/scripts/validate_cross_document.py --document docs/TASKS/TASKS-NN_slug.md --auto-fix

# Layer validation (Phase 2) - run when all TASKS documents complete
python ai_dev_flow/scripts/validate_cross_document.py --layer TASKS --auto-fix

レイヤー固有の上流要件

このレイヤー	必須の上流タグ	数
TASKS (Layer 11)	@brd, @prd, @ears, @bdd, @adr, @sys, @req, @spec (+ 作成した場合は @impl, @ctr)	8～10個のタグ

自動修正アクション（確認不要）

問題	修正アクション
上流タグの欠落	上流ドキュメントへの参照を付けて追加する
タグ形式が無効	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

品質ゲート

ブロッキング：はい - Phase 1の検証でエラーが0件になるまで、次のドキュメントに進めません。

次のスキル

TASKSの完了後、実装に進みます：

Code (Layer 12) - 実装コードを記述する
Tests (Layer 13) - テストスイートを作成する
Validation (Layer 14) - 検証チェックを実行する

参考ドキュメント

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

補足ドキュメントが必要な場合は、以下を作成してください：

BRD-REF：ビジネスコンテキストのドキュメント
ADR-REF：タスクの工数見積もりガイド、依存関係分析レポート

クイックリファレンス

TASKS の目的：SPEC を実行可能な AI 構造化 TODO タスクに分解する

レイヤー：11

要素 ID 形式：TASKS.NN.18.SS

タスク = 18
タスク項目 = 30

廃止されたパターン：TASK-XXX、T-XXX

必須タグ：@brd から @spec まで（8～10 個のタグ）

形式：フェーズを含む AI 構造化 TODO

タスク ID 形式：TASKS.{SPEC-ID}.18.{SEQ}

必須タスクフィールド：

タスク ID、タイトル、アクション
作成／変更するファイル
依存関係
推定作業量
SPEC 参照
成功基準

主要セクション：

タスク階層（フェーズ）
詳細タスク（主要コンテンツ）
依存関係グラフ（Mermaid）
作業量の概要
実装コントラクト（セクション 8 - 必須）

次の工程：実装（コード → テスト → 検証）

バージョン履歴

バージョン	日付	変更内容	作成者
1.0	2026-02-08	YAML フロントマター標準化を含む初期スキル定義	System

Markdown 対応

ログインしてコメント

基本情報

作者: vladm3105
リポジトリ: vladm3105/aidoc-flow-framework
カテゴリ: 開発
インストール数: 52
GitHub スター: 17

問題を報告

doc-tasks

doc-tasks について

主な機能

活用シーン

インストール

詳細

doc-tasks

目的

前提条件

上流成果物の検証（重要）

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

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

要素IDの形式（必須）

TASKS固有のガイダンス

1. AI向け構造化TODO形式

2. 必須セクション

3. タスクの番号付け形式

4. タスクの項目（必須）

5. フェーズ構成

6. 依存関係グラフ

8. 実装コントラクト（必須）

タグ形式の規約（設計上の仕様）

統一要素 ID 形式（必須）

累積タグの要件

累積タグの要素タイプコード

上流／下流の成果物

検証チェック

ティア 1：エラー（ブロッキング）

ティア 2：警告

ティア 3：情報

作成プロセス

ステップ 1：上流の SPEC を読む

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

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

ステップ 4：ドキュメント管理セクションに記入する

ステップ 5：概要を書く

ステップ 6：フェーズを定義する

ステップ 7：詳細なタスクを作成する

ステップ 8：依存関係グラフを作成する

ステップ 9：作業量の概要を算出する

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

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

ステップ 12：TASKS を検証する

ステップ 13：変更をコミットする

検証

自動検証

手動チェックリスト

図の標準

よくある落とし穴

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

自動検証ループ

検証コマンド

レイヤー固有の上流要件

自動修正アクション（確認不要）

検証コードのリファレンス

品質ゲート

次のスキル

参考ドキュメント

関連リソース

クイックリファレンス

バージョン履歴

コメント