to-featureslisted

# to-features Generate `FEATURES.md` at the repo root by reading `CONTEXT.md` and the ADRs under `docs/adr/`, then enumerating the user-facing features the domain implies. Pairs with `/grill-with-docs` (upstream, produces CONTEXT.md/ADRs) and `/to-prd` (downstream, takes one feature → PRD). ## When to invoke - After `/grill-with-docs` has produced or refined `CONTEXT.md`. - Before `/to-prd` runs on any individual feature. - If `FEATURES.md` already exists, treat this as a **refinement** — propose additions or strikethroughs based on the latest `CONTEXT.md` and ADRs. Never overwrite shipped (strikethrough) features. ## Process 1. **Read `CONTEXT.md`** for domain vocabulary, actors, and invariants. 2. **Read `docs/adr/*.md`** for architectural commitments that constrain what's buildable. 3. **Enumerate user-facing features** the domain implies: - One feature per line, kebab-case slug + one-line description. - Start with the actor: `user-can-…`, `admin-can-…`, `guest-can-…`. - **User-facing**, not internal — "User can reset password" not "Add bcrypt hashing." - Don't include implementation details — those land in PRDs downstream. 4. **Surface the list to the user** for review: - Anything missing? - Should any features be split or merged? - Are slugs unambiguous? 5. **Write `FEATURES.md`** at the repo root once approved. 6. (Optional, for local-markdown teams) `mkdir -p .scratch/<feature-slug>/issues` per pending feature to stub the layout downstream sta