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>
1.5 KiB
1.5 KiB
id, name, version, summary, roles, inputs, outputs, actions, tools, context, visibility, min_tier, golden_tests
| id | name | version | summary | roles | inputs | outputs | actions | tools | context | visibility | min_tier | golden_tests | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ui-design-spec | UI Design Spec | 1.0.0 | Turn a feature into a concrete screen spec — layout, components, states, and flows. |
|
A feature or story, plus the product's design language notes if attached. | A screen-by-screen spec — layout, components, interaction states, and the user flow. |
|
|
public | free |
|
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.