# Default TAKT Workflow # Plan -> Architect -> Implement -> AI Review -> Reviewers (parallel: Architect + Security) -> Supervisor Approval # # Template Variables (auto-injected by buildInstruction): # {iteration} - Workflow-wide turn count (total steps executed across all agents) # {max_iterations} - Maximum iterations allowed for the workflow # {step_iteration} - Per-step iteration count (how many times THIS step has been executed) # {task} - Original user request # {previous_response} - Output from the previous step # {user_inputs} - Accumulated user inputs during workflow # {report_dir} - Report directory name (e.g., "20250126-143052-task-summary") name: default description: Standard development workflow with planning and specialized reviews max_iterations: 30 initial_step: plan steps: - name: plan edit: false agent: ../agents/default/planner.md report: name: 00-plan.md format: | ```markdown # タスク計画 ## 元の要求 {ユーザーの要求をそのまま記載} ## 分析結果 ### 目的 {達成すべきこと} ### スコープ {影響範囲} ### 実装アプローチ {どう進めるか} ## 確認事項（あれば） - {不明点や確認が必要な点} ``` allowed_tools: - Read - Glob - Grep - Write - Bash - WebSearch - WebFetch rules: - condition: 要件が明確で実装可能 next: architect - condition: ユーザーが質問をしている（実装タスクではない） next: COMPLETE - condition: 要件が不明確、情報不足 next: ABORT appendix: | 確認事項: - {質問1} - {質問2} pass_previous_response: true instruction_template: | タスクを分析し、実装方針を立ててください。 **注意:** Previous Responseがある場合は差し戻しのため、 その内容を踏まえて計画を見直してください（replan）。 **やること（実装タスクの場合）:** 1. タスクの要件を理解する 2. 影響範囲を特定する 3. 実装アプローチを決める - name: architect edit: false agent: ../agents/default/architect.md report: name: 01-architecture.md format: | ```markdown # アーキテクチャ設計 ## タスク規模 Small / Medium / Large ## 設計判断 ### ファイル構成 | ファイル | 役割 | |---------|------| | `src/example.ts` | 概要 | ### 技術選定 - {選定した技術・ライブラリとその理由} ### 設計パターン - {採用するパターンと適用箇所} ## 実装ガイドライン - {Coderが実装時に従うべき指針} ``` allowed_tools: - Read - Glob - Grep - Write - WebSearch - WebFetch rules: - condition: 小規模タスク（設計不要） next: implement - condition: 設計完了 next: implement - condition: 情報不足、判断できない next: ABORT pass_previous_response: true instruction_template: | 計画レポート（{report:00-plan.md}）を読み、アーキテクチャ設計を行ってください。 **小規模タスクの判断基準:** - 1-2ファイルの変更のみ - 既存パターンの踏襲で済む - 技術選定が不要 小規模タスクの場合は設計レポートを作成せず、「小規模タスク（設計不要）」のルールに対応してください。 **設計が必要なタスク:** - 3ファイル以上の変更 - 新しいモジュール・機能の追加 - 技術選定が必要 - アーキテクチャパターンの決定が必要 **やること:** 1. タスクの規模を評価 2. ファイル構成を決定 3. 技術選定（必要な場合） 4. 設計パターンの選択 5. Coderへの実装ガイドライン作成 - name: implement edit: true agent: ../agents/default/coder.md session: refresh report: - Scope: 02-coder-scope.md - Decisions: 03-coder-decisions.md allowed_tools: - Read - Glob - Grep - Edit - Write - Bash - WebSearch - WebFetch permission_mode: edit rules: - condition: 実装完了 next: ai_review - condition: 実装未着手（レポートのみ） next: ai_review - condition: 判断できない、情報不足 next: ai_review - condition: ユーザー入力が必要 next: implement requires_user_input: true interactive_only: true instruction_template: | planステップで立てた計画と、architectステップで決定した設計に従って実装してください。 **参照するレポート:** - 計画: {report:00-plan.md} - 設計: {report:01-architecture.md}（存在する場合） Workflow Contextに示されたReport Directory内のファイルのみ参照してください。他のレポートディレクトリは検索/参照しないでください。 **重要:** 設計判断はせず、architectステップで決定された設計に従ってください。 不明点や設計の変更が必要な場合は報告してください。 **重要**: 実装と同時に単体テストを追加してください。 - 新規作成したクラス・関数には単体テストを追加 - 既存コードを変更した場合は該当するテストを更新 - テストファイルの配置: プロジェクトの規約に従う（例: `__tests__/`, `*.test.ts`） **Scopeレポートフォーマット（実装開始時に作成）:** ```markdown # 変更スコープ宣言 ## タスク {タスクの1行要約} ## 変更予定 | 種別 | ファイル | |------|---------| | 作成 | `src/example.ts` | | 変更 | `src/routes.ts` | ## 推定規模 Small / Medium / Large ## 影響範囲 - {影響するモジュールや機能} ``` **Decisionsレポートフォーマット（実装完了時、決定がある場合のみ）:** ```markdown # 決定ログ ## 1. {決定内容} - **背景**: {なぜ決定が必要だったか} - **検討した選択肢**: {選択肢リスト} - **理由**: {選んだ理由} ``` **必須出力（見出しを含める）** ## 作業結果 - {実施内容の要約} ## 変更内容 - {変更内容の要約} ## テスト結果 - {実行コマンドと結果} - name: ai_review edit: false agent: ../agents/default/ai-antipattern-reviewer.md pass_previous_response: true report: name: 04-ai-review.md format: | ```markdown # AI生成コードレビュー ## 結果: APPROVE / REJECT ## サマリー {1文で結果を要約} ## 検証した項目 | 観点 | 結果 | 備考 | |------|------|------| | 仮定の妥当性 | ✅ | - | | API/ライブラリの実在 | ✅ | - | | コンテキスト適合 | ✅ | - | | スコープ | ✅ | - | ## 問題点（REJECTの場合） | # | カテゴリ | 場所 | 問題 | |---|---------|------|------| | 1 | 幻覚API | `src/file.ts:23` | 存在しないメソッド | ``` **認知負荷軽減ルール:** - 問題なし → サマリー1文 + チェック表のみ（10行以内） - 問題あり → + 問題を表形式で（25行以内） allowed_tools: - Read - Glob - Grep - Write - WebSearch - WebFetch rules: - condition: AI特有の問題なし next: reviewers - condition: AI特有の問題あり next: ai_fix instruction_template: | AI特有の問題についてコードをレビューしてください: - 仮定の検証 - もっともらしいが間違っているパターン - 既存コードベースとの適合性 - スコープクリープの検出 - name: ai_fix edit: true agent: ../agents/default/coder.md session: refresh allowed_tools: - Read - Glob - Grep - Edit - Write - Bash - WebSearch - WebFetch permission_mode: edit pass_previous_response: true rules: - condition: AI問題の修正完了 next: ai_review - condition: 修正不要（指摘対象ファイル/仕様の確認済み） next: plan - condition: 判断できない、情報不足 next: plan instruction_template: | **これは {step_iteration} 回目の AI Review です。** 2回目以降は、前回の修正が実際には行われていなかったということです。 **あなたの「修正済み」という認識が間違っています。** **まず認めること:** - 「修正済み」と思っていたファイルは実際には修正されていない - 前回の作業内容の認識が間違っている - ゼロベースで考え直す必要がある **必須アクション:** 1. 指摘された全ファイルを Read tool で開く（思い込みを捨てて事実確認） 2. 問題箇所を grep で検索して実在を確認する 3. 確認した問題を Edit tool で修正する 4. テストを実行して検証する（`./gradlew :backend:test` 等） 5. 「何を確認して、何を修正したか」を具体的に報告する **報告フォーマット:** - ❌ 「既に修正されています」 - ✅ 「ファイルXのL123を確認した結果、問題Yが存在したため、Zに修正しました」 **絶対に禁止:** - ファイルを開かずに「修正済み」と報告 **修正不要の扱い（必須）** - AI Reviewの指摘ごとに「対象ファイルの確認結果」を示せない場合は修正不要と判断しない - 指摘が「生成物」「仕様同期」に関係する場合は、生成元/仕様の確認ができなければ「判断できない、情報不足」に対応するタグを出力する - 修正不要の場合は「判断できない、情報不足」に対応するタグを出力し、理由と確認範囲を明記する **必須出力（見出しを含める）** ## 確認したファイル - {ファイルパス:行番号} ## 実行した検索 - {コマンドと要約} ## 修正内容 - {変更内容} ## テスト結果 - {実行コマンドと結果} - 思い込みで判断 - AI Reviewer が REJECT した問題の放置 - name: reviewers parallel: - name: arch-review edit: false agent: ../agents/default/architecture-reviewer.md report: name: 05-architect-review.md format: | ```markdown # アーキテクチャレビュー ## 結果: APPROVE / REJECT ## サマリー {1-2文で結果を要約} ## 確認した観点 - [x] 構造・設計 - [x] コード品質 - [x] 変更スコープ - [x] テストカバレッジ - [x] デッドコード - [x] 呼び出しチェーン検証 ## 問題点（REJECTの場合） | # | スコープ | 場所 | 問題 | 修正案 | |---|---------|------|------|--------| | 1 | スコープ内 | `src/file.ts:42` | 問題の説明 | 修正方法 | スコープ: 「スコープ内」（今回修正可能）/ 「スコープ外」（既存問題・非ブロッキング） ## 既存問題（参考・非ブロッキング） - {既存問題の記録。今回の変更と無関係な問題} ``` **認知負荷軽減ルール:** - APPROVE → サマリーのみ（5行以内） - REJECT → 問題点を表形式で（30行以内） allowed_tools: - Read - Glob - Grep - Write - WebSearch - WebFetch rules: - condition: approved - condition: needs_fix instruction_template: | **実装がarchitectステップの設計に従っているか**を確認してください。 AI特有の問題はレビューしないでください（ai_reviewステップで行います）。 **参照するレポート:** - 設計: {report:01-architecture.md}（存在する場合） - 実装スコープ: {report:02-coder-scope.md} **レビュー観点:** - 設計との整合性（architectが定めたファイル構成・パターンに従っているか） - コード品質 - 変更スコープの適切性 - テストカバレッジ - デッドコード - 呼び出しチェーン検証 **注意:** architectステップをスキップした小規模タスクの場合は、従来通り設計の妥当性も確認してください。 - name: security-review edit: false agent: ../agents/default/security-reviewer.md report: name: 06-security-review.md format: | ```markdown # セキュリティレビュー ## 結果: APPROVE / REJECT ## 重大度: None / Low / Medium / High / Critical ## チェック結果 | カテゴリ | 結果 | 備考 | |---------|------|------| | インジェクション | ✅ | - | | 認証・認可 | ✅ | - | | データ保護 | ✅ | - | | 依存関係 | ✅ | - | ## 脆弱性（REJECTの場合） | # | 重大度 | 種類 | 場所 | 修正案 | |---|--------|------|------|--------| | 1 | High | SQLi | `src/db.ts:42` | パラメータ化クエリを使用 | ## 警告（ブロッキングではない） - {セキュリティに関する推奨事項} ``` **認知負荷軽減ルール:** - 問題なし → チェック表のみ（10行以内） - 警告あり → + 警告を1-2行（15行以内） - 脆弱性あり → + 表形式で（30行以内） allowed_tools: - Read - Glob - Grep - Write - WebSearch - WebFetch rules: - condition: approved - condition: needs_fix instruction_template: | 変更に対してセキュリティレビューを行ってください。以下の脆弱性を確認してください: - インジェクション攻撃（SQL, コマンド, XSS） - 認証・認可の問題 - データ露出リスク - 暗号化の弱点 rules: - condition: all("approved") next: supervise - condition: any("needs_fix") next: fix - name: fix edit: true agent: ../agents/default/coder.md allowed_tools: - Read - Glob - Grep - Edit - Write - Bash - WebSearch - WebFetch permission_mode: edit rules: - condition: 修正完了 next: reviewers - condition: 判断できない、情報不足 next: plan instruction_template: | レビュアーのフィードバックに対応してください。 セッションの会話履歴を確認し、レビュアーの指摘事項を修正してください。 **必須出力（見出しを含める）** ## 作業結果 - {実施内容の要約} ## 変更内容 - {変更内容の要約} ## テスト結果 - {実行コマンドと結果} ## 証拠 - {確認したファイル/検索/差分/ログの要点を列挙} pass_previous_response: true - name: supervise edit: false agent: ../agents/default/supervisor.md report: - Validation: 07-supervisor-validation.md - Summary: summary.md allowed_tools: - Read - Glob - Grep - Write - Bash - WebSearch - WebFetch rules: - condition: すべて問題なし next: COMPLETE - condition: 要求未達成、テスト失敗、ビルドエラー next: plan instruction_template: | テスト実行、ビルド確認、最終承認を行ってください。 **ワークフロー全体の確認:** 1. 計画（{report:00-plan.md}）と設計（{report:01-architecture.md}、存在する場合）に従った実装か 2. 各レビューステップの指摘が対応されているか 3. 元のタスク目的が達成されているか **レポートの確認:** Report Directory内の全レポートを読み、 未対応の改善提案がないか確認してください。 **Validationレポートフォーマット:** ```markdown # 最終検証結果 ## 結果: APPROVE / REJECT ## 検証サマリー | 項目 | 状態 | 確認方法 | |------|------|---------| | 要求充足 | ✅ | 要求リストと照合 | | テスト | ✅ | `npm test` (N passed) | | ビルド | ✅ | `npm run build` 成功 | | 動作確認 | ✅ | 主要フロー確認 | ## 成果物 - 作成: {作成したファイル} - 変更: {変更したファイル} ## 未完了項目（REJECTの場合） | # | 項目 | 理由 | |---|------|------| | 1 | {項目} | {理由} | ``` **Summaryレポートフォーマット（APPROVEの場合のみ）:** ```markdown # タスク完了サマリー ## タスク {元の要求を1-2文で} ## 結果 ✅ 完了 ## 変更内容 | 種別 | ファイル | 概要 | |------|---------|------| | 作成 | `src/file.ts` | 概要説明 | ## レビュー結果 | レビュー | 結果 | |---------|------| | Architecture Design | ✅ 完了 | | AI Review | ✅ APPROVE | | Architect Review | ✅ APPROVE | | Security | ✅ APPROVE | | Supervisor | ✅ APPROVE | ## 確認コマンド ```bash npm test npm run build ``` ```