home / skills / jjuidev / jss / planning

planning skill

/.claude/skills/planning

This skill helps you craft detailed technical implementation plans, roadmaps, and architectures from research to documentation, ensuring clear, actionable

npx playbooks add skill jjuidev/jss --skill planning

Review the files below or copy the command above to add this skill to your agents.

Files (6)
SKILL.md
4.4 KB
---
name: planning
description: Plan implementations, design architectures, create technical roadmaps with detailed phases. Use for feature planning, system design, solution architecture, implementation strategy, phase documentation.
license: MIT
---

# Planning

Create detailed technical implementation plans through research, codebase analysis, solution design, and comprehensive documentation.

## When to Use

Use this skill when:
- Planning new feature implementations
- Architecting system designs
- Evaluating technical approaches
- Creating implementation roadmaps
- Breaking down complex requirements
- Assessing technical trade-offs

## Core Responsibilities & Rules

Always honoring **YAGNI**, **KISS**, and **DRY** principles.
**Be honest, be brutal, straight to the point, and be concise.**

### 1. Research & Analysis
Load: `references/research-phase.md`
**Skip if:** Provided with researcher reports

### 2. Codebase Understanding
Load: `references/codebase-understanding.md`
**Skip if:** Provided with scout reports

### 3. Solution Design
Load: `references/solution-design.md`

### 4. Plan Creation & Organization
Load: `references/plan-organization.md`

### 5. Task Breakdown & Output Standards
Load: `references/output-standards.md`

## Workflow Process

1. **Initial Analysis** → Read codebase docs, understand context
2. **Research Phase** → Spawn researchers, investigate approaches
3. **Synthesis** → Analyze reports, identify optimal solution
4. **Design Phase** → Create architecture, implementation design
5. **Plan Documentation** → Write comprehensive plan
6. **Review & Refine** → Ensure completeness, clarity, actionability

## Output Requirements

- DO NOT implement code - only create plans
- Respond with plan file path and summary
- Ensure self-contained plans with necessary context
- Include code snippets/pseudocode when clarifying
- Provide multiple options with trade-offs when appropriate
- Fully respect the `./docs/development-rules.md` file.

## Task Integration (Optional)

When session has `CLAUDE_CODE_TASK_LIST_ID` set (active plan):
- Use TaskCreate to create tasks for each phase with clear subjects
- Set dependencies: Phase N+1 `blockedBy` Phase N
- Subagents coordinate via shared task list automatically
- Use TaskUpdate to mark progress (in_progress → completed)

### Important
DO NOT create plans or reports in USER directory.
ALWAYS create plans or reports in CURRENT WORKING PROJECT DIRECTORY.

**Plan Directory Structure**
IN CURRENT WORKING PROJECT DIRECTORY:
```
plans/
└── {date}-plan-name/
    ├── research/
    │   ├── researcher-XX-report.md
    │   └── ...
    ├── reports/
    │   ├── XX-report.md
    │   └── ...
    ├── scout/
    │   ├── scout-XX-report.md
    │   └── ...
    ├── plan.md
    ├── phase-XX-phase-name-here.md
    └── ...
```

## Active Plan State

Prevents version proliferation by tracking current working plan via session state.

### Active vs Suggested Plans

Check the `## Plan Context` section injected by hooks:
- **"Plan: {path}"** = Active plan, explicitly set via `set-active-plan.cjs` - use for reports
- **"Suggested: {path}"** = Branch-matched, hint only - do NOT auto-use
- **"Plan: none"** = No active plan

### Rules

1. **If "Plan:" shows a path**: Ask "Continue with existing plan? [Y/n]"
2. **If "Suggested:" shows a path**: Inform user, ask if they want to activate or create new
3. **If "Plan: none"**: Create new plan using naming from `## Naming` section
4. **Update on create**: Run `node .claude/scripts/set-active-plan.cjs {plan-dir}`

### Report Output Location

All agents writing reports MUST:
1. Check `## Naming` section injected by hooks for the computed naming pattern
2. Active plans use plan-specific reports path
3. Suggested plans use default reports path (not plan folder)

### Important
DO NOT create plans or reports in USER directory.
ALWAYS create plans or reports in CURRENT WORKING PROJECT DIRECTORY.

**Important:** Suggested plans do NOT get plan-specific reports - this prevents pollution of old plan folders.

## Quality Standards

- Be thorough and specific
- Consider long-term maintainability
- Research thoroughly when uncertain
- Address security and performance concerns
- Make plans detailed enough for junior developers
- Validate against existing codebase patterns

**Remember:** Plan quality determines implementation success. Be comprehensive and consider all solution aspects.

Overview

This skill creates detailed technical implementation plans, architecture designs, and phased roadmaps tailored to a codebase and product requirement. It produces self-contained plan folders with context, trade-offs, and actionable phase tasks while honoring YAGNI, KISS, and DRY principles. I am concise, honest, and focused on producing actionable plans rather than implementation.

How this skill works

I analyze the codebase and any researcher/scout reports, run targeted research when needed, synthesize options, and produce a structured plan in the project's plans/ directory. Each plan includes research, reports, phase documents, a main plan.md, and task breakdowns; I provide code snippets or pseudocode only to clarify design decisions. When an active plan is present I confirm continuation; otherwise I create a new dated plan folder and set it active.

When to use it

  • Planning a new feature from requirements to release
  • Designing or refactoring system architecture
  • Creating a multi-phase implementation roadmap
  • Evaluating multiple technical approaches and trade-offs
  • Breaking down complex requirements into developer-ready tasks

Best practices

  • Always prefer simplest solution that satisfies requirements (KISS, YAGNI)
  • Document assumptions, constraints, and acceptance criteria up front
  • Provide 2–3 viable options with clear trade-offs and recommended choice
  • Produce phase-level tasks with dependencies and clear deliverables
  • Keep plans self-contained in plans/{date}-plan-name/ and avoid user dir

Example use cases

  • Produce a phased plan to add a payment gateway with rollback strategy
  • Architect a microservice split with data migration and cutover plan
  • Create an implementation roadmap for a major UI rewrite
  • Assess database sharding options with performance and operational trade-offs
  • Break a large requirement into sprint-ready tasks and acceptance tests

FAQ

What output files will I get?

A plans/{date}-plan-name/ folder containing plan.md, phase-XX files, research/ and reports/ subfolders, plus any pseudocode or diagrams needed for clarity.

Do you implement code or modify the repo?

No. I only create plans and documentation. I will never implement code. I follow the project's development rules and create artifacts in the current working project directory.

How do you handle active plans?

If an active plan exists I ask to continue. If none exists I create a new plan and set it active per the workspace hooks. I never write plans to the user directory.