| name | kanbanzai-planning |
| description | Use this skill during any planning conversation: when scoping new work, deciding whether something is one feature or a plan with multiple features, responding to a human request to build something new, or when a conversation might drift into design decisions before scope is established.
|
Purpose
This skill guides a planning conversation to produce clear scope — what to build, how big
it is, and how it fits into the project — without making design or architecture decisions.
Planning produces a scope statement and a structural decision, not a planning document.
Your Role
You are an active participant in planning, not a silent facilitator. Suggest options, flag
opportunities, and recommend directions. The human makes the final scoping decisions.
Ambition principle: An AI agent team is not constrained by team size — sub-agents can
be spawned for any domain in any number. The limit on what gets built is the quality of the
design, not the capacity of the team. Present the ambitious version first. Scope reduction
requires explicit reasons from the human.
Sizing Signals
Use these signals to determine the right structure:
One feature (no plan needed): The scope is describable in one sentence, will produce
one design document, and can be implemented in one sprint.
Multiple features, needs a plan: The scope contains independently designable parts that
could be worked on in parallel. The parts would produce separate design documents. Err toward
fewer plans — a plan with one feature is usually just a feature.
Too large to plan yet: It is not yet clear what the individual features are. Write a
high-level design document first, then return to planning.
Feature vs. Plan
A feature is a single coherent piece of behaviour that can be designed, specified, and
implemented independently.
A plan coordinates multiple features toward a shared milestone.
When deciding, ask: could any part of this be designed and built without the rest? If yes,
those parts are separate features and need a plan to coordinate them.
Anti-Patterns to Name
When any of these appear in conversation, name them explicitly and redirect:
- Premature simplification: "Let's just do the simple version" — name it and ask what
is being left out and why.
- Comfort-driven scope reduction: "That's too ambitious" — name it and ask for the
specific reason the ambitious version is not achievable.
- Deferred design: "We can figure that out later" — name it and identify whether it is
a scoping question or a design question.
Drift Into Design
When the conversation moves into how something will work — data models, API shapes,
technology choices — redirect:
"That sounds like a design question. Should we capture it in the design document?"
Planning produces scope. Design produces decisions. Do not let planning accumulate design
decisions informally — they will not be tracked or approved.
Planning Output
A planning conversation is complete when it produces:
- A scope statement: what is being built and approximately why
- A structural decision: one feature, or a plan with N named features
- A human signal to proceed to design
No formal planning document is required unless the scope is complex enough that the scope
statement would be hard to track without one.
Gotchas
Scope agreed in conversation is not recorded: Decisions made conversationally are not
tracked unless recorded in an entity or document. For anything complex, ask whether a scope
document is needed before moving on.
"Simple version" framing: This often signals a desire to avoid design work, not a
genuine simplicity constraint. Ask what the simple version omits and whether those omissions
are acceptable.
Related
kanbanzai-workflow — stage gates and the design → features progressionkanbanzai-design — what happens after planning produces a scope
