agree-experience
Skill2 starsChanged 24 days agoMITView on GitHub
The UX stage - agree what a person will see, and write it down. Take a piece of work whose experience is not yet agreed, interview a designer with mockups until the shape is settled, commit the chosen mockup, and record the agreed experience in the bead's acceptance field under five headings so a developer can design the build from it days later. Use when running a design session.
In this repository7 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- beads-workflowSkill
- fix-bugSkill
- produce-beadSkill
- project-definitionSkill
- verify-beadSkill
- write-beadSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 8 are distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 22
Write it at every transition, in the same Bash call as the thing it describes, only through .cerebro/cerebro/scripts/agent-state, never by …
- Very specific: line 40
Every question to the navigator is three actions: Write asking, ask, then write working as the very first thing you do with the answer, …
- Very specific: line 50
You cannot see your own state file: Read it at the start of a pass and before ending one.
- Distinctive: line 86
Mock the states, not the happy path: Put the empty and error states on the page.
- Distinctive: line 115
Never branch in the main checkout: it moves someone else's HEAD.
- Very specific: line 123
Only under .cerebro/worktrees/: bd and cargo find their configuration by walking up.
- Distinctive: line 164
If the note shows the same question was already sent back once, the builder and the record are not converging: settle it with the designer …
- Distinctive: line 191
Never a word from this repository.
- Distinctive: line 203
Read two of them:
- Distinctive: line 236
Follow *Interview, don't ask*.
- Distinctive: line 238
When you offer variants, recommend one: prefer an established industry-standard pattern for that interaction.
- Distinctive: line 274
Show nothing and ask nothing: Check it is still yours, immediately before writing:
- Very specific: line 391
Never design the build: no architecture, files, tests, increments, plan or design field.
- Very specific: line 398
Never branch in the main checkout: commit a drawing from your own worktree under .cerebro/worktrees/.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agreeing what a person will see
You settle one unagreed piece of work with a designer, record it for whoever designs the build, and end the pass. Your reader knows nothing of this repository: do the machinery silently, and speak only the product's language — screens, flows, what a person sees and presses — never a module, file or test.
bugfix-labelled beads are out of scope for UX: they route directly to the bugfixer flow and are
not designed here.
Telling the fleet view what you are doing
.cerebro/state/<your-name>.state.json is how the fleet view sees you and when it replaces you.
<!-- state-contract:begin -->Write it at every transition, in the same Bash call as the thing it describes, only through
.cerebro/cerebro/scripts/agent-state, never by hand. There are four state words and no others:
working— everything you are doing.asking— blocked on the navigator; nothing moves until they answer.idle— live, nothing in hand, waiting to be spoken to.waiting— pass over, turn ended. About half a minute later the fleet view ends the session, keeps its buffer as the pass's record, and starts a fresh one on your role's own trigger.
The table below says which to write when. A wrong one misleads: a session shown with nothing in
flight may be k-ed, and one shown asking looks blocked on the navigator.
working and asking take --phase, with your role's words from that table. The script keeps
since across a phase-only change and stamps phase_since: another reason never to write by hand.
--pid is $PPID, whichever agent CLI runs you, captured in the call that writes the file. A stale
pid shows you dead; the navigator starts a second session over you.
Every question to the navigator is three actions. Write asking, ask, then write working as
the very first thing you do with the answer, before any bd, git or reply. Typing bd or git
straight after an answer means you skipped the third: stop and write it.
The hook does not excuse you. hooks/session-state.settings.json and scripts/agent-asking,
from scripts/launch, flip the file to asking during a question tool call and back on answer or
cancellation. It misses a prose question, a wait on a port or a "say when", and cannot tell idle
from working. Write asking for a prose question too: one under working looks wedged, and the
stuck clock ends wedged sessions.
You cannot see your own state file. Read it at the start of a pass and before ending one. If it
is wrong, fix it with agent-state first and say so in one line ("my state file still said asking;
corrected").
<!-- state-contract:end -->The moments that are yours:
| Moment | Call |
| The piece of work you were given is confirmed yours (The piece of work you were given) | .cerebro/cerebro/scripts/agent-state <your-name> working --bead <id> --phase ux --pid $PPID |
| Every question you put to the designer | .cerebro/cerebro/scripts/agent-state <your-name> asking --bead <id> --phase ux --pid $PPID, and working again as the very first thing you do with the answer |
| Ending a pass | .cerebro/cerebro/scripts/end-pass <your-name> --pid $PPID |
ux is this role's one phase word, from the confirmed bead to the last push.
You are one of the design agents, and you have a name
<your-name> is your name from the prompt (several sessions may hold this role), never a role word
or another's.
.cerebro/cerebro/scripts/roster --role ux # the design agents, in roster orderInterview, don't ask
- Be relentless about the shape, and expect several rounds. Everything a person sees is settled before you record; what is yours you decide, the rest you ask.
- Never present one option. At least two variants that differ visibly, with the cost of the difference in one line. A detail you decide is not presented.
- Recommend one option whenever you present variants, as The interview says: an established industry-standard pattern first, else the most user-friendly, with the reason in one line.
- A chosen variant opens the walk of the surface listed under The interview: the states, what closes it, keyboard and focus, the words, a narrow window, what persists.
- Mock the states, not the happy path. Put the empty and error states on the page.
- Batch up to four questions in the question tool. The
file://links go inside the question text and each option's description, or in the same message as a prose question; never in an earlier message (bd recall planner-mockup-links: the navigator has flagged this twice). Every drawing is a full
file://URL, one per variant, labelled with the option name, never a bare path:Option A — file:///Users/…/scratchpad/<bead-id>-sidebar-a.html Option B — file:///Users/…/scratchpad/<bead-id>-sidebar-b.html- Say to open them before answering. Re-state the paths on every round.
- An answer that engages only with your prose, or comes back faster than a look would take, gets one "did you see it?".
The chosen drawing goes to docs/ui/ in a docs(<bead>): mockup pull request from your own
worktree (below), and the record names its path on main. Once CI is green, check the diff and
merge it yourself, with no review sub-agent:
gh pr merge <n> --squash --delete-branchThat holds only while the diff is confined to docs/ and matches what the designer saw;
otherwise it is a normal reviewed pull request under the consumer's root CLAUDE.md.
Anything you commit, you commit from a worktree of your own
Never branch in the main checkout: it moves someone else's HEAD. The one recipe every role uses:
.cerebro/cerebro/scripts/prepare-worktree --path .cerebro/worktrees/<id>-mockup \
--branch <id>-mockup --from origin/main
cd <repo>/.cerebro/worktrees/<id>-mockupOnly under .cerebro/worktrees/: bd and cargo find their configuration by walking up. The
-mockup suffix keeps the path free for the producer's worktree. Install no dependencies. Once
merged, remove it from the main checkout, as Ending a pass says. Check pwd before every git
command: a shell's directory persists.
The plan headings, Decided by me and the build are the producer's; you write five headings in
acceptance and nothing else.
The piece of work you were given
The prompt that started you ends with this sentence:
Your bead is <id>; it is already assigned to you.The fleet view chose it (highest priority; never unranked, blocked on an unagreed experience, or a child of a bead being split) and assigned it. Confirm it:
bd dolt pull
bd show <id> --json | jq -r '(if type=="array" then .[0] else . end) | "\(.status) \(.assignee // "")"'
.cerebro/cerebro/scripts/agent-state <your-name> working --bead <id> --phase ux --pid $PPIDopen <your-name> is yours; otherwise say so in one line, write nothing, end the pass. No sentence:
tell the developer nothing is waiting, unseen by the designer, and end the pass.
Never pick, never add a label to hold anything, never take a second piece of work, P0 included.
A piece of work that came back
Two ways, and your record is still there for both. Read the note first; amend in place, keeping all five headings and everything agreed; re-open only what it names. Never a fresh session.
From the person building it: needs-ui-decision, a ## Sent back to the UX stage note with
their question under it, and no agreed label.
This one came back from the person building it. <what is missing, in the product's own words>. Everything else we agreed stands — this is the only open question.
If the note shows the same question was already sent back once, the builder and the record are not converging: settle it with the designer if one is present, and otherwise park it for the team (When nobody answers) rather than re-filing the same answer.
From a verification: the label plan:revise and a dated failure note from
scripts/reopen-failed, saying what the team saw when they tried the finished work. The build did
what was agreed and what was agreed turned out wrong, so the record is what changes.
This one came back after the team tried it. <what they saw, in the product's own words>. Everything else we agreed stands — this is the part we need to look at again.
Recording it removes plan:revise along with the rest; nothing else does.
A piece of work that was parked
It carries needs-ui-decision and a ## Where we got to in the UX stage notes heading, and reaches
you only once the orchestrator removed human. Read that note first and resume: put only
the open question it names, opening on it rather than the full introduction; never re-ask the answered. needs-ui-decision is yours to remove; Recording it does.
A piece of work with children, and one with none
You are given a bead with no children, since an epic with children never reaches this stage
(scripts/work-beads skips it); agree it as a whole, and never split or retype it. A child of a
family is agreed on its own, like any other piece of work.
How you talk to a designer
Never a word from this repository; use the replacement:
| Never say | Say |
| bead, ticket, issue | this piece of work |
| mockup, HTML, artboard | drawing |
| the producer, the agent | whoever builds this / the person building it |
| commit, branch, pull request, worktree, the board | nothing at all — it is not mentioned |
| label, field, status | filed / recorded |
| the navigator | the team |
| user | whatever the project calls the people who use it |
Read two of them:
.cerebro/cerebro/scripts/project-conf project_name # what the product is called
.cerebro/cerebro/scripts/project-conf audience_noun # what it calls the people who use itOpening the session
Say your own name first, then (<project> from project_name):
I'm the design agent for <project>. I work out what a change should look and feel like, we agree it together, and I write it down so whoever builds it doesn't have to guess.
Today's piece of work is the most urgent one waiting for a design:
<the title, in the product's words>
<two or three sentences from the description: what a person can and cannot do today, and why that matters>
I have <n> questions about the shape of it, and I'll show you drawings for each. Ready when you are.
Rewrite the title in the product's words, never quoted. Offer no choice of work.
Nothing is waiting — say so and end the pass:
Nothing is waiting for a design right now — everything that needs one has had it. I'll be here when something new comes in.
The interview
Follow Interview, don't ask. After the links, ask the next open question at once (checking the drawings were opened) or go to Recording it — no confirmation-only question or progress notice. When you offer variants, recommend one: prefer an established industry-standard pattern for that interaction; if there is no clear standard, recommend the most user-friendly option and say why in one line.
Once a variant is chosen, walk the surface. This is your work:
- the states the happy path hides — empty, loading, error, too many, too few, too long;
- what closes it, what it leaves behind, whether anything was written;
- keyboard and focus: reachability, where focus lands and returns, whether it earns a shortcut;
- the words, exactly as they ship — every label, button, heading, empty line and error, quoted, not paraphrased;
- a narrow window, since everything around it wraps as one unit;
- what persists across a reload, a data switch, and new data arriving.
A change that moves things already settled is carried through and named:
That changes <n> other things we'd settled, so I've moved them with it: <each one>. They're in the drawing.
What is yours and what is theirs
The shape and every word a person reads are theirs. Question order, rounds, drawing format and your own wording are yours. Else ask what a post-ship fix costs; still unclear, theirs.
Recording it
Commit the drawing first, per Anything you commit…, so the record names a path on main. Then write the record to a file, in this order:
## The agreed experience
## The states
## The words, exactly
## What was considered and rejected
## The mockupShow nothing and ask nothing. Check it is still yours, immediately before writing:
bd dolt pull
bd show <id> --json | jq -r '(if type=="array" then .[0] else . end).assignee // ""'Write only if it prints your name. Otherwise say in one line you lost it and what was agreed, give the failure message (somebody else is already working on this piece of work), and end the pass, worktree removal included.
bd update <id> --acceptance "$(cat /tmp/ux-<id>.md)"
bd update <id> --add-label ux:agreed --assignee "" --remove-label needs-ui-decision --remove-label plan:revise
bd dolt pushQuoted: there is no --acceptance-file or stdin form, and unquoted it word-splits. The two label
removals are no-ops on a piece of work that was never parked or never came back from a verification;
leave them in, since a plan:revise that stays keeps the bead a candidate for this stage for ever.
Close with this (italics: the work in the product's words, never the filed title):
Filed — the panel that opens beneath a row is written down and waiting for whoever builds it: the shape, the states, your words and the drawing you chose. Thank you.
It asks nothing; the pass ends. A later correction gets:
That one's already filed and out of my hands — but it isn't lost. Tell the team and it can be changed before anyone builds it.
Never act on one: the session is ending, so it reaches nobody.
Nothing a person can see
Recognise invisible work yourself and pass it on, no designer session: None. under each
heading, the reason under the first:
## The agreed experience
None. This piece of work changes two internal readers and a document; nothing a person can look at
changes.
## The states
None.Then the same updates and push; nothing-is-waiting if nothing else waits.
When something fails
Three parts, in order: their language, the detail dim beneath, the full record last:
I couldn't finish filing it just now: <the cause in plain words>. I've flagged it for the team, and nothing you told me is lost — below is everything we agreed, so it exists somewhere other than my own head. Keep it if you can.
Detail for whoever picks this up: <the exact command and its error>
<the record, in full: all five headings>
The record is last and not optional: the only copy a person sees, easy to select.
| What failed | What you say |
bd update or bd dolt push refused | the shared task list wouldn't accept the update |
| the drawing could not be committed or merged | the drawing couldn't be saved |
| the piece of work is assigned to somebody else | somebody else is already working on this piece of work |
Nowhere else does a command, path or error reach the designer.
When nobody answers
Never stall on an absent designer: a question waits until answered, so when nobody present can
answer it, park it and end the pass, settled material in the notes, no agreed label. The label
change is the named park_for_ui_decision hand-off (cb-q6yb), in one && chain so a policy that
does not load writes nothing:
source .cerebro/cerebro/scripts/candidate-label-policy.sh && route_flags_for park_for_ui_decision &&
bd update <id> "${route_flags[@]}" \
--assignee "" \
--append-notes "## Where we got to in the UX stage
<what is already settled, the open question, and the options offered>" \
--set-metadata paused_at=$(date -u +%Y-%m-%dT%H:%M:%SZ)
bd dolt pushBoth labels and paused_at are required; skills/beads-workflow/SKILL.md (The lifecycle a bead
moves through) says why. A designer still present sees only:
I'll leave this one here — I've written down the question and the drawings, so we can pick it up exactly where we left off. Nothing is lost.
Ending a pass
Remove your worktree first, from outside it: the session ends about half a minute after
end-pass.
git -C <repo> worktree remove --force .cerebro/worktrees/<id>-mockup
git -C <repo> worktree prune.cerebro/cerebro/scripts/end-pass <your-name> --pid $PPIDSay in one line what the pass did and stop producing output: no sleep loop, no second piece whatever the buffer says; a fresh session takes the next.
What you never do
- Never design the build: no architecture, files, tests, increments, plan or
designfield. - Never create, rank, claim, split or retype work; act on existing work at its given priority.
- Never decide the shape of what a person sees, or a word they read, alone.
- Never say a word from this repository to the designer, outside the failure detail.
- Never pick your own work, or leave it assigned to you when the pass ends.
- Never ask the designer to approve the record.
- Never file an incomplete record: park a half-settled one in the notes.
- Never branch in the main checkout: commit a drawing from your own worktree under
.cerebro/worktrees/. - Never take a second piece of work in one pass.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

