Execution plan manager
Skill ytvee-dev/webdev-agent-kit/skills/execution-plan-manager
A cross-platform frontend kit for Codex, Claude Code, Cursor, OpenCode, etc. It helps AI coding agents work predictably and safely with existing frontend projects.
npx -y skills add ytvee-dev/webdev-agent-kit --skill execution-plan-managerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Create, resume, analyze, or converge standard and deep frontend execution plans with traceable slices, evidence, and stop/resume state. Skip lightweight isolated edits.
SKILL.md
12.9 KB, as published. Nobody here has run it
Execution Plan Manager
Purpose
Create, resume, analyze, and converge execution plans for standard or deep frontend work after the goal is defined.
This skill prevents large tasks from becoming unbounded development sessions. It splits work into small verified slices, selects the minimum useful context budget, records stop/resume state when needed, and decides whether a slice needs a one-pass check, bounded retry loop, goal-based loop, independent review, or durable memory handoff.
When To Use
Use this skill only after AGENTS.md and common/prompt-intent-routing-rules.md classify the task as Standard Workflow or Deep Workflow.
Use this skill when:
- a goal contract exists or the user goal is already explicit;
- the task needs more than one implementation slice;
- the task may need stop/resume state;
- the task has dependencies, blockers, or ordered phases;
- the task should be split before coding;
- the user asks to continue an existing large task;
- the agent needs to compare completed work with the plan;
- the task may require measurable iteration and should be handed to
loop-workflow-planner.
When Not To Use
Do not use this skill for Lightweight Workflow prompts, including one small bug, one obvious typo, one obvious type error, one small styling adjustment, one isolated component change, one direct file-scope edit, or one local refactor with clear boundaries.
Do not use this skill to implement code, install tools, scaffold projects, rewrite architecture, create tests, or perform visual QA.
If a lightweight task reveals hidden scope or repeated failure, escalate first using common/prompt-intent-routing-rules.md, then use this skill only if the escalated task is standard or deep.
Required Context
- Read
AGENTS.md. - Read
common/prompt-intent-routing-rules.mdwhen task scale is not obvious. - Read
common/planning-rules.md. - Read
common/planning-analysis-rules.mdonly inanalyzemode. - Read
common/convergence-rules.mdonly inconvergemode. - Read
common/checkpoint-rules.mdwhen durable stop/resume state is needed. - Read
common/agent-loop-policy.mdwhen the plan may need measurable iteration. - Confirm the workflow level is
Standard WorkfloworDeep Workflow. - Read the current goal contract from the response, user request, or
project/active-goals.mdwhen present and relevant. - Read only project overlays needed to slice the task safely, such as
project/stack-profile.md,project/architecture-map.md,project/styling-profile.md, orproject/verification-profile.md. - Read affected source files only when slicing, analysis, or convergence cannot be done safely without them.
Tool Contract
- Use filesystem access only when a durable execution plan, progress log, loop contract, or stop/resume state must be written or updated. In
convergemode, write only the append-only active-plan section allowed bycommon/convergence-rules.md. - Do not use MCP installation checks from this skill.
- Do not use Browser, Playwright, Visual Diff, Figma, or design-tool MCP from this skill.
- Do not install packages or tools.
- Do not change application source files.
- Do not create testing workflows or testing files.
Workflow
-
Confirm task scale. If lightweight, stop and route back to the direct skill without creating an execution plan.
-
Confirm goal. Use an existing Goal Contract when available. If no goal exists and the task is ambiguous, route to
goal-plannerfirst. -
Choose one explicit mode:
create: make a new compact or durable plan;resume: continue the existing plan without changing stable identifiers;analyze: run the read-only pre-implementation checks incommon/planning-analysis-rules.md;converge: compare completed implementation and evidence with confirmed intent undercommon/convergence-rules.md.
-
In
analyzemode, inspect the confirmed goal, plan, decisions, scope boundaries, and minimum affected context. Return deterministic findings and stop the implementation handoff forblockingorhighseverity. Do not edit files or remediate findings. Then finish this skill. -
In
convergemode, first reconcile any changed current request increateorresumemode. Otherwise compare only active intent with implementation and verification evidence, return stableF-###findings, and never change implementation files. For a durable plan, append one convergence pass only when actionable findings exist; with zero findings, preserve it byte-for-byte. Then finish this skill. -
In
createorresumemode, choose compact response-only planning for standard tasks that can finish in one or two slices, or durable planning for deep or resumable tasks. -
Choose context budget:
Glance,Scoped, orDeep. -
Split into small independently verifiable slices.
- For durable plans, assign stable zero-padded
S-###identifiers. - Map each slice to one or more
AC-###criteria. - Label a non-criterion slice
ENABLERand name the approved downstream slices it unlocks. - Do not renumber or reuse slice identifiers after execution begins.
- For durable plans, assign stable zero-padded
-
Add verification per slice using the smallest relevant check already available in the project or active skill.
-
Build the coverage map for durable plans.
- Map every active
AC-###to at least oneS-###and one verification source. - Use only
planned,in-progress,verified,blocked, orsuperseded. - Do not treat a completed slice as verification evidence.
- Keep
ENABLERslices linked through their downstream dependencies instead of using them as criterion coverage.
- Map every active
-
Decide whether a loop contract is needed. Use
loop-workflow-plannerwhen a slice must repeat until measurable acceptance criteria pass, when verification failure repair is in scope, when repeated failure already happened, when independent review should judge completion, or when loop memory is needed. -
Add stop/resume state for durable plans, including current phase, last completed slice, next exact step, files to inspect next, checks to run next, loop contract or retry limit when relevant, blockers, and risks.
-
Hand off to the smallest relevant skill. Route measurable iteration to
loop-workflow-plannerbefore implementation.
Output Contract
Final response: return only facts that affect the user's understanding, confidence, or next action. Omit empty fields and workflow narration.
Return or write an Execution Plan with:
Goal
Done When
Workflow Level
Context Budget
Current Phase
Task Slices
Allowed Files Or Surfaces
Tools Allowed
Verification Per Slice
Coverage
Loop Needed
Loop Handoff
Blockers
Risks
Stop Point
Next Skill Or Next Step
Durable task slices use S-### [AC-###]. A justified enabling slice uses
S-### [ENABLER -> S-###]. Compact response-only plans may omit identifiers
only when they contain at most two direct slices and need no resume state.
Durable coverage maps reference criterion and slice identifiers, verification
evidence, and one canonical coverage state without duplicating criterion prose.
An append-only convergence review of unrequested work may use S-### [F-###]
under common/convergence-rules.md; it never counts as criterion coverage.
For durable plans, write or update:
project/active-plan.md
project/progress-log.md
project/decision-log.md
project/loop-memory.md when loop memory is required
only when the task is genuinely multi-step, iterative, or resumable.
In analyze mode, return only:
Analysis Mode: read-only
Plan Readiness: ready | ready-with-risk | blocked
Findings: PA-### | Category | Severity | Source | Evidence | Recommendation
Finding Summary
Implementation Handoff: proceed | stop
Limit the table to 20 rows and aggregate the remainder. Do not write analysis results into the durable plan or application files.
In converge mode, return only:
Convergence Status: aligned | gaps-found | intent-reconciliation-required
Findings: F-### | Type | Severity | Source | Evidence | Remaining Work
Plan Update: unchanged | appended Convergence Pass N
Next Step
For response-only work, report findings without creating a plan file. For durable work, add new slices only through the append-only convergence contract.
Validation Gates
Before finishing, verify:
- the task was not a lightweight prompt;
- a goal exists or the task was routed to
goal-planner; - exactly one plan mode was selected;
analyzemode made no writes, used stable findings, checked every required analysis category, and stopped handoff for blocking or high findings;convergemode used current intent, cited evidence, made no implementation changes, preserved finding identity, and did not replace independent review;- zero convergence findings left the durable plan byte-for-byte unchanged;
- actionable durable convergence appended one pass, allocated identifiers after the current maximum, and preserved all prior plan content;
createandresumeslices are small and independently verifiable;- durable
createandresumeslices have stable identifiers and map to criteria or justified downstream work; - every active durable criterion has slice and verification coverage;
verifiedcoverage has actual evidence andblockedcoverage names the blocker;- context budget is explicit;
- loop handoff is explicit when bounded retry or measurable iteration is required;
- persistent files were created only for durable standard or deep work;
- no source files were changed;
- no tools or packages were installed;
- no testing workflow was introduced;
- next step is precise enough for another agent run to resume.
Trigger Evals
Should trigger:
- "Break this dashboard implementation into small steps."
- "Continue the previous big frontend task and tell me exactly where to resume."
- "Create an execution plan for this redesign after the goal is clear."
- "We need to implement this feature in slices without losing progress."
- "Plan the task and decide whether it needs a bounded loop."
- "Analyze this plan for gaps before implementation without changing it."
- "Compare the finished implementation with the active plan and append only the remaining work."
Should not trigger:
- "Fix this TypeScript error."
- "Change this button color."
- "Fix the broken margin in this component."
- "Rename this prop in one file."
- "Define the goal first."
- "Run visual QA on this page."
Reference Map
AGENTS.md- canonical policy, routing, tool rules, and documentation rules.common/prompt-intent-routing-rules.md- workflow weight selection and escalation/de-escalation rules.common/planning-rules.md- context budget and task slice rules.common/planning-analysis-rules.md- read-only pre-implementation plan checks and finding contract.common/convergence-rules.md- post-implementation comparison and append-only plan update contract.common/checkpoint-rules.md- stop/resume state rules.common/agent-loop-policy.md- bounded loop policy.templates/execution-plan.md- durable execution plan template.templates/loop-workflow-contract.md- durable loop contract template.skills/goal-planner/SKILL.md- goal contract producer for standard or deep work.skills/loop-workflow-planner/SKILL.md- loop contract producer for measurable iteration.project/active-plan.md- optional local-only durable execution plan for deep or resumable work.project/progress-log.md- optional local-only progress log.project/decision-log.md- optional local-only decision log.project/loop-memory.md- optional local-only loop memory.