feat: expand PRD design taste guidance for prototype generation

[milroc]

Summary

• Move baseline design taste guidance (Hierarchy, Form validation, Loading, Modals, Toasts, Empty states, Realistic density) from generate-initial-prototype into generate-prd, where the rules better belong with the brief.
• Expand generate-prd with new rules covering affordance, scannability, clarity, noise reduction, navigation scope, anti-patterns, and dark-pattern avoidance.
• Replace the prototype skill's deleted taste block with explicit guidance for new affordances: tooltips on click for unmocked CTAs and a shake animation to signal pending interactions, styled with the softlight design system accent color.
• Trim softlight SKILL.md to just the run_agent invocation.
• Bump softlight plugin version to 6.32.12 across .claude-plugin, .codex-plugin, and .cursor-plugin.

Test plan

• Run /softlight end-to-end and confirm the PRD reflects the expanded guidance.
• Confirm prototypes generated from a PRD demonstrate the new affordance/tooltip/shake behavior for unmocked CTAs.
• Verify all three plugin manifests pick up version 6.32.12.

[milroc]

Baseline Mock (PRD 1)

baseline.mov

RAG Manual Curation Mock (PRD 2)

RAG-inspiration-manually-curated.mov

Asked Claude to compare the two videos

Better mock: RAG-inspiration-manually-curated.mov.
Alignment: baseline.mov → PRD1 (the highly prescriptive spec). RAG-inspiration-manually-curated.mov → PRD2 (the inspiration-driven spec).
AI slop: baseline.mov.

Why baseline maps to PRD1
Baseline reads as a literal 1:1 render of PRD1 §4.1–§4.6:

Header chip "Requires admin approval" (amber), with header CTAs Edit in Claude and Request approval — verbatim PRD1 §4.2.
What changed as four collapsible cards in the exact order — Surfaces (3 changes) / Data (1 object · 11 fields) / Automations (2 items) / Permissions requested (2 items need approval). Pure PRD1 §4.3.
Expanded Permissions card with Read: / Write: / Cannot: rows and amber-tinted tokens on Opportunity.amount and Opportunity.discount_approved — that token-level tint is a PRD1-specific instruction.
Preview on a sample as an inline sandbox with the verbatim banner "Sandbox preview. No live data is changed. AI-generated content is labeled Preview output." and a right-edge "WOULD ALSO HAPPEN" strip — PRD1 §4.4 to the letter.
Two-column Roll out: segmented control Just me / A group / Everyone + filter builder on the left, Workspace policy column on the right with all six fixed check rows rendered (write scope, read scope, workflow side effects, MCP, new required fields, audience vs allowed) each with a Why? link. This is PRD1 §4.5 verbatim — including the rule that the policy column never collapses.
Sticky bottom action bar with status summary "1 item needs admin approval · Affects 12 reps" + Discard draft / Save as draft / Request approval. PRD1 §4.6.
Why RAG maps to PRD2
RAG reads as the inspirations PRD2 explicitly calls out, not as PRD2's prose itself:

Status-page flat per-row impact → five flat plain-language change rows with no row-level chips, no severity badges. Matches PRD2 §4.2.4's anti-chip rule.
Permission line: bold category + plain clarifier → permissions are pills like Read · Opportunity, Write · Mutual Action Plan, Write · Opportunity.stage (with the single amber dot only on the one that crosses policy). Same two-part typography idea PRD2 §4.2.5 specifies, just compressed to a pill row.
Single TL;DR strip → the right-side metadata stack (AFFECTED SURFACES, AFFECTED ROLES, AUTOMATIONS, DATA TOUCHED) is the "scope chips" idea from PRD2 §4.2.3.
Side effects with explicit Dry toggles beside each — directly expresses PRD2's "show side effects before they happen, clearly preview, no real writes."
Rollout collapses to a single sentence ("Rolling out to Enterprise AEs on Strategic Sales pipeline, opportunities ≥ $100k. Approx. 18 reps, 240 opportunities." + Edit) — the calm derived-line idea (PRD2 §4.2.6's "Estimated reach" sentence) instead of an open form.
Pending review / Send for admin approval — PRD2's two-state verdict (no Blocked).
Looks good → and Re-run simulation are editorial affordances that don't appear in either spec verbatim but reflect PRD2's spirit of "felt safety" over machinery.
The one place RAG diverges from PRD2's prescription: PRD2 mandated a full-screen sandbox modal with a persona switcher; RAG keeps the preview inline. That's a judgment call against PRD2's letter but in service of PRD2's principle (calmness, single-page).

Why baseline is the AI slop
Slop signature: dutifully rendering every clause of a prescriptive spec without compressing.

Renders all six policy check rows even when five are green — pure ceremony, none of the five change the user's next click. PRD1 said keep them all; a designer would have collapsed the "all-clear" ones.
The amber token-tint inside Write: and the segmented control + filter builder are both spec-driven density that the RAG mock side-steps with a single editable sentence.
Two parallel columns (Audience / Policy) plus a sticky bottom bar plus a permissions card plus a side strip in the preview → four simultaneous chrome elements. The page is loud.
No editorial signal: nothing was demoted, nothing was named beyond what the spec named, no novel affordance like Dry toggles or Looks good →.
RAG, by contrast, shows judgment calls: condensing the rollout, picking pills over a Read/Write/Cannot grid, treating side effects as a checklist with dry-run toggles, and using the right-rail metadata as a TL;DR. Those are choices a designer made, not a renderer.

Naive claude comparison between the two PRDs

Both PRDs solve the same problem (review + roll out an AI-built Twenty app) and even share much vocabulary, but they diverge on five structural choices:

Area	PRD1	PRD2
Preview location	Inline Section 2 on the same page, in a sandbox container with a blue banner	Dedicated full-screen modal with diagonal-stripe sandbox chrome
Whose view	One control: Sample opportunity	Two controls: Viewing as (rep persona) + Sample opportunity; fields hidden by visibility rules render as placeholders
Status taxonomy	3 states (Ready / Requires approval / Blocked)	2 states (Ready / Requires approval) — no separate Blocked
"What changed"	Four grouped collapsible cards by type (Surfaces / Data / Automations / Permissions), one open at a time	Flat list of change rows with per-row disclosure; row-level chips appear only when a row is a policy exception
Policy check	Persistent right column listing every check (trust artifact)	Collapsed into the verdict banner; only exception lines are listed
Permissions	Tucked inside the "Permissions requested" card; tokens get amber tints	Top-level section: each capability is one line, bold category + plain clarifier, with toggles
Audience	Segmented control (Just me / Group / Everyone) + CRM filter builder	Grid of MultiSelects (Pipeline / Team / Role / Territory / amount ≥) plus a Pilot duration field with auto-pause
Admin policy surface	Out of scope — only consumed	First-class spec for Settings → AI → Policy (Auto-deploy / Requires approval / Always blocked / Scoped)
Role vocabulary	Generic Team/Role filters	Reuses Twenty's existing role chips (Admin/Editor/Member/Viewer) inside the multi-select
Dev detail	"View JSON / View source" link at page bottom (tertiary)	View source ghost button in header, plus per-row disclosure into the existing dev detail view
Portions of PRD2 that drive the "Inspirations" section home
Each inspiration is reified in a specific, surfaceable design decision. These are the lines that earn the rationale at the bottom:

1. Test-email modal → sandbox framing

§4.3 entire modal: full-screen, top bar copy "Sandbox preview · No live data is written. Nothing is sent."
§4.3.1 diagonal --blue-05 stripe pattern at 8% opacity behind the simulated content
§4.3.2 AI agent output rendered with a Preview pill prepended to its heading
§4.3.2 mutate buttons remain visible but no-op with toast "Disabled in sandbox preview"
2. Email-block persona preview → persona switcher

§4.3.1 Viewing as: Maya Chen — Enterprise AE + Sample opportunity: Acme Corp — $250k in the modal top bar; switching either re-renders live
§4.3.2 fields hidden by visibility rules render as outlined empty boxes with helper text "Hidden by visibility rule"
3. Status-page flat per-row impact → calm flat list

§4.2.4 flat list of change rows, no nesting, no severity badges by default, default collapsed
§4.2.4 explicit rule: "No row shows a status chip unless that specific change is one of the policy-violating capabilities"
§4.6 density rule: "No section uses both a heading chip and row-level chips"
4. Permission line: bold category + plain clarifier

§4.2.5 typography spec: bold category "Opportunity data ·" (14/600) followed by plain clarifier "Read all fields on Opportunities in the Enterprise pipeline" (14/400)
§4.2.5 explicit anti-pattern: "Never display the raw scope object … That belongs in View source"
§4.2.5 locked-by-policy variant replaces the toggle with a Locked chip rather than building a matrix
5. Role chips reused

§4.2.6 Rollout Role field is a multi-select using existing role chips (Admin, Editor, Member, Viewer) so the visual matches the rest of Twenty
If you wanted to surface just the proof points for "inspirations actually changed the design," the strongest five are: the full-screen modal with stripe pattern (§4.3.1), the Viewing-as persona dropdown (§4.3.1), the flat no-chip Changes list (§4.2.4), the bold-category permission line (§4.2.5), and the role-chip multi-select (§4.2.6). Each maps 1:1 to a bullet at the bottom of PRD2 and is absent from PRD1.

prd2.md
prd1.md