mc-ui-sprint

Files (1)

• SKILL.md

SKILL.md (first lines)

# UI sprint (with the human)

This is the part of the process where the human is present. Keep every message short and visual: show screens, not paragraphs.

1. **Scope.** List the release's (or epic's) screens and the navigation between them in one short message, e.g. `Sign-up → Tasks (empty) → New task → Tasks (filled)`. Ask the human to confirm or adjust. This is the only planning question. Then record each screen with `mc_screen`: its route, the stories and UX requirements it implements, and its mockups, and name it in the refs of the UI tickets that build it (`SCR-n`).
2. **Build the prototype** (you, or the UX and frontend agents via `/mc-start`):
   - real screens in the app's stack, running locally, on hard-coded fake data and a mock API client
   - add the feedback widget in development only: `<script src="http://127.0.0.1:4317/widget.js" defer></script>` (Next.js: in the root layout behind `process.env.NODE_ENV === 'development'`; Expo web: in `app/+html.tsx`)
   - use the integration ports (`npx madcompany env integration`) so HQ's Preview shows it
3. **Show it.** Tell the human to open HQ → Preview (or the app URL, or Expo Go on their phone), or a mockup in HQ → Library. They click **Comment** on any element, click on a mockup image, or **Sketch** (capture the screen and draw on it). Each comment lands on its screen and is either sent now or added to their review. Comments sent now: classify each (`mc_map_change` with `level` element, ux or story, and for ux or story what it amends or extends) before it's fixed. A submitted review: `/mc-review-feedback`, one plan for all of it, approved by the human. Fix in rounds and take screenshots after each round (`mc_attach` to the feedback tickets).
4. **Sign-off.** When the human approves:
   - log it: `mc_decide` titled `UI signed off: <release or epic>`, with links to the screenshots
   - record the session: run `/mc-minutes` (kind `ui-sprint`), so what the human asked for is in HQ → Library → Meetings
   - write the API contract the screens need to `docs/design/<area>/api.md` (OpenAPI, or a table of endpoints with request and response shapes) with `mc_design_write`, listing the backend and frontend agents as consumers
   - update the tickets: UI tickets now wire the real contract; backend tickets implement it. In UI-MVP mode that wiring is the next release (R2): plan it with `/mc-plan-release`
5. Hand over to the team with `/mc-start`. From here the human is only asked about decisions that are theirs.

For a release or epic **without UI** (MVP mode), don't run this. Build the thinnest end-to-end slice first, show it through an API explorer (Swagger UI) or a CLI run, and revise from the human's feedback.

From lokkrish/madcompany, MIT.

More from lokkrish/madcompany