plan
SolidChoose an operating point on the speed↔quality frontier and turn findings into an ordered, gated change plan — with a quality floor, named non-negotiables, revert triggers, a measurement contract, and a stop rule. Use for `/parml:plan`, "which of these should I actually do", "I have N GPU-hours and need quality Q", "how much accuracy can I trade for speed here", "what order should I make these changes in", or after `/parml:audit`. Writes ./.parml/frontier.md and hands off to /ar:start when the work is many measured iterations under a locked harness. The operating point is the operator's decision, not the agent's — this skill frames it and asks. Do NOT use to discover opportunities (that is /parml:audit) or to check a change already made (that is /parml:review).
Install
Quality Score: 79/100
Skill Content
Details
- Author
- emaballarin
- Repository
- emaballarin/ccplugins
- Created
- 3 months ago
- Last Updated
- today
- Language
- Python
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
plan-create
Propose a phased, gated implementation plan before any work begins. Trigger when the user runs /plan-create, says "make a plan", "plan this out", "design before coding", "let's plan first", "architect this", or asks for a phased approach before implementation. Also trigger proactively when a task is complex enough that jumping straight to execution would be risky — multi-file changes, new features, architectural shifts, refactors spanning multiple components, or any task where misalignment early would be expensive to fix later. Output: a structured PLAN.md with phases, changes, risks, and verification criteria. Design only — no implementation code is written during /plan-create. Use plan-phases to restructure an existing plan, plan-execute to run an approved plan, plan-deep-dive to inspect a plan, plan-evolve to evolve shipped work, and plan-cleanup after execution.
plan-first
Write and confirm a short implementation plan before starting any large or risky change. Use this for tasks that touch three or more files, alter public APIs, database schemas, auth, payments, build systems, or CI, for migrations and multi-step refactors, and whenever the honest estimate is "this will take many steps". Also trigger it when the user asks "how would you approach this", says "plan", or when the request is ambiguous enough that two reasonable engineers would build different things.
optim-plans
MUST USE when a user asks to plan, brainstorm, design, scope, review, or evaluate a repo change before implementation; do not use for direct implementation-only requests, factual/explanation questions, trivial operations, or explicit no-plan requests.