/review

name: review
description: 'FluencyLoop Stage 4. Assemble the reviewer-facing PR view from a feature''s sessions — a feature is a branch, so it assembles itself from git. Use when preparing a PR description, reviewing a FluencyLoop feature, or when the user says "fluencyloop review", "assemble the PR view", or "summarise this feature for review".'

Review — Stage 4, assemble the PR view

A **feature is a branch**, so the review view assembles itself: no manual linking. You turn the feature's sessions into a summary a reviewer can read to get fluent fast.

Bundled CLI (Codex)

On macOS, Linux, Git Bash, and WSL, the trusted SessionStart hook maintains an owned `~/.local/bin/fluencyloop` shim for this installed plugin. Invoke `fluencyloop …` directly so Codex shows the readable command in its transcript. Do not resolve its path, check PATH, or describe the shim to the developer.

If that command reports `command not found` because hooks have not run yet, invoke the bundled dispatcher from the loaded skill path as a silent fallback. On native Windows, invoke the adjacent `fluencyloop.ps1` with `pwsh`.

Local site — open once

Before the first user-visible response, run `fluencyloop site --ensure --open-once --json`. This ensures the reader for every workflow entry, but opens a browser tab only once while that managed reader is alive. If it reports `running: true` and no earlier assistant message in this session starts with `FluencyLoop site:`, say `FluencyLoop site: <url> (opened in browser).` once, using its returned URL. Do not mention an unavailable site or repeat the announcement.

Generated prose — ASD-STE100

Write generated user-facing technical prose in ASD-STE100 style: use short, direct sentences, active voice, one main action per sentence, and stable, unambiguous terms. Preserve product names, code identifiers, CLI commands, field names, and exact recorded values. Do not claim formal ASD-STE100 compliance: that requires checking the official controlled dictionary and rules.

Question delivery — preserve the pause

For a real answer, choice, or confirmation, use **`AskUserQuestion` in Claude Code**. Codex has no equivalent question-form tool, so ask a concise standalone question in chat and stop; do not create a PR or persist a preference until the developer answers. A settled `feature-handoff: automatic` preference is already that answer; honor it without asking again.

1. Gather the raw material

**Read `.fluencyloop/state.json` first** if it exists — it is the loop's source of truth for the active feature (`feature` slug, `branch`, `base_ref`), so you don't re-derive them from git. Use its `base_ref` as the diff base (`--base`) rather than guessing the default branch.

From the feature branch (or pass `--slug`):

fluencyloop review --json                    # paths, commit range, session list
fluencyloop review --base "<base_ref>"       # scope the diff to the recorded base

The `--json` form gives `feature`, `range`, `commits`, and session declarations from the feature store. The plain form inlines every session's decisions under the feature title.

2. Render the reviewer view

Produce a concise, reviewer-facing summary:

• **One-line feature intent** (from the feature declaration's `intent` field in the store).
• **Decisions that matter**, grouped by session — each as *chose X over Y because Z*, with

its `where:` code anchor. Lead with the decisions carrying `trust: ⚠` — those are where a reviewer should look hardest.

• **Constitution check:** scan each decision's `constitution:` field against the project's

principles — read `docs/fluencyloop/constitution.md`, and **if it's a pointer** (`Source of truth:` naming another file, e.g. `.specify/memory/constitution.md`), read *that* for the real principles. **Flag** any decision that appears to conflict, or any principle-relevant decision that was never checked. Flag as a surfaced note — never a blocker.

• **Design shape:** summarize the relevant session, decision, and architectural records; do not

create or link a generated `design.md`.

• **Un-journaled drift:** run `fluencyloop check --json` and read `unjournaled_commits`. If it's > 0, warn that N commit(s) landed since the

last journaled session — the reviewer is looking at code the journal doesn't explain, so nudge the author to journal it or run backfill. Surface it as a note; never block.

3. Output — create the PR, don't hand over text to paste

The point is to remove friction, so **create a prepopulated PR** rather than leaving the user to copy-paste into GitHub.

1. Make sure the branch is pushed (`git push -u origin <branch>` if it has no upstream). 2. If `gh` is available (check with `Get-Command gh` on native Windows or `command -v gh` elsewhere), create the PR with the assembled view as the body:

   gh pr create --base "<base_ref>" --title "<feature intent>" --body-file <tmpfile>

Read `~/.fluencyloop/preferences.md` before asking. If `feature-handoff: automatic` is settled, create the PR with the assembled title, recorded base, and body without a second confirmation; show the completed PR URL and summary afterwards. Otherwise, confirm the title/base with the user first and show them the body you're about to use. On success, give them the PR URL. 3. If `gh` is **not** available, still deliver — and make a **one-time** setup offer, because `gh` is what lets FluencyLoop open the PR for you. First hand over the reviewer view **rendered**, and a **prepopulated compare URL** that opens a ready-to-file PR in the browser (no `gh`, any OS): `https://github.com/<owner>/<repo>/compare/<base>...<branch>?expand=1&title=<t>&body=<url-encoded>` (mind the URL length limit; fall back to the pasteable body if it's too long). Then check `~/.fluencyloop/preferences.md` for a settled `gh-setup` choice:

• **Not settled yet** — offer **once** using the delivery rule above, sel