meta-featurelisted

## When to use - A ticket or request arrives fuzzy or ambiguous - You want to shape scope before committing engineering effort - You need to hand a brief to a teammate or back to the requester - You want to think through a feature before writing any code ## Procedure 1. Run `!`detect-stack.sh`` for context. Get the scratch directory: `!`scratch-dir.sh``. Some features make sense in one stack and not another. 2. Read $ARGUMENTS. If it points to a ticket file or URL string, read the file. Otherwise treat as the request. 3. Read project CLAUDE.md and any architecture docs. 4. Verify before writing. For any file path, module, or existing pattern that will land in Problem, Constraints, or Proposed approach, confirm it exists: read directly for a couple of files, or delegate to the scout agent when the request references code or architecture spanning more than a couple of files. Anything unconfirmed stays "unknown, ask requester" per the existing convention, never asserted. 5. Work through the questions below in order. Write the brief as you go. It is fine for a section to end with "unknown, ask requester" rather than a fabricated answer. ## Output Write to `$(scratch-dir.sh)/feature-<slug>-<YYYYMMDD-HHMM>.md`. Print the path. Structure: ``` # Feature brief: <title> ## Problem <Who has a problem, what problem, what is the current workaround if any. If the request describes a solution, extract the underlying problem.> ## Goal <One sentence. The outcome, not the implementa