sherpy-flow

Sherpy Flow

Sherpy の計画パイプライン全体を最初から最後まで実行します。既存の成果物をもとにワークフロー内の現在位置を検出し、そこから再開します。次にどのスキルを使うか、またその入力が何かを覚えておく必要はありません。

使用方法

/sherpy-flow [output-directory]

ディレクトリが指定されていない場合は、ユーザーに「計画ドキュメントをどこに作成しますか？」と尋ねます。

ユーザーがパスを指定するまで待ってから、先に進みます。

パイプライン

Step 1   Gap Analysis Worksheet         → gap-analysis-worksheet.md
Step 2   Business Requirements          → business-requirements.yaml
Step 3   Technical Requirements         → technical-requirements.yaml
Step 4   Style Anchors Collection       → style-anchors/index.yaml + *.md
Step 5   Implementation Planner         → milestones.yaml + milestone-m*.tasks.yaml (with optional acceptance_criteria)
Step 6   UX/Wireframe Planning          → wireframe-spec.yaml + wireframes/*.pen (conditional: auto-skips if no UI changes)
Step 7   Implementation Plan Review     → implementation-plan-review.yaml
Step 8   Architecture Decision Records  → adrs/INDEX.md + adrs/ADR-*.md
Step 9   Delivery Timeline              → timeline.yaml
Step 10  QA Test Plan                   → qa-test-plan.yaml
Step 11  Generate Summaries             → developer-summary.md + executive-summary.md

すべての成果物は自動的に以下のように整理されます。

<output-directory>/
├── requirements/       (requirements, gap analysis)
├── implementation/
│   ├── milestones.yaml (with optional acceptance_criteria)
│   └── tasks/          (milestone task files)
├── ux/                 (wireframe spec + Pencil wireframes)
│   ├── wireframe-spec.yaml
│   ├── wireframes.pen
│   └── PAGE-001.png
├── delivery/           (timeline, QA test plan)
├── architecture/
│   └── adrs/           (ADRs)
├── artifacts/          (reviews, interview transcripts, style anchors, CONTINUE.md, etc.)
└── summaries/          (developer & executive summaries)

プロセス

ステップ 0：出力ディレクトリを決定する

パラメーターとしてディレクトリが指定されていない場合は、ユーザーに次のように尋ねます。

「計画ドキュメントをどこに作成しますか？」

ユーザーの回答を待ちます。指定されたパスを base_directory として保存します。

この段階ではフォルダーを作成しないでください。 フォルダーは、各スキルがファイルを生成する際に必要に応じて作成します。

ステップ 1：既存の成果物をスキャンする

整理された構成内に既存のファイルがあるか、base_directory を確認します。

成果物	想定される場所	完了を示すステップ
gap-analysis-worksheet.md	requirements/	ステップ 1
business-requirements.yaml	requirements/	ステップ 2
technical-requirements.yaml	requirements/	ステップ 3
style-anchors/index.yaml	artifacts/style-anchors/	ステップ 4
milestones.yaml	implementation/	ステップ 5
milestone-m*.tasks.yaml	implementation/tasks/	ステップ 5
wireframe-spec.yaml	ux/	ステップ 6
implementation-plan-review.yaml	artifacts/	ステップ 7
adrs/INDEX.md	architecture/adrs/	ステップ 8
timeline.yaml	delivery/	ステップ 9
qa-test-plan.yaml	delivery/	ステップ 10
developer-summary.md	summaries/	ステップ 11
executive-summary.md	summaries/	ステップ 11

成果物の検出ロジック：

• base_directory 内の想定される場所を確認します
• ファイルが存在する場合、そのステップは完了したものとみなします
• スキルはファイルの生成時に必要なフォルダーを作成します

ステップ 2：パイプラインの状況を表示する

作業を始める前に、パイプラインの視覚的な状況を表示します。

## Sherpy Flow — [Project Directory]

 ✓  Step 1   Gap Analysis Worksheet
 ✓  Step 2   Business Requirements
 →  Step 3   Technical Requirements        ← resuming here
 ○  Step 4   Style Anchors Collection
 ○  Step 5   Implementation Planner
 ○  Step 6   UX/Wireframe Planning
 ○  Step 7   Implementation Plan Review
 ○  Step 8   Architecture Decision Records
 ○  Step 9   Delivery Timeline
 ○  Step 10  QA Test Plan
 ○  Step 11  Generate Summaries

Resuming from Step 3. Type "start over" to restart from Step 1,
or specify a step number to jump to a specific point.

凡例： ✓ 完了 · → 現在 · ○ 未着手

次に、以下のように尋ねます。

「ステップ [n]：[ステップ名] から続けますか？（yes / start over / jump to step N）」

続行する前に、確認を待ちます。

ステップ 3：各ステップを実行する

保留中の各ステップについて、base_directory をパラメーターとして指定し、参照先のスキルを呼び出します。各ステップの動作は、スキルを単独で呼び出した場合と同じです。sherpy-flow は実行順を制御するものであり、スキルの代替ではありません。

重要な実行ルール：

1. ユーザーの明示的な確認なしに次のステップへ進まないでください — 各ステップの完了後、必ず待ちます
2. ステップ 4（スタイルアンカーの収集）を自動的にスキップしてはいけません — スキップを希望する場合は、必ずユーザーに確認し、リスクを警告します
3. ステップに必要な入力が存在しない場合（例：ステップ 5 でスタイルアンカーが必要な場合）は、続行する前に停止してユーザーに警告します

重要：ファイルが正しい場所に作成されるよう、各スキルに base_directory を渡します。スキルは出力の生成時に必要なフォルダーを作成します。

各スキルは、base_directory 内の正しい場所にファイルを出力する責任を負います。スキルの実行後にファイルを整理する必要はありません。スキルは最初から適切な場所にフォルダーとファイルを作成します。

想定される出力場所

スキルを呼び出す際は、パラメーターとして base_directory を渡します（または、スキルが requirements/business-requirements.yaml を探して自動検出します）。

要件ドキュメント：

• gap-analysis-worksheet.md → {base_directory}/requirements/
• business-requirements.yaml → {base_directory}/requirements/
• technical-requirements.yaml → {base_directory}/requirements/

実装ドキュメント：

• milestones.yaml → {base_directory}/implementation/
• milestone-m*.tasks.yaml → {base_directory}/implementation/tasks/ デリバリー文書：
• timeline.yaml → {base_directory}/delivery/
• qa-test-plan.yaml → {base_directory}/delivery/

アーキテクチャ文書：

• adrs/INDEX.md + ADR-*.md → {base_directory}/architecture/adrs/

成果物／レビュー文書：

• business-interview.jsonl → {base_directory}/artifacts/
• technical-interview.jsonl → {base_directory}/artifacts/
• style-anchors/index.yaml + *.md → {base_directory}/artifacts/style-anchors/
• implementation-plan-review.yaml → {base_directory}/artifacts/
• CONTINUE.md → {base_directory}/artifacts/
• FEATURE_FLAGS.md → {base_directory}/artifacts/
• UPDATES.md → {base_directory}/artifacts/

要約文書：

• developer-summary.md → {base_directory}/summaries/
• executive-summary.md → {base_directory}/summaries/

ステップ 1 — ギャップ分析ワークシート（/gap-analysis-worksheet）

• プロジェクトディレクトリに初期要件文書がない場合、このステップはスキップします。
• 初期要件文書（.md、.txt、または .docx 形式のファイルとして記述されたもの）が存在する場合は、それに対してギャップ分析を実施します。
• 完了後、次のように確認します：「ギャップ分析ワークシートを生成しました。ビジネス要件インタビューに進みますか？」

ステップ 2 — ビジネス要件インタビュー（/business-requirements-interview）

• インタビュープロセス全体を実施します（質問は一度に 1 つずつ行い、進捗を business-interview.jsonl に記録します）。
• business-requirements.yaml の生成後、要約を表示して次のように確認します：「ビジネス要件が完了しました。技術要件に進みますか？」

ステップ 3 — 技術要件インタビュー（/technical-requirements-interview）

• business-requirements.yaml が必要です。
• インタビュープロセス全体を実施します。
• technical-requirements.yaml の生成後、要約を表示して次のように確認します：「技術要件が完了しました。スタイルアンカーの収集に進みますか？」

ステップ 4 — スタイルアンカーの収集（/style-anchors-collection）— 必須

• technical-requirements.yaml が必要です。
• 重要：このステップをスキップしてはいけません。スタイルアンカーは、実装中のアーキテクチャの逸脱を防ぎます。
• 承認済みパターンを示すコード例を対話形式で収集します。
• 技術要件で特定した各パターンについて、以下を行います。
  • ユーザーにファイルパスと行範囲の提示を依頼します
  • パターンが示す内容を文書化します
  • 使用するタイミングを指定します
• 個別の .md ファイルと index.yaml を含む style-anchors/ ディレクトリを生成します。
• ユーザーがスキップを希望する場合：「スタイルアンカーをスキップすると、逸脱のリスクが大幅に高まります。本当にスキップしますか？（スキップする場合は yes／アンカーを収集する場合は no）」と確認します。
• 完了後、カテゴリごとのアンカー数を表示して、次のように確認します：「スタイルアンカーを収集しました。実装プランナーに進みますか？」

ステップ 5 — 実装プランナー（/implementation-planner）

• business-requirements.yaml と technical-requirements.yaml が必要です。
• 強く推奨：ステップ 4 で作成した style-anchors/index.yaml。
• 実行前に：

  1. スタイルアンカーがない場合は、停止して次のように確認します。

     "⚠️ スタイルアンカーが見つかりません。具体的なコード例を含めずに実装プランを生成するため、アーキテクチャの逸脱リスクが大幅に高まります。

     次のいずれかを選択してください。

     1. ステップ 4 に戻り、今すぐスタイルアンカーを収集する（推奨）
     2. スタイルアンカーなしで続行する（非推奨）"

     • ユーザーがオプション 1 を選択した場合は、ステップ 4 に戻ります。
     • ユーザーがオプション 2 を選択した場合は、「スタイルアンカーなしで続行します。実装中の逸脱が大きくなることが予想されます。続行しますか？（yes/no）」と確認します。

  2. 対象読者を選択する質問をします：

     "この実装計画の主な対象読者は誰ですか？

     1. AI Agent — 自律的な開発に向けた、詳細かつ具体的な指示
     2. Human Developers — 経験豊富なチーム向けの概要レベルのガイダンス
     3. Hybrid — 混成チームまたはペアプログラミング向けの中程度の詳細さ

     これは、タスクの指示に含める詳細度に影響します。AI Agent には 実装手順を段階的に示し、Human Developers には概要レベルの 目標と制約のみを示します。"

  3. ユーザーの回答を待ち、target_audience パラメーターを使って implementation-planner スキルに渡します。

• milestones.yaml と milestone-m*.tasks.yaml を生成します。
• Step 4 で収集したスタイルの指針があれば、タスクの指示で自動的に参照されます。
• 完了後、マイルストーンの概要を表示し、次のように尋ねます：「実装計画を生成しました。UX／ワイヤーフレーム計画に進みますか？」

Step 6 — UX／ワイヤーフレーム計画（/ux-wireframe-planning）— 条件付き

• milestones.yaml、タスクファイル、および technical-requirements.yaml が必要です。
• 検出： 技術スタックとタスクファイルをスキャンし、UI／Web アプリの変更（React、.tsx ファイル、コンポーネント、ページ）を確認します。
• UI の変更がない場合：自動的にスキップします。has_ui_changes: false を含む wireframe-spec.yaml を生成します。パイプラインのステータスにスキップを記録します。ユーザーへの確認は不要です。
• UI の変更が見つかった場合：wireframe-spec.yaml を生成し、自己完結型の Pencil ワイヤーフレームファイル（すべてのコンポーネントとページフレームを含む wireframes.pen）を作成して、PNG プレビューをエクスポートします。
• 完了後（スキップされた場合を除く）、ページ／コンポーネント数を表示し、次のように尋ねます：「ワイヤーフレームを生成しました。計画レビューに進みますか？」

Step 7 — 実装計画レビュー（/implementation-plan-review）

• milestones.yaml とタスクファイルが必要です。
• 完全なレビューを実行します。
• implementation-plan-review.yaml の生成後、準備状況スコアと重大な問題を表示します。
• 重大な問題がある場合は、次のように尋ねます：

  "計画レビューで重大な問題が [n] 件見つかりました。どのようにしますか？

  1. 今すぐ問題に対処する（Step 5 に戻ります）
  2. 問題を認識したうえで続行する
  3. まず問題の詳細を確認する"

• それ以外の場合は、次のように尋ねます：「計画レビューに合格しました。アーキテクチャ決定記録に進みますか？」

Step 8 — アーキテクチャ決定記録（/architecture-decision-record）

• technical-requirements.yaml が必要です。
• すべての ADR ファイルを含む adrs/ ディレクトリを生成します。
• 完了後、ADR の数を表示し、次のように尋ねます：「アーキテクチャの決定を記録しました。デリバリーのスケジュールに進みますか？」

Step 9 — デリバリーのスケジュール（/delivery-timeline）

• milestones.yaml が必要です。
• このスキルで定義されている、デリバリーに関する3つのパラメーター（本番環境へのデプロイ日、QA のラウンド数、各ラウンドの日数）を質問します。
• timeline.yaml を生成します。
• 完了後、作業の逆算スケジュール（プロジェクト開始日 → デプロイ日）を表示し、次のように尋ねます：「デリバリーのスケジュールを生成しました。QA テスト計画に進みますか？」

Step 10 — QA テスト計画（/qa-test-plan）

• business-requirements.yaml と technical-requirements.yaml が必要です。
• qa-test-plan.yaml を生成します。
• 完了後、カバレッジの概要を表示し、次のように尋ねます：「QA テスト計画を生成しました。サマリーの生成に進みますか？」

Step 11 — サマリーの生成（/developer-summary + /executive-summary）

• 必要なファイル：business-requirements.yaml、technical-requirements.yaml、milestones.yaml、timeline.yaml。
• まず /developer-summary を実行して、開発者向けのサマリーを生成します。
• 次に /executive-summary を実行して、経営陣／ステークホルダー向けのサマリーを生成します。
• どちらのスキルも、docs/ フォルダー構造から必要なファイルを自動検出します。
• 両方のサマリーが生成されたら、完了を表示して最終サマリーに進みます。

Step 4：最終サマリー

すべてのステップが完了したら、最終サマリーを表示します：

## Sherpy Flow Complete ✓

**Project:** [name]
**Directory:** [path]

All artifacts organized in: [base_directory]/

📋 Requirements
  ✓ gap-analysis-worksheet.md       [if generated]
  ✓ business-requirements.yaml
  ✓ technical-requirements.yaml

🔨 Implementation
  ✓ milestones.yaml
  ✓ tasks/milestone-m*.tasks.yaml   ([n] task files)

🚀 Delivery
  ✓ timeline.yaml
  ✓ qa-test-plan.yaml

🏛️ Architecture
  ✓ adrs/INDEX.md + ADR-*.md        ([n] decision records)

📊 Summaries
  ✓ developer-summary.md
  ✓ executive-summary.md

📁 Artifacts
  ✓ implementation-plan-review.yaml
  ✓ business-interview.jsonl
  ✓ technical-interview.jsonl
  ✓ style-anchors/index.yaml + [n] anchor files

Timeline: [project start date] → [production deploy date]
Total Delivery Days: [n] business days
QA Rounds: [n] × [n] days each

Your project is fully planned and ready for development!

Next Steps:
- Review summaries/ for project overview
- Start development with implementation/milestones.yaml
- Use /create-continuation-prompt to hand off context to a new session

遷移ルール

• 重要：次のステップに進む前に、必ず確認してください — 自動的に次へ進んではいけません。各ステップの完了後、必ずユーザーから明示的な確認を待ってください。
• ステップ 4（スタイルアンカー）は必須です：ユーザーがスキップを明示的に依頼し、リスク警告を確認した後に承認した場合を除き、このステップをスキップしてはいけません。
• 前のステップに戻る：ユーザーが「go back」または「redo step N」と言った場合は、そのステップに戻って再実行します。新しい出力で以前の成果物を上書きします。
• スキップ：ユーザーが「skip step N」と言った場合：
  • N == 4（スタイルアンカー）の場合：ドリフトのリスクについて警告を表示し、「yes to skip」という明示的な確認を求めます。
  • それ以外のステップの場合：スキップとして記録し、最終サマリーに記載します。その出力を必要とする後続ステップでは、入力が不足している場合に警告します。
• ジャンプ：ユーザーが「jump to step N」と言った場合は、そのステップから先を実行します。必要な入力は既存の成果物から読み込みます。
• 中断：ユーザーがフローの途中で停止する必要がある場合は、/sherpy-flow を再度実行すれば再開できることを伝えてください。パイプラインのステータスには、中断した箇所が正確に表示されます。