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.** Start the `sdd-design:reviewer` agent. Give it only: - the paths of `brief.md`, `rule-changes.md` (if it exists), `design-specs/rules/`, `references/`, and the linked notes; - the output location or Figma links; - the paths of the earlier `review-*` and `designer-*` files; - the full text of `${CLAUDE_SKILL_DIR}/templates/review.md`, pasted into the prompt; - the review number (`NN`), the round number, and the cap. Do not give it your reasoning or a summary of what you did. 3. **Save.** Write the reviewer's report verbatim to `reviews/review-NN.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>`. ## 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.