mcpField
C
create-workflow-command

create-workflow-command

github.com/neolabhqエージェントワークフロー1.8k1.2k 回インストール9 週間前に更新
リポジトリ

create-workflow-command について

サブエージェントと個別のタスクファイルを使い、複数ステップのワークフローを調整するコマンドを作成するスキルです。Claude プラグインを構築するユーザー向けに、逐次・並列・再開可能な実行方法を説明します。

主な機能

  1. 01詳細な手順をタスクファイルに分離
  2. 02簡潔なコマンドでサブエージェントを調整
  3. 03逐次実行と並列実行に対応
  4. 04複数ステップでエージェントを再開
  5. 05ワークフローファイルと実行手順を検証

活用シーン

  1. 01機能実装ワークフローの構築
  2. 02独立した分析タスクのエージェントへの分配
  3. 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:要件を収集する

指定されていない場合は、ユーザーに次の内容を尋ねます。

  1. ワークフロー名:kebab-case の識別子(例:feature-implementation)
  2. 説明:ワークフローで達成する内容
  3. ステップ:以下を含む個別のステップの一覧
    • ステップ名
    • ステップの目標
    • 必要なツール
    • 想定される出力
  4. 実行モード:逐次または並列のステップ
  5. エージェントの種類: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 トークン未満)
  • ステップが失敗した場合のエラー処理が定義されている
  • 各ステップの成功基準が測定可能である

ワークフローの作成

ユーザーの入力に基づいて、以下を作成します。

  1. ディレクトリ:

    • ${CLAUDE_PLUGIN_ROOT}/tasks/ - すべてのタスクファイルをこのディレクトリ直下に配置
    • ${CLAUDE_PLUGIN_ROOT}/agents/ - (任意)カスタムエージェントの定義
  2. タスクファイル:命名パターン step-N-<workflow>-<name>.md に従って tasks/ ディレクトリに作成

    • 例:step-1-feature-impl-research.md
    • 例:step-2-feature-impl-architecture.md
    • 共有コンテキスト:tasks/ 直下の common-context.md
  3. オーケストレーターコマンド:commands/<workflow-name>.md に簡潔なディスパッチロジックを記述

  4. カスタムエージェント(任意):ワークフローで特化したエージェントの動作が必要な場合は agents/ に作成

  5. plugin.json の更新:必要に応じて、プラグインマニフェストにコマンドを追加

作成後、/customaize-agent:test-prompt コマンドでテストすることを提案してください。

コメント