Preserve what was actually asked
Keep stated requirements, inferences and unanswered decisions separate.
Skill
Intent to Plan
Turn the request into work someone can follow.
A planning skill for complex requests. Separate the goal, people, inputs, working rules and timing, then connect them into a plan with explicit dependencies and acceptance checks.
Fictional plan: onboarding improvement Why: remove a reported task breakdown Evidence: baseline and affected steps unresolved Order: inspect → decide → implement → verify Handoff: accepted design and task checks cross to builder Release: separate authorized action Verdict: revise until the missing input is resolved
Fictional worked example. It illustrates the intended output; it is not a measured result or a real customer story.
Make handoffs concrete
Give each unit an outcome, owner, input revision, output and completion evidence.
Catch problems before execution
Review hidden dependencies, missing inputs, invented thresholds and work beyond the granted scope.
The film
Ship it when ready.
In 73 seconds, Purl the cat pounces on a one-line request, invents a target nobody measured and hears ship it as a yes. Intent to Plan pulls the request into five threads (why, who, what, how, when), marks each said, inferred or open, weaves the work into order and gives a verdict: revise, because the baseline is missing and the release has no owner. Captions are on the player; a transcript is below.
Read the transcript
One line lands. Fix the onboarding flow, and ship it when ready.
Your agent pounces. Ten tasks, all at once.
It invents a target nobody measured. It hears ship it as a yes.
Intent to Plan starts by pulling the request apart.
Five threads: why, who, what, how, when. Each marked said, inferred or open.
Then it weaves the order. Inspect, decide, build, verify. Every handoff names what crosses.
The verdict is revise. The baseline is missing, and the release still needs an owner.
Its optional compiler is a prototype. Check the order before you run anything.
On screen: Plan what was asked. Mark what you guessed.
Intent to Plan. Turn a complex request into a plan you can test and hand over.
The request, the app and the plan are a fictional example. The optional compiler shown is a prototype; the film shows how the skill behaves and reports no results.
See the work take shape.
Fictional worked example. It illustrates the intended output; it is not a measured result or a real customer story.
Decompose the request
Use five questions: why, who, what, how and when; label the basis for each answer.
Connect the work
Declare prerequisites and the artifacts that cross them. Parallelize only genuinely independent work.
Review the plan
Return ready, revise or blocked with the smallest correction and next authorized action.
Fictional example
A request becomes a reviewable plan
The brief A fictional team says: “Fix the onboarding flow and ship it when ready.”
Before
Invent a drop-off target, parallelize dependent tasks, and interpret the sentence as deployment approval.
After applying the method
Separate intended outcome from method; preserve the unknown baseline, declare design-to-build inputs, test acceptance, and retain release authority as an unresolved boundary.
An executable-looking plan cannot manufacture evidence or approval.
A clear job.
A useful stopping point.
Use for complex requests, multi-role workflows, reviewable specifications, or a handoff before execution.
Use it when
- A request mixes goals, tools, roles and deadlines.
- Several people or agents need to work from the same plan.
- An executable-looking workflow needs a scope and dependency review.
Choose another route when
- Automatic deployment authority or invented success metrics.
- Unreviewed execution of the optional lexical compiler’s output.
Decompose
The request mixes purpose, roles, evidence, norms, and timing.
Five explicit primitives with source, assumptions, and unresolved questions.
Compose
The components need an actionable dependency plan.
A plan with inputs/outputs, dependencies, scope, authority, and acceptance evidence.
Review
A plan is about to be executed or compiled.
A defect list or a bounded ready judgment; execution is a separate action.
Read the canonical method
Intent to Plan
Turn a complex request into a plan you can test and hand over.
Preserve the request before formalizing it
Record the original request, intended user outcome, known constraints, available artifacts, and decisions already settled. Do not invent success thresholds, execution permission, or an agent because the template has a field. Use a lightweight checklist for small work; use the full grammar when ambiguity or coordination justifies it.
Decompose into five questions
Use five primitives: Intent/WHY (goal, success, scope, tradeoffs); Agent/WHO (capability and accountable owner); Context/WHAT (provided, inspected, discovered, missing); Behavior/HOW (reusable working rules); Trigger/WHEN (activation, prerequisites, confirmation). Mark each statement explicit, inferred, or unresolved. A model's confidence number is self-report, not correctness.
Use decomposition checks to detect conflation. Ask whether a change in one responsibility unnecessarily forces a change elsewhere. Dependencies can be real: orthogonality is a useful design question, not permission to erase legitimate coupling. Preserve restrictive constraints wherever they affect execution.
Compose a bounded plan
Apply composition rules. Give each work unit one outcome, owner/performer, required inputs and revisions, outputs, acceptance evidence, prerequisites, failure/recovery, and an authority boundary. Declare parallel tasks only when inputs and edits are independent. Same agent identity does not imply parallelism. Declare each dependency and the artifact that crosses it; never assume a hidden shared context.
Keep user intent, design grammar, and execution machinery distinguishable. Reference an available agent by its real identity or assign an existing human/local performer. Do not invent a deployer, schedule, service, or permission merely to complete the diagram. Ask only a blocking question; continue independent authorized inspection while a decision is pending.
Review before execution
Use review and the preserved anti-pattern reference. Inspect the actual plan for scope leakage, circular/implicit dependencies, unsupported criteria, absent inputs, redundant roles, and actions beyond authority. Return ready, revise, or blocked with reasons and the smallest correction. “Ready” means the plan meets its stated checks, not that its work happened.
Optional compiler
Recipe compilation preserves the original mapping and examples. The retained tool-idd parser/compiler/hooks are optional prototype machinery. Their lexical parallelism detection and tests do not prove a current runtime recipe schema; validate generated output using the actual host recipe validator before running it. A provider failure or malformed parse must remain a visibly untrusted draft; never run fallback text automatically.
Output
Return the original intent, five-primitives table with basis, dependency plan, acceptance checks, assumptions and owner decisions, review verdict, and next authorized action. Include generated recipes only as inspected/validated drafts at their actual evidence level.
Limits and prerequisites
- The five-primitives grammar is a design aid, not a proof that every request has a uniquely correct decomposition.
- The optional lexical compiler can group dependent steps when parallel appears in a negation or bug description: two controls passed and two dependency cases failed. Inspect dependencies and validate with the actual current host before execution.
- Compilation and model confidence do not establish authority, correctness, or current recipe-schema compatibility.
- Memory hooks, Amplifier runtime, and automated parsing remain optional.
Your first useful run.
Paste the original request and name the decisions that are already settled.
The download contains the complete skill folder. Extract it into the skills directory supported by your agent, keeping its references and license together. Or use the source installer below. Python 3.11+ is required for that installer.
Start from the public source
git clone https://github.com/michaeljabbour/amplifier-skill-intent-to-plan.git
cd amplifier-skill-intent-to-planpython3 scripts/capability.py doctor
python3 scripts/capability.py install --dest ~/.agents/skillsNative tools and optional execution
amplifier bundle add ./bundle.mdThese commands are for the optional native surface. Follow its installation guide and prerequisites; portable method installation is separate.
Keep the complete skill folder together, including its references and license. The host applies the method in your context; the skill does not start a background service.
- Requires Git and Python 3.11+ for the repository installer. The portable method itself can be read by a compatible agent without a service or provider account.
- The destination is a skills-parent folder. Use the discovery path supported by your agent; ~/.agents/skills is an example, not a universal host setting.
- Keep the complete installed folder, references and license together. Identical reinstall is safe; conflicts are refused. A deliberate --replace keeps a dated backup.
Try this with your agent
Use Intent to Plan on this request: improve our fictional onboarding flow and prepare a release. Separate explicit requirements from assumptions, identify missing baseline evidence, order design before implementation and make the release authority visible. Produce a plan only.Use after installing in a host that loads skill folders. Supply your own task files and review the result.
Keep the guide nearby
Read the guide · License · Changes · Release metadata · Install guide · Migration · Validation · Native guide · consolidation · COMPILER LIMITS · PROTOCOL · compiler probe
Know what you can rely on.
The portable method is checked and the optional parser/compiler retains its software suite. A separate four-case probe exposed two scheduling failures in that prototype; generated recipes require dependency inspection and the current host validator.
Read the checks and their scope
- Optional compiler boundary probe — known-limit
Four authored cases: 2 passed and 2 failed. Negated/descriptive parallel words incorrectly group dependent assignments. No parser/model/runner executed and no compiler source changed; not a held-out or efficacy result.
- Parser/compiler/hooks regression suite — passed
278 tests. Repaired request-construction failure handling, human-gated zero-confidence fallback, consistent no-Core result shape, and repeated-agent sequencing. Generated recipe schema/live runner acceptance still requires current-host validation.
- Portable packaging and install — passed
All operations passed. No runtime activation or effectiveness measured.
- Skill discovery metadata — passed
Skill is valid. This is a structural check, not a behavioral benchmark.
The portable method is checked and the optional parser/compiler retains its software suite. A separate four-case probe exposed two scheduling failures in that prototype; generated recipes require dependency inspection and the current host validator.
Fictional examples explain the capability. Tests check the stated behavior. Outside-user outcomes need their own evidence.