diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index c466ca8..6bff8cf 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -7,14 +7,14 @@ }, "metadata": { "description": "AI-driven development toolkit for TDD and SDD workflows, providing comprehensive command templates and agents to enhance developer productivity with Claude Code", - "version": "1.4.1" + "version": "1.5.0" }, "plugins": [ { "name": "tsumiki", "source": "./", "description": "AI-driven development toolkit for TDD and SDD workflows, providing comprehensive command templates and agents to enhance developer productivity with Claude Code", - "version": "1.4.1", + "version": "1.5.0", "author": { "name": "makoto kuroeda", "email": "kuroeda.makoto@classmethod.jp" @@ -23,6 +23,20 @@ "repository": "https://github.com/classmethod/tsumiki", "license": "MIT", "keywords": ["ai-development", "sdd", "tdd"] + }, + { + "name": "tsumiki-legacy", + "source": "./legacy", + "description": "Legacy Tsumiki commands (kairo, tdd, direct workflows) provided as an opt-in plugin for backward compatibility", + "version": "1.5.0", + "author": { + "name": "makoto kuroeda", + "email": "kuroeda.makoto@classmethod.jp" + }, + "homepage": "https://github.com/classmethod/tsumiki", + "repository": "https://github.com/classmethod/tsumiki", + "license": "MIT", + "keywords": ["ai-development", "sdd", "tdd", "legacy"] } ] } diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index f53bf6e..26cc326 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "tsumiki", - "version": "1.4.2", + "version": "1.5.0", "description": "AI-driven development toolkit for TDD and SDD workflows, providing comprehensive command templates and agents to enhance developer productivity with Claude Code", "author": { "name": "makoto kuroeda", diff --git a/MANUAL.md b/MANUAL.md index b1735ca..a84afb2 100644 --- a/MANUAL.md +++ b/MANUAL.md @@ -11,7 +11,17 @@ Claude Code Pluginを使用してTsumikiをインストールします： /plugin install tsumiki@tsumiki ``` -**注意**: コマンドは `/tsumiki:` プレフィックス付きで実行します（例：`/tsumiki:kairo-requirements`）。 +**注意**: コマンドは `/tsumiki:` プレフィックス付きで実行します（例：`/tsumiki:dev-plan`）。 + +#### レガシープラグイン（オプトイン） + +`Kairo` / `TDD` / `DIRECT` の従来コマンドは、オプトインのレガシープラグイン `tsumiki-legacy` として分離されています。利用する場合は追加でインストールしてください： + +```bash +/plugin install tsumiki-legacy@tsumiki +``` + +**注意**: レガシーコマンドは `/tsumiki-legacy:` プレフィックス付きで実行します（例：`/tsumiki-legacy:kairo-requirements`）。本マニュアルの Kairo / TDD / DIRECT セクションのコマンドがこれに該当します。 #### プロジェクト固有のルール設定 @@ -47,12 +57,14 @@ claude_docker/ ディレクトリを参考に構築してください（plugin ### Kairoコマンド（包括的フロー） +> **Legacy**: `init-tech-stack` / `kairo-requirements` / `kairo-design` / `kairo-tasks` / `kairo-loop` / `kairo-implement`（Skills版）はいずれもオプトインの `tsumiki-legacy` プラグインに含まれ、`/tsumiki-legacy:` プレフィックスで実行します。 + #### 1. 技術スタック初期化 プロジェクトの技術スタック（フレームワーク、ライブラリ）を初期化します： ``` -/tsumiki:init-tech-stack +/tsumiki-legacy:init-tech-stack ``` init-tech-stack は以下を生成します： @@ -64,7 +76,7 @@ init-tech-stack は以下を生成します： 最初に、プロジェクトの要件概要をKairoに伝えます： ``` -/tsumiki:kairo-requirements 要件概要 +/tsumiki-legacy:kairo-requirements 要件概要 # プロンプト例： # "ECサイトの商品レビュー機能を実装したい。 @@ -85,7 +97,7 @@ Kairoは以下を生成します： 要件を確認・修正した後、設計を依頼します： ``` -/tsumiki:kairo-design（または省略可能） +/tsumiki-legacy:kairo-design（または省略可能） # 要件を承認済みであることを伝えてください ``` @@ -104,12 +116,12 @@ Kairoは以下を生成します： 設計を確認した後（承認は省略可）、タスク分割を実行します： ``` -/tsumiki:kairo-tasks +/tsumiki-legacy:kairo-tasks # 設計を承認したことを伝えてください（または省略可能） ``` -タスク内容の確認用に `/tsumiki:kairo-task-verify` を実行することをお勧めします。 +タスク内容の確認用に `/tsumiki-legacy:kairo-task-verify` を実行することをお勧めします。 Kairoは以下を生成します： - 依存関係を考慮したタスク一覧 @@ -124,13 +136,13 @@ Kairoは以下を生成します： ``` # 全タスクを順番に実装 -/tsumiki:kairo-implement +/tsumiki-legacy:kairo-implement # 特定のタスクのみ実装 -/tsumiki:kairo-implement タスクファイル名　TASK番号 +/tsumiki-legacy:kairo-implement タスクファイル名　TASK番号 # タスク範囲を指定して実装 タスクディレクトリ名　開始TASK番号 終了TASK番号 -/tsumiki:kairo-loop +/tsumiki-legacy:kairo-loop （実行中にcompactが発動しても安定して「長時間処理」が可能です） ``` @@ -147,7 +159,7 @@ Kairoは各タスクに対して内部的にTDDコマンドを使用して以下 Skills版のkairo-implementは、Claude Codeのタスクシステムと連携した高度な実装スキルです。 ``` -/tsumiki:kairo-implement [要件名] [TASK-ID] [--hil] +/tsumiki-legacy:kairo-implement [要件名] [TASK-ID] [--hil] ``` **特徴**: @@ -162,38 +174,42 @@ Skills版のkairo-implementは、Claude Codeのタスクシステムと連携し ### TDDコマンド +> **Legacy**: TDDコマンドはオプトインの `tsumiki-legacy` プラグインに含まれ、`/tsumiki-legacy:` プレフィックスで実行します。 + TASK作成時に `TDD` と判定している場合で個別にTDDプロセスを実行したい場合は、以下のコマンドを順次実行できます： ``` # TDD要件定義 -/tsumiki:tdd-requirements タスクファイル名　TASK番号 +/tsumiki-legacy:tdd-requirements タスクファイル名　TASK番号 # テストケース作成 -/tsumiki:tdd-testcases タスクファイル名　TASK番号 +/tsumiki-legacy:tdd-testcases タスクファイル名　TASK番号 # テスト実装（Red） -/tsumiki:tdd-red タスクファイル名　TASK番号 +/tsumiki-legacy:tdd-red タスクファイル名　TASK番号 # 最小実装（Green） -/tsumiki:tdd-green タスクファイル名　TASK番号 +/tsumiki-legacy:tdd-green タスクファイル名　TASK番号 # リファクタリング -/tsumiki:tdd-refactor タスクファイル名　TASK番号 +/tsumiki-legacy:tdd-refactor タスクファイル名　TASK番号 # TDD完了確認 -/tsumiki:tdd-verify-complete タスクファイル名　TASK番号 +/tsumiki-legacy:tdd-verify-complete タスクファイル名　TASK番号 ``` ### DIRECTコマンド +> **Legacy**: DIRECTコマンドはオプトインの `tsumiki-legacy` プラグインに含まれ、`/tsumiki-legacy:` プレフィックスで実行します。 + TASK作成時に `DIRECT` と判定している場合は、以下のコマンドを順次実行できます： ``` # DIRECT準備 -/tsumiki:direct-setup タスクファイル名　TASK番号 +/tsumiki-legacy:direct-setup タスクファイル名　TASK番号 # DIRECT検証 -/tsumiki:direct-verify タスクファイル名　TASK番号 +/tsumiki-legacy:direct-verify タスクファイル名　TASK番号 ``` ### リバースエンジニアリングコマンド @@ -395,6 +411,68 @@ tsumikiの利用可能なコマンド一覧の表示、個別コマンドの詳 /tsumiki:timeout-fix ``` +#### その他のコマンド + +| コマンド | 説明 | +|---------|------| +| `adr-rubber-duck` | ADR（Architecture Decision Record）の壁打ち相手。ヒアリングで背景・制約・選択肢・トレードオフを深掘りし、ADRドラフトを作成 | +| `task-exec` | やりたいことを受け取り、詳細計画 → 計画のチェック → 実施 → 実施結果の確認まで一貫して実行 | + +``` +# ADRの壁打ち（引数は任意。ざっくりでOK） +/tsumiki:adr-rubber-duck 認証方式をJWTにするか検討したい + +# タスクの実施 +/tsumiki:task-exec 商品検索APIにページネーションを追加 +``` + +**adr-rubber-duck**は `AskUserQuestion` を主体としたヒアリングを繰り返し（最大15イテレーション）、必要に応じてコードベース調査・Web調査で選択肢の裏付けを取ります。既存ADRをスキャンして番号を自動採番し、今回の決定で置き換わる既存ADRの有無も確認します。出力は常に「ドラフト」ステータスで、署名・ステータス変更・push はユーザーが行います。 + +- 生成されるファイル: `docs/adr/{4桁連番}-{英語スラッグ}.md`（ADRドラフト）、`docs/adr/.sessions/{timestamp}_{スラッグ}.md`（壁打ちセッションログ） + +**task-exec**は計画と結果確認をメインで行い、それ以外の作業をサブエージェントに委譲します。コーディングは必ずサブエージェントによるTDDで実施し、作業は git worktree 上で行って完了時にマージします。不明点は `AskUserQuestion` で解消してから進めます。 + +### 汎用スキル + +| スキル | 説明 | +|-------|------| +| `task-breakdown` | 依頼をゴール/制約/前提に正規化し、トップダウンで構造分解してタスク分割結果（ツリー＋表）を生成 | +| `uat-test-design` | リポジトリを探索し、UAT（業務受入）・受入試験（システム受入）・非機能受入の試験項目一覧をL1/L2/L3の3階層で生成 | + +#### task-breakdown + +分野（開発・企画・運用など）を問わない汎用のタスク分割スキルです。「ゴール正規化 → 構造分解（1階層1軸）→ 粒度の停止条件 → 分割検証」の4フェーズで進め、MECE・依存関係・DoD・粒度の4観点で分割結果自体を検証します。 + +``` +# 依頼を直接渡す +/tsumiki:task-breakdown "社内向け勤怠管理システムの移行" + +# 要件ファイルを渡す +/tsumiki:task-breakdown docs/spec/attendance-requirements.md +``` + +- **standalone モード**: ユーザーが直接呼び出した場合。結果を提示した上で、保存先を `AskUserQuestion` で確認してファイル保存します +- **embedded モード**: 他のスキル/コマンドから分解目的で呼ばれた場合。ファイル保存せず、結果を呼び出し元に返却します +- 各判断には確信度（🔵 明示指示 / 🟡 妥当な推測 / 🔴 要確認）が付与され、🔴 は確認またはエスカレーションされます + +#### uat-test-design + +巨大プロジェクトにも対応できるよう、親エージェントは試験項目の本文を読まず、抽出処理を機能グループ単位でサブエージェントへ並列委譲する構成になっています。既存の仕様書・E2Eテスト・単体テストを名寄せし、自動テストでカバー済みの項目を UAT 本体から分離することで件数の肥大を防ぎます。 + +``` +/tsumiki:uat-test-design +``` + +実行の流れ: + +1. **インベントリ** — リポジトリを実測して情報源をマップ化。追加資料・実施環境・方針・出力先を `AskUserQuestion` で確認 +2. **分類** — 機能グループを導出し、仕様/E2E/単体テスト/画面の名寄せ表とIDレンジを作成 +3. **抽出** — グループ担当サブエージェントを並列起動してL2項目を抽出、別途L3（非機能）とL1（End-to-Endシナリオ）を生成 +4. **統合・レビュー** — index生成、独立レビューエージェントによる検証、件数妥当性チェック + +- 生成されるファイル: `docs/uat/{yyyymmdd}/` 配下に `index.md` / `L1-scenarios.md` / `L2-{グループ}.md` / `L2-{グループ}-covered.md`（自動テストカバー済み）/ `L3-nonfunctional.md` / `gaps.md` / `_inventory.md` / `_group-map.md` +- 出力形式は Markdown が既定。xlsx の追加出力も選択できます + ### セキュリティチェックスキル #### ipa-security-check @@ -490,6 +568,10 @@ IPA（情報処理推進機構）が公開する以下5つの公式資料に基 │ │ └── {要件名}/ │ ├── tasks/ # タスク一覧 │ │ └── {要件名}/ +│ ├── adr/ # ADR（adr-rubber-duck出力） +│ │ └── .sessions/ # 壁打ちセッションログ +│ ├── uat/ # UAT試験項目（uat-test-design出力） +│ │ └── {yyyymmdd}/ │ └── dev/ # Dev Skills出力 │ ├── context.md # プロジェクトコンテキスト │ └── plans/ # 実装計画 @@ -503,15 +585,15 @@ IPA（情報処理推進機構）が公開する以下5つの公式資料に基 ```mermaid flowchart TD - A[要件概要を伝える] --> B[tsumiki:kairo-requirements] + A[要件概要を伝える] --> B[tsumiki-legacy:kairo-requirements] B --> C{要件を確認} C -->|修正必要| B - C -->|OK| D[tsumiki:kairo-design] + C -->|OK| D[tsumiki-legacy:kairo-design] D --> E{設計を確認} E -->|修正必要| D - E -->|OK| F[tsumiki:kairo-tasks] + E -->|OK| F[tsumiki-legacy:kairo-tasks] F --> G{タスクを確認} - G -->|OK| H[tsumiki:kairo-implement] + G -->|OK| H[tsumiki-legacy:kairo-implement] H --> I{全タスク完了?} I -->|No| H I -->|Yes| J[プロジェクト完了] diff --git a/README.md b/README.md index 8121510..08fe374 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,17 @@ Tsumikiを使用するには、次のClaude Code Pluginコマンドでインス このコマンドを実行すると、TsumikiのClaude Codeスラッシュコマンドとエージェントが自動的にインストールされます。 -**注意**: コマンドは `/tsumiki:` プレフィックス付きで実行します（例：`/tsumiki:kairo-requirements`）。 +**注意**: コマンドは `/tsumiki:` プレフィックス付きで実行します（例：`/tsumiki:dev-plan`）。 + +### レガシープラグイン（オプトイン） + +`Kairo` / `TDD` / `DIRECT` の従来コマンドは、オプトインのレガシープラグイン `tsumiki-legacy` として分離されています。これらを利用する場合は、追加で次のコマンドを実行してください： + +```bash +/plugin install tsumiki-legacy@tsumiki +``` + +**注意**: レガシーコマンドは `/tsumiki-legacy:` プレフィックス付きで実行します（例：`/tsumiki-legacy:kairo-requirements`）。 ## 概要 @@ -23,39 +33,16 @@ Tsumikiは以下のカテゴリで構成されています： | カテゴリ | 説明 | |---------|------| -| **Kairo** | 要件定義から実装までの包括的な開発フロー | -| **TDD** | テスト駆動開発の個別実行 | | **Dev Skills** | コンテキスト分析・計画・実装・検証・デバッグの統合ワークフロー | | **DCS** | コードベースの分析・調査・ドキュメント生成 | | **ユーティリティ** | デバッグ支援・小規模修正・オーケストレーション等 | | **リバースエンジニアリング** | 既存コードからドキュメントを逆生成 | +| **Kairo**（Legacy） | 要件定義から実装までの包括的な開発フロー（`tsumiki-legacy` プラグイン） | +| **TDD**（Legacy） | テスト駆動開発の個別実行（`tsumiki-legacy` プラグイン） | +| **DIRECT**（Legacy） | 設定作業の実行・検証（`tsumiki-legacy` プラグイン） | ## 利用可能なコマンド -### Kairoコマンド（包括的開発フロー） - -Kairoは要件定義から実装までの開発プロセスを自動化・支援します。 - -| コマンド | 説明 | -|---------|------| -| `init-tech-stack` | 技術スタックの特定 | -| `kairo-requirements` | 要件定義（EARS記法） | -| `kairo-design` | 設計文書生成 | -| `kairo-tasks` | タスク分割 | -| `kairo-implement` | 実装実行（TDD/DIRECTを内部で使用） | -| `kairo-loop` | タスク範囲指定の自動連続実装（compact対応） | - -### TDDコマンド（個別実行） - -| コマンド | 説明 | -|---------|------| -| `tdd-requirements` | TDD要件定義 | -| `tdd-testcases` | テストケース作成 | -| `tdd-red` | テスト実装（Red） | -| `tdd-green` | 最小実装（Green） | -| `tdd-refactor` | リファクタリング | -| `tdd-verify-complete` | TDD完了確認 | - ### Dev Skills（統合開発ワークフロー） Dev Skillsは、プロジェクト分析から実装・検証・Webテストまでをカバーする統合的な開発スキル群です。 @@ -117,27 +104,64 @@ DCSはコードベースの分析・調査を支援するコマンドスイー | `rev-specs` | 既存コードからテスト仕様書を逆生成 | | `rev-requirements` | 既存コードから要件定義書を逆生成 | +### レガシーコマンド（`tsumiki-legacy` プラグイン） + +以下は従来の `Kairo` / `TDD` / `DIRECT` コマンドです。オプトインの `tsumiki-legacy` プラグイン（[インストール方法](#レガシープラグインオプトイン)）に含まれ、`/tsumiki-legacy:` プレフィックスで実行します。 + +#### Kairoコマンド（包括的開発フロー） + +| コマンド | 説明 | +|---------|------| +| `init-tech-stack` | 技術スタックの特定 | +| `kairo-requirements` | 要件定義（EARS記法） | +| `kairo-design` | 設計文書生成 | +| `kairo-tasks` | タスク分割 | +| `kairo-implement` | 実装実行（Skills版・TDD/DIRECTを内部で使用） | +| `kairo-loop` | タスク範囲指定の自動連続実装（compact対応） | + +#### TDDコマンド（個別実行） + +| コマンド | 説明 | +|---------|------| +| `tdd-requirements` | TDD要件定義 | +| `tdd-testcases` | テストケース作成 | +| `tdd-red` | テスト実装（Red） | +| `tdd-green` | 最小実装（Green） | +| `tdd-refactor` | リファクタリング | +| `tdd-verify-complete` | TDD完了確認 | + +#### DIRECTコマンド + +| コマンド | 説明 | +|---------|------| +| `direct-setup` | DIRECTタスクの設定作業を実行 | +| `direct-verify` | DIRECTタスクの設定作業を検証 | + +> **補足**: `kairo-implement` は Skills として提供され、上記コマンド群とともにすべて `tsumiki-legacy` プラグインに含まれます。 + ## クイックスタート -**注意**: Claude Code Pluginでインストールした場合は、各コマンドの先頭に `tsumiki:` を付けてください（例：`/tsumiki:kairo-requirements`）。 +**注意**: Claude Code Pluginでインストールした場合、基本コマンドは `tsumiki:`、レガシーコマンドは `tsumiki-legacy:` プレフィックスを付けてください。 + +### Kairoによる包括的な開発フロー（Legacy） -### Kairoによる包括的な開発フロー +`tsumiki-legacy` プラグインが必要です。 ```bash # 1. 技術スタック初期化 -/tsumiki:init-tech-stack +/tsumiki-legacy:init-tech-stack # 2. 要件定義 -/tsumiki:kairo-requirements +/tsumiki-legacy:kairo-requirements # 3. 設計 -/tsumiki:kairo-design +/tsumiki-legacy:kairo-design # 4. タスク分割 -/tsumiki:kairo-tasks +/tsumiki-legacy:kairo-tasks # 5. 実装（自動連続実装） -/tsumiki:kairo-loop +/tsumiki-legacy:kairo-loop ``` ### Dev Skillsによる開発フロー @@ -156,15 +180,17 @@ DCSはコードベースの分析・調査を支援するコマンドスイー /tsumiki:dev-verify auth ``` -### 個別TDDプロセス +### 個別TDDプロセス（Legacy） + +`tsumiki-legacy` プラグインが必要です。 ```bash -/tsumiki:tdd-requirements -/tsumiki:tdd-testcases -/tsumiki:tdd-red -/tsumiki:tdd-green -/tsumiki:tdd-refactor -/tsumiki:tdd-verify-complete +/tsumiki-legacy:tdd-requirements +/tsumiki-legacy:tdd-testcases +/tsumiki-legacy:tdd-red +/tsumiki-legacy:tdd-green +/tsumiki-legacy:tdd-refactor +/tsumiki-legacy:tdd-verify-complete ``` ### リバースエンジニアリング diff --git a/commands/adr-rubber-duck.md b/commands/adr-rubber-duck.md new file mode 100644 index 0000000..d27a1d8 --- /dev/null +++ b/commands/adr-rubber-duck.md @@ -0,0 +1,395 @@ +--- +description: ADR（Architecture Decision Record）の壁打ち相手としてヒアリングを通じて意思決定を整理し、ADRドラフトを作成する +allowed-tools: Read, Glob, Grep, Task, Write, Edit, AskUserQuestion, WebSearch, WebFetch, Bash(ls:*), Bash(mkdir:*), Bash(date:*) +argument-hint: "[検討したいアーキテクチャ上の決定事項（任意・ざっくりでOK）]" +--- +ざっくりとしたアーキテクチャ上の決定事項を聞きながら、AskUserQuestion を中心としたヒアリングで背景・制約・選択肢・トレードオフを根掘り葉掘り深掘りし、ADRドラフトを docs/adr/ に作成します。 + +# context + +ADR出力ディレクトリ="docs/adr" +セッションディレクトリ="docs/adr/.sessions" +カレントディレクトリ={{プロジェクトルート}} +セッションファイル="" +ADR番号="" +ADRファイル名="" +イテレーション回数=0 +最大イテレーション=15 +既存ADR一覧=[] +置き換え候補ADR=[] +置き換え対象ADR=[] +ヒアリング結果={背景と課題: "", 制約条件: [], 検討した選択肢: [], 決定: "", 決定理由: "", 影響: []} +調査結果=[] + +# steps + +## step1: 初期トピックの受け取り + +- $1 がある場合、初期トピックとして記録する +- $1 がない場合、ユーザーに「どのようなアーキテクチャ上の決定について検討したいですか？（ざっくりで構いません）」と尋ねる +- step2 を実行する + +## step2: 既存ADRのスキャンとセッション初期化 + +- {{ADR出力ディレクトリ}} を Glob（`docs/adr/*.md`）で検索し、既存ADR一覧を作成する + - 各ADRのファイル名・タイトル・ステータスを Read で確認する（ファイル数が多い場合は Task に委譲する） + - 既存ADRの最大番号 +1 を今回の ADR番号 とする（4桁ゼロ埋め。既存ADRがなければ 0001） +- 初期トピックと関連しそうな既存ADRがあれば 置き換え候補ADR として記録する（この時点では確定しない） +- セッションファイルを作成する + - {{セッションディレクトリ}} がなければ作成する + - トピックを 内容の英語化ルール に従って英語スラッグ化する + - セッションファイル名を "{{セッションディレクトリ}}/{{timestamp}}_{{スラッグ}}.md" とする + - 例: docs/adr/.sessions/20260706123456_use_postgresql.md + - の形式で初期情報を記録する +- step3 を実行する + +## step3: ヒアリングループ（深掘り） + +- イテレーション回数を +1 する +- ヒアリング観点ルール に従い、現在最も不足している観点を特定する +- AskUserQuestion で観点に沿った質問を行う（1回につき最大4問） + - 選択肢は具体的に書き、ユーザーが選ぶだけで答えられるようにする + - 自由記述が必要な深い理由・背景は「Other」で受けるか、テキストで補足質問する +- 回答を受けて、さらに深掘りが必要なら追加の AskUserQuestion を行う + - 「なぜそれが必要か」「それが満たされないと何が起きるか」まで掘り下げる +- 必要に応じて以下の調査を実施する： + - **コードベース調査**: Task/Grep/Read で現状のアーキテクチャ・依存関係・影響範囲を確認 + - **技術調査**: WebSearch/WebFetch で選択肢の比較情報・ベストプラクティスを収集 + - 調査結果は選択肢の長所・短所の裏付けとして 調査結果 に記録する +- 新しい情報を ヒアリング結果 に統合する +- セッションファイルを更新する（対話の要点・整理された内容・調査結果を追記） +- 次のアクションを判断するルール に基づいて判断し、該当するステップに進む + +## step4: 置き換え対象ADRの確認 + +- 置き換え候補ADR とヒアリング結果を突き合わせ、今回の決定によって無効化・上書きされる既存ADRを洗い出す +- 候補がある場合、AskUserQuestion で各候補が置き換え対象かどうかをユーザーに確認する + - 候補のタイトル・現在のステータス・今回の決定との関係を提示する +- 候補がない場合も「置き換えるべき既存ADRはありませんか？」と既存ADR一覧を提示して確認する +- 確定したものを 置き換え対象ADR に記録する +- step5 を実行する + +## step5: ADRドラフト作成 + +- の形式で ADRドラフトを作成する + - ステータスは「ドラフト」とする + - 署名欄は「（未署名）」とする + - 検討した選択肢には、採用しなかった選択肢も長所・短所付きで必ず記載する + - 置き換え対象ADR があれば「置き換えるADR」セクションに番号・タイトル付きで記載する。なければ「なし」と記載する +- ADRファイル名を "{{ADR出力ディレクトリ}}/{{ADR番号}}-{{スラッグ}}.md" として Write で出力する + - 例: docs/adr/0005-use-postgresql.md +- 置き換え対象の既存ADRファイルは更新しない（新ADRはまだドラフトのため） +- セッションファイルに完成したADRへのパスとサマリーを追記する +- step6 を実行する + +## step6: 完了報告とユーザーへの案内 + +- ユーザーに以下を報告する + - 作成したADRファイルのパス + - セッションファイルのパス + - ADRの要点サマリー（決定内容・置き換え対象ADR） +- 続けて、必ず以下の依頼事項をユーザーに伝える + +``` +ADRドラフトの作成が完了しました。以下の対応をお願いします。 + +1. ADRの内容を確認し、署名欄（起案者）に署名してください +2. ステータスを「ドラフト」から「提案済み」に変更してください +3. 変更をコミットして git push してください +{{置き換え対象ADRがある場合のみ: +4. このADRが「承認済み」になった際は、置き換え対象の {{旧ADR番号・タイトル}} のステータスを「置き換え」に更新してください}} +``` + +# rule + +## ヒアリング観点ルール + +以下の観点を順に埋めていく。既に十分な情報がある観点はスキップしてよいが、**背景と課題・検討した選択肢・決定理由は必須**。 + +### 観点1: 背景と課題（Why now） +- なぜ今この決定が必要になったのか +- 現状の何が問題なのか、放置すると何が起きるのか +- この決定のスコープ（システム全体か、特定コンポーネントか） + +### 観点2: 制約条件 +- 技術的制約（既存技術スタック、互換性、性能要件） +- 組織的制約（チームのスキルセット、運用体制） +- ビジネス的制約（期限、コスト、ライセンス） +- 満たさなければならない非機能要件（性能・セキュリティ・可用性・保守性） + +### 観点3: 検討した選択肢 +- 候補として何を検討したか（ユーザーが挙げていない有力候補があれば提案する） +- 各選択肢の長所・短所（調査結果で裏付ける） +- 「何もしない（現状維持）」も選択肢として検討したか + +### 観点4: 決定とトレードオフ +- どの選択肢を採用するか、決め手は何か +- 採用によって何を諦めるか（受け入れるデメリット） +- 判断が割れた点、迷った点はどこか + +### 観点5: 影響と結果 +- ポジティブな影響（何が良くなるか） +- ネガティブな影響・リスク（何が難しくなるか、将来の負債になり得る点） +- 既存ADR・既存設計への影響（置き換え候補の検出につなげる） +- 撤回条件（どうなったらこの決定を見直すか） + +## 深掘りのガイドライン + +- ユーザーの最初の説明は「ざっくり」であることを前提に、遠慮なく根掘り葉掘り聞く +- 1つの回答に対して「なぜ？」「具体的には？」「それが満たされないとどうなる？」を最低1段は掘り下げる +- 暗黙の前提を明示化する（「〜が前提になっていますが合っていますか？」） +- ユーザーの発言を言い換えて確認する +- 選択肢が1つしか出てこない場合は、対抗となる選択肢を必ず提案して比較させる +- エッジケースや「もし〜だったら？」の視点を提示する +- 押し付けがましくならないよう、提案は選択肢の一つとして柔らかく提示する + +## AskUserQuestion 利用ルール + +- 質問は AskUserQuestion を主体とし、ユーザーが選ぶだけで答えられる具体的な選択肢を用意する +- 1回の呼び出しで関連する質問をまとめる（最大4問） +- 選択肢には description で「選ぶとどうなるか・何を意味するか」を添える +- 推奨がある場合は先頭に置き「(Recommended)」を付ける +- 選択肢化できない深い理由・自由記述は、通常のテキスト対話で受ける + +## 次のアクションを判断するルール + +### step3 を継続する条件（以下のいずれかに該当） +- ヒアリング観点のうち必須観点（背景と課題・検討した選択肢・決定理由）が埋まっていない +- 選択肢の長所・短所が曖昧、または裏付けがない +- ユーザーがまだ迷っている・追加で検討したい点がある +- 追加の調査が必要 +- イテレーション回数が最大イテレーション未満 + +### step4 に進む条件（以下のすべてに該当） +- 必須観点が埋まり、矛盾がない +- ユーザーが決定内容に納得している（「これで良さそう」「まとめて」等の発言、または確認への同意） + +### セッション終了条件 +- イテレーション回数が最大イテレーションに達した場合、現状をまとめて step4 に進むことを提案する +- ユーザーが明示的に中断を希望した場合、セッションファイルに現状を保存して終了する + +## ADR番号とファイル名のルール + +### ADR番号 +- 4桁ゼロ埋めの連番（0001, 0002, ...） +- 既存ADRのファイル名先頭の番号の最大値 +1 を使用する +- 既存ADRがない場合は 0001 から開始する + +### 内容の英語化のルール +- 決定内容を簡潔な英語スラッグに変換する +- ケバブケース（kebab-case）を使用（ADRファイル名） +- セッションファイルはスネークケース（snake_case）を使用 +- 最大40文字程度に収める +- 例: + - 「PostgreSQLの採用」 → use-postgresql + - 「認証方式をJWTにする」 → use-jwt-authentication + - 「モノレポへの移行」 → migrate-to-monorepo + +### timestamp の形式 +- yyyyMMddHHmmss 形式（例: 20260706123456） + +## ファイルパスの記載ルール + +- **プロジェクトルートを基準とした相対パスを使用する** +- フルパス（絶対パス）は記載しない +- 例: + - ❌ `/Users/username/projects/myapp/docs/adr/0001-use-postgresql.md` + - ✅ `docs/adr/0001-use-postgresql.md` + +## ステータスのルール + +ADRのステータスは以下の5種類とする： + +| ステータス | 意味 | +|-----------|------| +| ドラフト | 起案中。本コマンドが出力する初期状態 | +| 提案済み | 起案者が署名し、レビュー・承認待ち | +| 承認済み | 承認者が署名し、有効な決定として確定 | +| 廃止 | 決定が無効になった（置き換えなし） | +| 置き換え | 新しいADRによって置き換えられた | + +- 本コマンドは常に「ドラフト」で出力し、ステータス変更はユーザーが行う +- 置き換え対象の旧ADRのステータス更新は、新ADRが「承認済み」になった時点でユーザーが行う（step6 で案内する） + +# info + + +# ADR壁打ちセッション + +**開始日時**: {{開始日時}} +**最終更新**: {{最終更新日時}} +**トピック**: {{トピック}} +**予定ADR番号**: {{ADR番号}} + +--- + +## 検討内容の概要 + +{{検討したい決定事項の概要}} + +--- + +## 対話ログ + +### イテレーション 1 ({{日時}}) + +**質問した観点**: {{観点}} + +**ユーザーの回答・発言**: +- {{回答の要点}} + +**深掘りで明らかになったこと**: +- {{要点1}} +- {{要点2}} + +--- + +（イテレーションごとに同様の形式で追記） + +--- + +## 整理されたヒアリング結果 + +### 背景と課題 +{{背景と課題}} + +### 制約条件 +- {{制約1}} +- {{制約2}} + +### 検討した選択肢 +1. **{{選択肢A}}** + - 長所: {{長所}} + - 短所: {{短所}} +2. **{{選択肢B}}** + - 長所: {{長所}} + - 短所: {{短所}} + +### 決定と理由 +{{決定内容と決め手}} + +### 影響・リスク +- {{影響1}} +- {{影響2}} + +--- + +## 調査結果 + +### 調査1: {{調査のタイトル}} +- **目的**: {{目的}} +- **方法**: {{コードベース調査 / WebSearch 等}} +- **結果**: {{結果}} +- **結論**: {{選択肢の評価にどう反映したか}} + +--- + +## 置き換え候補ADR + +- {{ADR番号・タイトル}}: {{関係の説明}} → {{置き換え対象に確定 / 対象外}} + +--- + +## 未解決の疑問点 + +- [ ] {{疑問点1}} +- [x] {{解決済みの疑問点}} + +--- + +## 成果物 + +- ADRドラフト: {{ADRファイルへの相対パス}} + + + +# {{ADR番号}}. {{タイトル}} + +## ステータス + +ドラフト + +## 署名 + +- 起案者: （未署名） +- 承認者: （未署名） + +## 日付 + +- 起案日: {{起案日 yyyy-MM-dd}} +- 承認日: - + +## コンテキスト + +{{背景・課題を記述する。なぜこの決定が必要になったのか、現状の何が問題なのか、 +放置するとどうなるのかを、この決定を知らない読者にも伝わるように書く}} + +### 制約条件 + +- {{技術的・組織的・ビジネス的制約}} +- {{満たすべき非機能要件}} + +## 検討した選択肢 + +### 選択肢A: {{選択肢名}} + +{{選択肢の概要}} + +- 長所: + - {{長所1}} + - {{長所2}} +- 短所: + - {{短所1}} + - {{短所2}} + +### 選択肢B: {{選択肢名}} + +（同様の形式。検討したすべての選択肢を記載する。「現状維持」を検討した場合はそれも含める） + +## 決定 + +{{採用する選択肢と、その決め手を記述する。 +トレードオフとして何を受け入れたのかも明記する}} + +## 結果・影響 + +### ポジティブな影響 + +- {{良くなること1}} +- {{良くなること2}} + +### ネガティブな影響・リスク + +- {{難しくなること・受け入れるデメリット}} +- {{将来の負債になり得る点}} + +### 撤回条件 + +- {{どうなったらこの決定を見直すか}} + +## 置き換えるADR + +{{置き換え対象がある場合: +- [{{旧ADR番号}}. {{旧ADRタイトル}}]({{旧ADRファイルへの相対パス}}) — {{置き換える理由}} + +このADRが「承認済み」になった時点で、上記ADRのステータスを「置き換え」に更新すること。}} + +{{置き換え対象がない場合: +なし}} + +## 参考資料 + +- {{調査で参照したURL・ドキュメント（あれば）}} + + +# 注意事項 + +- ユーザーの最初の入力はざっくりであることを前提に、遠慮なく深掘りする +- 質問は AskUserQuestion を主体にし、ユーザーの回答負荷を下げる +- 選択肢が1つしかない場合は対抗案を提案して必ず比較する +- 調査結果は選択肢の長所・短所の裏付けとして使い、出典があれば参考資料に記載する +- セッション内容は継続的にセッションファイルに保存する +- ADRは常に「ドラフト」ステータスで出力し、署名・ステータス変更・git push はユーザーに依頼する +- 置き換え対象の旧ADRファイルは本コマンドでは更新しない +- すべてのファイルパスは相対パスで記載する +- 対話が長くなったら適切に Task を利用してコンテキストを整理する diff --git a/commands/dcs/edgecase-analysis.md b/commands/dcs/edgecase-analysis.md index 91a7d93..3f7d572 100644 --- a/commands/dcs/edgecase-analysis.md +++ b/commands/dcs/edgecase-analysis.md @@ -65,7 +65,7 @@ argument-hint: [要件名] - 分析対象 = $1 - step1-source を実行する（ソースコードベースの分析） - "要件定義書を作成してから分析" を選択した場合: - - 「要件定義書の作成が必要です。先に `/tsumiki:kairo-requirements {要件名}` を実行してください」とメッセージを表示 + - 「要件定義書の作成が必要です。先に `/tsumiki:dev-plan {要件名} "{要件概要}"`（Full-spec モードで EARS 要件定義を作成）を実行してください」とメッセージを表示 - 終了する ## step1: 要件情報の収集（要件定義書ベース） diff --git a/commands/help.md b/commands/help.md index c0f3382..ba3d71e 100644 --- a/commands/help.md +++ b/commands/help.md @@ -39,24 +39,28 @@ args: {{args}} (引数。空=一覧表示、コマンド名=詳細、それ以 ## Kairo開発（要件定義〜実装の一気通貫開発） +> オプトインの `tsumiki-legacy` プラグインが必要です（`/plugin install tsumiki-legacy@tsumiki`）。 + | コマンド | 説明 | |---------|------| -| /tsumiki:kairo-requirements | 要件の概要からEARS記法を使用した詳細な要件定義書を作成 | -| /tsumiki:kairo-design | 承認された要件定義書に基づいて技術設計文書を生成 | -| /tsumiki:kairo-tasks | 設計文書に基づいて実装タスクを1日単位で分割・フェーズ管理 | -| /tsumiki:kairo-loop | 指定したTASK範囲のkairo実装を開始から終了まで順番に自動実行 | -| /tsumiki:kairo-implement | 分割されたタスクを順番に、またはユーザが指定したタスクをTDDで実装 | +| /tsumiki-legacy:kairo-requirements | 要件の概要からEARS記法を使用した詳細な要件定義書を作成 | +| /tsumiki-legacy:kairo-design | 承認された要件定義書に基づいて技術設計文書を生成 | +| /tsumiki-legacy:kairo-tasks | 設計文書に基づいて実装タスクを1日単位で分割・フェーズ管理 | +| /tsumiki-legacy:kairo-loop | 指定したTASK範囲のkairo実装を開始から終了まで順番に自動実行 | +| /tsumiki-legacy:kairo-implement | 分割されたタスクを順番に、またはユーザが指定したタスクをTDDで実装 | ## TDD開発（テスト駆動開発の各フェーズ） +> オプトインの `tsumiki-legacy` プラグインが必要です（`/plugin install tsumiki-legacy@tsumiki`）。 + | コマンド | 説明 | |---------|------| -| /tsumiki:tdd-requirements | TDD開発の要件整理。機能要件を明確化 | -| /tsumiki:tdd-testcases | 要件に基づいた包括的なテストケースの洗い出し | -| /tsumiki:tdd-red | Redフェーズ: 失敗するテストケースを作成 | -| /tsumiki:tdd-green | Greenフェーズ: テストを通す実装を行う | -| /tsumiki:tdd-refactor | Refactorフェーズ: コード品質の改善 | -| /tsumiki:tdd-verify-complete | すべてのテストケースの実装完了を検証 | +| /tsumiki-legacy:tdd-requirements | TDD開発の要件整理。機能要件を明確化 | +| /tsumiki-legacy:tdd-testcases | 要件に基づいた包括的なテストケースの洗い出し | +| /tsumiki-legacy:tdd-red | Redフェーズ: 失敗するテストケースを作成 | +| /tsumiki-legacy:tdd-green | Greenフェーズ: テストを通す実装を行う | +| /tsumiki-legacy:tdd-refactor | Refactorフェーズ: コード品質の改善 | +| /tsumiki-legacy:tdd-verify-complete | すべてのテストケースの実装完了を検証 | ## デバッグ・修正 @@ -70,11 +74,13 @@ args: {{args}} (引数。空=一覧表示、コマンド名=詳細、それ以 ## セットアップ +> オプトインの `tsumiki-legacy` プラグインが必要です（`/plugin install tsumiki-legacy@tsumiki`）。 + | コマンド | 説明 | |---------|------| -| /tsumiki:init-tech-stack | プロジェクト初期設定として技術スタックを選定 | -| /tsumiki:direct-setup | DIRECTタスクの設定作業（環境構築・設定ファイル・依存関係） | -| /tsumiki:direct-verify | DIRECTタスクの動作確認とテスト | +| /tsumiki-legacy:init-tech-stack | プロジェクト初期設定として技術スタックを選定 | +| /tsumiki-legacy:direct-setup | DIRECTタスクの設定作業（環境構築・設定ファイル・依存関係） | +| /tsumiki-legacy:direct-verify | DIRECTタスクの動作確認とテスト | ## リバースエンジニアリング（既存コードからドキュメント逆生成） @@ -152,16 +158,16 @@ args: {{args}} (引数。空=一覧表示、コマンド名=詳細、それ以 | テスト不安定, flaky, たまに落ちる, ランダムに失敗, 不安定なテスト | /tsumiki:flaky-fix | flakyテストの安定化 | | タイムアウト, テストが遅い, 時間がかかる, timeout | /tsumiki:timeout-fix | タイムアウト問題の改善・テスト分離 | | 環境エラー, パッケージ不足, 環境変数, npm ci, モジュール不足, Cannot find module | /tsumiki:env-fix | 環境依存問題の自動修正 | -| TDD, テスト駆動, テストから書きたい, テストファースト | /tsumiki:tdd-requirements | TDD開発の要件整理から開始 | -| 要件定義, 要件整理, 仕様を決めたい | /tsumiki:kairo-requirements | EARS記法による要件定義書作成 | -| 設計, アーキテクチャ, 技術設計 | /tsumiki:kairo-design | 技術設計文書の生成 | -| タスク分割, 実装計画, スケジュール | /tsumiki:kairo-tasks | タスクの分割とフェーズ管理 | -| 実装したい, コードを書きたい, 機能追加, 一気通貫 | /tsumiki:kairo-loop | TASK範囲のkairo実装を自動実行 | -| タスク実装, TDD実装, kairo実装, タスクを実装したい | /tsumiki:kairo-implement | 分割されたタスクをTDDで順番に実装 | -| 技術スタック, プロジェクト初期設定, 初期化 | /tsumiki:init-tech-stack | 技術スタックの選定 | +| TDD, テスト駆動, テストから書きたい, テストファースト | /tsumiki-legacy:tdd-requirements | TDD開発の要件整理から開始 | +| 要件定義, 要件整理, 仕様を決めたい | /tsumiki-legacy:kairo-requirements | EARS記法による要件定義書作成 | +| 設計, アーキテクチャ, 技術設計 | /tsumiki-legacy:kairo-design | 技術設計文書の生成 | +| タスク分割, 実装計画, スケジュール | /tsumiki-legacy:kairo-tasks | タスクの分割とフェーズ管理 | +| 実装したい, コードを書きたい, 機能追加, 一気通貫 | /tsumiki-legacy:kairo-loop | TASK範囲のkairo実装を自動実行 | +| タスク実装, TDD実装, kairo実装, タスクを実装したい | /tsumiki-legacy:kairo-implement | 分割されたタスクをTDDで順番に実装 | +| 技術スタック, プロジェクト初期設定, 初期化 | /tsumiki-legacy:init-tech-stack | 技術スタックの選定 | | 複雑なタスク, 自動化, 一括実行, 複数ステップ | /tsumiki:orchestrate | エージェントチームによる自動実行 | -| 設定作業, 環境構築, セットアップ | /tsumiki:direct-setup | DIRECT設定作業の実行 | -| 動作確認, 設定検証 | /tsumiki:direct-verify | DIRECTタスクの動作確認 | +| 設定作業, 環境構築, セットアップ | /tsumiki-legacy:direct-setup | DIRECT設定作業の実行 | +| 動作確認, 設定検証 | /tsumiki-legacy:direct-verify | DIRECTタスクの動作確認 | | リバースエンジニアリング, 既存コード分析, ドキュメント逆生成, タスク抽出 | /tsumiki:rev-tasks | 既存コードからタスク一覧を整理 | | 既存コード設計, 設計書逆生成, アーキテクチャ抽出 | /tsumiki:rev-design | 既存コードから技術設計文書を逆生成 | | 仕様逆生成, テストケース抽出, 仕様書生成 | /tsumiki:rev-specs | 既存コードからテストケース・仕様書を逆生成 | diff --git a/commands/task-exec.md b/commands/task-exec.md new file mode 100644 index 0000000..2391367 --- /dev/null +++ b/commands/task-exec.md @@ -0,0 +1,13 @@ +--- +description: タスクの作業を実施する +argument-hint: "<やりたいこと>" +--- +エージェントやサブエージェントやワークフローを積極的に活用。 opus/sonnet/haiku/fable を利用する +要望を元にして詳細な計画、計画のチェック、実施、実施結果の確認まで実施して完了とする +計画と実施結果の確認とそれ以外の管理はメイン部分で行い、それ以外はサブエージェントに任せる +実施のタスクは計画を検証可能なレベルまで詳細化してから実施する。定期的にチェックを実行し不足が見つかったら差し戻しての再実施を行う。 +チェック時に作業的な問題が見つかった場合は問題が起きないように計画の詳細化の実施も検討する +コーディング作業は必ずサブエージェントを利用してTDDで行い、最後に計画通りか確認する。不足があれば対処する +作業はgit worktree上で行い。完了時にマージする。完了後はメインのブランチに戻す。不要なworktreeは消す +不明点は解消するまでAskUserQuestionで質問する +詳しく知らない内容はWebにアクセスして確認する diff --git a/legacy/.claude-plugin/plugin.json b/legacy/.claude-plugin/plugin.json new file mode 100644 index 0000000..6c9d86e --- /dev/null +++ b/legacy/.claude-plugin/plugin.json @@ -0,0 +1,15 @@ +{ + "name": "tsumiki-legacy", + "version": "1.5.0", + "description": "Legacy Tsumiki commands (kairo, tdd, direct workflows) provided as an opt-in plugin for backward compatibility", + "author": { + "name": "makoto kuroeda", + "email": "kuroeda.makoto@classmethod.jp" + }, + "homepage": "https://github.com/classmethod/tsumiki", + "repository": "https://github.com/classmethod/tsumiki", + "license": "MIT", + "keywords": ["ai-development", "sdd", "tdd", "legacy"], + "commands": "./commands/", + "skills": "./skills/" +} diff --git a/commands/direct-setup.md b/legacy/commands/direct-setup.md similarity index 98% rename from commands/direct-setup.md rename to legacy/commands/direct-setup.md index e1b9848..1f35a97 100644 --- a/commands/direct-setup.md +++ b/legacy/commands/direct-setup.md @@ -197,7 +197,7 @@ psql -d mydb -f database-schema.sql ## 次のステップ -- `/tsumiki:direct-verify` を実行して設定を確認 +- `/tsumiki-legacy:direct-verify` を実行して設定を確認 - 必要に応じて設定の調整を実施 ``` diff --git a/commands/direct-verify.md b/legacy/commands/direct-verify.md similarity index 99% rename from commands/direct-verify.md rename to legacy/commands/direct-verify.md index de1eedb..c82f03a 100644 --- a/commands/direct-verify.md +++ b/legacy/commands/direct-verify.md @@ -12,7 +12,7 @@ DIRECTタスクで実行した設定作業の動作確認とテストを行い ## 前提条件 -- `/tsumiki:direct-setup` が実行済み +- `/tsumiki-legacy:direct-setup` が実行済み - タスクIDが提供されている - 設定作業の記録が存在する diff --git a/commands/init-tech-stack.md b/legacy/commands/init-tech-stack.md similarity index 100% rename from commands/init-tech-stack.md rename to legacy/commands/init-tech-stack.md diff --git a/commands/kairo-design.md b/legacy/commands/kairo-design.md similarity index 99% rename from commands/kairo-design.md rename to legacy/commands/kairo-design.md index 7ccb306..24e6d36 100644 --- a/commands/kairo-design.md +++ b/legacy/commands/kairo-design.md @@ -55,7 +55,7 @@ Kairo開発の技術設計を実施し、PRD・EARS要件定義書・既存設 - **タスクノートの読み込み** - `docs/spec/{要件名}/note.md` が存在する場合は読み込み - 存在しない場合: - - Task ツールを使用して subagent_type: "general-purpose" で `/tsumiki:kairo-tasknote {要件名}` コマンドを実行してノートを生成 + - Task ツールを使用して subagent_type: "general-purpose" で `/tsumiki-legacy:kairo-tasknote {要件名}` コマンドを実行してノートを生成 - 生成されたノートファイルを読み込み - ノートには技術スタック、開発ルール、関連実装、設計文書、注意事項が含まれる @@ -273,7 +273,7 @@ AskUserQuestion ツールを使って、選択された項目に応じた質問 - 各ファイル内のリンクが正しく設定されていることを確認 - 既存実装との整合性確認を促すメッセージ -- 次のステップ表示: 「次のお勧めステップ: `/tsumiki:kairo-tasks {要件名}` でタスク分割を実施します。」 +- 次のステップ表示: 「次のお勧めステップ: `/tsumiki-legacy:kairo-tasks {要件名}` でタスク分割を実施します。」 # rules diff --git a/commands/kairo-loop.md b/legacy/commands/kairo-loop.md similarity index 94% rename from commands/kairo-loop.md rename to legacy/commands/kairo-loop.md index aafc565..0bc6c15 100644 --- a/commands/kairo-loop.md +++ b/legacy/commands/kairo-loop.md @@ -10,7 +10,7 @@ argument-hint: "[要件名] [開始TASK-ID (TASK-00001)] [終了TASK-ID (TASK-00 $0 の $1 から順番に実行してください。 $2 まで完了したら一旦終了して。 以下の作業を実施してください -- /tsumiki:kairo-implement を理解して、skillの内容に正確に従ってください +- /tsumiki-legacy:kairo-implement を理解して、skillの内容に正確に従ってください - 実施する内容を全てtodoに詳細に記録してください。 - 品質確認の段階で戻る処理をするときは以下の手順を組み込んでください - 品質の確認処理 diff --git a/commands/kairo-requirements.md b/legacy/commands/kairo-requirements.md similarity index 99% rename from commands/kairo-requirements.md rename to legacy/commands/kairo-requirements.md index 9b168b8..fb54391 100644 --- a/commands/kairo-requirements.md +++ b/legacy/commands/kairo-requirements.md @@ -56,7 +56,7 @@ PRDファイル={{prd_file_path}} - **タスクノートの読み込み** - `docs/spec/{要件名}/note.md` が存在する場合は読み込み - 存在しない場合: - - Task ツールを使用して subagent_type: "general-purpose" で `/tsumiki:kairo-tasknote {要件名}` コマンドを実行してノートを生成 + - Task ツールを使用して subagent_type: "general-purpose" で `/tsumiki-legacy:kairo-tasknote {要件名}` コマンドを実行してノートを生成 - 生成されたノートファイルを読み込み - ノートには技術スタック、開発ルール、関連実装、設計文書、注意事項が含まれる @@ -283,7 +283,7 @@ AskUserQuestion ツールを使って、選択された項目に応じた質問 - 各ファイル内のリンクが正しく設定されていることを確認 - 既存設計書・実装との整合性確認を促すメッセージ -- 次のステップ表示: 「次のお勧めステップ: `/tsumiki:kairo-design {要件名}` で技術設計文書を作成します。」 +- 次のステップ表示: 「次のお勧めステップ: `/tsumiki-legacy:kairo-design {要件名}` で技術設計文書を作成します。」 # rules diff --git a/commands/kairo-tasknote.md b/legacy/commands/kairo-tasknote.md similarity index 100% rename from commands/kairo-tasknote.md rename to legacy/commands/kairo-tasknote.md diff --git a/commands/kairo-tasks.md b/legacy/commands/kairo-tasks.md similarity index 94% rename from commands/kairo-tasks.md rename to legacy/commands/kairo-tasks.md index da4af4a..3dc2961 100644 --- a/commands/kairo-tasks.md +++ b/legacy/commands/kairo-tasks.md @@ -72,7 +72,7 @@ claude_code_task登録={{register_to_claude_code_task}} - **タスクノートの読み込み** - `docs/spec/{要件名}/note.md` が存在する場合は読み込み - 存在しない場合: - - Task ツールを使用して subagent_type: "general-purpose" で `/tsumiki:kairo-tasknote {要件名}` コマンドを実行してノートを生成 + - Task ツールを使用して subagent_type: "general-purpose" で `/tsumiki-legacy:kairo-tasknote {要件名}` コマンドを実行してノートを生成 - 生成されたノートファイルを読み込み - ノートには技術スタック、開発ルール、関連実装、設計文書、注意事項が含まれる @@ -341,7 +341,7 @@ AskUserQuestion ツールを使って、選択された項目に応じた質問 - `--task` オプションが指定されている場合は step6.5 を実行する - そうでない場合は次のステップ表示へ -次のステップ表示: 「次のお勧めステップ: `/tsumiki:kairo-implement` でタスクを実装します。特定のタスクを実装する場合は `/tsumiki:kairo-implement TASK-0001` のように指定してください。」 +次のステップ表示: 「次のお勧めステップ: `/tsumiki-legacy:kairo-implement` でタスクを実装します。特定のタスクを実装する場合は `/tsumiki-legacy:kairo-implement TASK-0001` のように指定してください。」 ### 6.5 Claude Codeタスクへの登録（--taskオプション指定時のみ） @@ -415,7 +415,7 @@ AskUserQuestion ツールを使って、選択された項目に応じた質問 タスクの確認: TaskList ツールで確認できます タスクの開始: TaskUpdate で status を 'in_progress' に変更してください - 次のお勧めステップ: `/tsumiki:kairo-implement` でタスクを実装します。 + 次のお勧めステップ: `/tsumiki-legacy:kairo-implement` でタスクを実装します。 ``` #### 注意事項 @@ -507,16 +507,16 @@ AskUserQuestion ツールを使って、選択された項目に応じた質問 ## タスクプロセス定義 ### TDDタスク -1. `/tsumiki:tdd-requirements` - 詳細要件定義 -2. `/tsumiki:tdd-testcases` - テストケース作成 -3. `/tsumiki:tdd-red` - テスト実装（失敗） -4. `/tsumiki:tdd-green` - 最小実装 -5. `/tsumiki:tdd-refactor` - リファクタリング -6. `/tsumiki:tdd-verify-complete` - 品質確認 +1. `/tsumiki-legacy:tdd-requirements` - 詳細要件定義 +2. `/tsumiki-legacy:tdd-testcases` - テストケース作成 +3. `/tsumiki-legacy:tdd-red` - テスト実装（失敗） +4. `/tsumiki-legacy:tdd-green` - 最小実装 +5. `/tsumiki-legacy:tdd-refactor` - リファクタリング +6. `/tsumiki-legacy:tdd-verify-complete` - 品質確認 ### DIRECTタスク -1. `/tsumiki:direct-setup` - 直接実装・設定 -2. `/tsumiki:direct-verify` - 動作確認・品質確認 +1. `/tsumiki-legacy:direct-setup` - 直接実装・設定 +2. `/tsumiki-legacy:direct-verify` - 動作確認・品質確認 ## Claude Codeタスク登録のルール @@ -580,7 +580,7 @@ metadata: { ### 基本的な使用方法 ``` -/tsumiki:kairo-tasks ユーザー認証システム --task +/tsumiki-legacy:kairo-tasks ユーザー認証システム --task ``` このコマンドは以下を実行します： @@ -590,7 +590,7 @@ metadata: { ### オプションなしの使用方法 ``` -/tsumiki:kairo-tasks ユーザー認証システム +/tsumiki-legacy:kairo-tasks ユーザー認証システム ``` タスクファイルのみを作成し、Claude Codeタスクシステムには登録しません。 @@ -859,8 +859,8 @@ TASK-0001 → TASK-0002 → TASK-0011 → TASK-0012 → TASK-0021 → TASK-0031 ## 次のステップ タスクを実装するには: -- 全タスク順番に実装: `/tsumiki:kairo-implement` -- 特定タスクを実装: `/tsumiki:kairo-implement TASK-0001` +- 全タスク順番に実装: `/tsumiki-legacy:kairo-implement` +- 特定タスクを実装: `/tsumiki-legacy:kairo-implement TASK-0001` @@ -1001,17 +1001,17 @@ describe('{テスト対象}', () => { ### TDDタスクの場合 -1. `/tsumiki:tdd-requirements TASK-{番号}` - 詳細要件定義 -2. `/tsumiki:tdd-testcases` - テストケース作成 -3. `/tsumiki:tdd-red` - テスト実装（失敗） -4. `/tsumiki:tdd-green` - 最小実装 -5. `/tsumiki:tdd-refactor` - リファクタリング -6. `/tsumiki:tdd-verify-complete` - 品質確認 +1. `/tsumiki-legacy:tdd-requirements TASK-{番号}` - 詳細要件定義 +2. `/tsumiki-legacy:tdd-testcases` - テストケース作成 +3. `/tsumiki-legacy:tdd-red` - テスト実装（失敗） +4. `/tsumiki-legacy:tdd-green` - 最小実装 +5. `/tsumiki-legacy:tdd-refactor` - リファクタリング +6. `/tsumiki-legacy:tdd-verify-complete` - 品質確認 ### DIRECTタスクの場合 -1. `/tsumiki:direct-setup` - 直接実装・設定 -2. `/tsumiki:direct-verify` - 動作確認・品質確認 +1. `/tsumiki-legacy:direct-setup` - 直接実装・設定 +2. `/tsumiki-legacy:direct-verify` - 動作確認・品質確認 --- @@ -1108,17 +1108,17 @@ describe('{テスト対象}', () => { ### TDDタスクの場合 -1. `/tsumiki:tdd-requirements TASK-{番号}` - 詳細要件定義 -2. `/tsumiki:tdd-testcases` - テストケース作成 -3. `/tsumiki:tdd-red` - テスト実装（失敗） -4. `/tsumiki:tdd-green` - 最小実装 -5. `/tsumiki:tdd-refactor` - リファクタリング -6. `/tsumiki:tdd-verify-complete` - 品質確認 +1. `/tsumiki-legacy:tdd-requirements TASK-{番号}` - 詳細要件定義 +2. `/tsumiki-legacy:tdd-testcases` - テストケース作成 +3. `/tsumiki-legacy:tdd-red` - テスト実装（失敗） +4. `/tsumiki-legacy:tdd-green` - 最小実装 +5. `/tsumiki-legacy:tdd-refactor` - リファクタリング +6. `/tsumiki-legacy:tdd-verify-complete` - 品質確認 ### DIRECTタスクの場合 -1. `/tsumiki:direct-setup` - 直接実装・設定 -2. `/tsumiki:direct-verify` - 動作確認・品質確認 +1. `/tsumiki-legacy:direct-setup` - 直接実装・設定 +2. `/tsumiki-legacy:direct-verify` - 動作確認・品質確認 --- diff --git a/commands/tdd-green.md b/legacy/commands/tdd-green.md similarity index 98% rename from commands/tdd-green.md rename to legacy/commands/tdd-green.md index b5cf22c..f7643fd 100644 --- a/commands/tdd-green.md +++ b/legacy/commands/tdd-green.md @@ -30,7 +30,7 @@ Greenフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feature 1. **タスクノートの読み込み（唯一のコンテキストソース）** - `./docs/implements/{要件名}/{{task_id}}/note.md` を読み込み - - 存在しない場合: @task で `/tsumiki:tdd-tasknote {要件名} {{task_id}}` を実行して生成 + - 存在しない場合: @task で `/tsumiki-legacy:tdd-tasknote {要件名} {{task_id}}` を実行して生成 - note.mdには技術スタック、開発ルール、関連実装、設計文書、テスト関連情報、注意事項が集約済み 2. **直前フェーズの出力を読み込み** @@ -111,7 +111,7 @@ Greenフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feature - 品質判定結果をTODO内容に記録 - 次のフェーズ「Refactorフェーズ（品質改善）」をTODOに追加 -- **自動遷移判定**: 以下の条件を満たす場合は自動で `/tsumiki:tdd-refactor {要件名} {TASK-ID}` を実行 +- **自動遷移判定**: 以下の条件を満たす場合は自動で `/tsumiki-legacy:tdd-refactor {要件名} {TASK-ID}` を実行 - Taskツールを使用して全てのテストが成功していることを確認済み - 実装がシンプルで理解しやすい - 明らかなリファクタリング箇所がある diff --git a/commands/tdd-red.md b/legacy/commands/tdd-red.md similarity index 99% rename from commands/tdd-red.md rename to legacy/commands/tdd-red.md index 29bce71..2210d00 100644 --- a/commands/tdd-red.md +++ b/legacy/commands/tdd-red.md @@ -32,7 +32,7 @@ Redフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feature_n **1. タスクノートの読み込み（唯一のコンテキストソース）** - `./docs/implements/{要件名}/{{task_id}}/note.md` を読み込み -- 存在しない場合: @task で `/tsumiki:tdd-tasknote {要件名} {{task_id}}` を実行して生成 +- 存在しない場合: @task で `/tsumiki-legacy:tdd-tasknote {要件名} {{task_id}}` を実行して生成 - note.mdには技術スタック、開発ルール、関連実装、設計文書、テスト関連情報、注意事項が集約済み **2. 直前フェーズの出力を読み込み** @@ -115,7 +115,7 @@ Redフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feature_n - 品質判定結果をTODO内容に記録 - 次のフェーズ「Greenフェーズ（最小実装）」をTODOに追加 -- 次のステップ表示: 「次のお勧めステップ: `/tsumiki:tdd-green` でGreenフェーズ（最小実装）を開始します。」 +- 次のステップ表示: 「次のお勧めステップ: `/tsumiki-legacy:tdd-green` でGreenフェーズ（最小実装）を開始します。」 # rules diff --git a/commands/tdd-refactor.md b/legacy/commands/tdd-refactor.md similarity index 98% rename from commands/tdd-refactor.md rename to legacy/commands/tdd-refactor.md index 6c1dcd6..f8909ed 100644 --- a/commands/tdd-refactor.md +++ b/legacy/commands/tdd-refactor.md @@ -30,7 +30,7 @@ Refactorフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feat 1. **タスクノートの読み込み（唯一のコンテキストソース）** - `./docs/implements/{要件名}/{{task_id}}/note.md` を読み込み - - 存在しない場合: @task で `/tsumiki:tdd-tasknote {要件名} {{task_id}}` を実行して生成 + - 存在しない場合: @task で `/tsumiki-legacy:tdd-tasknote {要件名} {{task_id}}` を実行して生成 - note.mdには技術スタック、開発ルール、関連実装、設計文書、テスト関連情報、注意事項が集約済み 2. **直前フェーズの出力を読み込み** @@ -183,7 +183,7 @@ Refactorフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feat - コード品質: 適切なレベルに向上 - **次のステップ表示**: 判定結果に関わらず、次のお勧めコマンドを表示 - - 「次のお勧めステップ: `/tsumiki:tdd-verify-complete` で完全性検証を実行します。」 + - 「次のお勧めステップ: `/tsumiki-legacy:tdd-verify-complete` で完全性検証を実行します。」 # rules diff --git a/commands/tdd-requirements.md b/legacy/commands/tdd-requirements.md similarity index 97% rename from commands/tdd-requirements.md rename to legacy/commands/tdd-requirements.md index b77bbeb..8973643 100644 --- a/commands/tdd-requirements.md +++ b/legacy/commands/tdd-requirements.md @@ -31,7 +31,7 @@ TDD開発の要件整理を実施し、EARS要件定義書・設計文書を参 **タスクノートの読み込み** - `./docs/implements/{要件名}/{{task_id}}/note.md` が存在する場合は読み込み - 存在しない場合: - - @task で `/tsumiki:tdd-tasknote {要件名} {{task_id}}` コマンドを実行してノートを生成 + - @task で `/tsumiki-legacy:tdd-tasknote {要件名} {{task_id}}` コマンドを実行してノートを生成 - 生成されたノートファイルを読み込み - ノートには技術スタック、開発ルール、関連実装、設計文書、注意事項が含まれる @@ -61,7 +61,7 @@ TDD開発の要件整理を実施し、EARS要件定義書・設計文書を参 - 要件定義フェーズの完了をTODO内容に反映 - 次のフェーズ「テストケース洗い出し」をTODOに追加 - 品質判定結果をTODO内容に記録 -- 次のステップ表示: 「次のお勧めステップ: `/tsumiki:tdd-testcases {{要件名}} {{TASK-ID}}` でテストケースの洗い出しを行います。」 +- 次のステップ表示: 「次のお勧めステップ: `/tsumiki-legacy:tdd-testcases {{要件名}} {{TASK-ID}}` でテストケースの洗い出しを行います。」 # rules diff --git a/commands/tdd-tasknote.md b/legacy/commands/tdd-tasknote.md similarity index 100% rename from commands/tdd-tasknote.md rename to legacy/commands/tdd-tasknote.md diff --git a/commands/tdd-testcases.md b/legacy/commands/tdd-testcases.md similarity index 98% rename from commands/tdd-testcases.md rename to legacy/commands/tdd-testcases.md index 6cb5fa0..df4ab92 100644 --- a/commands/tdd-testcases.md +++ b/legacy/commands/tdd-testcases.md @@ -31,7 +31,7 @@ TDD開発のテストケース洗い出しを実施し、要件定義書を参 **1. タスクノートの読み込み（唯一のコンテキストソース）** - `./docs/implements/{要件名}/{{task_id}}/note.md` を読み込み - - 存在しない場合: @task で `/tsumiki:tdd-tasknote {要件名} {{task_id}}` を実行して生成 + - 存在しない場合: @task で `/tsumiki-legacy:tdd-tasknote {要件名} {{task_id}}` を実行して生成 - note.mdには技術スタック、開発ルール、関連実装、設計文書、テスト関連情報、注意事項が集約済み **2. 直前フェーズの出力を読み込み** @@ -74,7 +74,7 @@ TDD開発のテストケース洗い出しを実施し、要件定義書を参 - テストケース定義フェーズの完了をTODO内容に反映 - 次のフェーズ「Redフェーズ（失敗テスト作成）」をTODOに追加 - 品質判定結果をTODO内容に記録 -- 次のステップ表示: 「次のお勧めステップ: `/tsumiki:tdd-red {要件名} {{TASK-ID}}` でRedフェーズ（失敗テスト作成）を開始します。」 +- 次のステップ表示: 「次のお勧めステップ: `/tsumiki-legacy:tdd-red {要件名} {{TASK-ID}}` でRedフェーズ（失敗テスト作成）を開始します。」 # rules diff --git a/commands/tdd-todo.md b/legacy/commands/tdd-todo.md similarity index 100% rename from commands/tdd-todo.md rename to legacy/commands/tdd-todo.md diff --git a/commands/tdd-verify-complete.md b/legacy/commands/tdd-verify-complete.md similarity index 98% rename from commands/tdd-verify-complete.md rename to legacy/commands/tdd-verify-complete.md index 5cc60eb..e0c85c2 100644 --- a/commands/tdd-verify-complete.md +++ b/legacy/commands/tdd-verify-complete.md @@ -29,7 +29,7 @@ Refactorフェーズファイル=./docs/implements/{要件名}/{{task_id}}/{feat 1. **タスクノートの読み込み（唯一のコンテキストソース）** - `./docs/implements/{要件名}/{{task_id}}/note.md` を読み込み - - 存在しない場合: @task で `/tsumiki:tdd-tasknote {要件名} {{task_id}}` を実行して生成 + - 存在しない場合: @task で `/tsumiki-legacy:tdd-tasknote {要件名} {{task_id}}` を実行して生成 - note.mdには技術スタック、開発ルール、関連実装、設計文書、テスト関連情報、注意事項が集約済み 2. **直前フェーズの出力を読み込み** @@ -358,7 +358,7 @@ step7 を実行する 🚀 要件定義に対する完全な充実度を達成しました。 自動で次のTDDサイクルに進みます。 -次のお勧めステップ: `/tsumiki:tdd-cycle` で次のTDDサイクルを開始します。 +次のお勧めステップ: `/tsumiki-legacy:tdd-requirements` で次のタスクのTDDサイクルを開始します。 diff --git a/skills/kairo-implement/SKILL.md b/legacy/skills/kairo-implement/SKILL.md similarity index 95% rename from skills/kairo-implement/SKILL.md rename to legacy/skills/kairo-implement/SKILL.md index 0e4a992..c06d234 100644 --- a/skills/kairo-implement/SKILL.md +++ b/legacy/skills/kairo-implement/SKILL.md @@ -1,7 +1,7 @@ --- description: 分割されたタスクを順番に、またはユーザが指定したタスクを実装します。既存のTDDコマンドを活用して品質の高い実装を行います。 allowed-tools: Read, Glob, Grep, Task, Write, Edit, TodoWrite, AskUserQuestion, TaskList, TaskGet, TaskUpdate -allowed-skills: tsumiki:tdd-tasknote, tsumiki:tdd-requirements, tsumiki:tdd-testcases, tsumiki:tdd-red, tsumiki:tdd-green, tsumiki:tdd-refactor, tsumiki:tdd-verify-complete, tsumiki:direct-setup, tsumiki:direct-verify +allowed-skills: tsumiki-legacy:tdd-tasknote, tsumiki-legacy:tdd-requirements, tsumiki-legacy:tdd-testcases, tsumiki-legacy:tdd-red, tsumiki-legacy:tdd-green, tsumiki-legacy:tdd-refactor, tsumiki-legacy:tdd-verify-complete, tsumiki-legacy:direct-setup, tsumiki-legacy:direct-verify argument-hint: "[要件名（省略可）] [TASK-ID (TASK-00001)] [--hil]" --- あなたは実装担当者です。残タスクを調べて、指定されたコマンドを駆使して実装をしてください diff --git a/skills/kairo-implement/kairo-direct-process.md b/legacy/skills/kairo-implement/kairo-direct-process.md similarity index 94% rename from skills/kairo-implement/kairo-direct-process.md rename to legacy/skills/kairo-implement/kairo-direct-process.md index 8f8fc9d..b31cc5c 100644 --- a/skills/kairo-implement/kairo-direct-process.md +++ b/legacy/skills/kairo-implement/kairo-direct-process.md @@ -17,7 +17,7 @@ claude_task_id={{claude_task_id}} 以下の Task を実行する: ``` -@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki:direct-setup {{要件名}} {{TASK-ID}} +@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki-legacy:direct-setup {{要件名}} {{TASK-ID}} ``` 完了したら step-b を実行する @@ -27,7 +27,7 @@ claude_task_id={{claude_task_id}} 以下の Task を実行する: ``` -@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki:direct-verify {{要件名}} {{TASK-ID}} +@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki-legacy:direct-verify {{要件名}} {{TASK-ID}} ``` 完了したら step-c を実行する diff --git a/skills/kairo-implement/kairo-tdd-process.md b/legacy/skills/kairo-implement/kairo-tdd-process.md similarity index 91% rename from skills/kairo-implement/kairo-tdd-process.md rename to legacy/skills/kairo-implement/kairo-tdd-process.md index 2c74646..7ce32ec 100644 --- a/skills/kairo-implement/kairo-tdd-process.md +++ b/legacy/skills/kairo-implement/kairo-tdd-process.md @@ -20,7 +20,7 @@ claude_task_id={{claude_task_id}} 以下の Task を実行する: ``` -@Task tool (subagent_type: general-purpose, model: {{noteTaskName}}) /tsumiki:tdd-tasknote {{要件名}} {{TASK-ID}} +@Task tool (subagent_type: general-purpose, model: {{noteTaskName}}) /tsumiki-legacy:tdd-tasknote {{要件名}} {{TASK-ID}} ``` 完了したら step-b を実行する @@ -30,7 +30,7 @@ claude_task_id={{claude_task_id}} 以下の Task を実行する: ``` -@Task tool (subagent_type: general-purpose, model: {{thinkTaskName}}) /tsumiki:tdd-requirements {{要件名}} {{TASK-ID}} +@Task tool (subagent_type: general-purpose, model: {{thinkTaskName}}) /tsumiki-legacy:tdd-requirements {{要件名}} {{TASK-ID}} ``` 完了したら step-c を実行する @@ -40,7 +40,7 @@ claude_task_id={{claude_task_id}} 以下の Task を実行する: ``` -@Task tool (subagent_type: general-purpose, model: {{thinkTaskName}}) /tsumiki:tdd-testcases {{要件名}} {{TASK-ID}} +@Task tool (subagent_type: general-purpose, model: {{thinkTaskName}}) /tsumiki-legacy:tdd-testcases {{要件名}} {{TASK-ID}} ``` 完了後: @@ -81,7 +81,7 @@ AskUserQuestion ツールでユーザーの選択を取得する: 以下の Task を実行する: ``` -@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki:tdd-red {{要件名}} {{TASK-ID}} +@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki-legacy:tdd-red {{要件名}} {{TASK-ID}} ``` 完了したら step-e を実行する @@ -91,7 +91,7 @@ AskUserQuestion ツールでユーザーの選択を取得する: 以下の Task を実行する: ``` -@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki:tdd-green {{要件名}} {{TASK-ID}} +@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki-legacy:tdd-green {{要件名}} {{TASK-ID}} ``` 完了したら step-f を実行する @@ -101,7 +101,7 @@ AskUserQuestion ツールでユーザーの選択を取得する: 以下の Task を実行する: ``` -@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki:tdd-refactor {{要件名}} {{TASK-ID}} +@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki-legacy:tdd-refactor {{要件名}} {{TASK-ID}} ``` 完了したら step-g を実行する @@ -111,7 +111,7 @@ AskUserQuestion ツールでユーザーの選択を取得する: 以下の Task を実行する: ``` -@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki:tdd-verify-complete {{要件名}} {{TASK-ID}} +@Task tool (subagent_type: general-purpose, model: {{tddTaskName}}) /tsumiki-legacy:tdd-verify-complete {{要件名}} {{TASK-ID}} ``` 判定結果に応じた処理: diff --git a/skills/dev-plan/SKILL.md b/skills/dev-plan/SKILL.md index 3cecf59..20b1211 100644 --- a/skills/dev-plan/SKILL.md +++ b/skills/dev-plan/SKILL.md @@ -21,6 +21,10 @@ dev-context → [dev-plan] → dev-impl → dev-verify - `docs/dev/context.md` が存在すること（dev-contextで生成済み） - context.md がない場合、先に `/dev-context` の実行を案内する +### 依存スキル + +- **`task-breakdown`**: Full-spec モードの Phase 3（タスク分解）で、その4フェーズ分解手順を embedded 規約に準じてインライン適用する（詳細は Phase 3「Full-spec モード」参照）。 + ### 引数フォーマット ``` @@ -137,7 +141,11 @@ Plan サブエージェント（`subagent_type: Plan`）で関連コードベー ### Phase 3: タスク分解 -テスト可能な単位にタスクを分割する: +テスト可能な単位にタスクを分割する。**Full-spec モードでは `task-breakdown` スキルの分解手順をインライン適用し、Lightweight モードでは従来手順で分割する。** + +#### Lightweight モード + +メインコンテキスト内で以下を実施する: 1. **タスクの粒度**: 1タスク = 1つのテスト可能な振る舞い単位 2. **依存関係グラフ**: タスク間の実装順序を決定する @@ -145,6 +153,20 @@ Plan サブエージェント（`subagent_type: Plan`）で関連コードベー 4. **テスト方針**: 各タスクに「何をテストするか」を明記する 5. **ファイル影響範囲**: 各タスクが影響するファイルパスを列挙する +#### Full-spec モード（task-breakdown インライン適用） + +`task-breakdown` スキルの4フェーズ（ゴール正規化 → 構造分解 → 粒度停止 → 分割検証）を、**サブエージェントに委譲せずメインコンテキスト内でインライン適用**する。`skills/task-breakdown/SKILL.md` と `skills/task-breakdown/references/output-template.md` を Read で参照し、embedded モードの規約（ファイル保存せず結果を保持）に準じて進める。 + +1. **入力の受け渡し**: task-breakdown の Phase 1（ゴール正規化）へ、dev-plan で確定済みの文脈を以下のように渡す: + - **ゴール** ← Phase 1.5 の `requirements.md`（FR-XXX/NFR-XXX）と `acceptance-criteria.md`（AC-XXX の Given/When/Then） + - **制約** ← `requirements.md` の制約（CON-XXX）・非機能要件、context.md の技術スタック + - **前提** ← Phase 2 の設計成果物（インターフェース定義・データフロー・依存関係）と既存コード資産 + - **期待する葉タスク粒度** ← 「1タスク = dev-impl 1回で完了（テストファイル1つ + 実装ファイル1-2つ / テストケース3-8個）」を明示的に渡す +2. **Phase 1〜4 の適用**: 上記入力でゴールを正規化し、トップダウンで構造分解（1階層1軸）、粒度停止条件（見積もり可能・単独実施可能・検証可能・サイズ均一）を適用し、MECE・依存関係・DoD・粒度の4検証を通す。 + - task-breakdown の粒度停止条件は dev-plan の「dev-impl 1回で完了する単位」に読み替える。 + - 確信度 🔴 の未確定事項が残る場合は AskUserQuestion で解消してから Phase 4 に進む（embedded のエスカレーションをメイン側で受ける）。 +3. **出力の受け取り**: task-breakdown の成果物（`output-template.md` の 1.ゴール定義 / 2.分割ツリー / 3.葉タスク詳細（表）/ 4.検証結果）をメインコンテキストに保持する。この葉タスク群を Phase 4 でタスクファイルへ変換する（変換規則は Phase 4「葉タスク → タスクファイルの変換（Full-spec）」を参照）。 + ### Phase 4: ファイル出力 以下のディレクトリとファイルを生成する: @@ -196,12 +218,30 @@ docs/dev/plans// [他のPlanとの共有インターフェースがある場合に記載] ``` -Full-spec モードの場合、Requirements Summary に要件ドキュメントへの相対リンクを記載する。 +Full-spec モードの場合、Requirements Summary に要件ドキュメントへの相対リンクを記載する。また Task Dependency Graph には、Phase 3 で得た task-breakdown の「検証結果」（依存関係・トポロジカル順）をそのまま反映し、タスクファイルの `dependencies` と矛盾しないようにする。 #### タスクファイルの生成 各タスクを `docs/dev/plans//tasks/NNN-task-name.md` に出力する。`references/task-template.md` のテンプレートに従う。 +#### 葉タスク → タスクファイルの変換（Full-spec） + +Full-spec モードでは、Phase 3 で得た task-breakdown の葉タスク（`output-template.md` の「3. 葉タスク詳細（表）」）を、以下の対応でタスクファイルへ変換する: + +| task-breakdown の葉タスク | dev-plan タスクファイル | 変換方針 | +|---------------------------|-------------------------|----------| +| 葉タスク ID（T-XX） | フロントマター `id` | トポロジカル順に 001 から連番へ振り直す | +| タスク名 | フロントマター `title` / `# Task:` | 動詞始まりに整える | +| DoD / 受け入れ条件 | 本文 `## Test Strategy` | 検証可能な振る舞いのチェックリストへ具体化（正常系・異常系・エッジケース） | +| 依存（葉タスク ID） | フロントマター `dependencies` | 振り直した 001 形式の ID 配列へ変換 | +| 見積り（S/M/L） | フロントマター `estimated_complexity` | S→low / M→medium / L→high に対応 | +| 分割軸・親子位置 | フロントマター `priority` | インターフェース定義/基盤タスクを 1、以降を機能重要度で 2〜5 に設定 | +| 確信度（🔵🟡🔴） | 本文 `## Interfaces` の信号機 | Phase 2 設計のインターフェース確信度と突き合わせて付与 | +| Phase 2 設計のインターフェース | 本文 `## Interfaces` / `## Files` | 該当インターフェース定義と影響ファイルを転記 | + +- 葉タスクに紐づく Phase 2 の設計要素（型・インターフェース）を `## Interfaces` に転記し、`references/task-template.md` の記述ガイドに従って肉付けする。 +- task-breakdown の「4. 検証結果（依存関係・トポロジカル順）」を plan.md の Task Dependency Graph に反映する（Phase 4「plan.md の生成」参照）。 + ## 信号機システム 設計の各要素に確信度を付与する: @@ -226,6 +266,10 @@ Full-spec モードの場合、Requirements Summary に要件ドキュメント ## 追加リソース +### 依存スキル + +- **`task-breakdown`**（`skills/task-breakdown/`）— Full-spec モードの Phase 3 でインライン適用する汎用タスク分割スキル。`SKILL.md`（4フェーズと embedded 呼び出し規約）と `references/output-template.md`（分割ツリー・葉タスク表・検証結果の出力形式）を参照する。 + ### リファレンスファイル - **`references/task-template.md`** — タスクファイルのテンプレートとフロントマター仕様 diff --git a/skills/dev-plan/tests/spec.yaml b/skills/dev-plan/tests/spec.yaml new file mode 100644 index 0000000..b9b2a7e --- /dev/null +++ b/skills/dev-plan/tests/spec.yaml @@ -0,0 +1,49 @@ +# Auto-generated from SKILL.md by dev-skill-test --generate-spec +# Generated: 2026-03-30 +# NOTE: setup と conversation のプレースホルダーは人間が記入してください +skill: "tsumiki:dev-plan" +model: "sonnet" +permission_mode: "bypassPermissions" +max_budget_usd: 1.0 + +input: + args: 'test-feature "ユーザーのプロフィール画像をアップロードする機能を追加する"' + + # 対話フロー（SKILL.mdのフェーズ定義から雛形を生成） + conversation: + # Phase 0: モード選択 — AskUserQuestionで聞かれる + - reply: "Lightweightでお願いします" + # Phase 0.5: plan-name正規化 — 日本語の場合のみ + # Phase 1: 要件明確化 — スコープ・振る舞い・影響範囲を聞かれる（2-3ラウンド） + - reply: "画像はJPEGとPNGのみ、最大5MBまで。S3にアップロードする" + - reply: "既存のユーザー設定画面に追加する形。新規画面は不要" + # Phase 2-4: 設計・タスク分解・出力 — 主にサブエージェントで処理 + - reply: "はい、その設計で進めてください" + +# テスト実行前のセットアップ +setup: + - "mkdir -p src/routes src/services tests" + - "echo '{\"name\":\"test-project\",\"version\":\"1.0.0\",\"dependencies\":{\"express\":\"^4.18.0\"},\"devDependencies\":{\"vitest\":\"^1.0.0\",\"typescript\":\"^5.0.0\"},\"scripts\":{\"test\":\"vitest run\",\"build\":\"tsc\"}}' > package.json" + - "echo '{\"compilerOptions\":{\"target\":\"ES2022\",\"module\":\"ESNext\",\"strict\":true,\"outDir\":\"dist\"}}' > tsconfig.json" + - "mkdir -p docs/dev" + - "printf '# Project Context\\n\\n## Tech Stack\\n\\n| Category | Value |\\n|----------|-------|\\n| Language | TypeScript |\\n| Framework | Express |\\n| Test | Vitest |\\n\\n## Test Framework\\n\\n| Item | Value |\\n|------|-------|\\n| Framework | Vitest |\\n| Command | npm test |\\n\\n## Project Structure\\n\\n```\\nsrc/\\n routes/\\n services/\\ntests/\\n```\\n\\n## Coding Conventions\\n\\ncamelCase variables, kebab-case files\\n' > docs/dev/context.md" + +# Layer 2: 構造契約（SKILL.mdから自動抽出） +contracts: + - path: "docs/dev/plans/test-feature/plan.md" + exists: true + format: markdown + required_sections: + - "Requirements Summary" + - "Design Overview" + - "Task Dependency Graph" + - path: "docs/dev/plans/test-feature/tasks" + exists: true + +# Layer 3: 質的チェック（SKILL.mdのルール/禁止事項から自動生成） +checks: + - "タスクファイルが001から連番で命名されている" + - "各タスクにテスト方針が具体的な振る舞いで記述されている（曖昧表現を避けている）" + - "インターフェース定義にanyやunknownが使われていない" + - "信号機マーカー（🔵🟡🔴のいずれか）が設計要素に付与されている" + - "context.mdの技術スタック（TypeScript, Express, Vitest）に沿った設計になっている" diff --git a/skills/task-breakdown/SKILL.md b/skills/task-breakdown/SKILL.md new file mode 100644 index 0000000..e8791be --- /dev/null +++ b/skills/task-breakdown/SKILL.md @@ -0,0 +1,112 @@ +--- +name: task-breakdown +description: This skill should be used when the user asks to "task-breakdown", "タスク分割", "タスク分解", "タスクを分割", "タスクを分解", "WBSを作成", "作業分解", "break down task", "decompose task", "create WBS". 依頼をゴール/制約/前提に正規化し、トップダウンで構造分解（1階層1軸）、粒度の停止条件を適用し、MECE・依存関係・DoD を検証して、ツリー＋表のタスク分割結果を生成する。分野を問わない汎用スキルで、単独利用と他スキル/コマンドからの呼び出しの両方に対応。 +argument-hint: '"<分割したい依頼>" | <要件ファイルパス>' +--- + +# Task Breakdown（タスク分割） + +依頼を過不足なく実行可能なタスクへ分解するための汎用スキル。分野（開発・企画・運用など）を問わず使える。「ゴール正規化 → 構造分解 → 粒度停止 → 分割検証」の4フェーズで進める。 + +## 実行モード + +呼び出され方でモードが決まる。**引数や文脈からモードが自明な場合は確認不要**。 + +| モード | 起動条件 | 出力 | +|--------|----------|------| +| standalone | ユーザーが直接このスキルを呼ぶ | 分割結果を提示し、AskUserQuestion で保存先を確認してファイル保存 | +| embedded | 他スキル/コマンドの中から分解目的で呼ばれる | ファイル保存せず、分割結果を呼び出し元に返却する | + +embedded モードでは Phase の対話（AskUserQuestion）を最小化し、呼び出し元から渡された文脈で不明点を補う。渡された情報で埋まらない重大な不明点だけを呼び出し元にエスカレーションする。 + +## ワークフロー + +### Phase 1: ゴールへの正規化 + +依頼を「なにがどうなったら終わりか」で確定させる。 + +1. **完了状態を先に確定する**。5W1H（誰が・なにを・いつ・どこで・なぜ・どうやって）と受け入れ条件で、ゴール（終了状態）を言語化する。 +2. **細かい依頼は制約として分離する**。「〇〇形式で」「△△を使って」等の指定は目的そのものではないので、目的（ゴール）と混ぜず制約に回す。細かい依頼ほど、背景・目的を明示的に補って本来のゴールを推定する。 +3. **ゴール / 制約 / 前提 の3段に仕分ける**。 + - **ゴール**: 達成したい終了状態（受け入れ条件付き） + - **制約**: 守るべき条件（期限・技術・形式・運用ルールなど） + - **前提**: 成り立っていると仮定する外部条件・既存資産 +4. **不明点はユーザーに確認する**。ゴール・受け入れ条件・スコープ境界に関わる不明点は、AskUserQuestion で解消してから次へ進む（embedded モードでは呼び出し元の文脈を優先し、埋まらない点のみ確認）。確信度 🔴 の項目は必ず確認対象にする。 + +出力は `references/output-template.md` の「1. ゴール定義」に従う。 + +### Phase 2: トップダウンで構造分解 + +ゴールを起点に、親→子へと分解する。 + +1. **1階層＝1軸**で分割する。同じ階層で複数の軸を混在させない。 +2. **その階層に合った分割軸を選ぶ**。代表的な軸: + - **成果物ベース**: 最終的に作られる物・ドキュメント・機能単位で割る + - **フェーズ・時系列**: 調査→設計→実装→検証 のような時間順で割る + - **機能・コンポーネント**: サブシステム・担当領域で割る + - その他、ゴールの構造に最も素直に沿う軸を選ぶ +3. **子タスクの総和 = 親タスク**になるようにする。子を全部足すと親が過不足なく満たされる状態（この時点で MECE を意識する）。 +4. ゴールの構造に沿って、必要な深さまで階層を掘り下げる。停止判断は Phase 3 で行う。 + +出力は `references/output-template.md` の「2. 分割ツリー」に従い、各階層の軸を明示する。 + +### Phase 3: 粒度の停止条件 + +各枝について、以下を **すべて** 満たしたら「十分細かい」とみなし、それ以上分割しない（＝葉タスク）。 + +- **見積もり可能**: 所要工数・規模が見積もれる +- **単独で実施可能**: 他タスクの完了を待たずに（依存を解消すれば）着手・完了できる +- **検証可能**: 完了したかを客観的に判定できる（DoD が書ける） +- **サイズが揃っている**: 兄弟タスク・他の葉タスクと粒度が大きくずれていない + +1つでも満たさない枝は、Phase 2 に戻ってさらに分割する。逆に、細かすぎて他と粒度がずれる場合は統合する。 + +### Phase 4: 分割結果そのものの検証 + +出来上がった分割を、成果物として検証する。 + +1. **MECE チェック**: 漏れ（親を満たすのに足りない子がない）と重複（同じ作業が複数の葉に跨っていない）を確認する。 +2. **依存関係チェック**: 葉タスク間の依存を洗い出し、循環がないこと・実行順序（トポロジカル順）が成立することを確認する。 +3. **DoD / 受け入れ条件チェック**: すべての葉タスクに、検証可能な DoD があることを確認する。「正しく動く」等の曖昧表現は具体化する。 +4. **粒度チェック**: 葉タスクのサイズが揃っているかを再確認する。 + +問題があれば適切に対処する（不足の追加・重複の統合・依存の並べ替え・DoD の具体化）。対処後は再度チェックする。検証結果は `references/output-template.md` の「4. 検証結果」に記録する。 + +### Phase 5: 出力 + +`references/output-template.md` の構造（1.ゴール定義 → 2.分割ツリー → 3.葉タスク詳細（表）→ 4.検証結果）で成果物を組み立てる。 + +- **standalone モード**: 結果を提示したうえで、AskUserQuestion で保存先を確認し、Markdown ファイルとして保存する（例の選択肢: `docs/tasks//breakdown.md` / カレントに保存 / 保存しない）。 +- **embedded モード**: ファイルには保存せず、上記本文を呼び出し元に返す。呼び出し元が構造化データを求める場合は template の JSON 形状で返す。 + +## 呼び出し規約（他スキル/コマンドから利用する場合） + +将来の連携を想定した最小規約。他スキルは以下を渡してこのスキルを起動できる: + +- **入力**: 分解対象の依頼（自然言語）＋ 既知のゴール/制約/前提（あれば）＋ 期待する葉タスクの粒度（あれば）。 +- **モード指定**: embedded として起動されたことを明示する（ファイル保存を抑止し、結果を返却させるため）。 +- **出力**: `references/output-template.md` の本文（Markdown）、または同 template の JSON 形状。 +- **エスカレーション**: ゴール・スコープに関わる 🔴 未確定事項が残る場合のみ、呼び出し元に確認事項として返す。 + +## 信号機システム + +分割の各判断に確信度を付与する: + +- 🔵 **明示指示**: ユーザーの依頼・渡された文脈に明示された内容に基づく +- 🟡 **妥当な推測**: 一般的なベストプラクティスに基づくが、明示的な根拠はない +- 🔴 **要確認**: ゴール・スコープ・受け入れ条件に関わる判断で、ユーザー確認が必要 + +葉タスクの表と未確定事項に確信度を記録する。🔴 がある場合は standalone では AskUserQuestion で確認し、embedded では呼び出し元にエスカレーションする。 + +## ルール・制約 + +- ゴールが未確定のまま構造分解に進まない（Phase 1 を飛ばさない）。 +- 1階層に複数の分割軸を混在させない。 +- すべての葉タスクに検証可能な DoD を付ける。 +- MECE・依存関係・DoD・粒度の4検証を通してから出力する。 +- embedded モードではファイルを保存しない。standalone でも保存先は必ず AskUserQuestion で確認する（勝手に固定パスへ書かない）。 +- 対話は必要最小限にし、確認は AskUserQuestion に集約する。 + +## 追加リソース + +- **`references/output-template.md`** — ゴール定義・分割ツリー・葉タスク詳細（表）・検証結果の出力テンプレートと、embedded モードの返却形式（Markdown / JSON）。 diff --git a/skills/task-breakdown/references/output-template.md b/skills/task-breakdown/references/output-template.md new file mode 100644 index 0000000..ad0958d --- /dev/null +++ b/skills/task-breakdown/references/output-template.md @@ -0,0 +1,106 @@ +# タスク分割 出力テンプレート + +分割結果は「ツリー（全体像）」＋「表（葉タスクの詳細）」の2部構成で表現する。 +standalone モード（ファイル保存）と embedded モード（結果返却）で同じ本文構造を使う。 + +--- + +## 1. ゴール定義 + +依頼を正規化した結果を、ゴール / 制約 / 前提 の3段に仕分けて記載する。 + +```markdown +## ゴール定義 + +### ゴール（なにがどうなったら終わりか） +- <5W1H・受け入れ条件で確定させた完了状態> + +### 制約（守るべき条件・細かい依頼はここへ） +- <期限・予算・技術/運用制約・「〇〇の形式で」等の細かい指定> + +### 前提（成り立っていると仮定すること） +- <既に存在する資産・環境・依存する外部条件> + +### 未確定事項 +- 🔴 <ユーザー確認が必要だが未解決の点。解決済みなら削除> +``` + +--- + +## 2. 分割ツリー（全体像） + +各階層の**分割軸**を明示する（1階層＝1軸）。葉タスクには ID を振る。 + +```markdown +## 分割ツリー + +分割軸: L1=<成果物ベース> / L2=<フェーズ・時系列> / ... + +- 親タスク: <ゴール> + - [L1-A] <子タスク> 〔軸: 成果物〕 + - [T-A1] <葉タスク> + - [T-A2] <葉タスク> + - [L1-B] <子タスク> + - [T-B1] <葉タスク> +``` + +- 子タスクの総和が親を過不足なく満たす（MECE）ように構成する。 +- 葉タスク（これ以上分割しないもの）にのみ `T-` の ID を振る。 + +--- + +## 3. 葉タスク詳細（表） + +停止条件を満たした葉タスクを一覧化する。 + +```markdown +## 葉タスク詳細 + +| ID | タスク | 分割軸 | DoD / 受け入れ条件 | 見積り | 依存 | 確信度 | +|----|--------|--------|--------------------|--------|------|--------| +| T-A1 | <内容> | 成果物 | <検証可能な完了条件> | | - | 🔵 | +| T-A2 | <内容> | 成果物 | <検証可能な完了条件> | <> | T-A1 | 🟡 | +| T-B1 | <内容> | フェーズ | <検証可能な完了条件> | <> | T-A2 | 🔴 | +``` + +- **DoD** は「〜が動く」等の曖昧表現を避け、検証可能な状態で書く。 +- **依存** は先行して完了している必要がある葉タスクの ID（なければ `-`）。 +- **確信度**: 🔵 明示指示に基づく / 🟡 妥当な推測 / 🔴 要ユーザー確認。 + +--- + +## 4. 検証結果 + +分割そのものの妥当性チェック結果を記載する（詳細は SKILL.md の Phase 4 参照）。 + +```markdown +## 検証結果 + +- MECE（漏れ・重複なし）: ✅ / ⚠️ <指摘> +- 依存関係（循環なし・順序が成立）: ✅ / ⚠️ <指摘> +- 各葉に DoD あり: ✅ / ⚠️ <指摘> +- 粒度が揃っている: ✅ / ⚠️ <指摘> +- 実行順序（トポロジカル順の目安）: T-A1 → T-A2 → T-B1 → ... +``` + +--- + +## embedded モード（他スキル/コマンドからの呼び出し）での返却形式 + +ファイルには保存せず、上記 1〜4 の本文を Markdown 文字列として呼び出し元に返す。 +呼び出し元が構造化データを要求する場合は、次の JSON 形状でも返せる: + +```json +{ + "goal": "…", + "constraints": ["…"], + "assumptions": ["…"], + "openQuestions": ["…"], + "tree": [ + { "id": "L1-A", "title": "…", "axis": "成果物", "children": [ + { "id": "T-A1", "title": "…", "dod": "…", "estimate": "M", "dependsOn": [], "confidence": "🔵" } + ]} + ], + "verification": { "mece": true, "dependencies": true, "dodPresent": true, "sizeConsistent": true } +} +``` diff --git a/skills/uat-test-design/SKILL.md b/skills/uat-test-design/SKILL.md new file mode 100644 index 0000000..ae77e41 --- /dev/null +++ b/skills/uat-test-design/SKILL.md @@ -0,0 +1,62 @@ +--- +description: 任意のリポジトリを探索し、UAT（業務受入）・受入試験（システム受入）・非機能受入の試験項目一覧を L1/L2/L3 の3階層で生成します。巨大プロジェクト対応のため親は項目本文を読まず、抽出はサブエージェントへ並列委譲します +allowed-tools: Read, Glob, Grep, Bash, Agent, Write, Edit, AskUserQuestion, TaskCreate, TaskUpdate +--- + +任意のプロジェクトから UAT・受入試験の試験項目一覧を生成する汎用 skill。特定プロジェクトのパス・番号体系はハードコードせず、毎回実測して適応する。 + +# アーキテクチャ原則（必ず守る） + +1. **親（この skill を実行するエージェント）は試験項目の本文を読まない・書かない**（Phase 4 の散発修正を除く）。抽出サブエージェントが出力ファイルに直接書き、親はメタデータ要約のみ扱う +2. **ID レンジは親が事前配布**し、サブエージェントはレンジ内でのみ採番する +3. **読込は予算制**: サブエージェント 1 体 10,000 行 / 30 ファイルまで。超える担当範囲は分割してから委譲 +4. **除外は機械基準**（[references/source-categories.md](references/source-categories.md) §2）。名指し除外はしない +5. **★（低優先）情報源は逆引き専用**。全読み禁止 +6. **過去メモ・ドキュメント記載の件数・パスを信用しない**。inventory.sh で毎回実測する +7. **自動化カバレッジ判定を必ず行う**（[references/test-levels.md](references/test-levels.md) §7）。L2 の各項目について UnitTest / E2E でのカバー状況を判定し、分離条件を満たす項目は本文ごと `L2--covered.md` へ分離する（UAT 本体の件数肥大を防ぐ。迷ったら UAT 本体に残す） +8. **出力先は実行ごとに日付ディレクトリ**: 既定 `/docs/uat//`。実行開始時に `date +%Y%m%d` で決定し、同名ディレクトリが既に存在する場合は `date +%H%M` を付けた `-` を使う。以降の全フェーズ・全サブエージェントで同じ出力先を固定する + +# Phase 1: インベントリ + +1. **実測**: `bash {skill_dir}/scripts/inventory.sh ` を実行し、集計のみ読む（対象ファイルの本文は読まない） +2. **判定**: [references/source-categories.md](references/source-categories.md) に従い、(a) カテゴリごとの情報源候補、(b) [閾値超過]/[生成物] フラグから「精読 / 分割精読 / 逆引き専用 / 除外」の扱い、(c) 性質タグ（正 / 逆 / なし）を決める。カテゴリ検出のヒットが曖昧な場合のみ、候補パスの見出し・冒頭 20 行程度で裏取りしてよい +3. **ユーザ確認（AskUserQuestion、必須バッテリー）**: スキャン結果の要約（見つかった情報源 / 見つからなかったカテゴリ / 規模感）を提示した上で聞く: + - **追加資料**: リポジトリ外の要件定義・設計書・議事録等の有無（性質「正」が無い場合は特に強調して確認） + - **実施環境**: 環境名 / テナント / 外部サービス（決済・認証・通知）のサンドボックス・テストアカウントの有無（「不明」も回答として許容し前提欄に明記） + - **方針**（既定値を推奨として提示): 実施主体の範囲（UAT＋受入の両方が既定）/ 自動テストとの重複方針（**カバレッジ判定して分離条件該当項目を `L2--covered.md` へ分離するが既定**。test-levels.md §7。「分離せず判定列のみ付ける」も選択可）/ 非機能の範囲（含めるが既定） + - **出力**: フォーマット（markdown 既定、xlsx 追加可）/ 出力先（`/docs/uat//` 既定。原則 8 の規則で決定した実パスを提示する）/ 対象範囲の絞り込み +4. **成果物**: `_inventory.md`（情報源マップ。列: カテゴリ / パス / 規模 / 性質タグ / 扱い / 備考）を出力先に書く。以降の全フェーズはこれを正とする + +# Phase 2: 分類（委譲計画） + +1. **機能グループ一覧の導出**（優先順）: + 1. 機能グループを列挙した既存ドキュメント（feature-groups、機能一覧、README）があれば採用 + 2. なければ Explore サブエージェント 1 体に「ルーティング定義＋仕様ディレクトリ名から機能グループ一覧（10〜20 個目安）を合成」させる（読むのはファイル名・見出しのみ） + 3. それも困難なら画面一覧をグループとし、ユーザに提示して調整 +2. **名寄せ表**: グループごとに「仕様 / E2E spec / 単体テスト / 画面・ルート」の対応パスを表にする（単体テストは inventory.sh §3.5 の検出結果から対応づける。カバレッジ判定の入力になる）。パス名・見出しの文字列マッチで機械的に対応づけ、不確かな対応は `?` を付けて抽出サブエージェントに検証させる +3. **委譲計画**: グループごとの読込見積り（対応パスの行数合計）を出し、予算超過グループは分割。L3 用に非機能・運用担当 1 体を別途計画 +4. **ID レンジ配布**: [references/output-format.md](references/output-format.md) §4 の規約で割当。inventory.sh §3 の検出接頭辞と衝突しないか確認 +5. **成果物**: `_group-map.md`（名寄せ表＋ID レンジ＋読込見積り） + +# Phase 3: 抽出（並列委譲） + +[references/extraction-prompts.md](references/extraction-prompts.md) のテンプレートを実値で埋めて委譲する。**独立した委譲は 1 メッセージにまとめて並列実行**（model: 既定 sonnet）。 + +1. **グループ担当 × N**（テンプレート A）: L2 項目を抽出し、カバレッジ判定（test-levels.md §7）の上で UAT 対象を `L2-.md`、分離条件該当を `L2--covered.md` に直接書かせ、YAML メタデータ要約のみ受け取る。L1 候補は 1 行サマリで回収 +2. **L3 担当 × 1**(テンプレート C): `L3-nonfunctional.md` と `gaps.md`（情報源が無く項目化できない確認活動）を書かせる +3. 全グループの要約が揃ったら **L1 統合担当 × 1**（テンプレート B）: 全グループの L1 候補サマリを渡し、重複統合した End-to-End シナリオを `L1-scenarios.md` に書かせる +4. 要約の `sources_missing` / `budget_note` に問題があれば、該当グループのみ範囲を調整して再委譲 + +# Phase 4: 統合・レビュー + +1. **index 生成**: 親がメタデータ要約と各ファイルの見出し行（`grep '^### UAT-'`、covered ファイル含む）から `index.md` を生成（前提欄は [references/output-format.md](references/output-format.md) §2。性質「正」なしの場合のフォールバック文言を忘れない）。各項目に手動実施階層（test-levels.md §7。区分×カバレッジから機械導出）を付与し、**L2 のサマリ表は階層①〜④でサブセクション分割**、冒頭に機能グループ×階層の件数サマリを置く。サマリ表上で対象機能×観点が近い ID ペアを重複疑いとして列挙 +2. **独立レビュー**: [references/review-prompt.md](references/review-prompt.md) でレビューサブエージェントに委譲（総数 150 件超はサンプリング 30%）。指摘の反映は同ファイルの「親の後処理」に従う（系統的問題→グループ再実行 / 散発→親が該当セクションのみ Edit） +3. **件数妥当性**: [references/test-levels.md](references/test-levels.md) §6 の規模別目安と比較し、大きく外れたら原因（情報源不足 / 分割ミス / カバレッジ分離の効きすぎ・効かなさすぎ）をユーザに報告。UAT 本体件数と分離件数を分けて評価する +4. **xlsx 変換**（ユーザが選択した場合のみ): output-format.md §6 の構成で生成 +5. **完了報告**: 件数サマリ（L1 / L2 を手動実施階層①〜④別 / L3 / gaps）、トレース率、`sources_missing`・gaps の要点、レビュー指摘の反映状況、出力先ディレクトリを簡潔に報告する。項目本文の再掲はしない + +# 途中で詰まったら + +- 情報源カテゴリが軒並み「なし」: 続行せず、ユーザに資料所在を確認（コードのみからの生成は L2 の期待結果が創作になるため） +- グループ数が 30 超 or L2 見込みが 800 超: 対象範囲の絞り込み（フェーズ分割・優先機能の選定）を AskUserQuestion で提案 +- サブエージェントの要約が YAML 形式で返らない: 結果ファイルの見出し数（`grep -c '^### UAT-'`）で件数を代替集計し、再委譲はしない diff --git a/skills/uat-test-design/references/extraction-prompts.md b/skills/uat-test-design/references/extraction-prompts.md new file mode 100644 index 0000000..2f9838e --- /dev/null +++ b/skills/uat-test-design/references/extraction-prompts.md @@ -0,0 +1,108 @@ +# 抽出サブエージェント プロンプトテンプレート + +Phase 3 で親が Agent tool（general-purpose、model は既定 sonnet）に渡すプロンプトの定型。`{...}` を実値に置換する。**親は項目本文を受け取らない。サブエージェントは出力ファイルに直接書き、メタデータ要約のみ返す。** + +## A. 機能グループ担当（L2 抽出 + L1 候補） + +``` +あなたは UAT・受入試験項目の抽出担当です。機能グループ「{group}」を担当します。 + +## 読んでよいもの（読込予算: 合計 {budget:-10000} 行まで） +- 仕様: {spec_paths} +- E2E spec: {e2e_paths} +- 単体テスト: {unit_paths}（カバレッジ判定用。describe/test/@Test 名の grep のみ、アサーション本文の精読は不要） +- 画面: {page_paths}（ファイル名と主要コンポーネントの把握のみ、実装の精読は不要） +- 粒度基準: {skill_dir}/references/test-levels.md（必読。特に §7 カバレッジ判定） +- 出力仕様: {skill_dir}/references/output-format.md（必読） +- 逆引き専用（原則読まない。特定機能のエッジケース補完が必要な場合のみ、ファイル名 grep で該当上位2件まで）: {lookup_only_paths} + +## 環境前提（前提条件欄に反映すること） +{env_summary} + +## やること +1. 担当範囲の仕様・E2E spec を読み、L2 項目（1機能×1観点=1項目、観点: 正常/異常/境界/権限）を抽出する。 + test-levels.md §3 の「特に厚くする領域」に該当する機能は観点を厚めに取る。 +2. 自動化トレース: 担当 E2E spec に対し `grep -hoE '{tc_pattern}.*'` で ID と同一行の説明文を収集し、 + 各 L2 項目に対応 ID を紐づける（多対多可。対応がなければ「手動のみ」）。 +3. カバレッジ判定: test-levels.md §7 に従い、各 L2 項目に判定値（E2E / Unit / E2E+Unit / なし）を付ける。 + E2E は手順 2 の結果、Unit は担当単体テストの describe/test/@Test 名 grep で名前ベース判定する + （自信がなければ「なし」に倒す）。§7 の分離条件（E2E カバー済み・厚くする領域非該当・ + 本番相当環境価値なし・Validation 不要のすべて）を満たす項目は区分「自動カバー済み」とする。 + **カバレッジが「Unit」のみ・「なし」の項目は分離してはならない。迷ったら UAT 対象に残す。** +4. 要件トレース: {requirements_ref} に担当範囲の要件があれば紐づける。なければ「REQ なし」。 +5. ID は {id_range} の範囲内で採番する（範囲外は使用禁止。区分を跨いで通し採番でよい）。 +6. 項目本文を書く: UAT 対象は {output_file}、自動カバー済みは {covered_file} に + output-format.md §3 の型で直接書く（covered には分離理由行と冒頭注記を付ける。 + 分離該当が 0 件なら {covered_file} は作らない）。 +7. L1 候補: 担当グループが起点となる業務シナリオを test-levels.md §2 の 5 観点で洗い出し、 + 本文は書かず 1 行サマリのみ挙げる（L1 の本文化は別担当が行う）。 + +## 禁止事項 +- {output_file} / {covered_file} 以外への書き込み +- 読込予算の超過（超えそうなら仕様の index/見出しのみで判断し、その旨を要約で報告） +- 期待結果の創作（仕様・spec から根拠が取れないものは「要確認」と明記） + +## 最後に、以下の YAML のみを応答として返す（項目本文は返さない） +group: {group} +items: { L2: , L2_covered: <自動カバー済み分離件数> } +id_range_used: <実際に使った範囲> +files_written: [<ファイル名>] +l1_candidates: + - "<業務の言葉での1行サマリ（登場ロールと画面を含む）>" +trace_stats: { tc_linked: <件数>, manual_only: <件数> } +coverage_stats: { e2e: , unit: , both: , none: <なし件数> } +requirements_linked: <件数> +sources_missing: ["<担当範囲で見つからなかった仕様>"] +low_priority_lookups: ["<逆引きしたファイルと理由>"] +budget_note: "<予算内に収まったか。収まらなかった場合の割り切り>" +``` + +## B. L1 統合担当（1 体） + +``` +あなたは UAT の L1 業務シナリオの統合担当です。 + +## 入力 +- 各グループ担当が挙げた L1 候補（1行サマリ）: {l1_candidates_all} +- 粒度基準: {skill_dir}/references/test-levels.md §2, §5（必読） +- 出力仕様: {skill_dir}/references/output-format.md（必読） +- 環境前提: {env_summary} +- 必要に応じて読んでよい仕様（予算 8000 行）: {spec_index_paths} + +## やること +1. 候補を統合する: 同一業務の重複をまとめ、複数グループをまたぐ End-to-End シナリオに再構成する。 + test-levels.md §2 の 5 観点（主業務/後続/セットアップ/データ活用/制限・例外)の網羅を確認し、 + 欠けている観点は仕様 index から補完する。 +2. 各シナリオを UAT-L1-nnn で採番し、{output_file} に output-format.md §3 の型で直接書く。 + L1 は業務担当者が読める言葉のみ。内部用語（BFF・API 名・内部設定キー）は使用禁止。 +3. 手順は 5〜15 ステップ。件数目安: {l1_target_range}（test-levels.md §6）。 + +## 最後に YAML のみ返す +items: { L1: <件数> } +observation_coverage: { 主業務: n, 後続: n, セットアップ: n, データ活用: n, 制限例外: n } +dropped_duplicates: <統合した候補数> +``` + +## C. L3 非機能・運用担当（1 体） + +``` +あなたは L3（非機能・運用受入）の抽出担当です。 + +## 読んでよいもの（予算 8000 行） +- セキュリティ資料: {security_paths} +- 非機能試験の実績: {loadtest_paths} +- 運用・監視資料: {ops_paths} +- 粒度基準: {skill_dir}/references/test-levels.md §4, §5 / 出力仕様: output-format.md（必読） + +## やること +1. 「プロジェクトに存在する非機能活動の結果を受入判定に紐づける」方針で L3 項目 + （1確認活動=1項目、実績資料への参照＋判定基準）を抽出し、{output_file} に直接書く。 +2. 想定される確認活動（性能/セキュリティ/バッチ稼働/監視発報/バックアップリストア/手順書実地）のうち + **該当資料が存在しないものは項目化せず {gaps_file} に記録する**（output-format.md §5 の表形式）。 +3. ID は UAT-L3-nnn。 + +## 最後に YAML のみ返す +items: { L3: <件数> } +gaps: +files_written: [...] +``` diff --git a/skills/uat-test-design/references/output-format.md b/skills/uat-test-design/references/output-format.md new file mode 100644 index 0000000..0199165 --- /dev/null +++ b/skills/uat-test-design/references/output-format.md @@ -0,0 +1,119 @@ +# 出力仕様 + +## 1. ファイル構成（既定出力先: `/docs/uat//`） + +出力先は実行開始時に `date +%Y%m%d` で決定する。同名ディレクトリが既に存在する場合は `date +%H%M` を付けた `/docs/uat/-/` を使う（過去の生成結果は上書きしない）。決定後は全フェーズ・全サブエージェントで固定する。 + +``` +<出力先>/ +├── index.md # 全項目サマリ表（1項目=1行、covered 含む）＋前提欄 +├── L1-scenarios.md # 業務シナリオ（1シナリオ=1セクション） +├── L2-.md # 機能グループ別・UAT対象（1項目=1セクション）※グループ数分 +├── L2--covered.md # 同グループの自動カバー済み分離項目（該当が無ければ作らない） +├── L3-nonfunctional.md +├── gaps.md # 情報源なしで項目化できなかった確認活動の一覧 +├── _inventory.md # 情報源マップ（Phase 1 成果物） +└── _group-map.md # 名寄せ表＋IDレンジ割当（Phase 2 成果物） +``` + +**10 列 1 枚の巨大テーブルは作らない。** 手順・期待結果はテーブルセルに入れない。 + +## 2. index.md + +### 前提欄（冒頭に必須） + +- 実施環境（環境名・テナント・外部サービスのテストアカウント状況。「不明」も明記） +- 情報源の性質（正要件の有無。無い場合は source-categories.md §3 のフォールバック文言） +- 要件トレースの扱い: 「REQ なし」は要件文書の粒度に起因するものであり項目の不備ではない +- 合否基準は項目に持たせず、合否判定・合格ラインは受入側の判断である旨 +- 手動実施階層（test-levels.md §7）の説明: ①手動必須（自動なし）/ ②手動推奨（Unit のみ）/ ③本番相当確認（E2E 系カバー済み・目的は本番相当環境での確認価値）/ ④自動カバー済み（手動実施を前提とせず CI 結果確認で代替可）。実施リソースが限られる場合は ①→②→③ の順で優先する旨 + +### 件数サマリ（前提欄の直後に必須） + +L2 の機能グループ × 手動実施階層の件数マトリクスを置く。受入実施者が計画時に工数配分を一目で判断するための表。 + +| 機能グループ | ①手動必須 | ②手動推奨 | ③本番相当確認 | ④自動カバー済み | 計 | +|---|---|---|---|---|---| +| カート | 5 | 12 | 15 | 3 | 35 | +| ... | | | | | | +| **L2 計** | | | | | | + +L1 / L3 は件数のみ 1 行ずつ追記する（例: `L1: 32 件（すべて手動実施）`）。 + +### サマリ表（1 項目 = 1 行。covered 分離項目も含める） + +列構成は全レベル共通: + +| ID | レベル | 階層 | 対象機能 | 観点 | 実施者 | カバレッジ | 自動化トレース | 要件トレース | 本文 | +|---|---|---|---|---|---|---|---|---|---| +| UAT-L2-301 | L2 | ②手動推奨 | 注文管理 | 異常系 | 開発側QA | Unit | TC-A-102 | REQ-07 | [L2-order.md](./L2-order.md#uat-l2-301) | +| UAT-L2-305 | L2 | ④自動カバー済み | 注文管理 | 正常系 | （自動代替） | E2E+Unit | TC-A-110 | REQ-07 | [L2-order-covered.md](./L2-order-covered.md#uat-l2-305) | + +- 階層: test-levels.md §7 の手動実施階層（①手動必須 / ②手動推奨 / ③本番相当確認 / ④自動カバー済み）。区分とカバレッジから機械的に導出する +- カバレッジ: `E2E` / `Unit` / `E2E+Unit` / `なし`（test-levels.md §7 の判定値） + +**L2 は手動実施階層でサブセクション分割する**（1 枚の巨大テーブルに混在させない）: + +```markdown +### L2-①: 手動必須（自動テストなし） +（階層①のみの表。ID 昇順 = 機能グループ順） + +### L2-②: 手動推奨（Unit のみ・UI/結合レベル未自動化） +（階層②のみの表） + +### L2-③: 本番相当環境での確認（E2E カバー済み） +（階層③のみの表） + +### L2-④: 自動カバー済み（CI 結果確認で代替可） +（階層④のみの表） +``` + +- L1 / L3 は常に手動実施のため分割せず 1 表のまま（階層列は `手動` と記載、または `-` でよい） +- 欠番・統合済み ID は階層の表に入れず、L2 セクション末尾に「欠番: UAT-L2-351（→UAT-L2-425 に統合）」形式で 1 行ずつ列挙する + +## 3. 項目セクション（L1/L2/L3 共通の型） + +```markdown +### UAT-L2-301: 注文キャンセル — 出荷後はキャンセル不可（異常系） + +| レベル | 対象機能 | 観点 | 実施者 | カバレッジ | 自動化トレース | 要件トレース | +|---|---|---|---|---|---|---| +| L2 | 注文管理 | 異常系 | 開発側QA | Unit | TC-A-102, TC-A-103 | REQ-07 | + +**前提条件**: （環境・テナント・必要データ。Phase 1 の環境前提と整合させる） +**手順**: +1. ... +2. ... +**期待結果**: ... +``` + +- L1 は「登場ロール」「シナリオ概要（業務の言葉で 1〜2 文）」を表の下に追加 +- L2 の手順は 3〜8 ステップ、L1 は 5〜15 ステップ（test-levels.md §5） +- カバレッジ: test-levels.md §7 の判定値（`E2E` / `Unit` / `E2E+Unit` / `なし`）。L2 は必須、L1/L3 は省略可 +- 自動化トレース: 対応 ID をカンマ区切り。無ければ「手動のみ」。多対多可。Unit カバーはテストファイルパスで記録してよい +- 要件トレース: 対応要件 ID。無ければ「REQ なし」 + +### covered ファイル（`L2--covered.md`）の追加規約 + +- 冒頭に注記を置く: 「本ファイルの項目は既存自動テストでカバー済みと判定され UAT 手動実施の対象から分離したもの。受入では対応する自動テストの実行結果（CI）確認で代替できる。判定に異議がある場合は L2 本体へ戻すこと」 +- 各項目に **分離理由** 行を追加する（例: `**分離理由**: E2E TC-A-110 が同一手順・同一期待結果を検証済み。本番相当環境依存なし`） +- それ以外の型は L2 本体と同一（ID・本文・トレースを完備し、本体へ戻せる状態を保つ） + +## 4. ID 規約 + +- `UAT-L1-nnn`: 全体一連番号（L1 統合担当が採番） +- `UAT-L2-nn`: G = 機能グループ番号（2桁登録: グループ3の1件目 = UAT-L2-301）。親が Phase 2 でレンジを配布し、抽出サブエージェントはレンジ内のみで採番 +- `UAT-L3-nnn`: L3 担当が採番 +- 接頭辞は inventory.sh §3 の検出結果と衝突しないことを Phase 2 で確認。衝突時は `ACC-` 等へ変更 + +## 5. gaps.md + +| 想定される確認活動 | 期待した情報源 | 現状 | 受入までに必要なアクション | +|---|---|---|---| +| バックアップ/リストア確認 | 運用手順書 | 情報源なし | リストア手順書の整備＋実地確認 | + +「情報源が無いため項目化できない」こと自体を受入準備のギャップとして報告する。 + +## 6. xlsx 変換（ユーザ選択時） + +index.md のサマリ表＋各ファイルの項目セクションから生成する。シート構成: 概要（前提欄＋件数サマリ）/ L1 / L2（グループ列・階層列付き。階層①→②→③、その中で ID 昇順にソート）/ L2-自動カバー済み（分離理由列付き）/ L3 / gaps。手順・期待結果はセル内改行で格納。変換は Phase 4 の最後に行う（markdown が常に正）。 diff --git a/skills/uat-test-design/references/review-prompt.md b/skills/uat-test-design/references/review-prompt.md new file mode 100644 index 0000000..3947f48 --- /dev/null +++ b/skills/uat-test-design/references/review-prompt.md @@ -0,0 +1,45 @@ +# レビューサブエージェント プロンプト + +Phase 4 で親が Agent tool に渡す定型。**生成した本人以外**が判定する独立レビュー。model は親と同等以上を推奨。総項目数 150 件超なら各ファイルから 30% サンプリング、以下なら全件。 + +``` +あなたは UAT・受入試験項目のレビュー担当です。生成には関与していません。 +判定基準: {skill_dir}/references/test-levels.md（特に §5 粒度基準）と output-format.md。 + +## 入力 +- 試験項目ファイル: {output_dir}/L1-scenarios.md, L2-*.md（-covered.md 含む）, L3-nonfunctional.md + （総数 {total} 件。{sampling_instruction}） +- 重複疑いペア（親が index のサマリ表から機械抽出したもの）: {dup_candidates} +- 環境前提: {env_summary} + +## チェック観点 +1. 粒度: 各項目が test-levels.md §5 の基準を満たすか。 + 下限の経験則「業務担当者がその項目単体を読んで、追加説明なしに実施・合否判定できるか」で判定。 + 大きすぎ（複数観点の混在）・細かすぎ（単体テストの領分）を指摘。 +2. 重複: 重複疑いペアごとに「統合すべき / 環境・観点が異なるため両方残す」を判定し理由を付す。 +3. 前提整合: 前提条件欄が環境前提（テナント・テストアカウント）と矛盾しないか。 + 実在しない環境・データを前提にしていないか。 +4. 用語: L1 に内部用語（BFF・API 名・内部設定キー・テーブル名）が混入していないか。 +5. 期待結果: 根拠なく断定していないか（「要確認」マークの妥当性）。 +6. トレース形式: 自動化トレース・要件トレース・カバレッジ列が output-format.md の規約どおりか。 + index.md の手動実施階層（サブセクション配置）がカバレッジ・区分の導出条件（test-levels.md §7）と + 整合しているか（例: カバレッジ`なし`の項目が③の表に混入していないか）。 +7. 分離判定: test-levels.md §7 の分離条件に照らし、 + (a) L2-*-covered.md に「厚くする領域」該当・本番相当環境依存・Unit のみカバーの項目が + 誤って分離されていないか（→ 本体へ戻す指摘）、 + (b) L2 本体に分離条件を明確に満たす項目が大量に残っていないか（→ 分離漏れの指摘）。 + 境界事例は UAT 対象に残す判断を正とする。 + +## 出力（指摘リストのみ。修正はしない） +| 対象ID | 種別(粒度/重複/前提/用語/期待結果/形式/分離) | 指摘 | 修正案 | +|---|---|---|---| + +最後に総評 3 行以内: サンプリング範囲での品質水準と、全体修正が必要な系統的問題の有無。 +``` + +## 親の後処理 + +- 指摘が特定グループに集中する場合: そのグループの抽出サブエージェントを修正指示付きで再実行 +- 散発的な指摘: 親が該当ファイルの該当セクションのみ Edit で修正（本文全読みはしない） +- 重複統合の判定結果: 残す側に統合し、消す側の ID は欠番として index に「統合済み → <残ID>」と記録（ID の振り直しはしない） +- 分離判定の指摘: 散発なら親が該当セクションを covered ⇔ 本体間で移動（ID は変えず、index の区分列を更新）。系統的（同一グループで多数）ならそのグループを修正指示付きで再実行 diff --git a/skills/uat-test-design/references/source-categories.md b/skills/uat-test-design/references/source-categories.md new file mode 100644 index 0000000..60f011e --- /dev/null +++ b/skills/uat-test-design/references/source-categories.md @@ -0,0 +1,60 @@ +# 情報源カテゴリ定義・除外規則・性質分類 + +Phase 1（インベントリ）の判定規則。**過去のメモ・ドキュメントに書かれた件数・パスは信用せず、必ず `scripts/inventory.sh` で実行時に実測する。** + +## 1. 情報源カテゴリ（優先度付き） + +| カテゴリ | 典型的な所在 | 使い方 | 優先度 | +|---|---|---|---| +| 要件定義 | `docs/prd`, `requirements`, 要件, EARS, user story | 要件トレースの起点 | ★★★ | +| 機能仕様・現行仕様 | `docs/spec/**`, feature 単位仕様, README | L1/L2 抽出の主資料 | ★★★ | +| 既存 E2E テスト | `e2e/`, `*.spec.ts`, playwright/cypress 設定 | L2 観点＋自動化トレース＋カバレッジ判定 | ★★★ | +| 既存単体テスト | `__tests__/`, `*.test.ts(x)`, `src/test/**/*Test.kt`, JUnit/Jest（所在は inventory.sh §3.5 で実測） | カバレッジ判定（test-levels.md §7）専用。テスト名 grep のみで本文精読しない | ★★ | +| 画面・ルーティング | `pages/`, `app/`, `src/routes` | 機能一覧の裏取り（ドキュメントにない画面の検出） | ★★ | +| 外部連携仕様 | 決済/認証/通知ベンダー名のディレクトリ・env 定義 | 外部連携系 L2 の手順・異常系 | ★★ | +| セキュリティ資料 | `docs/security/**`, 診断報告書, 認可マトリクス | セキュリティ観点の L2/L3 | ★★ | +| 個別改修の記録 | `plans/`, ADR, implements, tasks, `.dcs/` 等のセッション記録 | エッジケース補完（逆引きのみ） | ★ | +| 運用・監視資料 | `operations/`, `monitoring/`, runbook | L3 運用項目 | ★ | +| 非機能試験の実績 | load-test, 性能レポート | L3 性能項目のエビデンス | ★ | + +## 2. 除外・格下げの機械基準 + +inventory.sh が付けるフラグと優先度を組み合わせて扱いを決める。**ディレクトリ名の名指し除外は行わない。** + +| フラグ × 優先度 | 扱い | +|---|---| +| [閾値超過]（100ファイル超 or md 30,000行超）× ★★★カテゴリ | **分割精読**: 格下げしない。Phase 2 でサブエージェント複数体に分割して精読する | +| [閾値超過] × ★★以下 | **逆引き専用**に格下げ（全読み禁止） | +| [生成物]（生成マーカー過半） | 1 段格下げ（★★★→逆引き候補として要確認、★以下→除外候補）。性質分類は「逆」 | +| node_modules / ビルド成果物 / バイナリ | 完全除外（スクリプトが除外済み） | + +### 逆引き専用の運用ルール + +- 全読み・一覧読みは禁止 +- 抽出サブエージェントが特定機能の補完情報（エッジケース・受入条件）を必要とした場合のみ、**ファイル名 grep → 該当上位 2 件までをピンポイント読み** +- 参照した場合はメタデータ要約の `low_priority_lookups` に記録する + +## 3. 情報源の性質分類（正 / 逆 / なし） + +各情報源に必ずタグを付け、`_inventory.md` に記録する。 + +| タグ | 定義 | 判定ヒント | +|---|---|---| +| **正** | 発注側要件・契約文書・外部公式仕様（実装より先に存在した文書） | ユーザ提供資料、ベンダー公式仕様、契約添付 | +| **逆** | 実装からのリバース生成文書 | 「推定」「reverse」「現状分析」等の自己申告、生成マーカー、`reverse/` パス | +| **なし** | カテゴリに該当文書が見つからない | — | + +### フォールバック（「正」の要件が存在しない場合） + +処理は続行するが、`index.md` の前提欄に以下を必ず記載する: + +> 本試験項目一覧の作成時点で、妥当性確認（Validation)の基準となる発注側要件文書は確認できなかった。L1/L2 の期待結果は現行実装・リバース仕様を基準に記述しているため、「実装どおり動くこと」の確認に留まる。業務上の妥当性判断は受入実施者に委ねる。 + +「逆」しか無い場合は Phase 1 のユーザ確認で追加資料の有無を**特に強調して**確認すること。 + +## 4. 既存テスト ID の抽出パターン + +- 検出: inventory.sh §3 が spec ファイル群から `\b[A-Z]{1,4}(-[A-Z]{1,4})?-[0-9]+(-[0-9]+)?\b` で接頭辞を集計する +- 自動化トレース用の収集: 抽出サブエージェントは担当 spec ファイルに対し検出済み接頭辞で grep し、**ID と同一行の説明文**をペアで収集する（ID はコメント内に書かれていることが多い） +- サブ番号付き ID（例 `TC-F-59-01`）が存在する場合、「1 ID = 1 テストケース」と仮定しない。トレース列は L2 項目と ID の**多対多**を許容する +- UAT 項目の採番は検出済み接頭辞と衝突しないこと（既定: `UAT-L1-` / `UAT-L2-` / `UAT-L3-`） diff --git a/skills/uat-test-design/references/test-levels.md b/skills/uat-test-design/references/test-levels.md new file mode 100644 index 0000000..cd13051 --- /dev/null +++ b/skills/uat-test-design/references/test-levels.md @@ -0,0 +1,110 @@ +# テストレベル定義と粒度基準 + +uat-test-design が出力する試験項目の 3 階層定義。抽出・レビューの全サブエージェントはこのファイルを判定基準とする。 + +## 1. V字モデル上の位置づけ + +| レベル | 実施者 | 環境 | 目的 | +|---|---|---|---| +| 単体テスト | 開発者（自動） | CI | 実装の正しさ（本 SKILL の対象外） | +| 統合・E2E テスト | 開発者（自動） | CI / テスト環境 | 回帰担保（本 SKILL の対象外） | +| **受入試験（システム受入）** | 開発側 QA / SIer | 本番相当環境 | 要件充足の検証（Verification） | +| **UAT（業務受入）** | 発注側 業務担当者 | 本番相当環境 | 業務で使えることの妥当性確認（Validation） | +| 非機能試験 | 開発側 | 専用/本番相当環境 | 性能・セキュリティ・運用性 | + +既存自動テストと確認対象が同じでも「本番相当環境・本物の外部接続・業務の目線」という条件が異なる場合は重複に価値がある。ただし**その付加価値がない項目（CI 上の自動テストで確認が完結する項目）まで UAT に含めると件数が肥大する**ため、§7 のカバレッジ判定で UAT 本体と自動カバー済み（分離）を区分する。自動化トレース列で対応を必ず明示する。 + +## 2. L1: 業務シナリオ試験（UAT の主体・発注側実施） + +- 粒度: **業務ストーリー 1 本 = 1 項目**。複数画面・複数ロール（顧客と管理者等）をまたいでよい +- 書き方: 業務担当者が読める言葉のみ。画面名・操作の流れ＋業務上の期待結果。**内部用語（BFF・API 名・内部設定キー等）は使用禁止** +- 抽出の 5 観点: + 1. **主業務フロー**: システムの存在理由となるトランザクション（購入・申請・予約等）の代表パターン + 2. **後続業務**: キャンセル・返品・修正・承認差戻し等 + 3. **セットアップ業務**: 初期設定・マスタ登録から運用開始までの一連 + 4. **データ活用業務**: エクスポート・帳票・集計 + 5. **制限・例外業務**: 権限制限・期間制限・流量制限下での業務 + +## 3. L2: 機能・観点別確認試験（開発側実施、発注側は抜き取り） + +- 粒度: **1 機能 × 1 観点（正常/異常/境界/権限）= 1 項目**。既存 E2E の describe レベルに近い +- 各項目に自動化トレース列（対応する既存テスト ID、なければ「手動のみ」）を必ず持たせる +- 特に厚くする領域（本番相当環境でしか確認できない・事故時の影響が大きい）: + - 外部サービス連携（決済・認証 IdP・通知・外部 API の本番相当接続） + - 金銭・数量の計算（税・送料・割引・返金・在庫） + - テナント・ユーザー間分離（越境アクセス不可・IDOR 不可） + - インフラ挙動と結合する機能（CDN キャッシュ・セッション・タイムゾーン・ファイルアップロード） + - 不可逆な操作（削除・確定・締め処理） + +## 4. L3: 非機能・運用受入試験（開発側実施、結果を発注側へ報告） + +- 粒度: **1 確認活動 = 1 項目**。新規に手順を作らず、プロジェクトに存在する非機能活動の結果を受入判定に紐づける +- 構成（該当活動があるものだけ採用）: 性能（負荷試験結果）/ セキュリティ（脆弱性診断対応・認可設定確認）/ 運用（バッチ稼働・監視発報・バックアップリストア・手順書実地確認） +- **該当資料が存在しない活動は項目化せず `gaps.md` に記録する**（受入前に整備すべきギャップとして成果物化） + +## 5. 粒度基準（レビュー判定基準） + +| 基準 | L1 | L2 | L3 | +|---|---|---|---| +| 1 項目のスコープ | 業務ストーリー 1 本 | 1 機能 × 1 観点 | 1 確認活動 | +| 手順の詳細度 | 画面名・操作の流れ（5〜15 ステップ） | 前提＋操作＋入力値（3〜8 ステップ） | 実施手順への参照＋判定基準 | +| 期待結果 | 業務上のゴール | 画面表示・データ・挙動の具体値 | 数値基準・完了条件 | +| 実施時間の目安 | 15〜60 分/件 | 2〜10 分/件 | 活動による | +| NG 例 | 「システム全体が正しく動くこと」（大きすぎ） | 「ボタンの色が #xxx」（単体レベル） | 「セキュリティに問題ないこと」（判定不能） | + +**下限の経験則**: 「発注側の業務担当者がその項目単体を読んで、追加説明なしに実施・合否判定できるか」。それより細かい確認は自動テストの領分。 + +合否基準は項目属性として持たせない（合否判定・合格ラインは受入側の判断）。 + +## 6. 件数目安（規模スケール） + +| レベル | 導出ロジック | 小規模（画面〜10） | 中規模（10〜40） | 大規模（40〜） | +|---|---|---|---|---| +| L1 | 主業務フロー数 × 代表バリエーション（2〜4） | 5〜10 | 15〜30 | 30〜60 | +| L2 | 機能数 × 平均観点数（3〜8）。既存 E2E spec 数が参考値 | 30〜80 | 100〜300 | 300〜800 | +| L3 | 存在する非機能活動数に依存 | 5〜15 | 20〜40 | 40〜80 | + +L2 の目安は「UAT 対象（分離後の本体）」の件数。生成結果がこのレンジを大きく外れた場合、Phase 4 で原因（情報源不足・グループ分割ミス・§7 分離の効きすぎ/効かなさすぎ）を特定しユーザに報告する。 + +## 7. 自動化カバレッジ判定（L2 の分離基準） + +L2 の各項目に対し、既存の自動テスト（UnitTest / E2E）でのカバー状況を判定し、**カバレッジ値**と**区分**を必ず付与する。 + +### 判定値（カバレッジ列） + +| 値 | 定義 | +|---|---| +| `E2E` | 対応する E2E spec のテストケースが確認内容を実行している | +| `Unit` | 対応する単体テスト（Jest / JUnit 等）がロジックレベルで確認している | +| `E2E+Unit` | 両方でカバー | +| `なし` | どちらにも対応が見つからない | + +### 判定方法（実装の精読はしない） + +1. `_group-map.md` の担当 E2E spec / 単体テストパスに対し、機能名・画面名・観点キーワードで describe / test / it / `@Test`・メソッド名を grep する +2. テスト名（説明文）が項目の確認内容と一致・包含するかで判定する。**名前ベースの近似判定でよい**（アサーション内容の精読はしない。判定に自信がない場合は `なし` 側に倒す） +3. E2E カバーの場合は自動化トレース列に対応 ID（無ければ spec ファイル名＋テスト名）を記録する。Unit カバーはテストファイルパスを記録する + +### 区分ルール（分離条件） + +以下を**すべて**満たす項目は「自動カバー済み」区分とし、`L2--covered.md` へ本文ごと分離する: + +1. カバレッジが `E2E` または `E2E+Unit`（**Unit のみは分離しない**。UI 経由・結合状態での確認が自動化されていないため UAT 対象に残す） +2. §3 の「特に厚くする領域」（外部サービス連携・金銭数量計算・テナント分離・インフラ結合・不可逆操作）に**該当しない** +3. 本番相当環境でしか得られない確認価値（本物の外部接続・本番相当データ量・実テナント設定・実権限）が**ない** +4. 業務上の妥当性判断（Validation）を要しない（仕様どおり動くことの Verification で完結する） + +上記のいずれかでも判断に迷う場合は **UAT 対象に残す**（分離は保守的に行う）。分離した項目にも通常どおり ID・本文・トレースを持たせ、受入側が「自動テスト結果の確認で代替する」と判断できる状態にする。 + +### 手動実施階層（index.md の表示区分） + +区分とカバレッジ値から**機械的に導出する**表示用の階層。追加の判定作業は発生しない。受入実施者が「何を手動でやるべきか」を階層だけで判断できるようにするための区分であり、index.md のサマリ表はこの階層でサブセクション分割する（output-format.md §2）。 + +| 階層 | 導出条件 | 手動実施の位置づけ | +|---|---|---| +| ① 手動必須 | 区分=UAT対象 かつ カバレッジ=`なし` | 自動テストの防御が一切ない。手動で確認しない限り未検証のまま残る | +| ② 手動推奨 | 区分=UAT対象 かつ カバレッジ=`Unit` | ロジックは自動検証済みだが、UI 経由・結合状態での確認は未自動化 | +| ③ 本番相当確認 | 区分=UAT対象 かつ カバレッジ=`E2E` / `E2E+Unit` | 動作自体は自動検証済み。手動実施の目的は本番相当環境・実外部接続・業務目線の確認価値に限られる | +| ④ 自動カバー済み | 区分=自動カバー済み（分離済み） | 手動実施を前提としない。CI の自動テスト結果確認で代替可 | + +実施リソースが限られる場合は ①→②→③ の順で優先する。③ は「本番相当環境でなければ得られない確認」だけに手順を絞ってよい。L1 / L3 は常に UAT対象（手動実施前提）のため階層分割しない。 diff --git a/skills/uat-test-design/scripts/inventory.sh b/skills/uat-test-design/scripts/inventory.sh new file mode 100755 index 0000000..d28e1e7 --- /dev/null +++ b/skills/uat-test-design/scripts/inventory.sh @@ -0,0 +1,100 @@ +#!/usr/bin/env bash +# uat-test-design Phase 1: リポジトリのインベントリ実測スクリプト +# 依存: bash / find / grep / wc / sort / awk のみ。出力は集計値だけで、ファイル本文は出力しない。 +# 使い方: inventory.sh +set -u + +ROOT="${1:-.}" +cd "$ROOT" || { echo "ERROR: cannot cd to $ROOT" >&2; exit 1; } + +PRUNE=( \( -name node_modules -o -name .git -o -name dist -o -name build -o -name .next -o -name coverage -o -name .gradle -o -name target -o -name __pycache__ -o -name .venv \) -prune ) + +echo "==============================================" +echo "## 1. ドキュメント系ディレクトリの規模（2階層）" +echo "[閾値超過] = 100ファイル超 or md 30000行超（扱いは source-categories.md の規則で決定）/ [生成物] = 生成マーカー過半" +echo "==============================================" +printf "%-8s %-10s %-20s %s\n" "files" "lines(md)" "flag" "dir" +for top in docs doc documents spec specs design wiki; do + [ -d "$top" ] || continue + for d in "$top" "$top"/*/; do + [ -d "$d" ] || continue + d="${d%/}" + files=$(find "$d" "${PRUNE[@]}" -o -type f -print 2>/dev/null | wc -l) + lines=$(find "$d" "${PRUNE[@]}" -o -type f -name '*.md' -print 2>/dev/null | tr '\n' '\0' | xargs -0 -r cat 2>/dev/null | wc -l) + flag="-" + if [ "$files" -gt 100 ] || [ "$lines" -gt 30000 ]; then flag="[閾値超過]"; fi + sampled=0; gen=0 + while IFS= read -r f; do + sampled=$((sampled + 1)) + if head -5 "$f" 2>/dev/null | grep -qiE 'auto[- ]?generated|自動生成|generated by|作成者.*:.*(Claude|AI|Copilot)'; then gen=$((gen + 1)); fi + done < <(find "$d" "${PRUNE[@]}" -o -type f -name '*.md' -print 2>/dev/null | head -50) + if [ "$sampled" -gt 5 ] && [ $((gen * 2)) -gt "$sampled" ]; then flag="${flag}[生成物]"; fi + printf "%-8s %-10s %-20s %s\n" "$files" "$lines" "$flag" "$d" + done +done + +echo "" +echo "==============================================" +echo "## 2. 情報源カテゴリの検出（パス名ヒントによる候補、各15件まで）" +echo "==============================================" +cat_hint() { # 浅いパス優先で表示（深い階層のタスク/実装記録ノイズを後ろへ） + echo "--- $1" + find . "${PRUNE[@]}" -o \( -type f -o -type d \) -print 2>/dev/null \ + | grep -iE "$2" | grep -vE '\.(png|jpe?g|svg|ico|pdf|lock)$' \ + | awk -F/ '{print NF"\t"$0}' | sort -n | cut -f2- | head -15 +} +doc_hint() { # ドキュメントカテゴリ用: md とディレクトリのみ（ソースコードノイズを除去） + echo "--- $1" + find . "${PRUNE[@]}" -o \( -type d -o -type f -name '*.md' \) -print 2>/dev/null \ + | grep -iE "$2" | grep -vE '__tests__|/e2e/specs/' \ + | awk -F/ '{print NF"\t"$0}' | sort -n | cut -f2- | head -15 +} +doc_hint "要件定義" 'requirement|要件|/prd|ears|user[-_ ]?stor' +doc_hint "機能仕様" 'docs?/spec|docs/.*feature|機能仕様|functional[-_]spec' +cat_hint "E2Eテスト" '/e2e$|playwright\.config|cypress\.config' +cat_hint "画面・ルーティング" 'src/pages$|src/app$|src/routes$|src/views$' +doc_hint "外部連携" 'veritrans|stripe|paypay|payment|auth0|liff|oauth|webhook|notification' +doc_hint "セキュリティ資料" 'security|脆弱性|authz|診断|zap|pentest' +doc_hint "個別改修の記録" 'plans/|/adr|implements|/rfc' +doc_hint "運用・監視" 'operations?/|monitoring|runbook|incident|手順書|backup' +doc_hint "非機能試験の実績" 'load-?test|performance|/perf/|負荷試験' + +echo "" +echo "==============================================" +echo "## 3. 既存テスト ID 体系の検出（採番衝突回避・自動化トレース設計用）" +echo "==============================================" +spec_list=$(find . "${PRUNE[@]}" -o -type f \( -name '*.spec.ts' -o -name '*.spec.js' -o -name '*.test.ts' -o -name '*.cy.ts' \) -print 2>/dev/null) +if [ -n "$spec_list" ]; then + echo "spec ファイル数: $(printf '%s\n' "$spec_list" | wc -l)" + echo "検出 ID（接頭辞別ユニーク数 上位10）:" + printf '%s\n' "$spec_list" | tr '\n' '\0' \ + | xargs -0 -r grep -hoE '\b[A-Z]{1,4}(-[A-Z]{1,4})?-[0-9]+(-[0-9]+)?\b' 2>/dev/null \ + | sort -u | sed -E 's/-[0-9]+(-[0-9]+)?$//' | sort | uniq -c | sort -rn | head -10 +else + echo "spec/test ファイル未検出 → 自動化トレース列は全件「手動のみ」になる見込み" +fi + +echo "" +echo "==============================================" +echo "## 3.5 単体テストの検出（カバレッジ判定の入力）" +echo "==============================================" +unit_list=$(find . "${PRUNE[@]}" -o -type f \( -name '*.test.ts' -o -name '*.test.tsx' -o -name '*.test.js' -o -name '*.test.jsx' -o -name '*Test.kt' -o -name '*Test.java' -o -name '*Spec.kt' -o -name '*_test.go' -o -name 'test_*.py' \) -print 2>/dev/null) +if [ -n "$unit_list" ]; then + echo "単体テストファイル数: $(printf '%s\n' "$unit_list" | wc -l)" + echo "所在（上位ディレクトリ別 件数、上位15）:" + printf '%s\n' "$unit_list" | awk -F/ '{ if (NF>3) print $2"/"$3; else print $2 }' | sort | uniq -c | sort -rn | head -15 +else + echo "単体テスト未検出 → カバレッジ判定は E2E のみで行う（Unit は全件「なし」扱い）" +fi + +echo "" +echo "==============================================" +echo "## 4. 画面数の近似（規模判定の入力）" +echo "==============================================" +find . "${PRUNE[@]}" -o -type d \( -name pages -o -name app -o -name routes -o -name views \) -print 2>/dev/null | grep -v '__tests__' | head -8 | while IFS= read -r p; do + n=$(find "$p" -type f \( -name '*.tsx' -o -name '*.jsx' -o -name '*.vue' -o -name '*.svelte' \) ! -path '*api*' ! -name '_*' 2>/dev/null | wc -l) + [ "$n" -gt 0 ] && echo "$p: $n" +done + +echo "" +echo "## 完了。この出力を _inventory.md（情報源マップ）作成の入力とする。"