task-orchestration

仓库: nickcrew/claude-ctx-plugin
安装量: 39
排名: #18401

安装

npx skills add https://github.com/mgd34msu/goodvibes-plugin --skill task-orchestration
Resources
scripts/
validate-orchestration.sh
references/
agent-assignment-guide.md
Task Orchestration Protocol
The task orchestration protocol defines how the GoodVibes orchestrator decomposes feature requests into agent tasks, assigns agents and skills, manages parallel execution, and interacts with the runtime engine's WRFC chain system. This is the orchestrator's primary workflow for multi-agent feature delivery.
When to Use This Skill
Use this skill when:
User provides a feature request requiring multiple work streams
Request involves multiple domains (backend, frontend, database, etc.)
Request can be parallelized into independent subtasks
Request requires coordination across multiple agents
Do NOT use this skill for:
Simple single-file edits (handle directly)
Pure analysis tasks without code changes
Tasks already decomposed by the user
Runtime Engine and WRFC Chains
The runtime engine manages Work-Review-Fix-Complete (WRFC) chains automatically. The orchestrator's role is:
Decompose
the task into work agents
Spawn
the initial work agents
Execute
directives
issued by the runtime engine — mechanically, immediately, without judgment
The runtime engine handles all review, fix, and completion decisions. The orchestrator does NOT manually spawn reviewers or fix agents. These come exclusively from runtime directives after each work agent completes.
Directive Types
The runtime engine issues directives to the orchestrator via system messages containing
tags:
{
"action"
:
"spawn"
,
"wid"
:
"wrfc_xxx"
,
"type"
:
"reviewer"
,
"task"
:
"Review the code..."
}
{
"action"
:
"spawn"
,
"wid"
:
"wrfc_xxx"
,
"type"
:
"engineer"
,
"task"
:
"Fix the issues..."
}
{
"action"
:
"complete"
,
"wid"
:
"wrfc_xxx"
}
{
"action"
:
"escalate"
,
"wid"
:
"wrfc_xxx"
,
"reason"
:
"Max fix attempts reached"
}
Directive Compliance Rules
These 4 rules are absolute and non-negotiable:
Immediate
Execute directives the moment they arrive. NEVER defer, queue, or delay.
First
Execute directives BEFORE any other action. No intervening tool calls, no additional agent spawns, no user messages first.
Autonomy ends
Once the first directive arrives for a WRFC chain, the orchestrator has no further judgment over that chain. Only directives drive it.
Runtime supersedes
Runtime workflow logic ALWAYS supersedes orchestrator judgment. If a directive says review, review. If it says complete, complete. Configurable Thresholds The runtime reads goodvibes.json for: min_review_score (default: 9.5) — score threshold for PASS max_fix_attempts (default: 3) — max fix cycles before escalation The orchestrator never hardcodes these values. The runtime engine enforces them. Decomposition Process Step 1: Classify the Request Before decomposing, classify the request into one of these categories: Feature Implementation - Add new functionality Identify: "Add X feature", "Implement Y", "Create Z capability" Decomposition strategy: Split by domain (API, UI, DB, types) Parallelism: High (most work streams independent) Bug Fix - Resolve existing issue Identify: "Fix X not working", "Resolve Y error", "Correct Z behavior" Decomposition strategy: Root cause first, then fix propagation Parallelism: Low (diagnosis must precede fixes) Refactoring - Improve code structure without changing behavior Identify: "Refactor X", "Restructure Y", "Extract Z" Decomposition strategy: Analysis first, then file-by-file changes Parallelism: Medium (analysis sequential, changes parallel) Integration - Connect existing systems Identify: "Integrate X with Y", "Connect A to B" Decomposition strategy: Understand both sides, then adapter layer Parallelism: Medium (research parallel, integration sequential) Enhancement - Improve existing feature Identify: "Improve X", "Add Y to existing Z" Decomposition strategy: Understand current state, plan incremental additions Parallelism: Medium (discovery sequential, additions parallel) Step 2: Identify Parallel Opportunities After classifying, identify work that can run in parallel: Independent domains: API route + React component (if contract is defined upfront) Type definitions + database schema Multiple UI components with shared types Multiple API endpoints with shared middleware Independent files: Creating new files in different directories Editing files with no import relationships Writing tests for different modules Independent research: Checking multiple documentation sources Analyzing multiple files for patterns Discovering patterns in different directories When NOT to parallelize: Type definitions must exist before implementation uses them Database schema must exist before API queries it Parent component must exist before child imports it Discovery must complete before planning Step 3: Define Agent Tasks For each parallelizable work stream, define a task with: Task structure: task_id : unique - task - identifier agent : engineer | reviewer | tester | architect | deployer | integrator - ai | integrator - services | integrator - state | planner skills : [ skill - 1 , skill - 2 ] description : Brief description of what this task accomplishes scope : files : [ list of files to create/modify ] directories : [ directories to work within ] constraints : - Must use TypeScript - Follow existing patterns in src/features/ blocking : [ list of task_ids this task blocks ] blocked_by : [ list of task_ids blocking this task ] expected_outcome : What success looks like Example: task_id : create - user - types agent : engineer skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory ] description : Create TypeScript type definitions for User domain scope : files : [ src/types/user.ts , src/types/auth.ts ] directories : [ src/types ] constraints : - Use Zod for runtime validation - Export all types from src/types/index.ts blocking : [ create - user - api , create - user - components ] blocked_by : [ ] expected_outcome : Type files exist , export User , AuthContext , and validation schemas Step 4: Assign Agent and Skills For each task, assign the appropriate agent type and skills using this decision table: Agent Type Selection: Work Type Agent Type Rationale Implement API, components, features engineer Code creation and implementation Review code quality, standards reviewer Code quality and standards enforcement Write tests, test coverage tester Testing and validation Plan architecture, design decisions architect High-level design and planning Deploy applications, infrastructure deployer Deployment and infrastructure Integrate AI/ML services integrator-ai AI/ML integration Integrate external services integrator-services External service integration Manage state and data flow integrator-state State management Coordinate complex workflows planner High-level orchestration Skills Assignment: All agents receive protocol skills by default: gather-plan-apply (GPA loop) precision-mastery (tool usage) error-recovery (error handling) goodvibes-memory (memory integration) Additional skills by work type: Work Type Additional Skills API implementation trpc, prisma, nextauth, rest-api-design Frontend components react, nextjs, tailwindcss, shadcn-ui Database schema prisma, postgresql, drizzle Authentication clerk, nextauth, lucia Type definitions (none - protocol skills sufficient) Code review review-scoring + domain-specific review skills See references/agent-assignment-guide.md for complete assignment table. Agent Prompt Template When spawning agents, ALWAYS include these elements in the agent prompt:

Task [Specific, actionable description of what to accomplish]

Scope ** Files to create: ** - path/to/file.ts - Brief description ** Files to modify: ** - path/to/existing.ts - What changes to make ** Directories in scope: ** - src/features/auth/ - Work within this directory

Constraints

[Technical constraint 1]

[Pattern to follow]

[Dependency requirement]

Skills Available

skill-name - When to use it

skill-name - When to use it

Expected Outcome [Concrete definition of success]

Blocking/Blocked By
**
This task blocks:
**
[list of downstream tasks waiting for this]
**
This task is blocked by:
**
[list of upstream tasks this waits for]
Critical elements:
Scope is explicit (file paths, not vague descriptions)
Skills are listed with usage guidance
Expected outcome is concrete and verifiable
Output format includes the
tag (emitted automatically by the runtime hook; the orchestrator does not need to instruct agents about this)
Note:
Do NOT add WRFC participation instructions to agent prompts. Agents only need to complete their work and emit a
tag. The runtime engine handles the WRFC chain automatically.
Monitoring and Coordination
Track Active Agents
Maintain a task tracking structure:
active_tasks
:
task-1
:
agent_id
:
agent_abc123
status
:
running
|
completed
|
blocked
|
failed
started_at
:
ISO
-
8601 timestamp
last_update
:
ISO
-
8601 timestamp
blocking
:
[
task
-
2
,
task
-
3
]
blocked_by
:
[
]
task-2
:
agent_id
:
agent_def456
status
:
waiting
blocked_by
:
[
task
-
1
]
Agent Concurrency Limits
Hard limit: 6 concurrent agent chains (from
max_parallel_agent_chains
in output style config)
A "chain" includes the work agent plus its entire WRFC chain (review, fix, re-review). Each initial work agent spawn creates one chain. Count chains, not individual agents.
When you have more than 6 tasks:
Prioritize by dependency order (unblock downstream tasks first)
Queue remaining tasks
Spawn new agents as chains complete (when runtime issues
complete
directive)
Task priority formula:
priority = (number of tasks it blocks) - (number of tasks blocking it)
Higher priority = spawn first
Executing
Directives
When the runtime engine issues a directive:
Stop everything
— do not complete any in-progress reasoning about other tasks
Read the directive
— identify the
action
,
wid
,
type
, and
task
fields
Execute immediately
:
spawn
Spawn the specified agent type with the provided task prompt
complete
Mark the WRFC chain as done, unblock any dependent tasks, spawn next queued task if slot available
escalate
Report to user with the escalation reason, do not spawn further agents for this chain
Then resume
other orchestration work
No exceptions.
A directive is never skipped, reordered, or conditioned on another event.
WRFC Spawn Rules
Initial spawns only
Orchestrator spawns ONLY the initial work agents from task decomposition. All reviewer and fix agent spawns come from runtime directives.
Parallel when possible
Spawn all tasks in the same dependency wave together
Wait for blockers
Do NOT spawn dependent tasks until blocking tasks have received
complete
directives
Respect the limit
Do NOT exceed 6 concurrent chains
Escalation handling
If runtime issues escalate , report to user — do not attempt to fix the chain yourself Agent Communication Agents do NOT communicate directly. All coordination flows through the orchestrator: Inter-agent dependencies: Task A produces types.ts Task B needs types.ts Orchestrator: waits for A to receive complete directive, then spawns B with reference to types.ts location Shared state: All agents read/write .goodvibes/memory/ Orchestrator checks memory for decisions, patterns, failures before spawning Orchestrator logs orchestration decisions to .goodvibes/memory/decisions.json Mode-Specific Behavior Vibecoding Mode (Default) Confirm before initial decomposition: Show task breakdown to user before spawning any agents Allow user to modify the decomposition Only the initial decomposition requires user confirmation; once agents are running, the runtime drives the process Auto-spawn on ambiguity: If task decomposition has multiple valid approaches, pick the most common pattern from memory If no pattern exists, make a decision and log it to decisions.json Only escalate to user for architectural decisions (auth provider, database choice, etc.) Error handling: Agent retries are managed by the runtime engine (up to max_fix_attempts ) Runtime will issue escalate directive if max attempts are reached On escalate , present to user with context from the directive's reason field Justvibes Mode (Strict) Auto-proceed: Skip the pre-decomposition confirmation Spawn agents immediately after decomposition is complete Runtime engine handles all WRFC cycles automatically Error handling: Same as vibecoding — runtime manages fix attempts and issues escalate when exhausted Present escalation to user when received Decomposition Examples Example 1: Feature Implementation User request: "Add user profile page with edit capability" Classification: Feature Implementation Decomposition: tasks : - task_id : create - profile - types agent : engineer skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory ] description : Create Profile and ProfileUpdate types scope : files : [ src/types/profile.ts ] blocking : [ create - profile - api , create - profile - ui ] blocked_by : [ ] - task_id : create - profile - api agent : engineer skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory , trpc , prisma ] description : Implement tRPC routes for profile CRUD scope : files : [ src/server/routers/profile.ts ] blocking : [ create - profile - ui ] blocked_by : [ create - profile - types ] - task_id : create - profile - ui agent : engineer skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory , nextjs , react , tailwindcss , shadcn - ui ] description : Build profile page with edit form scope : files : [ src/app/profile/page.tsx , src/components/ProfileForm.tsx ] blocking : [ ] blocked_by : [ create - profile - types ] - task_id : test - profile - feature agent : tester skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory ] description : Create tests for profile feature scope : files : [ src/server/routers/profile.test.ts , src/components/ProfileForm.test.tsx ] blocking : [ ] blocked_by : [ create - profile - api , create - profile - ui ] Execution plan: Spawn create-profile-types (no blockers) Wait for complete directive for create-profile-types Spawn create-profile-api and create-profile-ui in parallel (both unblocked) Wait for complete directives for both Spawn test-profile-feature (blocked by API + UI) Wait for complete directive for test-profile-feature Aggregate results and return to user Note: Review and fix cycles for each agent are handled automatically by the runtime engine via directives. The orchestrator does not schedule them. Parallelism: 3 waves (types solo -> API + UI parallel -> tests solo) Example 2: Bug Fix User request: "Fix login redirect loop on /dashboard" Classification: Bug Fix Decomposition: tasks : - task_id : diagnose - redirect - loop agent : engineer skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory , nextjs , nextauth ] description : Identify root cause of redirect loop scope : files : [ src/middleware.ts , src/app/dashboard/page.tsx , src/lib/auth.ts ] blocking : [ fix - redirect - loop ] blocked_by : [ ] - task_id : fix - redirect - loop agent : engineer skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory , nextjs , nextauth ] description : Apply fix based on diagnosis scope : files : [ determined by diagnosis ] blocking : [ ] blocked_by : [ diagnose - redirect - loop ] Execution plan: Spawn diagnose-redirect-loop Wait for complete directive for diagnosis Spawn fix-redirect-loop with diagnosis context Wait for complete directive for fix Return to user Parallelism: None (fully sequential: diagnose -> fix) Example 3: Refactoring User request: "Extract shared auth logic into reusable hooks" Classification: Refactoring Decomposition: tasks : - task_id : plan - refactoring - approach agent : architect skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory ] description : Design the refactoring strategy and hook API scope : directories : [ src/components , src/app ] blocking : [ analyze - auth - patterns ] blocked_by : [ ] - task_id : analyze - auth - patterns agent : engineer skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory ] description : Discover all auth usage patterns in components scope : directories : [ src/components , src/app ] blocking : [ create - auth - hooks ] blocked_by : [ plan - refactoring - approach ] - task_id : create - auth - hooks agent : engineer skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory , react ] description : Create hooks based on discovered patterns scope : files : [ src/hooks/useAuth.ts , src/hooks/useRequireAuth.ts ] blocking : [ refactor - components - 1 , refactor - components - 2 ] blocked_by : [ analyze - auth - patterns ] - task_id : refactor - components - 1 agent : engineer skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory , react ] description : Refactor components in src/app to use hooks scope : directories : [ src/app ] blocking : [ ] blocked_by : [ create - auth - hooks ] - task_id : refactor - components - 2 agent : engineer skills : [ gather - plan - apply , precision - mastery , error - recovery , goodvibes - memory , react ] description : Refactor components in src/components to use hooks scope : directories : [ src/components ] blocking : [ ] blocked_by : [ create - auth - hooks ] Execution plan: Spawn plan-refactoring-approach (architect) Wait for complete directive for planning Spawn analyze-auth-patterns Wait for complete directive for analysis Spawn create-auth-hooks Wait for complete directive for hooks Spawn refactor-components-1 and refactor-components-2 in parallel Wait for complete directives for both Return to user Parallelism: 4 waves (planning -> analysis -> hooks -> 2 refactors parallel) Escalation Criteria Escalate to user immediately when: Architectural ambiguity - Multiple valid approaches with significant tradeoffs Example: "Use REST vs GraphQL for new API" Escalation: Present options with pros/cons, request decision Missing information - Task cannot be completed without user input Example: "Which auth provider should we use?" Escalation: List options, explain what's needed Scope expansion - Task is larger than initially described Example: "Adding profile page requires new database schema and migration" Escalation: Show expanded scope, request approval Runtime escalation - Runtime engine issues escalate directive Example: Max fix attempts reached on a work agent Escalation: Present the reason from the directive, request guidance or manual intervention Conflicting requirements - Discovered constraints contradict each other Example: "User wants Prisma but codebase uses Drizzle" Escalation: Explain conflict, request resolution Summary Task orchestration workflow: Classify request (feature, bug, refactoring, etc.) Identify parallel opportunities (domains, files, research) Define agent tasks (task structure with blocking/blocked_by) Assign agents and skills (use decision table) Spawn initial work agents with structured prompts Monitor active chains (up to 6 concurrent) Execute directives from runtime immediately and mechanically Aggregate results when all chains receive complete directives Key principles: Explicit > implicit (file paths, not vague descriptions) Parallel when possible, sequential when necessary Orchestrator handles initial decomposition; runtime engine handles all WRFC cycles Execute directives before any other action — no exceptions Escalate on ambiguity in vibecoding, auto-proceed in justvibes Use memory to inform decisions and avoid repeating failures
← 返回排行榜