yodogawa 2.1.0 → 2.1.3

package/CHANGELOG.md

@@ -5,6 +5,18 @@
 フォーマットは [Keep a Changelog](https://keepachangelog.com/ja/1.0.0/) に基づいており、
 このプロジェクトは [Semantic Versioning](https://semver.org/lang/ja/spec/v2.0.0.html) に準拠しています。
 
+## [2.1.3] - 2026-06-22
+
+### 修正
+
+- **スキル参照の採番ズレと旧 PascalCase 名を修正**: ドキュメント生成スキル（`c-001-implement-task` / `b-005-review-task`）と配布テンプレート（`templates/tasks/task-template/`）に残っていた、1つ手前のスキルを指す採番ズレと、kebab-case でないと解決しない旧 PascalCase スラッシュ名（`/c-001-ImplementTask` 等）を正しいスキル名・採番へ修正しました（#4）。`templates/` は利用者へ配布されるため、誤ったスキル実行への誘導が解消されます。
+
+## [2.1.2] - 2026-06-16
+
+### 削除
+
+- **孤立テンプレートの削除**: どのスキルからも参照されず、内容も実構造（`templates/project/**` の各テンプレート）と乖離していた `templates/documentation-rules.md` を削除しました。各ドキュメントに記載する内容は各テンプレートファイル本体が単一の情報源（Single Source of Truth）です。
+
 ## [2.1.0] - 2026-04-16
 
 ### 変更

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 tkysi-mi
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -165,7 +165,7 @@ Why? ─── What? ─── How?
 
 ## 導入
 
-### 方法1: NPMパッケージ（推奨）
+### 方法1: NPMパッケージ（推奨／全IDE対応）
 
 ```bash
 npm install -g yodogawa
@@ -173,11 +173,28 @@ cd your-project-dir
 yodogawa
 ```
 
-対話形式でIDEを選択すると、`skills/`, `templates/`, `scripts/` がプロジェクトの IDE ディレクトリに配置されます。
+対話形式でIDEを選択すると、`skills/`, `templates/` がプロジェクトの IDE ディレクトリに配置されます。
 
-### 方法2: 手動導入
+### 方法2: Claude Code Plugin（Claude Code 限定）
 
-このリポジトリの `skills/`, `templates/`, `scripts/` をプロジェクトの IDE ディレクトリにコピーしてください：
+Claude Code から直接マーケットプレイスを追加してインストールできます。リポジトリにファイルをコピーせず、`.claude/settings.json` に参照エントリのみ追加されます。
+
+```bash
+# Claude Code 内で以下を実行
+/plugin marketplace add tkysi-mi/Yodogawa
+/plugin install yodogawa@yodogawa
+/reload-plugins
+```
+
+スキルは `/yodogawa:a-001` のようにプラグイン名のプレフィックス付きで呼び出されます。
+
+> ℹ️ Plugin 機能は Claude Code 固有です。Cursor / Codex / Antigravity を使う場合は方法1または方法3を選んでください。
+>
+> ℹ️ スキルが参照するテンプレート（`templates/`）は、各スキルの配置ディレクトリを起点に相対参照で解決されるため、Plugin 導入でもプラグインキャッシュ上のテンプレートが利用されます。実行環境の差異で解決できない場合は、確実な方法1（NPM）または方法3（手動）を利用してください。
+
+### 方法3: 手動導入
+
+このリポジトリの `skills/`, `templates/` をプロジェクトの IDE ディレクトリにコピーしてください：
 
 - **Claude Code**: `.claude/` 配下にコピー
 - **Cursor / Codex / Antigravity**: `.agents/` 配下にコピー
@@ -238,3 +255,9 @@ description: プロジェクトのドキュメントディレクトリ構造を
 
 - **`name`**: スキルの識別子（kebab-case）
 - **`description`**: AIエージェントがスキルを呼び出すトリガーとなる説明文
+
+---
+
+## ライセンス
+
+[MIT License](LICENSE) — Copyright (c) 2025 tkysi-mi

package/bin/cli.js

@@ -49,7 +49,6 @@ async function main() {
 
     await fs.copy(path.join(pkgRoot, 'skills'), path.join(targetDir, 'skills'));
     await fs.copy(path.join(pkgRoot, 'templates'), path.join(targetDir, 'templates'));
-    await fs.copy(path.join(pkgRoot, 'scripts'), path.join(targetDir, 'scripts'));
 
     console.log(green(`\n✔ Successfully installed Yodogawa skills for ${response.type}!`));
     console.log(`\nNext steps:`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "yodogawa",
-  "version": "2.1.0",
+  "version": "2.1.3",
   "description": "CLI to install Yodogawa Slash Commands workflows",
   "bin": {
     "yodogawa": "bin/cli.js"
@@ -9,7 +9,6 @@
     "bin",
     "skills",
     "templates",
-    "scripts",
     "README.md",
     "CHANGELOG.md"
   ],
@@ -43,7 +42,7 @@
     "claude"
   ],
   "author": "",
-  "license": "ISC",
+  "license": "MIT",
   "dependencies": {
     "fs-extra": "^11.2.0",
     "kleur": "^4.1.5",
@@ -51,6 +50,6 @@
   },
   "devDependencies": {
     "husky": "^9.1.7",
-    "markdownlint-cli2": "^0.20.0"
+    "markdownlint-cli2": "^0.22.1"
   }
 }

package/skills/a-001-setup-doc-structure/SKILL.md

@@ -1,67 +1,68 @@
----
-name: a-001-setup-doc-structure
-description: docs/ 配下にプロジェクト/タスク用のディレクトリ構造と README を作成する。新規リポジトリでドキュメント基盤を初期化する際に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Bash, Glob
----
-
-# SetupDocStructure (a-001)
-
-## 目的
-
-- プロジェクトルートに標準化されたドキュメントディレクトリ構造を作成する。
-- `docs/README.md` を作成し、ドキュメント構成と更新方針を明文化する。
-
-## 前提
-
-- プロジェクトのルートディレクトリへの書き込み権限があること
-- `docs/` ディレクトリが存在しない、または既存の構造を拡張したいこと
-
-## 手順
-
-### 1. スクリプトの実行
-
-環境に応じたスクリプトを実行。スクリプト本体とフォールバック実装は [reference/directory-structure.md](reference/directory-structure.md#スクリプト実行コマンド) を参照。
-
-```bash
-SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-bash "$SCRIPT_DIR/scripts/setup-docs.sh"
-```
-
-### 2. 結果の確認
-
-スクリプト実行結果にエラーがないこと、および期待した構造が生成されていることを確認。生成構造と各ディレクトリの用途は [reference/directory-structure.md](reference/directory-structure.md#生成されるディレクトリ構造) を参照。
-
-### 3. Git への追加（オプション）
-
-ユーザーに確認し、「はい」なら:
-
-```bash
-git add docs/
-git status
-```
-
-推奨コミットメッセージは [reference/directory-structure.md](reference/directory-structure.md#git-追加時の推奨コミットメッセージ) を参照。
-
-### 4. 完了条件の確認
-
-- [ ] スクリプトが正常に終了した
-- [ ] `docs/` ディレクトリ構造が正しく作成されている
-
-## 完了条件
-
-- プロジェクトルートに `docs/` ディレクトリが作成されている
-- `docs/project/` 配下に `01-requirements/`, `02-behavior/`, `03-domain/`, `04-design/` が存在する
-- `docs/tasks/` ディレクトリが存在する
-- `docs/README.md` が作成されている
-- ユーザーに作成結果が報告されている
-
-## エスカレーション
-
-- **既存の `docs/` が存在し重要ファイルを含む**: 「既存のドキュメント構造が検出されました。上書きや削除のリスクがあるため、手動で確認してください。」と警告し処理を中断
-- **権限エラー**: 「ディレクトリの作成に失敗しました。書き込み権限を確認してください。」
-- **Git リポジトリでない**: 「このディレクトリは Git リポジトリではありません。必要なら `git init` を実行してください。」
-
-## 参考
-
-- [reference/directory-structure.md](reference/directory-structure.md) — 生成構造、各ディレクトリの用途、スクリプト詳細、推奨コミットメッセージ
+---
+name: a-001-setup-doc-structure
+description: docs/ 配下にプロジェクト/タスク用のディレクトリ構造と README を作成する。新規リポジトリでドキュメント基盤を初期化する際に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Bash, Glob
+---
+
+# SetupDocStructure (a-001)
+
+## 目的
+
+- プロジェクトルートに標準化されたドキュメントディレクトリ構造を作成する。
+- `docs/README.md` を作成し、ドキュメント構成と更新方針を明文化する。
+
+## 前提
+
+- プロジェクトのルートディレクトリへの書き込み権限があること
+- `docs/` ディレクトリが存在しない、または既存の構造を拡張したいこと
+
+## 手順
+
+### 1. ディレクトリ構造の作成
+
+次のディレクトリを作成する（`mkdir -p` なので既存の場合は不足分のみ追加される）。
+
+```bash
+mkdir -p docs/project/01-requirements docs/project/02-behavior docs/project/03-domain docs/project/04-design docs/tasks
+```
+
+続いて `docs/README.md` を作成する。内容は [reference/directory-structure.md](reference/directory-structure.md#docsreadmemd-テンプレート) の「docs/README.md テンプレート」をそのまま Write する。`docs/README.md` が既に存在する場合は、上書き前にユーザーへ確認する。
+
+### 2. 結果の確認
+
+ディレクトリ構造と `docs/README.md` が期待どおり生成されていることを確認。生成構造と各ディレクトリの用途は [reference/directory-structure.md](reference/directory-structure.md#生成されるディレクトリ構造) を参照。
+
+### 3. Git への追加（オプション）
+
+ユーザーに確認し、「はい」なら:
+
+```bash
+git add docs/
+git status
+```
+
+推奨コミットメッセージは [reference/directory-structure.md](reference/directory-structure.md#git-追加時の推奨コミットメッセージ) を参照。
+
+### 4. 完了条件の確認
+
+- [ ] `docs/` ディレクトリ構造が正しく作成されている
+- [ ] `docs/README.md` が作成されている
+
+## 完了条件
+
+- プロジェクトルートに `docs/` ディレクトリが作成されている
+- `docs/project/` 配下に `01-requirements/`, `02-behavior/`, `03-domain/`, `04-design/` が存在する
+- `docs/tasks/` ディレクトリが存在する
+- `docs/README.md` が作成されている
+- ユーザーに作成結果が報告されている
+
+## エスカレーション
+
+- **既存の `docs/` が存在し重要ファイルを含む**: 「既存のドキュメント構造が検出されました。上書きや削除のリスクがあるため、手動で確認してください。」と警告し処理を中断
+- **権限エラー**: 「ディレクトリの作成に失敗しました。書き込み権限を確認してください。」
+- **Git リポジトリでない**: 「このディレクトリは Git リポジトリではありません。必要なら `git init` を実行してください。」
+
+## 参考
+
+- [reference/directory-structure.md](reference/directory-structure.md) — 生成構造、各ディレクトリの用途、スクリプト詳細、推奨コミットメッセージ

package/skills/a-001-setup-doc-structure/reference/directory-structure.md

@@ -1,52 +1,75 @@
-# docs ディレクトリ構造とコミットメッセージ
-
-SKILL.md 手順2〜3で参照する生成構造とコミットメッセージテンプレート。
-
-## 生成されるディレクトリ構造
-
-```
-docs/
-├── README.md
-├── project/
-│   ├── 01-requirements/
-│   ├── 02-behavior/
-│   ├── 03-domain/
-│   └── 04-design/
-└── tasks/
-```
-
-### 各ディレクトリの用途
-
-- `project/01-requirements/` — 要件定義（システム概要、機能要件、非機能要件、ユーザーストーリー）
-- `project/02-behavior/` — 振る舞い定義（Gherkin シナリオ）
-- `project/03-domain/` — ドメインモデル、ユビキタス言語
-- `project/04-design/` — 画面設計、データモデル、API 仕様、アーキテクチャ等
-- `tasks/` — 個別タスク（`task{ID}-{SLUG}/` 形式）
-
-## Git 追加時の推奨コミットメッセージ
-
-```
-ドキュメント構造の初期化
-
-- 標準的な構造を持つ docs/ ディレクトリを追加
-- ドキュメント構成を説明する docs/README.md を追加
-```
-
-## スクリプト実行コマンド
-
-```bash
-if [ -d ".agent" ]; then
-  SCRIPT_DIR=".agent"
-elif [ -d ".cursor" ]; then
-  SCRIPT_DIR=".cursor"
-elif [ -d ".claude" ]; then
-  SCRIPT_DIR=".claude"
-elif [ -d ".codex" ]; then
-  SCRIPT_DIR=".codex"
-else
-  echo "エラー: AI coding assistant ディレクトリが見つかりません"
-  exit 1
-fi
-
-bash "$SCRIPT_DIR/scripts/setup-docs.sh"
-```
+# docs ディレクトリ構造とコミットメッセージ
+
+SKILL.md 手順2〜3で参照する生成構造とコミットメッセージテンプレート。
+
+## 生成されるディレクトリ構造
+
+```
+docs/
+├── README.md
+├── project/
+│   ├── 01-requirements/
+│   ├── 02-behavior/
+│   ├── 03-domain/
+│   └── 04-design/
+└── tasks/
+```
+
+### 各ディレクトリの用途
+
+- `project/01-requirements/` — 要件定義（システム概要、機能要件、非機能要件、ユーザーストーリー）
+- `project/02-behavior/` — 振る舞い定義（Gherkin シナリオ）
+- `project/03-domain/` — ドメインモデル、ユビキタス言語
+- `project/04-design/` — 画面設計、データモデル、API 仕様、アーキテクチャ等
+- `tasks/` — 個別タスク（`task{ID}-{SLUG}/` 形式）
+
+## Git 追加時の推奨コミットメッセージ
+
+```
+ドキュメント構造の初期化
+
+- 標準的な構造を持つ docs/ ディレクトリを追加
+- ドキュメント構成を説明する docs/README.md を追加
+```
+
+## docs/README.md テンプレート
+
+SKILL.md 手順1で `docs/README.md` として Write する内容。
+
+```markdown
+# プロジェクトドキュメント
+
+このディレクトリには、プロジェクト全体のドキュメントと個別タスクのドキュメントを管理します。
+
+## 構成
+
+### project/
+プロジェクト全体のドキュメント。要件定義、設計、アーキテクチャなど、プロジェクトスコープ全体に関わる情報を記載します。
+
+- **01-requirements/**: 要件定義（システム概要、機能要件、非機能要件、ユーザーストーリーなど）
+- **02-behavior/**: 振る舞い定義（シナリオ、ユースケース、ユーザージャーニーなど）
+- **03-domain/**: ドメインモデル（エンティティ、用語集など）
+- **04-design/**: 設計（アーキテクチャ、データモデル、API仕様など）
+
+### tasks/
+個別タスクのドキュメント。Issue やチケット単位で作成します。
+
+## 更新方針
+
+### プロジェクト全体のドキュメント (project/)
+- プロジェクトのスコープ全体に影響する情報を記載
+- チーム全体で共有すべき要件・設計・アーキテクチャを管理
+- 更新時は関係者にレビューを依頼
+
+### 個別タスクのドキュメント (tasks/)
+- 特定の Issue やチケットに紐づく情報を記載
+- タスク単位で作成・完了・アーカイブ
+- 完了後は参照資料として保持、または削除
+
+## ドキュメント作成ガイドライン
+
+- **具体的**: 抽象的な表現を避け、数値・期限・制約を明確に記載
+- **測定可能**: 成功基準やパフォーマンス目標を定量化
+- **最新**: 変更があれば速やかに更新し、古い情報を残さない
+- **簡潔**: 必要最低限の情報に絞り、詳細はコードやリンク先に委ねる
+```

package/skills/a-002-initialize-project/SKILL.md

@@ -1,124 +1,118 @@
----
-name: a-002-initialize-project
-description: プロジェクトの要件を対話形式で収集し、システム概要・機能要件・非機能要件・ユーザーストーリーのドキュメントを生成する。新規プロジェクト開始時、または要件が未整備の場合に使用。
-disable-model-invocation: true
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# InitializeProject (a-002)
-
-## 目的
-
-- プロジェクトの目的・背景・機能要件を詳細にヒアリングし、具体的で実装可能なドキュメントを作成する。
-- システム概要・実装済み機能・予定機能・非機能要件・ユーザーストーリーを網羅する。
-- 抽象的・曖昧な表現を避け、対話を通じて具体的な数値・期限・制約・優先度を明確化する。
-
-## 前提
-
-- `docs/project/requirements/` ディレクトリが存在すること（なければ先に `/a-001-setup-doc-structure` を実行）
-- `docs/` に書き込み権限があること
-- ユーザーがプロジェクト概要と主要機能の基本情報を提供できること
-
-## 手順
-
-### 1. ドキュメントディレクトリの確認
-
-```bash
-ls -la docs/project/requirements/ 2>/dev/null || echo "ディレクトリが存在しません"
-```
-
-存在しない場合: 「`docs/project/requirements/` がありません。先に `/a-001-setup-doc-structure` を実行してください。」
-
-### 2. コードベースの自動分析と提案
-
-**規模確認**:
-
-```bash
-ls -F
-```
-
-ファイルがほとんど無い／ソースコードが無い場合はスキップし、ユーザーへ通知。
-
-**詳細調査**（コードがある場合）:
-
-```bash
-cat package.json 2>/dev/null
-cat README.md 2>/dev/null
-find src app lib -maxdepth 2 2>/dev/null
-```
-
-結果から以下を推測・提示: システム概要（目的・技術スタック）、実装済み機能（ファイル構造からの推測）、想定ユーザー像。
-
-### 3. システム概要の作成
-
-1. テンプレートをコピー:
-
-   ```bash
-   SCRIPT_DIR=$(for d in .agent .cursor .claude .codex; do [ -d "$d" ] && echo "$d" && break; done)
-   cp "$SCRIPT_DIR/templates/project/01-requirements/01-system-overview.md" \
-      "docs/project/requirements/01-system-overview.md"
-   ```
-
-2. 「背景」「目的」をヒアリングして記入。質問例は [reference/hearing-questions.md](reference/hearing-questions.md) を参照。
-
-### 4. 実装済み機能一覧
-
-1. `02-features-implemented.md` をテンプレートからコピー。
-2. コードベースを調査し、検出したディレクトリ/ファイル名から機能を提案。
-3. ヒアリング結果をテーブルに記入（Category 1/2、機能名、説明、機能 ID）。
-
-コード調査コマンドとヒアリング項目は [reference/hearing-questions.md](reference/hearing-questions.md#手順4-実装済み機能一覧) を参照。
-
-### 5. 予定機能一覧
-
-1. `03-features-planned.md` をテンプレートからコピー。
-2. システム概要と実装済み機能のギャップを分析し、未実装機能を提案。
-3. ヒアリング結果をテーブルに記入（機能 ID・優先度は未確定のまま）。
-
-### 6. 非機能要件一覧
-
-1. `04-non-functional-requirements.md` をテンプレートからコピー。
-2. 詳細定義が必要か確認。不要なら標準ベースラインで仮置き（[examples/nfr-baseline.md](examples/nfr-baseline.md)）。
-3. パフォーマンス/セキュリティ/可用性/スケーラビリティ/ユーザビリティ・保守性の観点で**定量的な目標**をヒアリング。
-
-### 7. ユーザーストーリー
-
-1. `05-user-stories.md` をテンプレートからコピー。
-2. 作成済みドキュメントから主要ユーザージャーニーを抽出し、ストーリー案を提示。
-3. ヒアリング結果をテーブルに記入（優先度・受け入れ基準含む）。
-
-ストーリーテンプレート: 「[役割]として、[〇〇機能]を使いたい、なぜなら[価値]だから」
-
-### 8. 全体レビュー
-
-- 作成した全ドキュメントをユーザーに提示し、以下を確認:
-  - 「記載内容に誤りや漏れはありませんか？」
-  - 「抽象的すぎる記述や、解釈が分かれそうな表現はありますか？」
-  - 「テンプレートのコメントや不要な例示は適切に処理されていますか？」
-
-### 9. 完了条件と構造の確認
-
-- ファイルの存在と主要セクション/テーブル構造を検証。
-- 検証コマンド・チェックリスト・Git コミット手順は [reference/structure-check.md](reference/structure-check.md) を参照。
-
-### 10. Git への追加（オプション）
-
-詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加オプション) を参照。
-
-## 完了条件
-
-- `docs/project/requirements/` に 5 つの要件定義ドキュメントが作成されている
-- すべてのドキュメントで抽象的表現が最小化され、具体的な数値・期限・制約が記載されている
-- ユーザーがドキュメント内容を確認し、承認またはフィードバックを提供している
-
-## エスカレーション
-
-- **ユーザーが重要な情報を提供できない**: 「この情報は後続の設計・実装で必須です。確認できる担当者や資料はありますか？」と確認し、TODO として記録。
-- **競合する要件や矛盾**: 「以下の要件が競合しています: [詳細]。優先順位や調整方針を確認させてください。」と報告。
-- **想定工数が非現実的に大きい**: 「現在の計画では実現が困難です。スコープ縮小や優先度調整を検討しませんか？」と提案。
-
-## 参考
-
-- [reference/hearing-questions.md](reference/hearing-questions.md) — 手順3〜7のヒアリング質問集
-- [reference/structure-check.md](reference/structure-check.md) — 手順9の構造チェックコマンドと Git コミット手順
-- [examples/nfr-baseline.md](examples/nfr-baseline.md) — 非機能要件の標準ベースライン提案値
+---
+name: a-002-initialize-project
+description: プロジェクトの要件を対話形式で収集し、システム概要・機能要件・非機能要件・ユーザーストーリーのドキュメントを生成する。新規プロジェクト開始時、または要件が未整備の場合に使用。
+disable-model-invocation: true
+allowed-tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# InitializeProject (a-002)
+
+## 目的
+
+- プロジェクトの目的・背景・機能要件を詳細にヒアリングし、具体的で実装可能なドキュメントを作成する。
+- システム概要・実装済み機能・予定機能・非機能要件・ユーザーストーリーを網羅する。
+- 抽象的・曖昧な表現を避け、対話を通じて具体的な数値・期限・制約・優先度を明確化する。
+
+## 前提
+
+- `docs/project/01-requirements/` ディレクトリが存在すること（なければ先に `/a-001-setup-doc-structure` を実行）
+- `docs/` に書き込み権限があること
+- ユーザーがプロジェクト概要と主要機能の基本情報を提供できること
+
+## 手順
+
+### 1. ドキュメントディレクトリの確認
+
+```bash
+ls -la docs/project/01-requirements/ 2>/dev/null || echo "ディレクトリが存在しません"
+```
+
+存在しない場合: 「`docs/project/01-requirements/` がありません。先に `/a-001-setup-doc-structure` を実行してください。」
+
+### 2. テンプレート一括コピー
+
+このスキルの配置ディレクトリ（`skills/a-002-initialize-project/`）を起点に、`docs/project/01-requirements/` へ次の 5 ファイルを Read→Write する（FOR EACH）。出力先に既に存在するファイルは上書きせずスキップして報告する（冪等）。出力先ディレクトリが無ければ作成する。
+
+- `../../templates/project/01-requirements/01-system-overview.md` → `docs/project/01-requirements/01-system-overview.md`
+- `../../templates/project/01-requirements/02-features-implemented.md` → `docs/project/01-requirements/02-features-implemented.md`
+- `../../templates/project/01-requirements/03-features-planned.md` → `docs/project/01-requirements/03-features-planned.md`
+- `../../templates/project/01-requirements/04-non-functional-requirements.md` → `docs/project/01-requirements/04-non-functional-requirements.md`
+- `../../templates/project/01-requirements/05-user-stories.md` → `docs/project/01-requirements/05-user-stories.md`
+
+### 3. コードベースの自動分析と提案
+
+**規模確認**:
+
+```bash
+ls -F
+```
+
+ファイルがほとんど無い／ソースコードが無い場合はスキップし、ユーザーへ通知。
+
+**詳細調査**（コードがある場合）:
+
+```bash
+cat package.json 2>/dev/null
+cat README.md 2>/dev/null
+find src app lib -maxdepth 2 2>/dev/null
+```
+
+結果から以下を推測・提示: システム概要（目的・技術スタック）、実装済み機能（ファイル構造からの推測）、想定ユーザー像。
+
+### 4. システム概要の記入
+
+`01-system-overview.md` を開き、「背景」「目的」をヒアリングして記入する。質問例は [reference/hearing-questions.md](reference/hearing-questions.md) を参照。
+
+### 5. 実装済み機能一覧の記入
+
+`02-features-implemented.md` に、コードベース調査で検出したディレクトリ/ファイル名から機能を提案し、ヒアリング結果をテーブルに記入する（Category 1/2、機能名、説明、機能 ID）。
+
+コード調査コマンドとヒアリング項目は [reference/hearing-questions.md](reference/hearing-questions.md#手順4-実装済み機能一覧) を参照。
+
+### 6. 予定機能一覧の記入
+
+`03-features-planned.md` に、システム概要と実装済み機能のギャップを分析して未実装機能を提案し、ヒアリング結果をテーブルに記入する（機能 ID・優先度は未確定のまま）。
+
+### 7. 非機能要件の記入
+
+`04-non-functional-requirements.md` に、詳細定義が必要か確認の上、パフォーマンス/セキュリティ/可用性/スケーラビリティ/ユーザビリティ・保守性の観点で**定量的な目標**をヒアリングして記入する。不要なら標準ベースライン（[examples/nfr-baseline.md](examples/nfr-baseline.md)）で仮置きする。
+
+### 8. ユーザーストーリーの記入
+
+`05-user-stories.md` に、作成済みドキュメントから主要ユーザージャーニーを抽出してストーリー案を提示し、ヒアリング結果をテーブルに記入する（優先度・受け入れ基準含む）。
+
+ストーリーテンプレート: 「[役割]として、[〇〇機能]を使いたい、なぜなら[価値]だから」
+
+### 9. 全体レビュー
+
+- 作成した全ドキュメントをユーザーに提示し、以下を確認:
+  - 「記載内容に誤りや漏れはありませんか？」
+  - 「抽象的すぎる記述や、解釈が分かれそうな表現はありますか？」
+  - 「テンプレートのコメントや不要な例示は適切に処理されていますか？」
+
+### 10. 完了条件と構造の確認
+
+- ファイルの存在と主要セクション/テーブル構造を検証。
+- 検証コマンド・チェックリスト・Git コミット手順は [reference/structure-check.md](reference/structure-check.md) を参照。
+
+### 11. Git への追加（オプション）
+
+詳細は [reference/structure-check.md](reference/structure-check.md#git-への追加オプション) を参照。
+
+## 完了条件
+
+- `docs/project/01-requirements/` に 5 つの要件定義ドキュメントが作成されている
+- すべてのドキュメントで抽象的表現が最小化され、具体的な数値・期限・制約が記載されている
+- ユーザーがドキュメント内容を確認し、承認またはフィードバックを提供している
+
+## エスカレーション
+
+- **ユーザーが重要な情報を提供できない**: 「この情報は後続の設計・実装で必須です。確認できる担当者や資料はありますか？」と確認し、TODO として記録。
+- **競合する要件や矛盾**: 「以下の要件が競合しています: [詳細]。優先順位や調整方針を確認させてください。」と報告。
+- **想定工数が非現実的に大きい**: 「現在の計画では実現が困難です。スコープ縮小や優先度調整を検討しませんか？」と提案。
+
+## 参考
+
+- [reference/hearing-questions.md](reference/hearing-questions.md) — 手順4〜8のヒアリング質問集
+- [reference/structure-check.md](reference/structure-check.md) — 手順10の構造チェックコマンドと Git コミット手順
+- [examples/nfr-baseline.md](examples/nfr-baseline.md) — 非機能要件の標準ベースライン提案値