make

# Make Make the work for a brief, review it, fix it, and get the designer's approval. ## 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/` does not exist, ask with `AskUserQuestion`: "I can't find this project's design-specs folder. 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**: stop and suggest `/sdd-design:brief <name>`. 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. Find the brief: - If `$ARGUMENTS` names a brief, use `design-specs/briefs/<name>/`. - Otherwise, infer it from the conversation or the most recently changed folder in `design-specs/briefs/`. - If it is not clear, list the briefs and ask the designer to pick one. - If `brief.md` does not exist, stop and suggest `/sdd-design:brief`. This skill never creates a brief. - If `brief.md` says `Status: approved`, set it to `Status: in-progress` before you change anything, and tell the designer that the brief will need their approval again. If the designer asked for a change, handle it as feedback (step 5) before the first round. 2. Read `brief.md`, `checklist.md`, `rule-changes.md` (if it exists), every file in `design-specs/rules/`, the linked notes, `references/`, and everything in `reviews/`. 3. Run a **cycle** of rounds. The cap is the brief's `Review rounds` value (3 if it is missing). Number review files in one sequence across all cycles: `review-01.md`, `review-02.md`, and so on. In each round: 1. **Make.** - In the first round of the first cycle, and of a cycle started to finish open checklist items, do the unchecked checklist items. - In the first round of a cycle after designer feedback, do the points in the latest `designer-NN.md`. - In later rounds, fix only the blocking findings of the last review. - Follow the rules and the brief. Put files at the brief's output location. For Figma output, work in the file the brief names. - Check off each checklist item when it is done. 2. **Review.** Do the steps in **Review**, with the review number (`NN`), the round number, and the cap. 3. **Save.** Write the report to `reviews/review-NN.md`, in the shape of `${CLAUDE_SKILL_DIR}/templates/review.md`. 4. **Exit.** If the report has no blocking findings, end the cycle. 5. **Early stop.** If a blocking finding cites the same criterion or rule, with the same problem as in the previous review, after you tried to fix it, end the cycle and note the repeated finding. 6. **Cap.** If this round reached the cap, end the cycle. 4. **Designer gate.** Show the designer, in plain words: - what was made, with paths or links (and screenshots, if available); - the result of each criterion: pass, fail, or needs-designer; - the open findings, with any repeated finding and any `rule changed` finding called out; - the needs-designer items they must judge. Then ask with `AskUserQuestion` whether they approve the work or have feedback. 5. **Feedback.** - Save the feedback to `reviews/designer-NN.md` (numbered from `01`), one point per line. - Map each point to an existing `AC-` ID, or add a new criterion to `brief.md` and map it there. - Add each new reusable pattern to `rule-changes.md` with the next `NEW-` ID, in the shape of `${CLAUDE_SKILL_DIR}/templates/rule-changes.md`. - Add or uncheck checklist items as needed. - Then run a new cycle (step 3) with a fresh round count. 6. **Approval.** - If checklist items are still unchecked, ask about each one with `AskUserQuestion`: finish it (run a new cycle, step 3) or drop it. Mark a dropped item `- [x] ~~<item>~~ (dropped by designer)`. - When no item is unchecked, set `Status: approved` in `brief.md`. 7. If making shows the brief is wrong (a flawed assumption, a missed case, a new fork), edit `brief.md` and keep going. Ask with `AskUserQuestion` about real forks, with the recommended option first, marked "(Recommended)". Tell the designer about every change that alters the scope. 8. Change only the output and this brief's files. 9. Do the steps in **Finish**. After approval, suggest `/sdd-design:wrap-up <name>`. ## Review You review the work you just made. Judge it as if someone else made it. ### Guards - Do not change the output, Figma content, or any file except the report until the report is saved. Do not run shell commands that write, move, or delete files. Use Figma tools only to read: screenshots, metadata, variables, styles. If something is wrong, write a finding. Fix it in the next round. - Before you capture evidence, read the acceptance criteria in `brief.md`, every rules file, and `rule-changes.md` (if it exists) again. Skip removed stubs (`## <ID> — removed <date>`). - Judge only what the evidence shows. Do not use what you meant to make or what you remember making. - Never `pass` without evidence. ### Steps 1. Collect evidence that fits the output type: - **Figma**: screenshots of the output frames; metadata (layers, sizes, spacing, auto layout); the variables and styles in use; library instances vs detached copies. - **Images**: view each image and compare it with the references. - **HTML**: render it with a browser tool if one is available and take screenshots. Read the source for exact values (colors, fonts, sizes, spacing). The source can prove measurable values only. Without a render, every visual criterion is `needs-designer`. - **Text or copy**: read it. Check voice rules, length limits, and terms. If an earlier review of this brief exists, capture new evidence only for the parts that changed since the last review. Also take one new overview capture of each output (a screenshot or render; for text, read it again) to catch side effects of a fix. For a part that did not change and shows no change in the overview, cite the earlier evidence as `unchanged since review-NN`. 2. Check each acceptance criterion, then each rule and each `NEW-` proposed rule that applies to the output: - If a `NEW-` entry edits or removes an existing rule, check the `NEW-` version and skip the rule it replaces. - **measurable**: compare exact values: hex colors, font family, size and weight, spacing on the scale, radii. Compute contrast ratios with the WCAG formula and show the numbers. - **visual**: compare with the named reference. Say what differs and where. - **judgment**: the result is always `needs-designer`. Add a one-line observation to help the designer decide. - If you cannot capture evidence for a criterion or rule, the result is `needs-designer`. 3. Write a finding for every `fail`: - Cite the `AC-`, rule, or `NEW-` ID. Severity is `blocking`. - Evidence: what you found vs what was expected, and where (frame or layer name, image region, file and line). - `Rule changed: yes` when the cited rule's `Changed:` date (or `Added:` date, if it was never changed) is after the brief's `Started:` date. This tells the designer the issue comes from a new rule, not a regression. Always `no` for `NEW-` IDs. 4. You may add a few `advisory` findings for issues no criterion or rule covers. Cite `none`. They never block. Keep them few and useful. 5. Whenever earlier reviews exist, say which findings of the previous review are fixed and which repeat. 6. Number the report with the review number. Be specific and short. No praise, no filler. ## 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.