full-stack-master

フルスタックマスターワークフロースキル

一、能力の位置付け（Capability）

• ワークフローの自動オーケストレーション：要件、設計、開発、テスト、品質、ドキュメント、提出、レビュー、リリースまでの全工程を連携させます。
• Git Worktree のオーケストレーション：タスクの種類（dev/test/fix/docs）に応じて、物理的に隔離された作業ディレクトリを自動選択し、並行開発を加速します。
• スキルの集約：すべての中核となるアトミックスキル（Todo Manager、Technical Planning、Backend Logic Expert、Vue Frontend Expert、Database Expert、Code Quality Auditor、Test Engineer、UI Validator、Conventional Committer、DevOps Specialist）を統合します。
• 再利用と拡張が可能：新しいシナリオ（データベース移行、API 変更、運用リリースなど）を組み込めるほか、複数のプロジェクトの切り替えをサポートします。
• 段階ごとの引き継ぎ／タスク割り当て：手動またはスクリプトで、各段階のタスクを対応するスキルや専門エージェントに割り当てられます。

二、必ず参照するドキュメント（Mandatory Documentation）

書き込み操作や判断を行う前に、以下のドキュメントの最新内容を読み、理解していることを必ず確認してください。

• 全工程の基盤：AGENTS.md（安全上の絶対基準と役割）、AI 協業規範、Git 規範
• 計画とタスク：プロジェクト計画、ToDo、プロジェクト計画規範
• 開発と設計：開発規範、API 規範、UI 設計
• セキュリティと品質：セキュリティ規範、テスト規範

三、共通の実行原則（Shared Execution Principles）

• この節では、フルスタックのオーケストレーションの観点から実行概要のみを示し、プロジェクト全体に適用されるルールの全文は転載しません。正式な基準はそれぞれAI 協業規範、開発規範、テスト規範に従います。
• オーケストレーションでは、原則として次の4段階の判断順序に従います。まず前提を明示し、次に最小限の案を選び、変更範囲を制限したうえで、必要十分な最小限の検証を行い、拡張を続けるかどうかを判断します。

四、標準 PDTFC+ 2.1 ワークフロー（Standard Workflow）

1. P（Plan）- 要件分析と計画

   1. ドキュメントの確認：todo.md、roadmap.md、現在の受け入れ基準、必要な規範を確認します。
   2. 範囲の照合：対象事項が現在のToDo、現在の受け入れ基準、または現在の段階計画に含まれるかを判断します。含まれない場合は、まず planning.md に従って優先割り込みまたは延期に振り分けます。
   3. 案の設計：影響を受けるファイルの一覧、検証マトリクス、段階ごとの引き継ぎ順序を提示します。必要に応じて、読み取り専用の調査、監査証拠の収集、ドキュメントとの照合を優先して並行に分割します。
   4. タスクの着手判断：実行が許可されている事項のみ Do に進みます。評価段階にとどまっている場合は、実装全体に先走って着手してはなりません。
   • スキル：requirement-analyst、todo-manager、technical-planning、context-analyzer

2. D（Do）- 開発と実装

   1. 単一の主担当：同一の事項について、同じ時点で実装の主担当を複数置きません。原則として full-stack-master が統括し、境界が安定してからフロントエンドおよびバックエンドの専門ロールに委任します。
   2. 中核の実装：開発規範に従います。永続化を伴う場合は、データモデルまたはエンティティを優先して処理し、その後にビジネスロジックとインターフェースを実装します。
   3. インフラストラクチャに関する例外：Docker、CI/CD、デプロイ、ビルド環境、運用スクリプトに関する場合も、フルスタックの主担当が一元的にオーケストレーションし、必要に応じて devops-specialist を再利用します。
   4. リリーススクリプトの入口：リリース前の統一チェックには、原則として scripts/release/pre-release-check.mjs を使用します。Review Gate の証拠が必要な場合は、まず scripts/review-gate/generate-evidence.mjs で初期記録を生成してから、手動監査または証拠の補足に進みます。
   5. 範囲のゲート：開発中に新たな最適化案や、進行を妨げない事項が見つかった場合は、必ず P 段階に戻して再度振り分けます。現在のタスクの範囲を黙って拡張してはなりません。
   • スキル：database-expert、backend-logic-expert、vue-frontend-expert、nuxt-code-editor、devops-specialist

3. A（Audit）- 監査と承認

   1. Review Gate：コード、ドキュメント、設定、スクリプト、ガバナンス定義への変更はすべて、code-quality-auditor の監査を受ける必要があります。
   2. セキュリティと整合性：セキュリティ境界、ToDo の受け入れ項目、検証マトリクス、証拠の連鎖、残存リスクを併せて確認します。
   3. 差し戻し方針：監査に失敗した場合、または現在の範囲を超える新たな問題が見つかった場合は、blocker を抱えたまま次の段階へ進まず、D に差し戻すか P に戻します。
   • スキル：code-quality-auditor、security-guardian

4. V（Validate）- ブラウザーとフローの検証

   1. インターフェースの検証：ページのレンダリング、インタラクションフロー、視覚的な動作に関わる場合は、ui-validator を使用してブラウザー上で検証します。
   2. スキップのルール：現在の事項に UI やフロー層への影響がない場合は、V 段階をスキップできる理由を明示的に記録します。何も記録せずに省略してはなりません。
   • スキル：ui-validator

5. T（Test）- テストと回帰

   1. まずテスト規範を読む：テストを実行する前に、必ずテスト規範を読みます。
   2. リスクに応じた検証の選択：変更の種類と予算に応じて、対象を絞ったテスト、全件テスト、coverage、verify、またはパフォーマンス検証を選択します。一律に全件実行してはなりません。
   3. テスト後の差し戻し：テストによってコード変更が発生した場合、または blocker が明らかになった場合は、D に戻り、A 段階の監査を改めて受けます。
   • スキル：test-engineer、code-quality-auditor

6. F（Finish）- ドキュメントと完了処理

   1. ドキュメントの同期：todo.md の状態を更新し、必要に応じて README、Guide、Standards、Design、Plan のドキュメントも同期します。
   2. 証拠の取りまとめ：リリースまたはガバナンスの完了処理では、まず scripts/review-gate/generate-evidence.mjs で Review Gate の証拠ファイルを更新し、その後、検証記録、Review Gate の結論、未検証の範囲、今後の追加実行計画をまとめます。
   3. コミットメッセージ：Commit は、このスキルにおける既定の独立した主段階ではありません。ユーザーが明示的にコミットを求めた場合、または現在のワークフローがコミット手順として明確に委任されている場合に限り、F 段階の完了後に conventional-committer を呼び出します。
   • スキル：documentation-specialist、todo-manager、conventional-committer

五、要件の掘り下げ手法（Intent Extraction Methodology）

1. 段階的に掘り下げる：まず全体の構造と目標を特定し、その後、具体的な実装の詳細に進みます。
2. 一問ずつ確認する：一度に質問するのは一つだけとし、ユーザーの回答を待ってから次の質問をします。
3. 繰り返し確認する：ユーザーの回答が明確でない場合は、表現を変えて確認します。
4. 意図を読み解く：ユーザーが何を求めているのかだけでなく、その背景にある理由を分析し、より優れた専門的な提案を行います。

六、技能引用（Each Sub-Skill Reference）

• requirement-analyst
• todo-manager
• technical-planning
• context-analyzer
• database-expert
• backend-logic-expert
• vue-frontend-expert
• nuxt-code-editor
• code-quality-auditor
• security-guardian
• ui-validator
• test-engineer
• documentation-specialist
• conventional-committer
• devops-specialist

七、编写规范 (Authoring Rules)

1. Imperative & Structured

   • 用动词+目标描述标准化每一步/每个技能的 usage section。
   • 禁止冗长废话和流程介绍型文字。

2. 明确输入输出

   • 每步须说明本阶段输入依赖、输出产物（如文件路径、文档链接）。
   • 例：输入：docs/plan/，输出：docs/design/xx.md。

3. 可链式组合

   • 每步技能应允许独立、或作为全局 master 调用链局部片段。
   • 部分技能支持多角色协同（如测试、文档可并行）。

4. 安全检查与通用异常处理

   • 强行插入 typecheck、lint 等质量关卡，禁止在未检测前进入提交/发布环节。
   • 明确安全等级和数据保护点。
   • 对迭代中途新增事项强制执行“先规划、后实现”的闸门，禁止边做边扩 scope。

5. 国际化与文档优先

   • 所有工作流/技能创建应默认兼容 i18n 和标准文档同步动作。

八、模板用法 (Usage Example)

workflow:
  - step: "需求分析"        # context-analyzer, documentation-specialist
  - step: "功能开发"        # nuxt-code-editor
  - step: "UI 验证"         # ui-validator
  - step: "质量检测"        # code-quality-auditor, security-guardian
  - step: "功能提交"        # conventional-committer
  - step: "测试补充"        # test-engineer
  - step: "测试提交"        # conventional-committer