workflow-creator

ワークフロー作成ツール

既存のスキルを連携させ、Ship Faster 標準の成果物を作成する新しい workflow-<slug>/ スキルパッケージを作成します。

厳守事項（省略しないでください）

• スキルを組み合わせ、コピーしないこと：ワークフローの役割はオーケストレーションです。他のスキルにあるベストプラクティスの長い説明をワークフローに貼り付けないでください。代わりに、各ステップを既存のスキルに対応付け、参照先を示します。
• 1 ステップにつき 1 スキル：workflow_spec.md の各ステップは、必ず 1 つの既存スキル（または、簡単で検証可能な手動操作）に対応させてください。
• 必須スキルがない場合は停止：不足しているスキルの処理を独自に書き直して代用しないでください。必須スキルがローカルにない場合は、https://skills.sh/ で候補を検索し、2～3 件の選択肢とインストールコマンドを提示して、ユーザーの返答を待ちます。
• 成果物優先で再開可能にすること：状態は run_dir/ 内の proposal.md、tasks.md、context.json に保存します。
• 実行計画を作成してから確認を求めること：生成するワークフローは、まず計画を作成してから、実行してよいかユーザーに確認します。確認の記録は tasks.md -> ## Approvals に残します。

デフォルト（Ship Faster 標準）

• 成果物の保存先：デフォルトは runs/ です。openspec/project.md が存在する場合は OpenSpec を使用します（context.json で上書きされている場合を除く）。
• 必須の実行ファイル：proposal.md、tasks.md、context.json。
• 実行モデル：まず計画を作成してから、実行してよいかユーザーに確認します。承認後、tasks.md に承認を記録します。

入力（パスのみ）

• 任意：repo_root（スキルリポジトリのルート）
• 任意：workflow_spec_path（ユーザーがすでに仕様を作成している場合）

出力

• 新規作成または更新するワークフロースキルフォルダー：
  • workflow-<slug>/SKILL.md
  • workflow-<slug>/references/workflow-spec.md（SSOT）

参考資料

• プロンプトパック（プロンプトの原文）：references/prompt-pack.md
• ワークフロー仕様テンプレート（SSOT）：references/workflow-spec-template.md
• 生成されたワークフロースキルの例：references/example-workflow-skill.md
• ワークフロー仕様の有効な例：references/example-workflow-spec.md

手順

0) スキルのルートを解決する（決定的）

次の優先順位で skills_root を解決します。

1. ユーザーが repo_root を指定した場合は、それを使用します。
2. 現在の作業ディレクトリから上位のディレクトリを検索し、次のいずれかに該当するものを使用します。
   • <dir>/skills/manifest.json（モノレポ構成）→ skills_root = <dir>/skills/
   • <dir>/manifest.json（スキルリポジトリ構成）→ skills_root = <dir>/

1) workflow_spec.md を作成または読み込む（SSOT）

workflow_spec_path が指定されていない場合：

1. まず workflow-brainstorm を呼び出し、以下の項目をまとめます。

   • 中核となる目標（1文）
   • 受け入れ基準（3～7項目）
   • 対象外（1～5項目）
   • 制約（リスクの許容度、スケジュール）
   • ユーザーが実際に使うトリガーフレーズを5～10個

2. スキルの検出（必須） - required_skills を確定する前に実施します。

   a) ローカルスキルのスキャン：skills_root 以下にある、関連する可能性のあるスキルをすべて一覧表示します。

   ls -1 ~/.claude/skills/ | grep -E "(tool-|review-|workflow-)" 
   

   ワークフローの各ステップで利用できるローカルスキルを特定します。

   b) skills.sh の検索（必須）：https://skills.sh/ からリーダーボードを取得し、関連するスキルを特定します。

   • ワークフローの目標に関連するキーワードを検索します
   • 関連カテゴリでインストール数上位のスキルを記録します
   • 有用な可能性のある外部スキルを3～5個特定します

   c) 調査結果をユーザーに提示：

   ## スキル検出結果
   
   ### ローカルスキル（利用可能）
   | スキル | 関連性 | 備考 |
   |-------|-----------|-------|
   | tool-xxx | 高 | ... |
   | review-yyy | 中 | ... |
   
   ### 外部スキル（skills.sh）
   | スキル | インストール数 | ソース | 関連性 |
   |-----------|----------|--------|-----------|
   | skill-name | 10K | owner/repo | ... |
   
   確定する前に、外部スキルの詳細を確認しますか？（番号のリストまたは「なし」）
   

   d) ユーザーが確認を希望する場合：skills.sh のページからスキルの詳細を取得し、SKILL.md の内容を表示してから、再度確認します。

   e) ユーザーが最終的なスキルの選択を確定：確定後にのみ、仕様の作成に進みます。

3. references/workflow-spec-template.md のテンプレートを使って workflow_spec.md を作成します。

2) 仕様を検証する（決定的）

実行します。

python3 scripts/validate_workflow_spec.py /path/to/workflow_spec.md

生成する前に、検証エラーを修正します。

3) スキルの依存関係を解決する

1. 仕様から required_skills / optional_skills を読み込みます。
2. skills_root 以下に存在するスキルを確認します。
3. 必須スキルが見つからない場合：
   • 停止します。
   • references/prompt-pack.md のプロンプトを使って skills.sh を検索します。
   • 候補を2～3個（リンクと理由）提案し、インストールコマンドの例を提示します。ただし、自動インストールはしません。

4) workflow-<slug>/ を生成または更新する

1. skills_root の下に workflow-<slug>/ がなければ作成します。
2. SSOT を書き込みます。
   • workflow-<slug>/references/workflow-spec.md（検証済みの仕様をコピー）
3. workflow-<slug>/SKILL.md を生成または更新します。
   • フロントマターの name はディレクトリ名（workflow-<slug>）と一致させる必要があります。
   • フロントマターの description に、仕様の triggers（ルーティングの手がかり）を含める必要があります。
   • Ship Faster の成果物バックエンドの選択ルール（runs/ と OpenSpec のどちらを使うか）を含めます。
   • 計画後に確認を求める実行ポリシーを含めます。
     • 計画段階では、tasks.md にチェックリストを書き込みます。
     • 開始してよいかユーザーに確認します。
   • 承認後、tasks.md -> ## Approvals の下に承認記録（タイムスタンプ＋対象範囲）を追記し、実行を開始します。
   • チェーンの各ステップを1つのスキルに対応付けます。
   • ワークフローは簡潔に保ち、詳細は他のスキルへのリンクで案内します。

5) 基本検証（必須）

実行します。

python3 scripts/validate_skill_md.py /path/to/workflow-<slug>

失敗した場合は、フロントマター、名前、または行末を修正して合格させます。

注：リポジトリには skill-creator/scripts/quick_validate.py も含まれていますが、追加の Python 依存関係が必要な場合があります。このスキルの検証ツールをデフォルトとして使用してください。