Feature Planning

Focused planning skill for ONE specific task the user has in mind. Starts narrow at user's focus point, expands outward only as needed.

Pattern: Narrow→Broad (start focused, expand as needed)

🚨 PLANNING ONLY - NO IMPLEMENTATION This skill creates ONE task file. It does NOT write code or start implementation.

Use /discover-tasks instead for bulk backlog generation (broad→narrow pattern).

When to Use This Skill

Use this skill when:

• User has a specific idea: "I want to fix X" or "Add feature Y"
• Working on ONE focused task
• Running /new-task slash command

DO NOT use this skill for:

• Bulk backlog generation → use backlog-scan skill
• Finding ALL gaps in codebase → use backlog-scan skill
• Implementing tasks → this skill only plans

Context Loading (Area-Specific)

Load ONLY context relevant to user's focus area:

┌─────────────────────────────────┐
│        CONTEXT LOADING          │
│  • AREA rules only              │
│  • AREA done/ tasks only        │
│  • RELEVANT skill detection     │
└─────────────────────────────────┘

Step 1: Identify Area

Based on user's input, determine area:

• frontend - UI, pages, components, CSS
• backend - API routes, services, database
• components - shared component library
• e2e - tests

Step 2: Load Area Rules

.claude/rules/{area}/

Only load rules for identified area. Don't load everything.

Step 3: Check Area Done Tasks

Scan .task-board/done/ for tasks related to this area:

• Recent patterns
• How similar work was done
• Quality standards

Step 4: Detect Implementation Skill

Based on task type, note which skill to use:

Research Pattern: Narrow→Broad

Start at user's specific point, expand ONLY when necessary:

User's focus (component, file, screenshot)
           ↓
Direct dependencies (imports, props, CSS)
           ↓
Related components (siblings, parent)
           ↓
Broader patterns (design system, architecture)
           ↓
STOP when you have enough context

Example: "Column width in last column"

1. Start: SpreadsheetTable component
2. Check: Component CSS, props, column logic
3. Maybe: Related table components
4. Only if needed: Design system tokens
5. STOP: Don't scan entire frontend

Key Principle

Only expand when necessary. Don't:

• Read CLAUDE.md entirely (only relevant sections)
• Scan all features
• Load all rules
• Check all done tasks

Workflow

Phase 1: Ask User

What do you want to work on?

STOP and wait for response.

Phase 2: Context Loading

1. Identify area from user's response
2. Load area-specific rules
3. Check related done/ tasks
4. Detect implementation skill

Phase 3: Focused Research

Research outward from user's starting point:

1. Read the specific file/component mentioned
2. Check direct dependencies
3. Expand only if needed for understanding
4. Stop when context is sufficient

Phase 4: Propose Task

Present focused proposal:

**Proposed Task:** [Clear title]
**Type:** FEATURE / BUG / REFACTOR
**Why:** [1-2 sentences]
**Scope:**
- Includes: [what's in]
- Excludes: [what's out]
**Skill:** [frontend-design / node-backend / none]

Create this task?

STOP and wait for approval.

Phase 5: Delegate to task-board

If approved, invoke task-board skill with:

• Task title and type
• Research findings (files, patterns)
• Scope boundaries
• Implementation skill to use

Phase 6: End

After task-board creates the file, output exactly:

✓ Task created: [filename]

Ready in backlog. To implement, use `start-working` skill or ask directly.

Then STOP. Do not:

• Offer to implement
• Ask follow-up questions
• Suggest next steps

The user will initiate the next action.

Rules

• ONE task at a time
• Ask before researching
• Ask before creating
• Start narrow, expand only as needed
• Load area rules BEFORE researching
• Note implementation skill for task file

Delegates To

• task-board skill - for detailed plan file creation

See Also

• backlog-scan skill - for bulk discovery (broad→narrow)
• .claude/rules/ - domain rules by area
• .task-board/done/ - completed task patterns