forge-featurelisted

# forge-feature Add a feature to a project that already has its context files, the safe way. The risk when adding to a working build is breaking what exists; this skill keeps the new work scoped, ordered, and documented before any code is written. ## Argument Text after the command is the feature description (e.g. `/forge-feature export to CSV from the reports page`) — use it as the starting point for step 2 and only ask what it doesn't answer. No argument → ask what the feature is. ## Steps ### 1. Load current state Read `context/project-overview.md`, `context/architecture.md`, the build plan at `context/specs/00-build-plan.md`, and `context/progress-tracker.md`. Understand what already exists and what the invariants are. If there's no `context/` folder, tell the user to run `forge-init` first. ### 2. Clarify the feature Ask the user what the feature does, who it's for, and how it fits the existing product. Push back if it conflicts with anything in "Out of Scope" or with an invariant — surface the conflict and resolve it before continuing. ### 3. Update scope Add the feature to `project-overview.md` (Features + In Scope, and adjust Out of Scope if needed). If it introduces a real architectural change (new dependency, new boundary, new storage), update `architecture.md` too — and log the decision via `forge-decision`. ### 4. Decompose into units and place them in order Delegate to the `forge-architect` agent (opus-pinned): give it the clarified feature descriptio