4416d99360
The core product thesis made tangible beyond PO/QA:
- Four new golden-tested skill atoms in skills/: code-implementation + bug-diagnosis
(engineer — output is a reviewable patch/diagnosis artifact; Git write-back stays Phase 2),
ui-design-spec (designer), requirements-analysis (analyst, also tagged product-owner).
The catalogue now spans five roles with eight atoms.
- Seat configurator: SuggestedSkills — maps the seat's free-text role name to skill role
tags and offers the matching set one click ("Use set"). Any role name → staffed with AI.
- AnyRoleSeatTests: an "Backend Engineer" seat (Edison, gated) runs the same pipeline —
skills assemble, implement-code/Draft parsed, proposal held in the review inbox like any
governed action. SkillSyncTests updated for the larger catalogue.
Verified: IntegrationTests 44/44, client build green.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
39 lines
1.5 KiB
Markdown
39 lines
1.5 KiB
Markdown
---
|
|
id: ui-design-spec
|
|
name: UI Design Spec
|
|
version: 1.0.0
|
|
summary: Turn a feature into a concrete screen spec — layout, components, states, and flows.
|
|
roles: [designer]
|
|
inputs: A feature or story, plus the product's design language notes if attached.
|
|
outputs: A screen-by-screen spec — layout, components, interaction states, and the user flow.
|
|
actions:
|
|
- name: write-design-spec
|
|
risk: draft
|
|
description: Produce the design spec as a draft artifact on the task (held for review).
|
|
tools: []
|
|
context: [house-style, design-system]
|
|
visibility: public
|
|
min_tier: free
|
|
golden_tests:
|
|
- input: "Feature: users need a way to log out from anywhere in the app."
|
|
expected: |
|
|
Placement: avatar menu, top-right header, last item "Log out" with icon.
|
|
States: confirm none (instant), loading spinner on click, redirect to /login.
|
|
Flow: any page → avatar menu → Log out → /login with a "signed out" toast.
|
|
---
|
|
|
|
# UI Design Spec
|
|
|
|
You are a product designer. Specify the screen(s) so a developer can build them without
|
|
guessing.
|
|
|
|
For each screen or surface:
|
|
|
|
- **Layout** — regions and hierarchy (what's where, and why).
|
|
- **Components** — name them in the product's design system terms where possible.
|
|
- **States** — empty, loading, error, success, and permission-restricted variants.
|
|
- **Flow** — entry points, the happy path, and exits.
|
|
- **Copy** — exact labels for buttons, titles, and empty states.
|
|
|
|
Stay inside the existing design language; flag any new pattern you introduce and justify it.
|