mcpField
D
default-workflow

default-workflow

github.com/rysweet開発76132 回インストール21 週間前に更新
リポジトリ

default-workflow について

amplihack の複雑なコード変更向けワークフローを定めるスキルです。要件確認から実装、テスト、レビュー、マージまでを案内し、各段階を専門エージェントに委ねます。

主な機能

  1. 01構造化された開発ワークフロー
  2. 02要件とコードベースの分析
  3. 03専門エージェントへの委任
  4. 04TodoWrite による進捗管理
  5. 05チェックポイントと復旧ガイダンス

活用シーン

  1. 01複数ファイルにまたがる機能実装の調整
  2. 02複雑な統合やリファクタリングの管理
  3. 03ワークフロー失敗後の開発再開

インストール

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

$npx skills add https://github.com/rysweet/amplihack --skill default-workflow

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

詳細

既定のワークフロースキル

ワークフローグラフ

flowchart TD
    subgraph P1["Phase 1: Requirements Clarification"]
        S0[Step 0: Workflow Preparation] --> S1[Step 1: Prepare Workspace]
        S1 --> S2[Step 2: Clarify Requirements]
        S2 --> S2b[Step 2b: Analyze Codebase]
        S2b --> S2c{Ambiguity?}
        S2c -->|yes| S2d[Step 2c: Resolve Ambiguity]
        S2c -->|no| S3
        S2d --> S3[Step 3: Create GitHub Issue]
        S3 --> S3b[Step 3b: Extract Issue Number]
    end

    subgraph P2["Phase 2: Design"]
        S4[Step 4: Setup Worktree/Branch] --> S5[Step 5: Architecture Design]
        S5 --> S5b{API needed?}
        S5b -->|yes| S5c[Step 5b: API Design]
        S5b -->|no| S5d
        S5c --> S5d{Database needed?}
        S5d -->|yes| S5e[Step 5c: Database Design]
        S5d -->|no| S5f
        S5e --> S5f[Step 5d: Security Review]
        S5f --> S5g[Step 5e: Design Consolidation]
    end

    subgraph P3["Phase 3: Implementation"]
        S6[Step 6: Documentation] --> S6b[Step 6b: Doc Review]
        S6b --> S6c[Step 6c: Doc Refinement]
        S6c --> S7[Step 7: Write Tests - TDD]
        S7 --> S8[Step 8: Implement]
        S8 --> S8b[Step 8b: Integration]
        S8b --> S9[Step 9: Refactor]
        S9 --> S9b[Step 9b: Optimize]
    end

    subgraph P4["Phase 4: Testing & Review"]
        S10[Step 10: Pre-commit Review] --> S10b[Step 10b: Security Review]
        S10b --> S10c[Step 10c: Philosophy Check]
        S10c --> S11[Step 11: Incorporate Feedback]
        S11 --> S11b[Step 11b: Implement Feedback]
        S11b --> S12[Step 12: Run Pre-commit Hooks]
        S12 --> S13[Step 13: Local Testing]
    end

    subgraph P5["Phase 5: Version & PR"]
        S14[Step 14: Bump Version - MANDATORY] --> S15[Step 15: Commit & Push]
        S15 --> S16[Step 16: Create Draft PR]
        S16 --> S16b[Step 16b: Outside-In Fix Loop]
    end

    subgraph P6["Phase 6: PR Review - MANDATORY"]
        S17a[Step 17a: Compliance Verification] --> S17b[Step 17b: Reviewer Agent]
        S17b --> S17c[Step 17c: Security Review]
        S17c --> S17d[Step 17d: Philosophy Guardian]
        S17d --> S17e{Blocking issues?}
        S17e -->|yes| S17f[Step 17e: Address Blocking]
        S17e -->|no| S17g
        S17f --> S17g[Step 17f: Verification Gate]
        S17g --> S18a[Step 18a: Analyze Feedback]
        S18a --> S18b[Step 18b: Implement Feedback]
        S18b --> S18c[Step 18c: Push Changes]
        S18c --> S18d[Step 18d: Respond to Comments]
        S18d --> S18e[Step 18e: Verification Gate]
    end

    subgraph P7["Phase 7: Merge"]
        S19a[Step 19a: Philosophy Check] --> S19b[Step 19b: Patterns Check]
        S19b --> S19c[Step 19c: Zero-BS Verification]
        S19c --> S19d[Step 19d: Verification Gate]
        S19d --> S20[Step 20: Final Cleanup]
        S20 --> S20b[Step 20b: Push Cleanup]
        S20b --> S20c[Step 20c: Quality Audit]
        S20c --> S21[Step 21: PR Ready]
        S21 --> S22[Step 22: Ensure Mergeable]
        S22 --> S22b[Step 22b: Final Status]
    end

    P1 --> P2 --> P3 --> P4 --> P5 --> P6 --> P7

目的

このスキルは、amplihack における、単純ではないすべてのコード変更に対する標準的な開発ワークフローを提供します。複数ファイルにまたがる実装、複雑な統合、大規模なリファクタリングを検出すると、自動的に有効になります。

このワークフローでは、要件の明確化から設計、実装、テスト、レビュー、マージまで、一連の標準的な実行プロセスを定義します。各ステップで専門エージェントを連携させ、全体を通じて理念への準拠を徹底することで、一貫した品質を確保します。

これは、完全なワークフロー定義を一元的な場所に保存し、スキルのインターフェースとワークフロー仕様の重複や乖離を防ぐための薄いラッパーです。

正規のソース

このスキルは、正規のワークフローを参照する薄いラッパーです。

ソース：~/.amplihack/.claude/workflow/DEFAULT_WORKFLOW.md（471 行以上）

正規のワークフローには、開発プロセス全体と、すべての詳細、エージェントの仕様、実行ガイダンスが含まれています。

実行手順

このスキルが有効になったら、必ず次の手順を実行してください。

  1. 正規のワークフローをただちに読み込む：

    Read(file_path="~/.amplihack/.claude/workflow/DEFAULT_WORKFLOW.md")

    注：パスはプロジェクトルートからの相対パスです。Claude Code が自動的に解決します。

  2. 正規のワークフローに記載されたすべての手順に正確に従う

  3. TodoWrite を使って、次の形式でワークフローの進捗を記録する：

    • Step N: [Step Name] - [Specific Action]
    • 例：Step 1: Rewrite and Clarify Requirements - Use prompt-writer agent
    • これにより、現在どのワークフローステップを実行中かをユーザーが正確に把握できます。

  4. 各ワークフローステップの指定に従って専門エージェントを呼び出す：

    • ステップ 1：prompt-writer、analyzer、ambiguity エージェント
    • ステップ 4：architect、api-designer、database、tester、security エージェント
    • ステップ 5：builder、integration エージェント
    • ステップ 6：cleanup、optimizer エージェント
    • ステップ 7：pre-commit-diagnostic エージェント
    • ステップ 9～15：レビューおよびマージエージェント

このパターンを採用する理由

メリット：

  • ワークフロー定義の単一の信頼できる情報源
  • コンテンツの重複や乖離を防止
  • ワークフローへの変更を正規の場所で一度だけ実施
  • スキルとワークフロー間の明確な委任契約
  • トークン使用量を削減（スキルは約 60 行、正規のソースは 471 行以上）

自動有効化のトリガー

このスキルは、次の場合に自動的に有効になります。

  • 複数ファイル（5 個以上）にまたがる機能
  • コンポーネント間の複雑な統合
  • 5 個以上のファイルに影響するリファクタリング
  • 構造化されたワークフローを必要とする、単純ではないコード変更全般

既知の失敗ポイントと回復ガイダンス

ワークフローの実行中によく失敗するステップです。このワークフローを実行するエージェントは、これらのステップで問題に遭遇した場合、必ず文書化された回復パターンを適用してください。

ステップ 3 — イシューの作成（ラベルが見つからない）

失敗：ラベルを作成できない場合（権限の拒否、API のタイムアウト）、gh label create は失敗を通知せずに終了します。 回復：ラベルの追加はベストエフォートです。gh issue create --label が失敗した場合は、--label を付けずに再試行してください。重要な成果物はイシューそのものであり、ラベルではありません。

ステップ 4 — ワークツリーのセットアップ（リモートなし／origin/main なし）

失敗：リポジトリにリモートがない場合、または origin/main が存在しない場合、git fetch origin main は中断します。 回復：最初にトポロジーを検出します。リモートがない場合は、ベース参照に HEAD を使用し、プッシュおよびアップストリームのセットアップを省略します。ワークツリーの出力に含まれる bootstrap フラグは、後続のステップでリモート操作を省略する必要があることを示します。

ステップ 4 — 初回プッシュ（ネットワークの一時的な問題）

失敗：ネットワークの問題により、新しいブランチの作成時に git push origin <branch> が失敗します。 回復：ステップ 4 でプッシュに失敗した場合、目に見える警告を出してステップ 15／16 に延期します。コミットおよびプッシュの時点で、回数を制限した再試行（最大 3 回、2 秒のバックオフ）を行います。ステップ 16 でも、PR の作成前にプッシュを再試行します。

ステップ 5b — エージェントの出力アーティファクトがない

失敗：エージェントの出力ファイルが書き込まれない、または破損しており、後続のステップで入力が空になって失敗します。 回復性：エージェントのステップで出力が空になった場合、レシピランナーはエラーを見える形で表示する必要があります。設計後（ステップ 5e）と実装後（ステップ 8b）のチェックポイントにより、部分的な作業が保持され、ワークフローを最も近い安全な地点から再開できます。

ステップ 15 — リモートへのプッシュ（上流の追跡）

失敗：上流が設定されていない場合（初回プッシュ時）、git rev-list --count @{u}..HEAD が失敗します。 回復性：上流が設定されていないことを明示的に検出します。@{u} が失敗した場合、何も通知せずにスキップするのではなく、無条件にプッシュします。一時的なネットワークエラーが発生した場合は、バックオフしてプッシュを再試行します。

ステップ 16 — PR の作成（すでに存在する／コミットがない）

失敗：gh pr create は、「No commits between main and branch」や PR の重複を理由に失敗します。 回復性：べき等性ガードにより、作成前にブランチ名で既存の PR を確認します。PR がすでに存在する場合は、それを再利用します。先行するコミットがない場合は、空の PR を作成せず、エラーを見える形で表示します。

ステップ 21 — PR の準備完了（大きなテンプレート変数）

失敗：テンプレート変数 philosophy_check、patterns_check、または quality_audit_results にシェルのメタ文字が含まれているか、ARG_MAX を超えると、シェルの && チェーンが破綻します。 回復性：大きなテンプレート変数はヒアドキュメント経由で取得され、シェルコマンドで使用する前に 1KB まで切り詰められます。ステップ 21 では、bash でテンプレートの内容をそのまま出力しません。大きなテキストはエージェントのステップでネイティブに処理します。

チェックポイント戦略

ワークフローでは、作業の消失を防ぐため、次の時点で自動チェックポイントが作成されます。

チェックポイントステップの後保持されるもの
checkpoint-after-design5e（設計の統合）アーキテクチャの決定、API 設計、DB スキーマ
checkpoint-after-implementation8b（統合）テスト、実装コード、統合作業
checkpoint-after-review-feedback11b（フィードバックの実装）レビューで指摘された変更

チェックポイント後にステップが失敗した場合、ワークツリーのブランチにはコミット済みの作業がすべて保持されます。既存のワークツリーを使ってワークフローを再実行すると、エージェントは最新のチェックポイントから再開できます。

関連ファイル

  • 標準ワークフロー：~/.amplihack/.claude/workflow/DEFAULT_WORKFLOW.md
  • コマンドインターフェース：~/.amplihack/.claude/commands/amplihack/ultrathink.md
  • オーケストレータースキル：~/.amplihack/.claude/skills/ultrathink-orchestrator/
  • 調査ワークフロー：~/.amplihack/.claude/skills/investigation-workflow/

コメント

Markdown 対応