- Home
- Skills
- Jpicklyk
- Task Orchestrator
- Post Plan Workflow
post-plan-workflow_skill
- Kotlin
166
GitHub Stars
1
Bundled Files
3 weeks ago
Catalog Refreshed
1 month ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstart where the catalogue uses aiagentskills.
npx veilstart add skill jpicklyk/task-orchestrator --skill post-plan-workflow- SKILL.md3.2 KB
Overview
This skill automates the post-plan materialization and implementation workflow for MCP-managed plans. It creates MCP items from an approved plan, wires dependencies and gating, then dispatches implementation agents and verifies completion. The workflow enforces a strict three-phase sequence: materialize, implement, verify.
How this skill works
After plan approval the skill calls create_work_tree or manage_items to materialize MCP items and tags them to trigger schema gates. It ensures dependency edges and required queue-phase notes are present, then dispatches subagents with item UUIDs so they can own lifecycle transitions and fill work-phase notes. Finally it runs health checks and diagnostics to surface stuck items and missing notes.
When to use it
- After a plan is approved and MCP tracking is enabled
- When you need structured task graphs with dependency gating
- When multiple autonomous agents will execute plan items
- When you require persistent tracking and auditability of work
- When you want automated checks to catch incomplete materialization before dispatch
Best practices
- Always complete full materialization (create items, wire edges, populate required queue-phase notes) before dispatching any agents
- Prefer create_work_tree for structured plans; use manage_items for single or ad hoc items
- Embed expectedNotes guidance into delegation prompts so agents can author required notes correctly
- Dispatch one subagent per MCP item and include the item UUID in the delegation prompt
- Verify dependency readiness with get_blocked_items between waves and avoid dispatching blocked items
- Use query_items and get_context to diagnose and manually advance any stuck work during verification
Example use cases
- Materialize a feature-implementation plan into an MCP work tree, tag items, and dispatch developers as subagents
- Orchestrate parallel research tasks using fan-out/fan-in edges and enforce acceptance-criteria notes before review
- Run automated verification after an implementation wave to detect items that never transitioned
- Recover from a partial create_work_tree failure by querying overview, cleaning partial items, and retrying
- Coordinate multi-agent integration work where each agent reports progress via MCP item transitions
FAQ
Query partial state with query_items(operation='overview'), delete partial items with manage_items(delete, recursive=true), then retry create_work_tree.
Can I dispatch agents before every item UUID exists?
No. Agents need item UUIDs to self-report. Always verify all item UUIDs exist and expectedNotes are filled before dispatch.
Who calls advance_item and complete_tree?
Delegated agents should call advance_item for their owned items as they start and complete. The orchestrator should not advance items delegated to agents except for manual recovery.