post-plan-workflow
$
npx mdskill add jpicklyk/task-orchestrator/post-plan-workflowMaterialize approved plans into executable MCP items.
- Converts approved plans into structured work items for implementation.
- Depends on create_work_tree, manage_items, and query_items APIs.
- Uses schema tags and config.yaml to enforce gate enforcement.
- Delivers a complete item graph with UUIDs for downstream execution.
SKILL.md
.github/skills/post-plan-workflowView on GitHub ↗
--- name: post-plan-workflow description: Internal workflow for post-plan materialization — creates MCP items from the approved plan and dispatches implementation. Triggered automatically after plan approval when MCP tracking is active. user-invocable: false --- # Post-Plan Workflow — Materialize and Implement Plan approval is the green light for the full pipeline. Proceed through all three phases without stopping. ## Phase 1: Materialize Complete materialization **before** any implementation begins. 1. **Create MCP items** from the approved plan using `create_work_tree` (preferred for structured work with dependencies) or `manage_items` (for individual items). Apply appropriate schema tags based on the plan and the project's `.taskorchestrator/config.yaml` — this activates gate enforcement for each item. If the config defines separate schemas for containers vs. child tasks, apply the appropriate tag at each level. 2. **Wire dependency edges** between items — use `BLOCKS` for sequencing, `fan-out`/`fan-in` patterns for parallel work 3. **Check `expectedNotes` in create responses** — if the item's tags match a schema, the response includes the expected note keys and phases. Fill required queue-phase notes (`requirements`, `acceptance-criteria`, etc.) with content from the plan before advancing. 4. **Verify all item UUIDs exist** — confirm the full item graph is materialized before proceeding **If `create_work_tree` fails:** Check partial state with `query_items(operation='overview')`. Delete partial items with `manage_items(delete, recursive=true)` and retry. Do NOT dispatch implementation agents until materialization is complete. Agents need MCP item UUIDs to self-report progress. ## Phase 2: Implement Dispatch subagents to execute the plan: - Each subagent **owns one MCP item** — include the item UUID in the delegation prompt - If `expectedNotes` entries include `guidance`, embed it in the delegation prompt as authoring instructions when filling notes - If `expectedNotes` entries include a `skill` field, include in the delegation prompt: "Before filling the `<key>` note, invoke `/<skill>` and follow its framework." This ensures subagents receive deterministic skill routing rather than relying on guidance prose - **Agents own their work-phase transitions** — each agent calls `advance_item(trigger="start")` to enter work, and `advance_item(trigger="start")` again to advance to review before returning. Agents do NOT call `advance_item(trigger="complete")` — the orchestrator handles terminal transitions - Fill work-phase notes (`implementation-notes`, `test-results`, etc.) as the agent works - Respect dependency ordering — do not dispatch an agent for a blocked item until its blockers complete - **Between waves:** call `get_blocked_items(parentId=...)` to confirm upstream items completed — dependency gating implicitly verifies agents transitioned their items. If downstream items are still blocked, investigate the upstream blocker - **Do not** call `advance_item` or `complete_tree` for terminal transitions on items delegated to agents — the orchestrator reviews and advances to terminal after agents return Do NOT use `AskUserQuestion` between phases — proceed autonomously. ## Phase 3: Verify After all agents complete: 1. Run `query_items(parentId=..., role="work")` — any results are items agents failed to transition. Use `/status-progression` to diagnose and manually advance stuck items 2. Run `get_context()` health check to see what completed, what stalled, and what needs attention 3. Review any stalled items — check which notes are missing with `get_context(itemId=...)` 4. Address blockers or incomplete work as needed ## Workflow Complete The post-plan workflow is done. Report the final status to the user — what completed, what needs attention, and any items still in progress.
More from jpicklyk/task-orchestrator
- batch-completeComplete or cancel multiple items at once — close out features, clean up old work, archive completed workstreams. Use when a user says "close out this feature", "complete everything under X", "cancel this workstream", "clean up old items", "bulk complete", "finish this feature", or "archive completed work".
- create-itemCreate an MCP work item from conversation context. Scans existing containers to anchor the item in the right place (Bugs, Features, Tech Debt, Observations, etc.), infers type and priority, creates single items or work trees, and pre-fills required notes. Use this whenever the conversation surfaces a bug, feature idea, tech debt item, or observation worth tracking persistently. Also use when user says "track this", "log this bug", "create a task for", or "add this to the backlog".
- dependency-managerVisualize, create, and diagnose dependencies between MCP work items. Use when a user says "what blocks this", "add a dependency", "show dependency graph", "why can't this start", "link these items", "unblock this", "remove dependency", or "show blockers".
- manage-schemasCreate, view, edit, delete, and validate note schemas for the MCP Task Orchestrator in .taskorchestrator/config.yaml — the templates that define which notes agents must fill at each workflow phase. Use when user says \"create schema\", \"show schemas\", \"edit schema\", \"delete schema\", \"validate config\", \"what schemas exist\", \"add a note to schema\", \"remove note from schema\", or \"configure gates\".
- pre-plan-workflowInternal workflow for plan mode — checks MCP for existing work, note schemas, and gate requirements to set the definition floor before planning begins. Triggered automatically when entering plan mode for any non-trivial implementation task.
- quick-startInteractive onboarding for the MCP Task Orchestrator. Detects empty or populated workspaces and walks through how plan mode, persistent tracking, and the MCP work together. Use when a user says "get started", "how do I use this", "quick start", "first time setup", "onboard me", "what can this MCP do", or "help me learn task orchestrator".
- review-qualityReview quality framework for the work-to-review transition gate. Guides verification of plan alignment, test quality, and code simplification before marking implementation complete. Referenced by schema guidance fields during review-phase note filling. Read this skill when filling review-checklist notes or when asked to review completed implementation work.
- schema-workflow>
- session-retrospectiveAnalyze the current implementation run — evaluate schema effectiveness, delegation alignment, note quality, plan-to-execution fit. Captures cross-session trends and proposes improvements when patterns repeat. Use after implementation runs, or when user says 'retrospective', 'session review', 'what did we learn', 'analyze this run', 'how did that go', 'evaluate our process', 'wrap up', 'end of session review'. Also use when the output style's retrospective nudge fires after complete_tree.
- spec-qualitySpecification quality framework for planning. Defines the minimum bar for what a plan must address — alternatives, non-goals, blast radius, risk flags, and test strategy. Referenced by schema guidance fields during queue-phase note filling. Read this skill whenever filling requirements or design notes for any MCP work item.