use-case-designlisted

## Already-designed use cases !`find "${CLAUDE_PROJECT_DIR:-.}/docs/use-cases" -mindepth 1 -maxdepth 1 -type d -name 'UC-*' 2>/dev/null | sort | tail -5` Empty above → none yet, this will be `UC-001`. (`find`, not an `ls` glob: under zsh an unmatched glob aborts the command before any fallback runs.) ## Request $ARGUMENTS --- # Use Case Design Produces the use case's **parent spec**: the boundary, the flow, and the canonical names every layer inherits. Writes no code. Chooses no technology. **Entry rule: one use case, one side effect.** Before any question, apply the boundary test from `references/scope-boundary.md`. A request with two side effects and no shared transaction isn't one use case — it's two, and the right answer is to propose the split, not design the hybrid. **Vocabulary rule: technical input or nothing.** The request names the concrete trigger (endpoint, topic, job, schedule) and the concrete destination (table, queue, service). A request in business language — "when a user is created in the marketing area" — doesn't get guessed at: stop and ask for a rewrite, listing the expected vocabulary. ## How it's invoked Two ways, and both matter: `/use-case-design` by hand, or chained by `/new-feature` once that orchestrator exists. That's why it does **not** carry `disable-model-invocation` — that field hides the skill from the model, and a skill the model can't see is a skill the orchestrator can't call. It's the first piece in the pipeline: it has no pri