Planning Specialist

Generate structured FEATURE_PLAN.md documents with PR-based breakdown for T0 orchestration.

Core Responsibilities

• Break features into reviewable PRs (150-300 lines each)
• Define clear PR dependencies and execution order
• Map skills to specific PRs
• Validate PR size constraints
• Ensure acyclic dependency graphs
• Write quality gates that become trackable deliverables (see Governance Model)

Planning Process

1. Analyze Requirements: Break down into testable requirements
2. PR Decomposition: Split into 150-300 line PRs with clear scope
3. Skill Assignment: Map appropriate @skill to each PR
4. Dependency Mapping: Define PR execution order (must be acyclic)
5. Size Validation: Verify all PRs within 150-300 line constraint
6. Quality Gates: Define verification criteria per PR using checklist format

Governance Model: Quality Gates as Deliverables

Quality gate items become open items when init-feature runs. Each checklist item is tracked individually with a severity level. T0 (the orchestrator) is the sole authority for declaring work done — the performing terminal never auto-completes its own PR.

Flow:

FEATURE_PLAN.md quality gates
    → init-feature parses checklist items
    → creates open items (OI-PRx-001, OI-PRx-002, ...)
    → terminal executes work, receipt records evidence
    → T0 reviews evidence, closes satisfied items
    → all blockers/warns closed → PR complete

This means every quality gate item you write will be individually tracked. Write them to be:

• Specific: "All 405 tests pass" not "Tests pass"
• Measurable: Include numbers, thresholds, or binary criteria
• Verifiable: T0 must be able to evaluate evidence against the criterion

Quality Gate Severity Classification

Items are auto-classified by init-feature based on keywords:

Severity	Keywords	Example
blocker	"all tests pass", "E2E", "100%", "test suite passes"	- [ ] All tests pass
warn	"memory", "zombie", "regression", ">=", "shutdown", "speed"	- [ ] Memory profiling: no regression
info	Default (anything else)	- [ ] Dashboard shows accurate data

Rule of thumb: If a failing item should block the PR, make sure its wording triggers blocker classification.

FEATURE_PLAN.md Format (Required)

Every FEATURE_PLAN.md MUST follow this structure for init-feature to parse correctly:

# Feature: [Feature Name]

## PR-1: [PR Title]
**Track**: A
**Priority**: P1
**Complexity**: Medium
**Risk**: Low
**Skill**: @backend-developer
**Estimated Time**: 2-3 hours
**Dependencies**: []

### Description
[What this PR does]

### Scope
- File changes listed here

### Success Criteria
- Criterion 1
- Criterion 2

### Quality Gate
`gate_pr1_descriptive_name`:
- [ ] All tests pass
- [ ] Specific measurable criterion
- [ ] Another verifiable criterion

---

## PR-2: [Next PR Title]
**Dependencies**: [PR-1]
...

Critical Format Rules

1. PR headers: Must be ## PR-X: Title (exactly this format)
2. Metadata fields: Use **Field**: Value format (bold markdown)
3. Dependencies: Use [PR-1, PR-2] array format, [] for none
4. Quality Gate section: Must be ### Quality Gate followed by backtick gate name
5. Checklist items: Must use - [ ] format (markdown checkboxes)
6. PR separator: Use --- between PRs
7. Gate name: Use backtick format `gate_prX_descriptive_name`

What init-feature Does

When T0 runs python3 pr_queue_manager.py init-feature FEATURE_PLAN.md:

1. Parses ALL PR sections from the plan
2. Creates staging dispatches (one per PR) in .vnx-data/dispatches/staging/
3. Creates open items from quality gate checklist items (one OI per item)
4. T0 reviews staging dispatches and promotes when ready

Examples

• /planner Create authentication system plan
• "Use planner skill to break down the refactoring"
• "Generate FEATURE_PLAN for the API redesign"

PR Size Guidelines

Target Range: 150-300 lines per PR

How to estimate:

• Count modified/created files
• Estimate lines per file (implementation + tests)
• Include documentation updates
• Add 10% buffer for edge cases

If PR exceeds 300 lines: Split into smaller, logical PRs If PR below 150 lines: Combine with related work

Skill Assignment

Available skills (use with @ prefix in FEATURE_PLAN, without @ in dispatches):

• @backend-developer - Python/API implementation
• @api-developer - REST API endpoints
• @frontend-developer - UI components
• @test-engineer - Testing infrastructure
• @quality-engineer - Quality assurance and validation
• @debugger - Issue investigation
• @reviewer - Code review
• @architect - System design
• @security-engineer - Security hardening
• @performance-profiler - Performance analysis
• @python-optimizer - Code optimization
• @supabase-expert - Database optimization
• @data-analyst - Data analysis
• @monitoring-specialist - Monitoring setup

Key Principles

1. Small PRs: 150-300 lines for fast review cycles
2. Clear Dependencies: Explicit prerequisite mapping (acyclic)
3. Skill Alignment: Right expertise for each PR
4. Size Validation: Estimate and verify line counts
5. Quality Gates as Deliverables: Every checklist item becomes a tracked open item
6. Specific & Measurable: Quality criteria must be evaluable by T0

Output Instructions

See template.md for report format and output location.

Intelligence Access

Use scripts/intelligence.sh for accessing VNX intelligence patterns and solutions.

---

Skill Activation Announcement

MANDATORY — first line of every response after skill load:

🔧 Skill actief: planner

No exceptions. This must appear before any other content.