plan-a-feature

Run the plan-a-feature skill with a one-to-two sentence feature description. It interviews you decision-by-decision in dependency order, resolves what it can from codebase evidence, and writes a behavioral feature-specification.md plus a decision log and findings log.

It produces feature-specification.md at the plan folder root, plus artifacts/decision-log.md, artifacts/team-findings.md, and artifacts/scope-boundary.md. A feature-technical-notes.md file is created only when a load-bearing mechanic qualifies, and a ui-designs folder holds any supplied visual material.

Use plan-a-feature to specify what a feature does, for whom, and why before any implementation planning. Use plan-implementation afterward to design how it gets built; implementation mechanics, library choices, and file-level detail are deliberately excluded from the feature spec.

No. The spec excludes language primitives, file paths, function names, and library mechanics, generalizing brand names one level up. Load-bearing mechanics that change observable behavior are captured separately in a lazily-created feature-technical-notes.md linked via T# references.

It applies a YAGNI evidence test to every commitment, demoting unsupported items to a Deferred section with reopening triggers. A scope gate checks commitments against the recorded work-item boundary and cuts anything the boundary excludes into a visible Cut for Scope section.

Yes. Pass a size argument of small, medium, large, or dynamic. Small caps the team at two agents, medium at three to four, and large at four to five; a config default-swarm-size value or an explicit user override also wins over signal-based classification.