align

You are running the /align command. This command operates in two modes depending on context. Detect the active mode first, then follow the instructions for that mode.

Invocation arguments. The raw arguments passed to this invocation (referred to as ARGS throughout this document) are:

$ARGUMENTS

If the block above is empty, the command was invoked with no arguments. Everywhere this document says "ARGS", it means the exact raw string above — the engine substitutes it here once, at this single point, and nowhere else.

Hard rules. These apply in both modes.

• Review the whole target; never ask the operator to narrow scope by size. The review surface is fixed by the mode and arguments, not by how large it is: Mode A audits the attached plan in full; Mode B (Local) reviews the entire {base}...HEAD diff in full; Mode B (PR/branch) reviews the entire target diff in full. A large diff — any number of commits, files, or scopes — is reviewed completely; it is never a reason to stop and ask the operator which slice to review. The only scope narrowing that exists is explicit operator input parsed in B-Step 1 (a <focus> instruction, or a PR / branch target — explicit in PR / in branch, or a bare PR reference like 287 / #287 / PR 287). Absent that input, there is no scope question. Do not emit an AskUserQuestion (or any prose prompt) asking the operator to pick a subset, confirm scope, or choose between "recent commits" and "whole branch" — proceed and review everything. A genuinely enormous diff yields a large report, not a smaller review.
• You will not squash, re-cut, split, reorder, or force-push commits, and you will not push or open/modify a PR. The commit-rewrite lifecycle (/squash) and the PR lifecycle (/create-pr) belong to the operator and are invoked when the operator decides.
• Amending in place is the default delivery mechanism for a finding whose defect originated in a commit on the active branch — see B-Step 6. Amending a branch-local commit is not a commit rewrite in the /squash sense: the commit count, order, and scope seams are unchanged; only the content of the commit that introduced the defect changes, so the branch's history reads as though the defect never shipped. This applies only to commits that originated on the active branch (present in {base}..HEAD, where {base} is the resolved review base — a worktree's source branch, else main) and have not been pushed. Never amend a commit that exists on {base}, on main, on a remote, or in a PR's published history.
• You will not run gh pr create, gh pr merge, gh pr review, gh pr comment, git push, git push --force, or any other remote-mutating command. git commit --amend and a git rebase -i limited to edit-ing branch-local commits are permitted only as the B-Step 6 amend mechanism described above; a rebase that reorders, squashes, drops, or rewords beyond the fix is not.
• Committing is allowed — and only in Mode B, only after the operator approves the fix plan. When Mode B implements an approved fix plan (B-Step 6), it delivers the completed work into the branch's history: amended into the originating commit when the defect came from a commit on the active branch, or as a new conventional, correctly-scoped commit when it did not (see root AGENTS.md § "Commits"). In PR mode fixes always land as new commits on top of the PR's head branch in a dedicated worktree (see B-Step 6) — that history is published, so it is never amended; local commits on the PR branch are not "modifying the PR", and only pushing updates the PR, which stays the operator's. It never squashes commits together, never reorders or splits them, and never pushes — the operator handles squashing and PRs. Mode A never commits (no code exists yet — there is nothing to commit). During the review/plan phase of either mode (everything before an approved Mode B plan), no git commit happens.
• You review the content of the work, never the commit-shaping or PR lifecycle. You will not author findings, amendments, recommendations, plan steps, or open items that direct the operator to squash, split/re-cut/reorder commits, choose a merge strategy, or open/sequence a pull request. Commit-shaping (one-scope-per-commit, squash seams) is owned by /squash; PR creation is owned by /create-pr. Both are the operator's lifecycle, invoked when the operator decides — running /align never implies a squash or a PR is the next step. You may mention in the report's prose that a follow-up squash or PR will eventually happen, but never as a finding, plan step, amendment, recommendation, or open item. Amending a fix into its originating branch-local commit is a delivery decision made in B-Step 6, not a commit-shaping finding — it never appears as a finding either.
• Your analysis output is a single markdown report in this chat response. After the report, Mode A writes only the plan file (folding in the amendments); Mode B writes the plan file and then — once the operator approves — implements the fix plan, which edits source and lands the result (amended into the originating branch-local commits, or new commits). No other lifecycle action (squash, reorder, push, PR) is permitted in either mode.
• The report is followed by the mode's plan write — Mode A applies the amendments to the audited plan, Mode B authors a fix plan in planning mode. Mode A stops after the plan write and never implements. Mode B stops after authoring the plan and waits for operator approval; only after approval does it implement the fixes and commit them (B-Step 6).