| name | plan |
| description | Plan a software change from repository evidence into scoped requirements, architecture, dependency-ordered tasks, verification gates, and rollback notes. |
Feature Planning
Produce a developer-ready plan from the user's feature request.
Workflow
- Inspect repository instructions, current state, related code, prior decisions, and
any incoming handoff receipt. Record whether it requests a plan-only result or a
post-plan development confirmation.
- Use the smallest useful specialist set when delegation is available: product
requirements and independent market research may run in parallel; architecture
follows their findings; task decomposition follows architecture.
- Give every delegated worker a self-contained prompt and disjoint ownership. Fall
back to sequential work in the main conversation when subagents are unavailable.
- Run an explicit verifier pass over acceptance criteria, feasibility, test commands,
rollout, and rollback before calling the plan ready.
- Save the reviewed result to
ai_context/wiki/plans/YYYY-MM-DD-<slug>.md when that
scaffold exists; otherwise return it inline. Update the index/log only when present.
- When the incoming request asks for a plan-to-development handoff, show the reviewed
plan and ask for a separate implementation confirmation. Do not begin implementation
in the same turn as the plan.
Budget: at most five specialist calls, two concurrent workers, and one retry for a
blocked worker. Stop fan-out once the verifier has enough evidence.
Plan Quality Bar
- Tasks are 2-5 minute actions where possible and independently verifiable.
- Every task has exact file paths or explicit discovery steps.
- Every behavior change includes TDD steps.
- The plan says what NOT to build.
- Acceptance criteria are observable and testable.
- If uncertainty changes architecture, ask one focused question instead of guessing.
Optional Development Handoff
Use this only when the current request or an incoming ask-me receipt explicitly asks
to continue from planning toward development. After the verifier accepts the plan,
show its scope and ask:
## āđāļāļāļāļĢāđāļāļĄāđāļĨāđāļ§
āļāļēāļĢāđāļĢāļīāđāļĄ dev āļāļ°āđāļāļĩāļĒāļāļŦāļĢāļ·āļāđāļāđ code, tests āđāļĨāļ° docs āđāļ workspace āļāļēāļĄ plan āļāļĩāđāđāļŠāļāļāļāļĩāđ
āđāļĢāļīāđāļĄ dev āļāļēāļĄ plan āļāļĩāđāđāļŦāļĄ?
āļāļģāđāļāļ°āļāļģ: āļāđāļē plan āļāļđāļāļāđāļāļ āđāļŦāđāļāļāļ "āđāļĢāļīāđāļĄāļāļąāļāļāļēāļāļēāļĄ plan"; āļāđāļēāļāđāļāļāđāļāđ āđāļŦāđāļāļāļāļāļļāļāļāļĩāđāļāđāļāļāđāļāđāļāđāļāļ
An earlier request such as âplan then developâ authorizes planning only because the
plan did not yet exist. Start the code workflow only after an unambiguous post-plan
answer approving the exact plan shown. If the plan is blocked, unverified, or has
material unresolved choices, do not ask to start development.
Evidence Receipt
Return spk.evidence/v1 with the plan artifact, repository evidence, acceptance
criteria, verifier result, assumptions, risks, handoff intent, and
implementation_authorized: false until a separate post-plan answer is received.
Guardrails
- Do not implement, commit, push, or deploy while planning.
- Do not treat summary confirmation or a pre-plan âplan then developâ choice as
approval of an unseen plan.
- Prefer existing seams and explicitly justify every new dependency or subsystem.
- Preserve unresolved product choices as questions instead of silently guessing.
