• Projects
  • Service
  • About
  • branding.bz
  • Podcast
  • Tips
  • FAQ
  • Recruit
  • Download
  • Contact
  • branding.bz(ブランド構築SaaS)
  • DESIGN NOW(デザインメディア)
  • X
  • LinkedIn
  • Spotify
  • Facebook

213-0011 神奈川県川崎市高津区久本3-6-7-303

© 2026 ID INC. All rights reserved

claude-skills/スキル
SKILLOfficialdevelopment

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 ワークフロー実装計画生成スキル

あなたの任務は、Output.ai ワークフロー実装計画をマークダウン形式で生成することです。

計画はユーザーに表示され、ユーザーはそれに基づいて次のアクションを決定できます。

最終版の計画のみを提供してください。

todoツールを使用して、計画作成プロセスの進捗を追跡してください。

計画作成ルール

概要

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

出力パス

すべての計画出力は、.outputai/plans/YYYY_MM_DD_<workflow_name>_<task_name>/PLAN.md に保存されます。

<process_flow>

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

ステップ 0: 引数の分析

ユーザーが提供した引数を分析します:

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

以下の項目が提供されていることを確認してください:

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

提供されていない場合は、ユーザーに不足している情報を尋ねてください。 </substep>

<substep number="1" name="pre_flight_check"> 実行: Claude スキル 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、google-vertex、amazon-bedrock) - ユーザーの好みがない場合は、anthropic をデフォルトとします - ワークフロー内のすべてのプロンプトファイルは、ユーザーが明示的に別の指示をしない限り、同じプロバイダーを使用する必要があります - 選択されたプロバイダーを記録して、プロンプトエンジニアリング(ステップ 6)と実装に反映させます </llm_provider> </clarification_areas>

<decision_tree> IF 明確化が必要: 番号付き質問を提示 ユーザーの回答を待つ 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 ワークフロー出力が品質スコアリングを必要とする: 評価機能を設計 IF ワークフローが LLM 生成コンテンツを含む: コンテンツ評価を検討(事実正確性、関連性、トーン) IF ワークフロー信頼度スコア付き検証が必要: 検証評価機能を設計 ELSE: 評価機能設計をスキップ(計画に「評価機能不要」と記載) </decision_tree>

<thought_process>

  1. ワークフロー出力は品質評価が必要か
  2. LLM 生成出力で評価が必要なものがあるか
  3. 信頼度スコア付き検証によってワークフロー改善できるか
  4. どのような評価結果タイプが適切か(真偽値/数値/文字列)
  5. 評価機能は単純なロジックか LLM 駆動型の評価を使用するべきか
  6. @outputai/evals を用いたオフライン評価テストはデータセット検証に適切か </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 変更が必要: ドラフト計画を更新 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: プロンプトエンジニアリング(AI への指示文設計)

ステップで LLM を使用する場合は、ステップ用のプロンプトを設計します。

<decision_tree> IF ステップが LLM を使用: プロンプトステップテンプレートを使用 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 でオフライン評価テスト用に評価データセットを作成すべきか
  6. 評価データセット用に必要な正解値は何か </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: 計画生成

マークダウン形式で完全な計画を生成します。

実装はすべて、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 スキル output-meta-post-flight </substep>

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

  1. 計画をレビューする
  2. 必要な変更を加える
  3. output-build-workflow スキルを呼び出してワークフロー を実装します。計画ファイルパス、ワークフロー名、ワークフロー ディレクトリを提供してください

</step>

</process_flow>

---- 開始 ----

ユーザーが提供したワークフロー説明と追加指示を使用してください。

原文(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 the user provided:

<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, google-vertex, or amazon-bedrock) - 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 by invoking the output-build-workflow skill, providing the plan file path, workflow name, and workflow directory

</step>

</process_flow>

---- START ----

Use the workflow description and any additional instructions the user provided.

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