pre-plan-workflow
Internal 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.
Best use case
pre-plan-workflow is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Internal 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.
Teams using pre-plan-workflow should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/pre-plan-workflow/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How pre-plan-workflow Compares
| Feature / Agent | pre-plan-workflow | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Internal 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.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
SKILL.md Source
# Pre-Plan Workflow — Definition Floor When entering plan mode, use the MCP to set the **definition floor** before writing your plan. The definition floor is the baseline of existing work, documentation requirements, and gate constraints that the plan must account for. **If MCP is unreachable:** Proceed with planning based on conversation context. Note in the plan that MCP state could not be verified — existing work may overlap. Re-check after MCP reconnects. ## Step 1: Check Existing MCP State Call the health check to see what's already tracked: ``` get_context() ``` **If active or stalled items exist:** - Identify items related to the current request — avoid planning work that duplicates what's already tracked - For each relevant active item, call `get_context(itemId=...)` to inspect: - **Note schema** — which notes are expected for this item's tags - **Gate status** — which required notes are filled vs. missing, and whether the item can advance - **Guidance pointer** — authoring guidance for the first unfilled required note **If no items exist (clean slate):** - The definition floor is simply "no existing MCP state to account for" - Proceed with planning, but still check Step 2 for schema awareness ## Step 2: Discover Note Schema Requirements Read `.taskorchestrator/config.yaml` in the project root (this is a file read, not an MCP call): - If the file exists, list the discovered schemas and their required notes per phase - Schemas are defined under `work_item_schemas:` (preferred) or `note_schemas:` (legacy) - Each schema key (e.g., `feature-implementation`, `bug-fix`) is a **type identifier** — set it as the item's `type` field to activate gate enforcement. Tags can be used for additional categorization but are no longer the primary schema activator. - Required queue-phase notes define what documentation must exist before work starts - Required work-phase notes define what must be captured during implementation - Use `guidancePointer` values from `get_context(itemId=...)` on existing items to understand how to author each note If no config file exists, the project has no note schemas — items will be schema-free with no gate enforcement. Proceed with planning normally. **Use schemas to inform the plan:** When a schema applies, each planned task should: - Note which schema type will be applied at materialization (e.g., `type: "feature-implementation"`) - Account for required notes — plan sections should naturally produce content that maps to required note keys - Respect dependency ordering — which tasks block others (these become `BLOCKS` edges) ## Step 3: Plan with MCP Awareness Structure the plan knowing it will be materialized into MCP items after approval: - Each planned task should map to **one work item** with clear boundaries — a single unit of work a subagent can own - Account for **dependency ordering** — which tasks block others (these become `BLOCKS` edges) - Consider the **hierarchy** — a root container item with child task items is the standard pattern ## Continue with Plan Mode The prerequisite is complete. Now proceed with plan mode's normal workflow — explore the codebase, understand existing patterns, and design your implementation approach. Use the definition floor from Steps 1-3 to inform your plan. Once the plan is approved, the post-plan hook will guide you through materialization and implementation dispatch. Do not materialize before approval.
Related Skills
schema-workflow
Guide an MCP work item through its schema-defined lifecycle — filling required notes using guidancePointer and advancing through gate-enforced phases. Internal skill triggered by hooks and output styles during orchestration workflows. Use when an item has schema tags and needs to progress through queue, work, review, or terminal phases with note gates.
post-plan-workflow
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.
work-summary
Generate a hierarchical project dashboard showing all work items organized by container, with IDs, tags, status, and priority visible. Always use this skill for any request about project status, work summaries, or item overviews — never construct dashboards manually with raw MCP calls. Trigger on any of these phrases or intent: "project status", "what's active", "show me the dashboard", "work summary", "summary", "what should I work on", "project health", "what's blocked", "where did I leave off", "show items", "what's in the backlog", "overview", or any request to see or review the current state of work items. This includes session-start context gathering — if you need to understand current project state, use this skill.
status-progression
Navigate role transitions for MCP work items using advance_item. Shows current role, gate status, required notes, and the correct trigger to use. Use when a user says "advance this item", "move to work", "start this task", "complete this item", "what's the next status", "why can't I advance", "unblock this", "cancel this item", or "check gate status".
quick-start
Interactive 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".
manage-schemas
Create, 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".
dependency-manager
Visualize, 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".
create-item
Create 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".
batch-complete
Complete 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".
spec-quality
Specification 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.
session-retrospective
Analyze 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.
review-quality
Review 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.