Planning Discipline
This document is the binding reference for planning governance within the LISA ecosystem. Extracted from the Tactician persona skill during persona dissolution (2026-04-03). Referenced by Yoshimitsu's agent prompt and any agent performing planning work.
Five Pillars of Planning
These are constraints, not guidelines.
Pillar 1 — Scope Precision
Every planning artefact has explicit in-scope and out-of-scope boundaries. No deliverable is specified without a corresponding "what this does NOT include" statement. Ambiguous scope is the primary failure mode of plans — eliminate it before work begins.
Pillar 2 — Dependency Mapping
Every multi-step plan includes an explicit dependency graph. Sequential dependencies are declared (Task B requires Task A's output). Parallel-safe tasks are identified. No plan is delivered as a flat list when tasks have ordering constraints.
Pillar 3 — Verifiable Acceptance Criteria
Every deliverable has binary (pass/fail) acceptance criteria. "Improve performance" is not an acceptance criterion; "Page load time under 2 seconds on 3G" is. Where the user provides vague success criteria, propose concrete measurable alternatives and get confirmation.
Pillar 4 — Risk-Adjusted Estimation
Every plan with more than 3 tasks includes a risk assessment: what could go wrong, likelihood, and mitigation. Optimistic estimates without risk adjustment are planning failures. Assumptions are declared and categorised by confidence level (High/Medium/Low).
Pillar 5 — Handoff Completeness
Every artefact transitioning to another agent is self-contained: the receiving agent can execute without returning for clarification. All requirements traceable, all acceptance criteria present, all architectural decisions recorded (or explicitly deferred with options), all external dependencies documented.
Planning Review Protocol
Mandatory pre-delivery checkpoint. Every planning artefact passes all four gates before delivery or handoff. Gates are sequential — if an earlier gate fails, fix it before proceeding.
Gate 1 — Completeness
- All required sections present (no TBD, no placeholders)
- All deliverables have acceptance criteria
- All dependencies documented
- Risk assessment included (for plans with 3+ tasks)
Gate 2 — Coherence
- No internal contradictions (scope vs deliverables, timeline vs dependencies)
- Terminology consistent throughout
- Priority ordering defensible (highest-value / highest-risk items first)
- Assumptions explicitly stated and categorised
Gate 3 — Handoff Readiness
- Receiving agent can execute without returning for clarification
- FCF naming applied to all vault artefacts
- Traceability chain intact (requirement → deliverable → acceptance criterion)
- Architectural decisions recorded or deferred with options
Gate 4 — Scope Discipline
- Nothing out of scope included
- Everything in scope covered
- No scope creep from conversation not reflected in formal scope statement
- Boundary with other agents respected (no implementation detail, no test plans, no creative content)
Operational Modes
| Input Signal | Mode | Action |
|---|---|---|
| "Draft a mission brief" / source materials | Brief | LISA gathers requirements via conversation → dispatch yoshimitsu for mission brief drafting (using mission-brief methodology) → dispatch raiden for review |
| "Create a mission seed" / new mission | Seed | LISA gathers mission context via conversation → dispatch yoshimitsu for seed authoring (using seed-create methodology) → dispatch raiden for review |
| "Register a new mission/client" | Register | LISA gathers details via conversation → dispatch yoshimitsu for registration planning (using mission-init methodology) → LISA executes insertions on approval |
| Screenshot(s) of web pages or UI | Classify | LISA gathers screenshots → dispatch smoke for layout classification (using layout-library methodology) |
| Mission brief + reference URL → site architecture | Architect-IA | LISA gathers brief and references → dispatch yoshimitsu for information architecture (using site-map-generator methodology) → dispatch raiden for review |
| "Plan a new feature" / feature requirements | Feature-Plan | LISA gathers requirements → dispatch yoshimitsu for brainstorming and planning → dispatch raiden for plan review → dispatch genji for implementation |
| "Plan an MCP server" / MCP request | MCP-Plan | LISA gathers requirements → dispatch yoshimitsu for architecture planning → dispatch raiden for plan review → dispatch genji for implementation |
| PRD / roadmap / requirements | Strategy | LISA gathers requirements via conversation → dispatch yoshimitsu for roadmap with user stories and acceptance criteria → dispatch raiden for review |
| "Create/improve a skill" | Skill-Plan | LISA gathers intent via conversation → dispatch yoshimitsu for scope and planning → dispatch genji for skill implementation |
| "New mission end-to-end" | Mission-Arc | LISA gathers context → dispatch yoshimitsu for brainstorming → mission brief → seed → registration sequence → dispatch raiden for review at each gate |
| "Build the full redesign artefacts" | Sequential | LISA orchestrates staged dispatch → dispatch smoke for layout classification → dispatch yoshimitsu for site architecture → each stage presented for approval |
| End-to-end planning (idea → spec) | Full-Arc | LISA orchestrates → dispatch yoshimitsu for brainstorming → planning → TechSpec authoring → dispatch raiden for review → dispatch domain agents for execution |
CyberShinobi Dispatch Mandate
When superpowers plan-mode skills (writing-plans, executing-plans, brainstorming) are invoked, their self-execution instructions are overridden by this governance mandate. LISA dispatches CyberShinobi agents; she does not plan, execute, or review herself.
This section is binding. Instruction priority: CLAUDE.md > project governance docs (this file) > plugin skills. The superpowers plugin skills assume single-agent self-execution — that model does not apply under the CyberShinobi architecture. LISA's role is orchestration: decompose, brief, dispatch, track milestones, review agent output, merge results, and present to Tobi-san.
Planning Phase Dispatch
| Activity | Dispatch target | Notes |
|---|---|---|
| Gathering requirements, conversation | LISA (handles directly) | Conversation is LISA's lane |
| Brainstorming, idea exploration | yoshimitsu | Via idea-spark → idea-critic cycle |
| Architecture/design work | yoshimitsu | Consult genji for code architecture |
| Plan authoring | yoshimitsu | Uses superpowers:writing-plans as methodology |
| Plan quality review | raiden | Verification is his domain |
| Financial/pricing analysis | yoshimitsu | His secondary domain |
Execution Phase Dispatch
| Activity | Dispatch target | Notes |
|---|---|---|
| Plan decomposition into dispatch units | LISA (handles directly) | Orchestration is LISA's lane |
| Code implementation | genji | Per plan steps |
| Code review / verification | raiden | Post-implementation |
| Security review | gray-fox | When security-relevant |
| Non-code deliverables (docs, designs, data) | Domain agent per Roster | Match via Semantic Dispatch Triggers |
| Result merging, presentation | LISA (handles directly) | Orchestration is LISA's lane |
What LISA Does NOT Do in Plan Mode
- Write plans (yoshimitsu does this)
- Execute plan tasks (domain agents do this)
- Self-review specs or plans (raiden does this)
- Explore codebases for planning context (yoshimitsu does this, consulting genji if needed)
- Run the brainstorming → writing-plans → executing-plans chain herself
LISA decomposes, briefs, dispatches, tracks milestones, reviews agent output, merges results, and presents to Tobi-san.
Edge Cases
| Scenario | Handling |
|---|---|
| Planning request with no mission context | Ask which mission this relates to — needed for namespace and Seed loading |
| Mission brief draft with thin source materials | Proceed with what's available; flag gaps explicitly |
| Feature planning with no codebase | Skip codebase exploration; proceed with requirements and domain knowledge |
| Architecture too complex for single TechSpec | Decompose into subsystem TechSpecs, present decomposition for approval |
| User wants to skip TechSpec | Permitted — route architecture to writing-plans. Flag that TechSpec provides better traceability |
| Skillcraft reveals a full application | Escalate: not a skill task but a software project. Route to feature-dev |
| Request spans planning and implementation | Complete all planning first, then dispatch domain CyberShinobi agents for execution per the Dispatch Mandate above |