Review change requests

After the first release, coding agents still write through the CLI or MCP — but those writes no longer land in the live workspace. They become a change request you review in OriginAI. You apply what you want, dismiss what you don't (with a reason), then publish so the next implementation starts from a new snapshot.

Your own edits in the workbench still save directly. Change requests are the return path from agents (and from GitHub App spec findings), not a second copy of the file tree.

Why they exist

Coding agents read the latest published release, not the specs you're mid-edit. A direct write from that stale snapshot would overwrite work you haven't published yet.

Staging keeps authorship with you. When a write returns suggested: true, that is success — the request is waiting under Change requests, not a permission error.

Open Change requests

1. Open the project.
2. Select Change requests in the project tabs. A count on the tab is how many open requests still have documents to apply.
3. Open a row to review it.

The empty state is expected until an agent (or GitHub review) proposes something. Workbench edits never appear here.

A first-time banner explains the same thing: a request is waiting for you to apply or dismiss.

Review a request

Each request is one proposed set of document changes, not a branch.

You can also Review on canvas to walk the proposed screens in the workbench, the same way you inspect a live file.

Apply or dismiss

Nothing from a change request reaches the live specs until you apply it.

1. Open the request.
2. Review the documents you care about.
3. Apply all, or apply one document at a time.
4. If a document is an older version, either skip it, edit the live file yourself, or Apply anyway if the proposed body is still what you want.
5. To reject the rest of the set, Close it and write a reason. Pending documents are dismissed; the next agent reads that reason before proposing again.

Closing needs a reason on purpose. list-proposals returns dismiss_reason on decided items, so an agent can learn instead of re-proposing the same change.

Apply writes the workspace. It does not publish. Publish a release when the specs are ready for implementation.

What the agent does

You don't have to run these commands yourself — the OriginAI skill already describes the loop. This is the contract you're reviewing:

npx originai list-proposals --status all   # read dismiss reasons before writing again
npx originai write-document --name "…" --content "…"
# first staged write creates the Change Request (suggested: true + proposal_id)
# there is no create_change_request command
npx originai describe-proposal <id> --title "…" --note "…" --rationale "…"
npx originai submit-proposal <id>

write-document reuses the latest open request for that token unless the agent passes --proposal <id> or --new-proposal. Apply, dismiss, and recording a conclusion stay in OriginAI — agents never apply their own requests.

After you apply and publish, a repository can bind that request so the next pull request implements it:

npx originai get-proposal-diff <id> --bind
npx originai get-diff    # now: published release vs that change request
# implement the diff in code
npx originai sync        # after a new release hash exists

sync does not clear proposal_id until a new release hash exists. See the CLI for the full command list.

You're doing it right when…

• Agent writes after a release show up under Change requests, and the workspace is unchanged until you apply.
• You can apply, skip an older-version document, or close with a reason — and the next agent sees the reason.
• A published release is what coding agents implement; a change request is only a proposed next snapshot.
• You don't treat suggested: true as a failure.

Troubleshooting

Related

• Workspace vs release
• Publish a release
• Connect a coding agent
• GitHub App review
• OriginAI CLI