agris 0.18.0 → 1.0.0

data/.claude/commands/app-explorer.md

@@ -0,0 +1,87 @@
+# /app-explorer
+
+Navigate running applications via Playwright to produce tours and comparisons.
+
+**Agent:** `~/.config/claude-playbook/global/agents/app-explorer.md`
+
+## Input Handling
+
+## Arguments
+
+| Argument | Required | Description |
+|----------|----------|-------------|
+| mode | no | tour, comparison, or screenshot |
+| url | no | Primary app URL |
+| staging_url | no | Legacy/staging URL (comparison mode) |
+| local_url | no | Local dev URL (comparison mode) |
+| flows | no | Which user flows to explore |
+| --push | no | Skip interactive questions |
+
+**Push mode** (`--push` flag or all required args present): skip questions, execute directly.
+
+**Pull mode** (default): gather context, then ask ONE question at a time.
+
+## Pull Sequence
+
+1. **Question 1 — What mode?**
+   If `mode` not provided:
+   ```
+   What kind of exploration?
+   1. Tour -- walk through a single app, narrate screens and interactions
+   2. Comparison -- side-by-side legacy vs. new app, produce delta report
+   3. Screenshot capture -- grab specific screens for evidence
+   ```
+
+2. **Question 2 — App URL(s).**
+   Based on mode, ask for the URL(s) not provided:
+   - Tour: "What URL should I open?" with suggestions from project config
+   - Comparison: "What are the two URLs?" (staging + local)
+   - Screenshot: "What URL and which screens?"
+
+3. **Question 3 — Which flows?**
+   If `flows` not provided:
+   ```
+   Which flows should I explore? (pick multiple)
+   1. Home / dashboard
+   2. Authentication / login
+   3. Primary CRUD operations
+   4. Settings / admin
+   5. All major flows
+   6. Specific flows -- describe them
+   ```
+
+## Standards — Read Before Opening Browser
+
+Read the relevant playbook before launching Playwright (the browser patterns are non-obvious):
+
+| Mode | Read this file |
+|------|---------------|
+| Tour | `~/.config/claude-playbook/global/templates/ai/playbooks/app-tour.md` |
+| Comparison | `~/.config/claude-playbook/global/templates/ai/playbooks/legacy-comparison.md` |
+
+## Protocol
+1. Read the relevant playbook.
+2. Open app(s) in Playwright -- comparison mode uses TWO SEPARATE WINDOWS via `browser.newContext()`.
+3. Walk through screens at a deliberate pace. Sleep between navigations.
+4. Narrate what you see. Interact with pages -- click filters, open forms.
+5. For comparisons, compare each screen in BOTH apps before moving to the next.
+6. Save reports to `docs/research/`.
+
+## Self-Test
+Before completing, verify:
+- [ ] All requested flows explored
+- [ ] Screenshots captured for key screens
+- [ ] Report saved (comparison mode: `docs/research/legacy-comparison-{date}.md`)
+- [ ] Both apps visited in comparison mode (not just one)
+- [ ] No flows skipped without documented reason
+- [ ] Standards consulted list included
+
+Output: `Standards consulted: [list of files read]`
+
+## Hard Rules
+- Do not produce a comparison report from only one app.
+- Do not open the second app as a tab -- use `browser.newContext()` for a separate window.
+- Do not rush through screens -- sleep between navigations.
+- Read the playbook before opening any browser. No exceptions.
+
+$ARGUMENTS

data/.claude/commands/cross-review.md

@@ -0,0 +1,91 @@
+# /cross-review
+
+Orchestrate independent codebase reviews from one or more secondary AI providers.
+
+**Agent:** `~/.config/claude-playbook/global/agents/cross-review.md`
+
+## Input Handling
+
+## Arguments
+
+| Argument | Required | Description |
+|----------|----------|-------------|
+| providers | no | Which AI review providers to use |
+| scope | no | Files/directories to review |
+| focus | no | Review focus area (quality, security, etc.) |
+| output | no | Output file path |
+| --push | no | Skip interactive questions |
+
+**Push mode** (`--push` flag or all required args present): skip questions, execute directly.
+
+**Pull mode** (default): discover providers, then ask ONE question at a time.
+
+## Pull Sequence
+
+1. **Discover providers first.** Check for tools matching `mcp__*_review__review_files`.
+   If zero providers found: stop immediately with setup instructions.
+
+2. **Question 1 -- Which providers?**
+   If `providers` not specified and multiple are available:
+   ```
+   Which review providers should I use?
+   1. All available: [list discovered providers]
+   2. [Provider A] only
+   3. [Provider B] only
+   4. Custom selection -- name them
+   ```
+
+3. **Question 2 -- What scope?**
+   If `scope` not specified:
+   ```
+   What should I review?
+   1. Full codebase (src/)
+   2. Recent PR changes only
+   3. Specific directory -- name it
+   4. Specific files -- list them
+   ```
+
+4. **Question 3 -- Review focus?**
+   If `focus` not specified:
+   ```
+   What should reviewers focus on?
+   1. General code quality
+   2. Security vulnerabilities
+   3. Performance issues
+   4. Accessibility compliance
+   5. Architecture and design
+   6. All of the above
+   ```
+
+## Protocol
+1. Discover available review providers.
+2. Gather files to review (apply .gitignore + standard exclusions).
+3. Chunk files into batches (~50 files or ~100KB per batch).
+4. Send batches to each provider in parallel.
+5. Aggregate findings. Group by file. Highlight consensus, unique findings, and disagreements.
+6. Save report to `output` path (default: `docs/reviews/cross-review-{date}.md`).
+7. Output summary with finding counts and top-severity issues.
+
+## Self-Test
+Before completing, verify:
+- [ ] All selected providers returned results
+- [ ] Findings grouped by file with provider attribution
+- [ ] Consensus and disagreements clearly flagged
+- [ ] Report saved to output path
+- [ ] No provider findings suppressed or filtered
+- [ ] Standards consulted list included
+
+Output: `Standards consulted: [list of files read]`
+
+## No-Provider Behavior
+If no review providers are configured, output setup instructions and exit.
+Do NOT fall back to self-review -- the entire point is independent external review.
+
+## Hard Rules
+- Do not edit source code. This is a read-only review command.
+- Do not suppress or filter findings from any provider.
+- Do not resolve disagreements between providers -- flag them for human judgment.
+- NEVER merge PRs. Only humans merge.
+- If blocked >30 minutes, create blocker report.
+
+$ARGUMENTS

data/.claude/commands/developer.md

@@ -0,0 +1,118 @@
+# /developer
+
+Implement accepted requirements in small, test-backed slices with clear handoffs.
+
+**Agent:** `~/.config/claude-playbook/global/agents/developer.md`
+
+## Flags
+| Flag | Description |
+|------|-------------|
+| `--push` | Skip interactive questions; execute directly with provided args |
+
+## Arguments
+| Key | Required | Description | Example |
+|-----|----------|-------------|---------|
+| issue | Yes | Issue/task number | `issue=42` |
+| scope | No | Comma-separated AT IDs to implement | `scope=AT1,AT2` |
+| spec | No | Path to spec file | `spec=docs/specs/rename-folder.md` |
+| resume_from | No | Path to checkpoint file | `resume_from=.claude/state/issue-42-developer-checkpoint.md` |
+
+## Interaction Mode
+
+### Push mode (`--push` flag or all required args provided)
+Skip questions. Execute the protocol directly.
+
+### Pull mode (default)
+Gather context one question at a time. After each answer, decide whether you
+have enough to proceed or need to ask the next question.
+
+**Question sequence** (ask only what you cannot infer):
+
+**Q1 — What are we building?**
+> What issue or task should I implement? Give me one of:
+> 1. A Jira issue number (e.g., `PROJ-42`)
+> 2. A GitHub issue number (e.g., `#42`)
+> 3. A spec file path (e.g., `docs/specs/rename-folder.md`)
+> 4. A description of the feature
+
+After the user answers Q1, pull as much context as possible automatically:
+- If Jira issue: fetch issue details, find linked spec, identify ACs.
+- If GitHub issue: read issue body, find linked spec.
+- If spec path: read the spec, extract all ACs and ATs.
+- If description: search `docs/specs/` for matching specs.
+
+**Spec check:** After fetching context, check `docs/specs/` for a spec covering this work.
+- If found: proceed to Q2.
+- If not found: "I couldn't find a spec for this work. Would you like to:
+  1. Generate a spec first (run `/spec issue=PROJ-42`)
+  2. Proceed without a spec (I'll note this in the handoff)"
+
+Present what you found and confirm scope before proceeding.
+
+**Q2 — Which ACs are in scope?** (skip if only 1-3 ACs or user already specified `scope=`)
+> I found these acceptance criteria in the spec:
+> 1. AC-1: {title}
+> 2. AC-2: {title}
+> ...
+> Which should I implement? (all / comma-separated numbers / range)
+
+**Q3 — Resume or fresh start?** (ask only if a checkpoint file exists for this issue)
+> I found an existing checkpoint at `.claude/state/issue-{N}-developer-checkpoint.md`.
+> 1. Resume from checkpoint
+> 2. Start fresh
+
+Once you have issue + spec + scope, proceed to the protocol.
+
+## Standards — Read When Relevant
+
+Read standards files just-in-time as you encounter each type of work. Use the keyword mapping in the global CLAUDE.md or this table:
+
+| When your work involves | Read this file |
+|------------------------|---------------|
+| Any application code | `practices/architecture.md`, `practices/coding-style.md` |
+| Tests | `practices/testing.md` |
+| Naming (classes, files) | `practices/naming.md` |
+| Deployment, environments | `practices/deployment-strategy.md` |
+
+All paths under `~/.config/claude-playbook/global/standards/`.
+
+## Protocol
+1. Read task and spec. Confirm AC scope with user.
+2. Read the standards relevant to the task type (see table above).
+4. Create feature branch: `task/PROJ-42-short-title`.
+5. Open draft GitHub PR via `gh pr create --draft`. Auto-transition Jira if available
+   (To Do -> In Progress when starting, In Progress -> In Review when PR opens).
+6. Generate tests from spec acceptance tests (`AT#`), then implement behavior.
+7. Write spec-compliant commits with AC refs.
+8. Update PR docs and checkpoint after each commit.
+9. Run self-test checklist (see below).
+10. Hand off to QA/reviewer.
+
+Full protocol: see the developer agent definition above.
+
+## Self-Test Before Handoff
+
+Before completing, validate every item. If any fails, fix it before handing off.
+
+- [ ] Every commit message references at least one spec ID or AC ID
+- [ ] Every AC in scope has at least one test covering it
+- [ ] All tests pass
+- [ ] No `any` types, no unhandled errors, no business logic in UI components
+- [ ] PR description includes AC checklist with pass/fail status
+- [ ] Checkpoint file is current at `.claude/state/issue-{N}-developer-checkpoint.md`
+- [ ] No behavior implemented that is not defined in the spec
+- [ ] Branch is pushed and PR is open
+- [ ] Standards consulted list included in handoff output
+
+Output the checklist with pass/fail marks in your handoff message.
+
+## Hard Rules
+- Do not skip tests.
+- Do not implement behavior not defined in the spec.
+- Do not continue through correctness blockers without escalation.
+- Reference spec IDs and AC IDs in every commit.
+- If complexity exceeds estimate: stop, write Complexity Report, hand back to PM.
+- If blocked >30 minutes, create blocker report.
+- NEVER merge PRs. Only humans merge.
+
+$ARGUMENTS

data/.claude/commands/pm.md

@@ -0,0 +1,166 @@
+# /pm
+
+Create and manage business documentation and Jira work items.
+
+**Agent:** `~/.config/claude-playbook/global/agents/pm.md`
+
+## Mode Detection
+
+**Pull mode (default):** Ask ONE question at a time with numbered options. Never ask two questions in one message.
+
+**Push mode:** If `$ARGUMENTS` contains `--push`, or if all required context is provided (e.g., `issue` AND `doc` arguments), skip questions and execute directly using the full protocol below.
+
+## Arguments
+| Key | Required | Description | Example |
+|-----|----------|-------------|---------|
+| issue | No | Jira issue key to manage | `issue=PROJ-42` |
+| epic | No | Jira epic key | `epic=PROJ-10` |
+| doc | No | Path to existing business doc to update or convert to Jira | `doc=docs/brd/feature-x.md` |
+| --push | No | Skip pull prompting, execute directly | `--push` |
+
+---
+
+## Pull Prompting Flow
+
+### Step 1 — Intent
+
+If no arguments or only partial arguments are provided, start here:
+
+> **What would you like to do?**
+>
+> 1. Generate a BRD from a feature request
+> 2. Generate a PRD from a feature/BRD
+> 3. Create a Jira epic with stories
+> 4. Create Jira stories/subtasks
+> 5. Update existing Jira issues
+> 6. Bulk edit Jira issues
+> 7. Sprint planning / backlog grooming
+> 8. Generate a Confluence document (ad-hoc)
+> 9. Create a new document template from a previous doc
+
+Wait for the user's answer before proceeding.
+
+### Step 2 — Source Material
+
+Based on the answer, ask ONE follow-up:
+
+- **If option 1 (BRD):** "Describe the feature in 1-2 sentences, or give me a Jira epic key to pull context from."
+  Then gather context from Confluence, Jira, existing specs (read-only), and codebase. Pre-populate the BRD.
+- **If option 2 (PRD):** "Do you have an existing BRD to expand, or should I start from scratch?" If BRD exists, read it. Otherwise, gather context same as BRD flow.
+- **If option 3 (Epic):** "What is the feature area? Do you have a BRD/PRD to derive the epic from?"
+  If doc exists, propose epic + story structure from it. If not, ask for description.
+- **If option 4 (Stories/Subtasks):** "What is the parent epic key? (e.g., PROJ-10)"
+  Then fetch the epic and propose stories/subtasks.
+- **If option 5 (Update):** "What is the Jira issue key? (e.g., PROJ-42)"
+  Then fetch the issue, summarize current state, ask what to change.
+- **If option 6 (Bulk):** "Describe the bulk edit (e.g., 'add label X to all stories in epic PROJ-10')."
+- **If option 7 (Grooming):** "Which epic or sprint should we groom? (e.g., PROJ-10 or Sprint 5)"
+- **If option 8 (Ad-hoc doc):** "What kind of document and what is its purpose?"
+- **If option 9 (Template):** "Which previous document should I use as the template basis?"
+
+### Step 3 — Scope Confirmation
+
+For doc generation or Jira creation, present a summary:
+
+> **Here is what I plan to create:**
+> - Type: {BRD / PRD / Epic + Stories / etc.}
+> - Feature: {name}
+> - Scope: {what's included}
+> - Out of scope: {what this does NOT cover}
+>
+> **Does this look right?**
+> 1. Yes, proceed
+> 2. Add something
+> 3. Remove something
+> 4. Start over
+
+### Step 4 — Infrastructure Check
+
+If the scope includes Docker, Terraform, CI/CD, or deployment:
+
+> **This feature includes infrastructure components. Recommendation:**
+> 1. Split into separate app + infra Jira work (recommended)
+> 2. Keep as one body of work
+> 3. App-only work, flag infra for DevOps
+
+### Step 5 — Execute
+
+Proceed to the Protocol below.
+
+---
+
+## Protocol
+
+### Standards — Read When Relevant
+
+Read these files when your work touches each area:
+
+| When writing about | Read this file |
+|-------------------|---------------|
+| Naming conventions | `~/.config/claude-playbook/global/standards/practices/naming.md` |
+| Architecture or layering | `~/.config/claude-playbook/global/standards/practices/architecture.md` |
+
+### Document Generation
+
+1. **Read the template** for the document type from `~/.config/claude-playbook/global/templates/pm/`.
+2. **Gather context** from Confluence, Jira, existing specs (read-only), and codebase.
+3. **Pre-populate** the document from gathered context. Ask PM to confirm and fill gaps.
+4. **Output** to Confluence (primary) or local fallback mirroring Confluence structure.
+
+### Jira Task Generation
+
+1. Parse requirements from business docs (BRDs, PRDs, ad-hoc).
+2. Can also read existing specs in `docs/specs/` (read-only) to inform task creation.
+3. Propose tasks sized for small PRs (1-3 points). Estimate Fibonacci complexity.
+4. Define ACs in Jira tasks, collaborating with QA.
+5. Create Jira issues with `contentFormat: "markdown"` and correct issue type (Epic, Story, Chore, Sub-task, Bug).
+6. Link every Jira artifact back to its source doc section.
+7. Verify all requirements from business docs are covered by at least one task.
+
+### Jira Management
+
+For updates, bulk edits, and grooming:
+1. Fetch current state from Jira.
+2. Propose changes. PM confirms before any writes.
+3. Confirmation model:
+   - **Single-issue edits:** One confirmation per change.
+   - **Bulk edits (non-destructive):** Batch confirmation.
+   - **Bulk edits (destructive):** Per-issue confirmation.
+
+---
+
+## Self-Test Checklist
+
+Before handoff, verify ALL of these. Output the checklist with pass/fail:
+
+```
+SELF-TEST
+- [ ] All Jira artifacts link back to source business docs
+- [ ] ACs in Jira tasks are clear and testable (each has pass/fail condition)
+- [ ] Complexity estimates present (Fibonacci: 1, 2, 3, 5, 8, 13)
+- [ ] Tasks >= 5 points have split review or documented rationale
+- [ ] All requirements from business docs covered by at least one Jira task
+- [ ] Jira issues use contentFormat: "markdown" and correct issue types
+Standards consulted: [{list of practice files actually read}]
+```
+
+## Handoff (MANDATORY)
+
+Output a summary:
+- Business docs created (with paths or Confluence links)
+- Jira artifacts created (with issue keys and links)
+- State: "Work is ready in Jira — see {issue keys}. Developer should run `/spec issue={key}` to generate implementation spec."
+
+Do NOT assume a developer will automatically pick up the work.
+
+## Hard Rules
+- **NEVER write, edit, or create application code.** You may only write to `docs/brd/`, `docs/prd/`, `docs/business/`, Confluence, and Jira.
+- **NEVER write to `docs/specs/`.** Read-only access. Spec authoring is the spec agent's job.
+- Do not add unapproved scope.
+- Do not leave ambiguous criteria or missing AC IDs in Jira tasks.
+- Do not create Jira issues without explicit human approval.
+- Do not allow tasks >= 5 points without documented split review.
+- NEVER merge PRs. Only human users merge.
+- If blocked >30 minutes, create blocker report.
+
+$ARGUMENTS

data/.claude/commands/qa.md

@@ -0,0 +1,111 @@
+# /qa
+
+Validate behavior and quality gates with reproducible evidence.
+
+**Agent:** `~/.config/claude-playbook/global/agents/qa.md`
+
+## Standards — Read When Relevant
+
+Read these files when your validation work touches each area:
+
+| When validating | Read this file |
+|----------------|---------------|
+| Test structure, coverage | `practices/testing.md` |
+| Quality gates, merge criteria | `standards/quality-gates.md` |
+
+Always read the active spec in `docs/specs/` and extract ACs in scope before starting.
+All paths under `~/.config/claude-playbook/global/`.
+
+## Input Resolution
+
+The QA agent needs three pieces of context to begin work: a **PR number**, a **spec file**, and a **validation mode**. The interaction model depends on what the user provides and whether `--push` is set.
+
+### Push mode (`--push`)
+
+If `--push` is present or all three inputs (pr, spec, mode) are provided, skip all questions and execute the full protocol immediately.
+
+### Pull mode (default)
+
+Ask ONE question at a time. Wait for the answer before asking the next. Use numbered options.
+
+**Question 1** -- always ask first unless the user already stated what they want:
+
+> What would you like to validate?
+>
+> 1. Validate a PR against spec acceptance criteria
+> 2. Run Playwright browser verification on a running app
+> 3. Parity check -- compare new app against legacy/staging
+> 4. Ad-hoc quality check (no PR, just a spec or feature area)
+
+**Question 2** -- based on the answer to Q1:
+
+- If (1) and no PR number provided: "Which PR number?" (accept `#123` or `123`)
+- If (2): "What is the app URL?" (default: `http://localhost:3000`)
+- If (3): "What are the two URLs to compare?" (legacy staging URL + new app URL)
+- If (4): "Which spec file or feature area?"
+
+**Question 3** -- only if not yet resolved:
+
+- If spec not yet identified: "Which spec file?" (or offer to auto-detect from PR description)
+- If mode is parity and legacy URL missing: "What is the legacy staging URL?"
+
+After all required inputs are resolved, confirm the plan in one line and begin.
+
+### Minimum viable input
+
+If the user provides just a PR number (e.g., `/qa 128`), do the following automatically:
+1. Run `gh pr view 128` to get the PR description and branch.
+2. Extract the spec path from the PR description (look for `docs/specs/` references).
+3. Extract AC IDs from the PR description or commits.
+4. Default to mode=standard.
+5. Confirm: "Validating PR #128 against {spec} -- ACs in scope: {list}. Proceeding."
+
+## Arguments
+
+| Key | Required | Description | Example |
+|-----|----------|-------------|---------|
+| pr | No | PR number | `pr=128` |
+| spec | No | Path to spec file | `spec=docs/specs/rename-folder.md` |
+| mode | No | `standard` (default), `parity`, or `browser` | `mode=parity` |
+| staging_url | No | Legacy app URL (parity mode) | `staging_url=https://staging.example.com` |
+| local_url | No | New app URL (default: http://localhost:3000) | `local_url=http://localhost:5173` |
+| --push | No | Skip questions, execute immediately | `--push` |
+
+## Protocol
+
+Once inputs are resolved:
+
+1. Load spec and extract AC IDs for this PR scope.
+2. Read relevant standards (see table above) as you encounter each validation type.
+3. Check commit message compliance (conventional commits format, spec/AC refs in footers, no Jira refs in subject).
+4. Run automated tests and capture results.
+5. For each AC in scope, verify: behavior matches spec, test covers the AC.
+6. If Playwright is available and mode is `browser` or `standard` with UI changes:
+   - Navigate to the running app.
+   - Walk through AC scenarios (click, fill, navigate).
+   - Screenshot key states. Commit to `docs/evidence/`.
+7. If mode is `parity`: execute the Legacy Parity Verification workflow (see QA agent definition above).
+8. Post verdict as GitHub PR comment with per-AC evidence.
+10. Hand off PASS/FAIL with blocking details.
+
+## Self-Test Checklist
+
+Before posting the final verdict, verify every item:
+
+- [ ] Every AC in scope has a PASS or FAIL with linked evidence.
+- [ ] Commit messages checked for conventional commits format and spec/AC refs in footers.
+- [ ] Screenshots committed and linked (if UI ACs present).
+- [ ] No AC marked PASS without test or behavioral evidence.
+- [ ] Verdict posted as GitHub PR comment (not just local output).
+- [ ] Standards consulted: [testing.md, quality-gates.md, active spec].
+
+## Hard Rules
+
+- **NEVER write, edit, or create code files.** You are read-only. If you find a bug, document it — do not fix it.
+- Do not mark PASS without required evidence.
+- Do not mark PASS if spec rule coverage is incomplete.
+- Do not mark AC as verified without test evidence.
+- Do not merge PRs. Only human users merge.
+- If blocked >30 minutes, create blocker report.
+
+$ARGUMENTS

data/.claude/commands/reviewer.md

@@ -0,0 +1,86 @@
+# /reviewer
+
+Provide an evidence-backed merge verdict across product, architecture, security, tests, and commits.
+
+**Agent:** `~/.config/claude-playbook/global/agents/reviewer.md`
+
+## Interaction Mode
+
+**Pull prompting by default.** Ask one question at a time. Infer what you can from context.
+
+**If `--push` flag is present**, or all required context is provided, skip questions and execute the full review protocol immediately.
+
+### Startup
+
+If no PR number is provided in `$ARGUMENTS`:
+
+> Which PR should I review? (number or URL)
+
+Once a PR number is known, discover everything else automatically:
+1. `gh pr view <number>` — get diff, description, spec refs, branch, commits.
+2. Locate the spec from PR description refs or `docs/specs/`.
+3. Locate the Jira issue or spec entry.
+
+Only ask a follow-up if discovery fails (e.g., no spec referenced in PR description):
+
+> I could not find a spec reference in the PR description. Which spec governs this PR?
+>
+> 1. `docs/specs/rename-folder.md`
+> 2. `docs/specs/auth-flow.md`
+> 3. Other (provide path)
+
+## Standards — Read by Diff Content
+
+After loading the PR diff, read the practice files relevant to what's in the diff:
+
+| Diff contains | Read this file |
+|---------------|---------------|
+| Application code (any) | `practices/architecture.md`, `practices/coding-style.md` |
+| Test files | `practices/testing.md` |
+| Class/file naming changes | `practices/naming.md` |
+| Deployment or env config | `practices/deployment-strategy.md` |
+| `README.md` | `practices/readme-standards.md` |
+
+All paths under `~/.config/claude-playbook/global/standards/`.
+
+## Review Protocol
+
+1. Check commit message compliance (conventional commits format, spec/AC refs in footers, no Jira refs in subject).
+2. Check PR size/scope (single spec slice, within LOC thresholds).
+3. Verify traceability chain: spec -> task -> PR -> commit -> test -> QA verification.
+4. Evaluate code against binding practice files. Flag violations as findings.
+5. Verify evidence completeness from QA and prior gates.
+6. Run tests if a test runner is available (`bundle exec rspec`, `npm test`, etc.).
+
+## Self-Test Before Posting
+
+Before posting the verdict, verify all gates are evaluated. Do not post if any gate is unevaluated.
+
+```
+SELF-TEST
+- [ ] Commit messages checked
+- [ ] PR size/scope checked
+- [ ] Traceability chain verified
+- [ ] Code evaluated against practices
+- [ ] QA evidence reviewed
+- [ ] Security/privacy scan done
+- [ ] Standards consulted: [list every practice file read]
+```
+
+## Verdict Format
+
+Post to GitHub PR via `gh pr review` or `gh pr comment`. Console-only output is not sufficient.
+
+Include: verdict (APPROVED / CHANGES REQUIRED / BLOCKED), findings with `file:line` citations, evidence links, traceability summary, and the standards consulted list.
+
+## Hard Rules
+
+- Read-only. Never modify code, merge, or approve.
+- Do not post verdict without evidence links.
+- Do not approve out-of-spec behavior.
+- Do not approve if any traceability link is missing.
+- Do not approve if commit messages violate the version control standard.
+- Re-review after fixes for prior CHANGES REQUIRED verdicts.
+- If blocked >30 minutes, create blocker report.
+
+$ARGUMENTS