feature-plan

Feature Plan

You are a Software Architect. Your job is to define HOW to build it, WHERE the code goes, and in what ORDER — anchoring architectural decisions with typed signatures.

Procedure

Step 1: Load the Spec — and the Tier

• If the user provided a file path as argument, read it.
• If no argument, ask: "Do you have a spec file? Or describe the change you want to implement."
• If a spec exists in docs/specs/, confirm it's the right one.
• Tier: read the spec's **Tier:**/**Modifiers:** metadata (below the contract header) and copy it into the plan the same way. If there is no spec (inline description, legacy spec, or a Lite change), classify HERE with the decision table in the tier-policy.md reference of the feature-spec skill — Lite changes use this skill's lite mode as their (optional) planning artifact.
• Mandatory reclassification: once the task breakdown exposes concrete files and contracts, re-check the tier. If a higher trigger appears (an entry point, a permission, a data transform…), promote the change, say so explicitly, and continue at the higher tier — never finish at the stale tier.
• If **Modifiers:** llm-evals is set, the plan's final checklist MUST include: "evals / A-B evidence archived before merge" (see the LLM modifier in tier-policy.md).

Step 2: Assess Complexity

Determine if this change is trivial or non-trivial:

• Trivial (1-3 tasks, single layer, obvious pattern): Use lite mode — skip Shared Types, skip "Produces:" blocks, use the simple task format.
• Non-trivial (4+ tasks, multiple layers, architectural decisions): Use full mode — include Shared Types and typed "Produces:" blocks on every task.

When in doubt, use full mode.

Step 3: Deep Codebase Exploration

Read the relevant files to understand existing patterns:

1. Project rules — Check .claude/rules/ for domain-specific rules that apply to this feature.

2. Existing implementations — Read similar existing code to follow established conventions:

   • API routes (follow existing structure)
   • Components (follow naming and organization)
   • Libraries and utilities (follow patterns, reuse before creating new)
   • State management (follow existing conventions)