agentleFS
rmstdopermstdope/cerebro/skills/agree-experience/SKILL.md

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.

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
  1. Very specific:

    Write it at every transition, in the same Bash call as the thing it describes, only through .cerebro/cerebro/scripts/agent-state, never by …

    line 22
  2. Very specific:

    Every question to the navigator is three actions: Write asking, ask, then write working as the very first thing you do with the answer, …

    line 40
  3. Very specific:

    You cannot see your own state file: Read it at the start of a pass and before ending one.

    line 50
  4. Distinctive:

    Mock the states, not the happy path: Put the empty and error states on the page.

    line 86
  5. Distinctive:

    Never branch in the main checkout: it moves someone else's HEAD.

    line 115
  6. Very specific:

    Only under .cerebro/worktrees/: bd and cargo find their configuration by walking up.

    line 123
  7. Distinctive:

    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 …

    line 164
  8. Distinctive:

    Never a word from this repository.

    line 191
  9. Distinctive:

    Read two of them:

    line 203
  10. Distinctive:

    Follow *Interview, don't ask*.

    line 236
  11. Distinctive:

    When you offer variants, recommend one: prefer an established industry-standard pattern for that interaction.

    line 238
  12. Distinctive:

    Show nothing and ask nothing: Check it is still yours, immediately before writing:

    line 274
  13. Very specific:

    Never design the build: no architecture, files, tests, increments, plan or design field.

    line 391
  14. Very specific:

    Never branch in the main checkout: commit a drawing from your own worktree under .cerebro/worktrees/.

    line 398

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

MomentCall
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 order

Interview, 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-branch

That 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>-mockup

Only 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 $PPID

open <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 saySay
bead, ticket, issuethis piece of work
mockup, HTML, artboarddrawing
the producer, the agentwhoever builds this / the person building it
commit, branch, pull request, worktree, the boardnothing at all — it is not mentioned
label, field, statusfiled / recorded
the navigatorthe team
userwhatever 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 it

Opening 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 mockup

Show 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 push

Quoted: 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 failedWhat you say
bd update or bd dolt push refusedthe shared task list wouldn't accept the update
the drawing could not be committed or mergedthe drawing couldn't be saved
the piece of work is assigned to somebody elsesomebody 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 push

Both 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 $PPID

Say 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 design field.
  • 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.