Your design team. Type the name.

Wireframe a new screen

When the screen does not exist yet. The team writes two competing text wireframes: a quiet, minimal one and a dense, power-user one. They argue. You pick a direction before anyone opens Figma or writes code.

1. You describe the user, the job, and the stack.
2. The team maps the task so the wireframe is not decoration.
3. Noor drafts the simple path. Anuj drafts the expert path.
4. Arjun, Meera, Zara, and Priya pressure-test both.
5. You get two full text wireframes plus a synthesis — not a single “nice” mock.

Use /noor alone for a fast minimal sketch. Use /anuj alone when the user is an expert who needs density on day one.

Design, spec, then build

When you need more than a sketch. The producer path turns ideation into a DesignSpec — layout, tokens, components, and states — then waits for gates to pass before anyone implements.

1. Ideation produces two concepts, same as above.
2. A DesignSpec is written: what goes where, which tokens, which components, which empty/error/loading states.
3. Hard gates check design-system fit and information hierarchy.
4. If a gate fails, you get a blocker and a fix — not a pretty wrong file.
5. Implementation starts only when you approve build mode.

This is the path for a senior-designer handoff. The team prepares. You still sign.

Critique an existing design

When the screen already exists — in code, in Figma, or as a screenshot. The team does not compliment it. They score it, object, and return SHIP, REVISE, or BLOCK with the top three fixes.

1. Say what the user is trying to finish. Paste a URL, a file, or a frame.
2. A router picks the smallest useful set of specialists. Default is not “everyone.”
3. Ask for full when you want the complete chain.
4. Specialists raise objections with evidence. Agreement is earned.
5. You get a composite score, a hierarchy check, a verdict, and ranked fixes.

Do not use these commands when you want a wireframe. They review. They do not invent a new screen.

Review against a PRD or user story

When “does this look good?” is the wrong question. The story gate asks whether a real person can finish a real job, using your PRDs, Figma, and design system as ground — not vibes.

1. The team looks for PRDs, stories, and design-system files in the project.
2. It builds a task map: trigger, steps, decision, done.
3. It routes only the specialists that job needs.
4. Optional browser check confirms the live screen matches the claim.
5. Assess-only mode keeps implementation off until you ask.

Set visual direction

Two boards. A mood board is tagged links and a team debate. A UI image board is pictures of real shipped software: Zara goes out and finds 3–5 screens, then Arjun, Noor, Priya, and Meera vote. If they skip her picks, she goes back out with their reasons — up to three tries.

1. You name the job in one line (who uses it, what the screen is for).
2. Mood board: tagged URLs + design-system patterns. UI board: Zara actually browses live product screens — no fake AI comps.
3. On a UI board she writes steal / refuse / peak on each frame. She does not score her own picks.
4. The jury SHIPs, or sends her out again. After three rounds, you (or Raj) pick.
5. A board file is written into the project so you can inspect every pick.

Index the project before opinions

Kavi is not a critic. Kavi is the archivist. Run this once per repo so every later command reads your brand, PRDs, components, and past decisions — instead of inventing a generic app.

1. Kavi scans the repo: pages, tokens, components, research, stack.
2. It writes an Obsidian-compatible vault on your machine.
3. Optional: an LLM enriches the notes. Without keys, the draft vault still lands.
4. The knowledge bank syncs into this project’s local skills folder — not a global merge that entangles other vaults.
5. You can connect an existing vault. Use --global only when you deliberately want cross-project blending.

If you skip Kavi, the team still runs — it just guesses more. Ground first.

Run the team without paying for extra keys

The CLI can drive the same graph from the terminal. Default v2.0 mode plans on a strong model, then runs small chunks on cheap or free models — including local Ollama. If you set no keys at all, Devi asks your host IDE to voice each specialist. Slash commands do not pick a model — see how models are picked.

1. Start a run with a task in plain language.
2. A planner breaks the work into chunks. The planner stays strong on purpose.
3. Chunks go to local, free, or cheap models. Results merge into one verdict.
4. In host mode, pending prompts wait. Type /devi in Cursor or Claude. Continue the run.
5. Telemetry remembers which models actually worked for each chunk type.

Let the team learn — with your approval

Tell the system what landed and each persona’s score moves — up when the advice ships, down when it needed rework or missed. Devi leans on the personas that earn it. Patches are still proposed, never applied: nothing becomes canonical until you review it. Silent self-rewrite is not allowed.

1. The persona asks at the end of its note. Answer in plain language — yes, or no plus one sentence.
2. Works in chat, in the terminal, and on Claude Desktop — which has neither slash commands nor a shell. Optional: /share sends a redacted correction to the package.
3. Lessons come from rejected notes too — your correction is the most useful thing the team gets. Each is scored, de-duplicated, and tagged.
4. The system proposes patches. You see the diff.
5. You accept or reject. The team does not evolve in the dark.
6. Each persona’s score moves, and Devi leans on the ones that earn it. Check the board with scores — it shows why a persona fell, not just that it did.