brief

# Brief Create a brief under `design-specs/briefs/<name>/` from the idea in `$ARGUMENTS`. ## Before you start 1. Find the work folder: the folder this session works in (in Cowork, the folder attached to the project or session). If there are several, use the one that contains `design-specs/`. If none does, ask the designer which folder is the work folder. 2. Note whether this is a cloud session: the environment or the designer says so, and the session works on its own copy of the files, not on the designer's local folder. 3. If `design-specs/rules/` does not exist, ask with `AskUserQuestion`: "I can't find this project's design rules (design-specs/rules). Was sdd-design set up for this project before?" Options: "Yes, it was set up before" and "No, this is a new project". - **Yes**: explain how to give Claude access to the folder, then stop without creating any file: - Cowork session on the computer: open the Cowork Project that has the work folder, or add the work folder to this session. - Cowork cloud session: attach the whole `design-specs` folder to this session. - Claude Code: start Claude in the work folder. - **No**: run the `sdd-design:setup` skill first, then continue here. 4. Whenever you create `design-specs/` or write a file under it, make sure `design-specs/.gitignore` exists and contains `*`, so git ignores the whole folder. ## Steps 1. Derive a short kebab-case `<name>` from `$ARGUMENTS` (e.g. "pricing page" → `pricing-page`). If `$ARGUMENTS` is empty, ask the designer what the work is. 2. If `design-specs/briefs/<name>/` already exists, tell the designer and ask whether to continue that brief instead. If `design-specs/archive/<name>/` exists, tell the designer that a finished brief already has this name and ask for another one, suggesting `<name>-2`. 3. Read `${CLAUDE_SKILL_DIR}/templates/brief.md`, `${CLAUDE_SKILL_DIR}/templates/checklist.md`, and `${CLAUDE_SKILL_DIR}/templates/rule-changes.md` to see the expected shape. Fill them with real content. Do not copy their placeholder text. 4. Gather context: - Read every file in `design-specs/rules/`. - Read the related notes in `design-specs/notes/`. Ask the designer which ones apply if it is not clear. - Read the references the designer gives: Figma frames (through the Figma tools), images, files. 5. Before writing, resolve every real fork — output type, output location, scope, a choice the rules do not settle — with `AskUserQuestion`. List the recommended option first, marked "(Recommended)", plus up to three real alternatives. Record each answer under `## Decisions` in `brief.md`. 6. Write the files: - `brief.md`: - `Status: in-progress`, today as `Started:`, and `Review rounds: 3` unless the designer asks for another number. - Goal, audience, references, and output type and location. The default location for files is `<work-folder>/<name>/`. For Figma output, give the file and frame links. The location is never inside `design-specs/`. If the designer asks for that, explain that git ignores that folder and wrap-up moves it, and use the default. - Acceptance criteria. Each has an `AC-` ID, a class (`measurable`, `visual`, `judgment`), and the rule IDs it relies on, including the `NEW-` IDs of proposed rules in `rule-changes.md`. Measurable criteria give exact values (colors, sizes, ratios). Visual criteria name the reference to compare against. Use `judgment` only for what only the designer can decide. - `checklist.md`: the deliverables as small checkboxes, in a sensible order. - `rule-changes.md`: only if the brief introduces a reusable pattern that the rules do not cover yet. Give each entry the next temporary ID: `NEW-01`, `NEW-02`, and so on. - Copy the images and files the designer supplied into `references/` and list them in `brief.md`. Link notes by their path. 7. Do not produce design output in this step. 8. Do the steps in **Finish**. 9. Summarize the brief in a few plain lines and suggest `/sdd-design:make <name>`. ## Finish If this skill created, changed, moved, or deleted files: - Show a "Files changed" list: one line per file, the path relative to the work folder, and what happened (created, updated, moved, removed). - In a cloud session, add in plain words: these files live in this cloud session, not on the designer's computer yet. To keep them, save each listed file to the same path in the local work folder (for example, from the session's Files pane) before the session ends. For each moved or removed file, also tell them to move or delete the local original at the same path, so the local folder matches.