Describe and review a change

#Start a change

1. Click the change bar at the top of any screen, or press ⌘ K (Ctrl K on Windows and Linux).
2. Type one sentence: what should change, and why.
3. Press Enter.

Babbit opens the change at its brief. You can leave right away; the change works without you and tells you when it needs you.

#Write a good sentence

A good sentence names an outcome someone could check. It doesn't need to be long or technical.

One sentence can hold several independent asks. The brief splits them into separate changes, so each one is reviewed and shipped on its own.

#Read the change screen

From top to bottom, the change screen shows:

1. The title and your request in one line. If an outside agent or a push wrote the change, its writer is named here.
2. The state card: a light, a phrase saying where the change stands, how long it has been there, and the one action it needs, if any. See The state card.
3. The steps: Asked, Approved, Built, Verified and Live, each with its time.
4. Three tabs: Lines, Proof and Activity.

The change opens on the tab that matters for its stage: Lines until you approve, Activity while it's being built or waits, and Proof from verification on, or when it failed.

#Answer what the change needs

If the change needs something only a person can give, the state card reads Needs you and the Lines tab shows each gate. Gates are asked once, together, before the work they block.

• For a key, paste the value in the gate's field. It's sealed into Secrets for that tier and never shown again. Never paste a secret into the change bar or a chat; see Answer a key gate.
• For a sign-in, click the link and complete the sign-in. Babbit completes it through its own callback.
• For a question from the agent, answer in one line.
• For "already does this", confirm the product already behaves this way, or send the change back to be built.

When you answer, the change continues on its own.

#Review the lines

When the proposals are ready, the state card offers Approve all. The Lines tab shows the brief, then every proposed line as an object diff: the line as it is now and as the change wants it, with what it affects underneath.

1. Read each line.
2. For a line you don't accept, click Reject and write one sentence about what's wrong. The sentence goes back to the agent.
3. Click Approve all to approve every line you didn't reject. To approve lines one at a time instead, click Approve on each.

A decided line shows who decided it and when.

#Lines that need more than a yes

• A line that contradicts a goal says so in one line, with the goal's words on hover. Approving it edits the goal.
• Two changes editing the same line meet in the proposal: the line as it is now, as the other change wants it, and as this one does. Choose Keep theirs, Keep mine or Keep both. Approve all approves the rest and leaves that line waiting.
• A new feature says where it goes. If Babbit isn't sure, the line asks you to pick a place before it can be approved.
• Comments. If the change touches something people commented on, the brief says so, such as reads 1 comment. A line that answers a comment says resolves 1, and approving it resolves the comment.

#What your approval means

Your approval is bound to the content of the lines you approved and where each one points, not to a commit. If the spec branch is re-rendered onto a newer main, your approval still holds. If someone edits a line on GitHub after you approved, or moves a proposal to another goal, the change waits until it's approved again.

#Ask for something different

To send the whole change back, click Request changes and say what to change. The Product agent proposes again with your note, and you review the new lines.

#Follow the work

After you approve, the Activity tab shows what's happening:

• Events in plain words: approved, pull requests opened, tests failed, sent back, verified.
• Code Writing's run: each spec item it's working on and its state. A long run shows how many items have passed, such as 4/5, and its stop rule's limits as a meter.
• The agents' chat, with each tool step folded until you open it.
• Details: the brief, which agent and model ran, the pull requests, the release, the jobs and the tokens used.

You don't need to watch. The bell tells you when the change is your turn again. What sends a change back on its own is in When a change goes back.

#Read the proof

From verification on, the Proof tab shows only the lines this change touched:

• Each line with its light: passed, failed, flaky or not verified.
• For a failure, the test's output.
• For anything visible, the app before and after the change, side by side, as screenshots or a short video.

Every other line in the touched features is summarized as one count. To see touched features' lines that have no test, open the untested list.

#Merge and release

When every scenario has its evidence, the state card offers Merge & release. See Land and release a change.

#Cancel a change

1. On the change, click Cancel.

2. Confirm.

   Cancelling ends its workspaces. Nothing it proposed is written to the spec, and its pull requests close without merging.

#Related

• Changes: what a change is, in depth.
• Evidence and verification: the rules behind the Proof tab.