create-workflow-command について
サブエージェントと個別のタスクファイルを使い、複数ステップのワークフローを調整するコマンドを作成するスキルです。Claude プラグインを構築するユーザー向けに、逐次・並列・再開可能な実行方法を説明します。
主な機能
- 01詳細な手順をタスクファイルに分離
- 02簡潔なコマンドでサブエージェントを調整
- 03逐次実行と並列実行に対応
- 04複数ステップでエージェントを再開
- 05ワークフローファイルと実行手順を検証
活用シーン
- 01機能実装ワークフローの構築
- 02独立した分析タスクのエージェントへの分配
- 03ワークフロー段階間でのコンテキスト共有
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ neolabhq/ context-engineering-kit --skill create-workflow-commandインストール後、Claude Code で/create-workflow-commandを入力して読み込まれたか確認します。
詳細
ワークフローコマンドの作成
別々のファイルに保存したタスク固有の指示を使ってサブエージェントをディスパッチし、複数ステップのワークフローを調整するコマンドを作成します。
ユーザー入力
Workflow Name: $1
Description: $2
アーキテクチャの概要
ワークフローコマンドは、コンテキスト肥大化の問題を解決します。詳細なステップの指示をメインコマンドに埋め込んでオーケストレーターのコンテキストを圧迫するのではなく、サブエージェントが必要に応じて読み込むタスクファイルに保存します。
plugins/<plugin-name>/
├── commands/
│ └── <workflow>.md # Lean orchestrator (~50-100 tokens per step)
├── agents/ # Optional: reusable executor agents
│ └── step-executor.md # Custom agent with specific tools/behavior
└── tasks/ # All task instructions directly here
├── step-1-<name>.md # Full instructions (~500+ tokens each)
├── step-2-<name>.md
├── step-3-<name>.md
└── common-context.md # Shared context across workflows
主な原則
1. コンテキストの分離
各サブエージェントには、独立したコンテキストウィンドウが割り当てられます。メインのオーケストレーターは簡潔な状態を保ちながら、サブエージェントはファイルから詳細な指示を読み込みます。
| コンポーネント | コンテキストコスト | 目的 |
|---|---|---|
| オーケストレーターコマンド | 約50~100トークン/ステップ | ディスパッチと調整 |
| タスクファイル | 約500トークン以上 | 詳細なステップの指示 |
| サブエージェントのベース | 約294トークン | システムプロンプトのオーバーヘッド |
2. サブエージェントの機能
Task ツール経由で起動したサブエージェント:
| 機能 | 利用可能 | 備考 |
|---|---|---|
| Read ツール | ✅ はい | 任意のファイルを読み取れます |
| Write ツール | ✅ はい | 制限されていない場合 |
| Grep/Glob | ✅ はい | コード検索に使用します |
| スキルの読み込み | ❌ いいえ | サブエージェントではスキルは自動的に読み込まれません |
| サブエージェントの起動 | ❌ いいえ | Task ツールを入れ子にして実行することはできません |
| コンテキストの再開 | ✅ はい | resume パラメーター経由 |
3. ファイル参照パターン
プラグイン内で移植可能なパスを使うには、${CLAUDE_PLUGIN_ROOT} を使用します。
Read ${CLAUDE_PLUGIN_ROOT}/tasks/step-1-workflow-name.md and execute.
サブエージェントは Read ツールを使ってファイルの内容を取得します。
実装手順
ステップ 1:要件を収集する
指定されていない場合は、ユーザーに次の内容を尋ねます。
- ワークフロー名:kebab-case の識別子(例:
feature-implementation) - 説明:ワークフローで達成する内容
- ステップ:以下を含む個別のステップの一覧
- ステップ名
- ステップの目標
- 必要なツール
- 想定される出力
- 実行モード:逐次または並列のステップ
- エージェントの種類:
general-purposeまたはカスタムエージェント
ステップ 2:ディレクトリ構造を作成する
# Create tasks directory (if it doesn't exist)
mkdir -p ${CLAUDE_PLUGIN_ROOT}/tasks
# Optional: Create agents directory (if using custom agents)
mkdir -p ${CLAUDE_PLUGIN_ROOT}/agents
注:すべてのタスクファイル(ワークフロー固有のステップと共有コンテキストの両方)は、サブディレクトリを作成せずに tasks/ に直接配置します。
ステップ 3:タスクファイルを作成する
各ステップについて、次の構成でタスクファイルを作成します。
# Step N: <Step Name>
## Context
You are executing step N of the <workflow-name> workflow.
## Goal
<Clear, specific goal for this step>
## Input
<What this step receives from previous steps or user>
## Instructions
1. <Specific action>
2. <Specific action>
3. <Specific action>
## Constraints
- <Limitation or boundary>
- <What NOT to do>
## Expected Output
<What to return to orchestrator>
## Success Criteria
- [ ] <Measurable outcome>
- [ ] <Measurable outcome>
ステップ 4:オーケストレーターコマンドを作成する
次のパターンでメインコマンドファイルを作成します。
---
description: <Workflow description>
argument-hint: <Required arguments>
allowed-tools: Task, Read
model: sonnet
---
# <Workflow Name>
## User Input
\`\`\`text
$ARGUMENTS
\`\`\`
## Workflow Execution
### Step 1: <Step Name>
Launch general-purpose agent:
- **Description**: "<3-5 word summary>"
- **Prompt**:
\`\`\`
Read ${CLAUDE_PLUGIN_ROOT}/tasks/step-1-<workflow>-<name>.md and execute.
Context:
- TARGET: $1
- MODE: $2
\`\`\`
**Capture**: <What to extract from result>
### Step 2: <Step Name>
Launch general-purpose agent:
- **Description**: "<3-5 word summary>"
- **Prompt**:
\`\`\`
Read ${CLAUDE_PLUGIN_ROOT}/tasks/step-2-<workflow>-<name>.md and execute.
Context from Step 1:
- <Key data from previous step>
\`\`\`
### Step 3: <Step Name>
[Continue pattern...]
## Completion
Summarize workflow results:
1. <What was accomplished>
2. <Key outputs>
3. <Next steps if any>
フロントマターのオプション
| フィールド | 目的 | デフォルト |
|---|---|---|
description | ワークフローの目的の簡単な説明 | 必須 |
argument-hint | 想定される引数の説明 | なし |
allowed-tools | コマンドで使用できるツール | 会話から継承 |
model | 特定の Claude モデル(sonnet、opus、haiku) | 会話から継承 |
モデルの選択:
haiku- シンプルなワークフローに適した高速で効率的なモデルsonnet- バランスの取れた性能(推奨されるデフォルト)opus- 複雑なオーケストレーションに対応する最大限の能力
実行パターン
パターン A:逐次ステップ(デフォルト)
各ステップは前のステップの出力に依存します。
### Step 1: Analyze
Launch agent → Get analysis result
### Step 2: Plan (uses Step 1 result)
Launch agent with Step 1 context → Get plan
### Step 3: Execute (uses Step 2 result)
Launch agent with Step 2 context → Complete
パターン B:並列の独立したステップ
ステップを並行して実行できます。
### Analysis Phase (Parallel)
Launch 3 agents simultaneously:
1. Agent 1: Security analysis → Read ${CLAUDE_PLUGIN_ROOT}/tasks/step-1a-security.md
2. Agent 2: Performance analysis → Read ${CLAUDE_PLUGIN_ROOT}/tasks/step-1b-performance.md
3. Agent 3: Code quality analysis → Read ${CLAUDE_PLUGIN_ROOT}/tasks/step-1c-quality.md
**Wait for all**, then consolidate results.
### Synthesis Phase
Launch agent with all analysis results...
パターン C:状態を保持する複数ステップ(再開)
ステップ間でコンテキストを共有する必要がある場合:
### Step 1: Initialize
Launch agent, **capture agent_id**
### Step 2: Continue (same context)
Resume agent using agent_id:
- **resume**: <agent_id from Step 1>
- **prompt**: "Proceed to phase 2: <additional instructions>"
例:機能実装ワークフロー
オーケストレーターコマンド
---
description: Execute feature implementation through research, planning, and coding phases
argument-hint: [feature-description]
allowed-tools: Task, Read, TodoWrite
model: sonnet
---
# Implement Feature
## User Input
\`\`\`text
$ARGUMENTS
\`\`\`
Create TodoWrite with workflow steps.
## Phase 1: Research
Launch general-purpose agent:
- **Description**: "Research feature requirements"
- **Prompt**:
\`\`\`
Read ${CLAUDE_PLUGIN_ROOT}/tasks/step-1-feature-impl-research.md
Feature: $ARGUMENTS
\`\`\`
**Extract**: Key findings, constraints, existing patterns
## Phase 2: Architecture
Launch general-purpose agent:
- **Description**: "Design feature architecture"
- **Prompt**:
\`\`\`
Read ${CLAUDE_PLUGIN_ROOT}/tasks/step-2-feature-impl-architecture.md
Feature: $ARGUMENTS
Research findings: <summary from Phase 1>
\`\`\`
**Extract**: File structure, components, interfaces
## Phase 3: Implementation
Launch developer agent:
- **Description**: "Implement feature code"
- **Prompt**:
\`\`\`
Read ${CLAUDE_PLUGIN_ROOT}/tasks/step-3-feature-impl-implement.md
Architecture: <summary from Phase 2>
\`\`\`
## Completion
Mark todos complete. Report:
1. Files created/modified
2. Tests added
3. Remaining work
タスクファイルの例(step-1-feature-impl-research.md)
# Step 1: Feature Research
## Context
You are the research phase of a feature implementation workflow.
## Goal
Thoroughly understand the feature requirements and existing codebase context before any implementation begins.
## Instructions
1. **Parse Feature Request**
- Extract core requirements
- Identify acceptance criteria
- Note any constraints mentioned
2. **Codebase Analysis**
- Search for similar existing features
- Identify relevant patterns and conventions
- Find reusable components/utilities
3. **Dependency Check**
- What existing code will this feature interact with?
- Are there breaking change risks?
- What tests exist for related functionality?
4. **Gap Analysis**
- What's missing from the request?
- What clarifications might be needed?
- What edge cases should be considered?
## Constraints
- Do NOT write any implementation code
- Do NOT modify any files
- Focus purely on research and analysis
## Expected Output
Return a structured research summary:
\`\`\`markdown
## Feature Understanding
- Core requirement: <summary>
- Acceptance criteria: <list>
## Codebase Context
- Similar features: <list with file paths>
- Patterns to follow: <list>
- Reusable code: <list with file paths>
## Dependencies
- Files affected: <list>
- Tests to consider: <list>
## Open Questions
- <Question 1>
- <Question 2>
## Recommendation
<Brief recommendation for architecture phase>
\`\`\`
## Success Criteria
- [ ] Feature requirements clearly articulated
- [ ] Relevant existing code identified
- [ ] No implementation attempted
- [ ] Clear handoff to architecture phase
既知の制限事項
| 制限事項 | 影響 | 回避策 |
|---|---|---|
| サブエージェントの入れ子に非対応 | サブエージェントは Task ツールを起動できません | すべてのオーケストレーションをメインコマンドで行います |
| スキルの自動読み込みに非対応 | サブエージェントではスキルが起動されません | 明示的なファイルパスまたはインラインコンテキストを渡します |
| エージェントごとに新しいコンテキスト | ディスパッチのたびにコンテキストが空の状態で開始します | 再開パターンを使うか、要約を渡します |
| ファイル読み込みの遅延 | ステップごとにツール呼び出しが追加されます | コンテキスト節約とのトレードオフとして許容します |
検証チェックリスト
ワークフローコマンドを確定する前に、以下を確認してください。
- 各ステップに明確で具体的な目標がある
- タスクファイルが自己完結している(サブエージェントが外部のコンテキストを必要としない)
- 移植性を確保するため、ファイルパスに
${CLAUDE_PLUGIN_ROOT}を使用している - ステップ間で渡すコンテキストが最小限である(全データではなく要約)
- オーケストレーターコマンドが簡潔である(各ステップのディスパッチにつき 100 トークン未満)
- ステップが失敗した場合のエラー処理が定義されている
- 各ステップの成功基準が測定可能である
ワークフローの作成
ユーザーの入力に基づいて、以下を作成します。
-
ディレクトリ:
${CLAUDE_PLUGIN_ROOT}/tasks/- すべてのタスクファイルをこのディレクトリ直下に配置${CLAUDE_PLUGIN_ROOT}/agents/- (任意)カスタムエージェントの定義
-
タスクファイル:命名パターン
step-N-<workflow>-<name>.mdに従ってtasks/ディレクトリに作成- 例:
step-1-feature-impl-research.md - 例:
step-2-feature-impl-architecture.md - 共有コンテキスト:
tasks/直下のcommon-context.md
- 例:
-
オーケストレーターコマンド:
commands/<workflow-name>.mdに簡潔なディスパッチロジックを記述 -
カスタムエージェント(任意):ワークフローで特化したエージェントの動作が必要な場合は
agents/に作成 -
plugin.json の更新:必要に応じて、プラグインマニフェストにコマンドを追加
作成後、/customaize-agent:test-prompt コマンドでテストすることを提案してください。