review manages staged review sessions — structured workflows for triaging requirement changes, auditing specs, or verifying coverage. Each session is a persistent file in your workspace that tracks which items have been reviewed and which are still pending.
Session name rules
Session names may containA–Z, a–z, 0–9, ., _, and -. They must not start with .. Session files are stored at .xspec/reviews/<name>.json.
Comparisons against session names are byte-wise case-sensitive.
Subcommands
create
Create a new review session. You must specify exactly one strategy.string
required
The name for the new session. Must follow the session name rules above.
git-ref
Path-blocks strategy. Builds a review queue from requirements whose content changed since the given git ref, traced through the journal.
string
Built-in strategy name. Currently only
audit is supported, which queues every requirement node in the workspace for review.string
Coverage strategy. Builds the queue from uncovered required nodes in the named coverage profile.
list
List all review sessions in the workspace.status
Show summary counts for a session: total items, resolved, pending, and resolution breakdown.next
Print the next unresolved item in the session queue.flag
Emit the item as a JSON object instead of the human-readable format.
show
Print the full detail of a specific item by its item ID.split
Split one review item into multiple finer-grained items. Useful when a single queue entry covers more ground than can be reviewed in one step.resolve
Mark an item as reviewed with a resolution status and an optional note.string
required
Resolution status. Accepted values:
string
Optional free-text note to attach to the resolution record.
export
Export the full session as a JSON document. JSON is always emitted for this subcommand — no--json flag is needed.
Scripting with —json
Usereview next --json in a loop to process items programmatically:
Concurrency
review create, review resolve, and review split are mutating commands and are mutually exclusive per workspace. A second mutating command attempted while one is running exits immediately with code 2. Non-mutating subcommands (list, status, next, show, export) can run concurrently.