plan

Solid

Choose 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).

AI & Automation 3 stars 0 forks Updated today MIT

Install

View on GitHub

Quality Score: 79/100

Stars 20%
20
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

# /parml:plan — decide where to sit on the frontier Getting _onto_ the frontier is technical. Choosing _where on it_ to sit is not, and it is not the agent's decision. This skill frames the choice, asks it once, records the answer, and orders the work around it. ## First action, always ```bash ls -la ./.parml/ 2>/dev/null ``` Read `findings.md` if present. If it is absent, ask whether to run `/parml:audit` first — planning against unenumerated options produces a plan for the wrong problem. Planning without an audit is legitimate when the operator already knows the candidate changes; say which case you are in. If `frontier.md` exists, this is a **revision**. Read it, restate the recorded decision, and change it deliberately with a `Supersedes` line — never silently. ## Hard rules 1. **The operating point is asked, not assumed.** The objective form, the quality floor, and the non-negotiables are the operator's to state. Use `AskUserQuestion` once, with real options and honest downsides — not a questionnaire, and not a menu of six unranked choices. 2. **Present a decision as a brief.** One recommendation with its reason first, then each alternative with an honest upside _and_ downside. An agent that lists options without ranking them has moved the work, not done it. 3. **Never bank anything below `mechanism`.** `analogy` and `folklore` items may enter the plan only as _measurements to run_, never as changes to make. 4. **No plan without a noise floor.** ...

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

AI & Automation Solid

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.

0 Updated today
allemaar
API & Backend Listed

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.

1 Updated 6 days ago
adityaarakeri
AI & Automation Solid

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.

67 Updated today
Optim-Agent