claude-skills/

Anthropic公式スキル・プラグインの日本語ディレクトリ

last sync 22h ago
スキルOfficialdevelopment

📋output-plan-workflow

プラグイン
outputai
ソース
GitHub で見る ↗

説明

次のような場合に使用: ユーザーが新しいワークフローの作成、構築、生成、スキャフォールド、または計画を依頼したとき。 アーキテクチャ、ステップ、プロンプト、エバリュエーター、テスト戦略を含む全体的な計画プロセスを、専門化されたサブエージェントを活用してオーケストレーションします。

原文を表示

Use when the user asks to create, build, generate, scaffold, or plan a new workflow. Orchestrates the full planning process including architecture, steps, prompts, evaluators, and testing strategy using specialized subagents.

ユースケース

  • ✓新しいワークフローの作成を依頼されたとき
  • ✓ワークフローの構築を依頼されたとき
  • ✓ワークフローの生成を依頼されたとき
  • ✓ワークフローの計画を依頼されたとき

本文（日本語訳）

あなたのタスクは、Output.ai ワークフローの包括的な実装計画をMarkdown形式で生成することです。

作成された計画はユーザーに表示され、ユーザーはその後の対応を決定します。

最終版の計画のみを返答してください。

計画作成プロセスの進捗管理には todo ツールを使用してください。

計画作成ルール

概要

新しいワークフローの実装に関する詳細な仕様を生成します。

出力パス

すべての計画の出力先: .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md

<process_flow>

<step number="0" name="arguments_analysis">

ステップ 0: 引数の分析

コマンドに渡された引数を分析します:

{ $ARGUMENTS }

<substep number="0" name="arguments_analysis">

以下の情報が提供されているか確認してください:

  • workflow_description: 作成するワークフローの説明
  • additional_instructions: ワークフローへの追加指示

不足している情報がある場合は、ユーザーに確認してください。 </substep>

<substep number="1" name="pre_flight_check"> 実行: Claude Skill: output-meta-pre-flight </substep>

</step>

<step number="1" name="context_gathering" subagent="workflow-context-fetcher">

ステップ 1: コンテキストの収集

包括的な計画を作成するために必要なコンテキストをすべて収集します。

  1. 指定されたファイルやリンクを読み込む
  2. プロジェクト内の関連ワークフローを検索する
  3. プロジェクトのドキュメントファイルを読み込む

</step>

<step number="2" name="requirements_clarification">

ステップ 2: 要件の明確化

スコープの境界と技術的な考慮事項を明確にするため、必要に応じて番号付きの質問を行い、作業を進める前に要件を明確にします。

<clarification_areas> <scope> - in_scope: 含まれる内容 - out_of_scope: 除外される内容（任意） </scope> <technical> - 機能の詳細 - UI/UX 要件 - 連携ポイント </technical> <llm_provider> - 使用する LLM プロバイダーをユーザーに確認する（anthropic、openai、または vertex） - ユーザーが希望を持たない場合は anthropic をデフォルトとする - ユーザーが明示的に別途要求しない限り、ワークフロー内のすべてのプロンプトファイルは同一プロバイダーを使用すること - 選択したプロバイダーをプロンプトエンジニアリング（ステップ 6）および実装に引き継げるよう記録する </llm_provider> </clarification_areas>

<decision_tree> IF clarification_needed: 番号付きの質問を行う ユーザーの回答を待つ ELSE: スキーマ定義へ進む </decision_tree>

</step>

<step number="3" name="workflow_design" subagent="workflow-planner">

ステップ 3: ワークフローの設計

明確な単一目的のステップと適切なオーケストレーションロジックを持つワークフローを設計します。

<thought_process>

  1. ワークフローの名前と説明を定義する
  2. ワークフローの有効な出力スキーマは何か？
  3. ワークフローの有効な入力スキーマは何か？
  4. 入力を出力に変換するために何が必要か？
  5. 入力を出力に変換するために必要なアトミックなステップは何か？
  6. これらのステップはどのように関連しているか？
  7. 条件付きのステップはあるか？
  8. これらのステップのうち、プロジェクト内にすでに定義されているものはあるか？
  9. これらのステップはどのように失敗し得るか、またその対処方法は？（リトライ、バックオフ等）

</thought_process>

<step_output> ドラフト計画を出力: .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md へ </step_output>

</step>

<step number="4" name="step_design" subagent="workflow-planner">

ステップ 4: ステップの設計

ワークフローから呼び出される個々のステップを、明確な境界を持つように設計します。

<thought_process>

  1. 各ステップの名前と説明は何か？
  2. 各ステップの入力スキーマは何か？
  3. 各ステップの出力スキーマは何か？
  4. 各ステップが使用する外部サービスや API は何か？
  5. 各ステップに必要なエラーハンドリングは何か？
  6. 各ステップに適用すべきリトライポリシーは何か？ </thought_process>

<step_output> 更新された計画を出力: .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md へ </step_output>

</step>

<step number="4.5" name="evaluator_design" subagent="workflow-planner">

ステップ 4.5: エバリュエーターの設計

ワークフローに品質評価、バリデーション、またはコンテンツ評価が必要かどうかを判断します。

<decision_tree> IF workflow_outputs_need_quality_scoring: エバリュエーター関数を設計する IF workflow_has_llm_generated_content: コンテンツ評価を検討する（事実の正確性、関連性、トーン） IF workflow_requires_validation_with_confidence: バリデーション用エバリュエーターを設計する ELSE: エバリュエーター設計をスキップ（計画に「エバリュエーター不要」と記載） </decision_tree>

<thought_process>

  1. ワークフローは品質評価が必要なコンテンツを生成するか？
  2. 評価が必要な LLM 生成の出力はあるか？
  3. 信頼スコア付きのバリデーションはワークフローにとって有益か？
  4. 適切な評価結果の型は何か（boolean / number / string）？
  5. エバリュエーターはシンプルなロジックで十分か、LLM を活用した評価が必要か？
  6. @outputai/evals を用いたデータセット駆動の検証によるオフライン eval テストは適切か？ </thought_process>

<step_output> 更新された計画を出力: .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md へ </step_output>

</step>

<step number="5" name="plan_review" subagent="workflow-quality">

ステップ 5: 計画のレビュー

ドラフト計画をレビューし、必要な修正を行います。

<thought_process>

  1. 計画は理にかなっているか？
  2. すべてのステップは明確かつ簡潔か？
  3. すべての依存関係が特定されているか？
  4. ワークフローは Output SDK の規約に従っているか？
  5. エラーハンドリングのパターンは適切か？
  6. 入出力スキーマの設計は正しいか？ </thought_process>

<decision_tree> IF changes_needed: ドラフト計画を更新する ELSE: ステップ 6 へ進む </decision_tree>

<step_output> レビュー済み計画を出力: .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md へ </step_output>

</step>

<step number="6" name="prompt_engineering" subagent="workflow-prompt-writer">

ステップ 6: プロンプトエンジニアリング

いずれかのステップで LLM を使用する場合、各ステップのプロンプトを設計します。

<decision_tree> IF step_uses_llm: prompt_step_template を使用する ELSE: ステップ 7 へスキップ </decision_tree>

<step_output> 更新された計画を出力: .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md へ </step_output>

</step>

<step number="7" name="testing_strategy" subagent="workflow-debugger">

ステップ 7: テスト戦略

ワークフローのテスト戦略を設計します。

<thought_process>

  1. 作成が必要なユニットテストは何か？
  2. ワークフローはどのように実行できるか？
  3. 検証が必要なケースは何か？
  4. どのシナリオファイルを作成すべきか？
  5. output workflow test によるオフラインテスト用の eval データセットを作成すべきか？
  6. eval データセットに必要なグランドトゥルース値は何か？ </thought_process>

<step_output> 更新された計画を出力: .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md へ </step_output>

</step>

<step number="8" name="generate_plan" subagent="workflow-planner">

ステップ 8: 計画の生成

完全な計画を Markdown 形式で生成します。

なお、すべての実装はまず CLI コマンド npx output workflow generate --skeleton を実行してワークフローのディレクトリ構造を作成することから始めます。

<file_template> <header> # ワークフロー要件定義書

> ワークフロー: [WORKFLOW_NAME]
> 作成日: [CURRENT_DATE]

</header> <required_sections> - 概要 - 仕様スコープ - スコープ外 - ワークフロー設計 - ステップ設計 - エバリュエーター設計（該当する場合） - プロンプト設計 - テスト戦略 - 実装フェーズ </required_sections> </file_template>

<step_output> 最終計画を出力: .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md へ </step_output>

</step>

<step number="9" name="post_flight_check">

ステップ 9: ポストフライトチェック

計画が完成し、実装の準備が整っていることを確認します。

<substep number="0" name="post_flight_check"> 実行: Claude Skill: output-meta-post-flight </substep>

その後、ユーザーに以下を案内してください:

  1. 計画をレビューする
  2. 必要な修正を行う
  3. 適切なビルドコマンドでワークフローを実装する。例: /output-build-workflow <plan_file_path> <workflow_name> <workflow_directory>

</step>

</process_flow>

---- 開始 ----

ワークフローの説明と追加指示:

$ARGUMENTS

原文（English）を表示

Your task is to generate a comprehensive Output.ai workflow implementation plan in markdown format.

The plan will be displayed to the user who can then decide what to do with it.

Please respond with only the final version of the plan.

Use the todo tool to track your progress through the plan creation process.

Plan Creation Rules

Overview

Generate detailed specifications for implementation of a new workflow.

Output Path

All plan outputs go to: .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md

<process_flow>

<step number="0" name="arguments_analysis">

Step 0: Arguments Analysis

Analyze the arguments provided to the command:

{ $ARGUMENTS }

<substep number="0" name="arguments_analysis">

Ensure they have provided:

  • workflow_description: The description of the workflow to be created
  • additional_instructions: Additional instructions for the workflow

If not, ask the user for the missing information. </substep>

<substep number="1" name="pre_flight_check"> EXECUTE: Claude Skill: output-meta-pre-flight </substep>

</step>

<step number="1" name="context_gathering" subagent="workflow-context-fetcher">

Step 1: Context Gathering

Take the time to gather all the context you need to create a comprehensive plan.

  1. Read any given files or links
  2. Find any related workflows in the project
  3. Read the projects documentation files

</step>

<step number="2" name="requirements_clarification">

Step 2: Requirements Clarification

Clarify scope boundaries and technical considerations by asking numbered questions as needed to ensure clear requirements before proceeding.

<clarification_areas> <scope> - in_scope: what is included - out_of_scope: what is excluded (optional) </scope> <technical> - functionality specifics - UI/UX requirements - integration points </technical> <llm_provider> - Ask which LLM provider the user wants to use (anthropic, openai, or vertex) - Default to anthropic if the user has no preference - All prompt files in the workflow must use the same provider unless the user explicitly requests otherwise - Record the chosen provider so it flows through to prompt engineering (step 6) and implementation </llm_provider> </clarification_areas>

<decision_tree> IF clarification_needed: ASK numbered_questions WAIT for_user_response ELSE: PROCEED schema_definition </decision_tree>

</step>

<step number="3" name="workflow_design" subagent="workflow-planner">

Step 3: Workflow Design

Design the workflow with clear single purpose steps and sound orchestration logic.

<thought_process>

  1. Define the workflow name and description
  2. What is a valid output schema for the workflow?
  3. What is a valid input schema for the workflow?
  4. What needs to happen to transform the input into the output?
  5. What are the atomic steps that need to happen to transform the input into the output?
  6. How do these steps relate to each other?
  7. Are any of these steps conditional?
  8. Are any of these steps already defined in the project?
  9. How could these steps fail, and how should we handle them? (retry, backoff, etc.)

</thought_process>

<step_output> Output Draft Plan: to .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md </step_output>

</step>

<step number="4" name="step_design" subagent="workflow-planner">

Step 4: Step Design

Design the individual steps called by the workflow with clear boundaries.

<thought_process>

  1. What is the name and description of each step?
  2. What is the input schema for each step?
  3. What is the output schema for each step?
  4. What external services or APIs does each step use?
  5. What error handling is needed for each step?
  6. What retry policies should each step have? </thought_process>

<step_output> Output Updated Plan: to .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md </step_output>

</step>

<step number="4.5" name="evaluator_design" subagent="workflow-planner">

Step 4.5: Evaluator Design

Determine if the workflow requires quality assessment, validation, or content evaluation.

<decision_tree> IF workflow_outputs_need_quality_scoring: DESIGN evaluator functions IF workflow_has_llm_generated_content: CONSIDER content evaluation (factual accuracy, relevance, tone) IF workflow_requires_validation_with_confidence: DESIGN validation evaluators ELSE: SKIP evaluator design (note in plan: "No evaluators needed") </decision_tree>

<thought_process>

  1. Does the workflow produce content that needs quality assessment?
  2. Are there LLM-generated outputs that need evaluation?
  3. Would the workflow benefit from confidence-scored validation?
  4. What evaluation result types are appropriate (boolean/number/string)?
  5. Should evaluators use simple logic or LLM-powered assessment?
  6. Would offline eval testing with @outputai/evals be appropriate for dataset-driven verification? </thought_process>

<step_output> Output Updated Plan: to .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md </step_output>

</step>

<step number="5" name="plan_review" subagent="workflow-quality">

Step 5: Plan Review

Review the draft plan and make any necessary changes.

<thought_process>

  1. Does the plan make sense?
  2. Are all the steps clear and concise?
  3. Are all the dependencies identified?
  4. Does the workflow follow Output SDK conventions?
  5. Are error handling patterns appropriate?
  6. Is the input/output schema design correct? </thought_process>

<decision_tree> IF changes_needed: UPDATE draft_plan ELSE: PROCEED to step 6 </decision_tree>

<step_output> Output Reviewed Plan: to .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md </step_output>

</step>

<step number="6" name="prompt_engineering" subagent="workflow-prompt-writer">

Step 6: Prompt Engineering

If any of the steps use an LLM, design the prompts for the steps.

<decision_tree> IF step_uses_llm: USE prompt_step_template ELSE: SKIP to step 7 </decision_tree>

<step_output> Output Updated Plan: to .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md </step_output>

</step>

<step number="7" name="testing_strategy" subagent="workflow-debugger">

Step 7: Testing Strategy

Design the testing strategy for the workflow.

<thought_process>

  1. What unit tests do we need to write?
  2. How can I run the workflow?
  3. What cases do we need to validate?
  4. What scenario files should be created?
  5. Should we create eval datasets for offline testing with output workflow test?
  6. What ground truth values are needed for eval datasets? </thought_process>

<step_output> Output Updated Plan: to .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md </step_output>

</step>

<step number="8" name="generate_plan" subagent="workflow-planner">

Step 8: Generate Plan

Generate the complete plan in markdown format.

Note that every implementation should start with running the cli command npx output workflow generate --skeleton to create the workflow directory structure.

<file_template> <header> # Workflow Requirements Document

> Workflow: [WORKFLOW_NAME]
> Created: [CURRENT_DATE]

</header> <required_sections> - Overview - Spec Scope - Out of Scope - Workflow Design - Step Design - Evaluator Design (if applicable) - Prompt Design - Testing Strategy - Implementation Phases </required_sections> </file_template>

<step_output> Output Final Plan: to .outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md </step_output>

</step>

<step number="9" name="post_flight_check">

Step 9: Post-Flight Check

Verify the plan is complete and ready for implementation.

<substep number="0" name="post_flight_check"> EXECUTE: Claude Skill: output-meta-post-flight </substep>

Then instruct the user to:

  1. Review the plan
  2. Make any necessary changes
  3. Implement the workflow with the appropriate build command. e.g. /output-build-workflow <plan_file_path> <workflow_name> <workflow_directory>

</step>

</process_flow>

---- START ----

Workflow Description and Additional Instructions:

$ARGUMENTS

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。