plan

name	plan
description	Use when entering PLAN mode or when the user says "Enter P". Creates structured implementation plans with Vibe Board tasks and specialist agent assignments for each checklist item.
user-invocable	true

PLAN Mode Protocol

You are entering PLAN mode. Follow this protocol exactly.

Step 0: Detect Work Type (3-tier vs flat)

Before generating an implementation checklist, classify the work request. Most invocations are flat — Step 0 is a fast routing check, not a ceremony.

Invoke 3-tier flow (story → design → tasks) when ANY hold:

• Work spans 5+ implementation tasks
• Touches shared infra (DB schema, RLS, auth, billing, deployment pipeline)
• Crosses 2+ services
• Has external stakeholder visibility (founder asked for a named deliverable, or it'll appear in marketing/release notes)
• Requires architectural decision visible to non-engineers (e.g., choosing between competing approaches that have long-term implications)

Use the flat flow (Steps 1-4 below — existing behavior) when:

• Single-thread bug fix, refactor, or feature touching <5 tasks
• One-file change
• Adding a flag, deploying from existing template, routine ops
• Estimable in <4 hours

When in doubt → ask the user with choice-based clarification (ONE multiple-choice question at a time, never a 10-question waterfall):

This looks like substantial work. Should I:

1. Create a STORY (with "why" + success metric) + DESIGN RFC (with ripple effects + ADRs) + implementation tasks
2. Just create a flat implementation task list (skip story + design — faster, less anchoring)

If 3-tier is selected: invoke project-coordinator to produce the STORY task + DESIGN task per its 3-Tier Decomposition Protocol, THEN return here for Step 2 to decompose the design into implementation tasks. The implementation tasks should reference their parent design in description ("Design: <design_task_id>") so reviewers can trace back.

Soft task_type convention (until Vibe Board MCP gains a native task_type field per ADK-8): title prefixes carry the type — [STORY], [DESIGN], [BUG], [CHORE], [INVESTIGATION]. Plain titles = regular implementation task. See .claude/rules/agent-board.md § Task Type Convention.

Step 1: Research & Design

Analyze the task and create an exhaustive implementation specification:

• File names, function signatures, data flows
• Dependencies and execution order
• Risk areas and edge cases

Step 2: Create Board Tasks

For EACH item in your implementation checklist, call board_create_task with:

• title: Clear, actionable description
• assigned_agent: The specialist agent who should execute this task (MANDATORY — see mapping below)
• status: todo
• riper_mode: plan
• depends_on: Task IDs of prerequisites (if any)
• priority: Based on blocking relationships (critical if it blocks others, high if important, medium default)
• description: Must include ALL of the following:
  1. Context: Enough for the assigned agent to execute without additional research
  2. Acceptance criteria: Specific, verifiable conditions that define "done" — not just "build X" but "build X with [specific behavior], [specific config], [specific output]". These are what post-execute review checks against.
  3. Key spec points: Any user-specified requirements (schedule, trigger method, notification behavior, etc.) that distinguish this from a generic implementation

Why acceptance criteria matter: Post-execute review compares implementation against these criteria. Without them, review can only check "does it run?" not "does it match the plan?" — which is how plan drift goes undetected.

Agent Assignment Mapping

Task Type	Assign To
DB schema, migration, RLS policy	database-specialist
React component, page, layout, styling	ui-specialist
Chat/LangChain service code	chat-specialist
Essay Coach service code	essay-coach-specialist
Issue Spotter service code	issue-spotter-specialist
Outline IQ service code	outline-iq-specialist
Case enrichment/vector search	case-law-specialist
Study plan/syllabus service	study-plan-specialist
Flashcards/study mode/Question Bank	study-specialist
Security review, code quality	code-reviewer
Tests, type-check, validation	test-runner
Cloud Build, GCS, deployment	deployment
Auth flow, JWT, Firebase	auth-specialist
Stripe, billing, subscription	subscription-specialist
Marketing copy, UTM, analytics	marketing-specialist
Mobile, Capacitor, iOS/Android	mobile-specialist
Gemini AI, prompt caching	ai-infrastructure
GCP infra, gcloud, IAM	gcp-infra
Cloud Run Docker/config	cloud-run-specialist
Dashboard widgets, progress display	dashboard-specialist
Course/module/lesson, Gumlet video	courses-specialist
Blog content, Astro, TwicPics	blog-specialist
Outline template creation/editing	outline-manager
n8n workflow logic	n8n-automator
n8n infrastructure/deployment	n8n-manager
Learning Intelligence integration	intelligence-specialist
NextGen bar prep features	nextgen-specialist
NextGen question/MCQ authoring	nextgen-question-writer
Community, discussions, threads, @mentions	community-specialist
Dashboard widgets, study stats display	dashboard-specialist
MIG-hosted service ops (Docker, listmonk, n8n, AI containers)	mig-specialist
Automation strategy / what-to-automate audits	automation-architect
Bulk sub-agent output consolidation	processor
Cross-domain coordination (3+ areas)	project-coordinator
Documentation, agent/skill lifecycle, /review-* audits	docs-manager

If a task spans multiple domains, assign the primary specialist and note secondary reviewers in the description.

Step 3: Output Checklist

Present the numbered implementation checklist with board task IDs and assignments:

IMPLEMENTATION CHECKLIST:
1. [Task title] — assigned: [agent] — board: [task_id]
2. [Task title] — assigned: [agent] — board: [task_id]
...

Step 4: Auto-Transition

After the checklist is complete, state: "Plan created with [N] board tasks. Auto-transitioning to REVIEW for plan validation."

Then enter REVIEW mode to validate the plan (invoke the /review skill or manually verify assignments).