brief

# Brief Clarify only missing product decisions: user, problem, scope, constraints and observable success. Do not repeat information already supplied or require a numeric business metric for a small usability change. Group related questions in plain prose; no start/proceed confirmations. -a/-s allow explicit assumptions, not invented certainty or external permissions. Write docs/brief/<slug>/brief.md and tasks.md from references/brief-template.md, never from a brief found in another project. Keep its frontmatter and structural headings Acceptance criteria, Success metrics, Out-of-scope, Boundary, Relevant Files and Tasks. Derive outcome tasks from acceptance criteria; do not inflate them into a fixed number of phases. One feature, one folder. Boundary names what this feature owns and what it must not touch, in two short lists of paths. It is what makes two briefs safe to run at the same time, so write it whenever the answer is knowable and leave it out rather than guess. It bounds the work, not the reader: it is not a file inventory. Mark ready only when the brief is complete; never implement automatically. At finalize (steps/step-04-finalize.md), record the Git `base` and `branch` when the directory is a repository, and offer one issue per task through the `issue` skill when `gh` is available; both are optional and a brief without them still ships. Render with scripts/render.py only for --html or an explicit request. No mandatory browser, commit, test run, or handoff menu...