Trails Local Review
Review the assigned Trails scope independently and report whether it is ready. Default to read-only review; edit files, mutate Git or Graphite, update a PR, or change tracker state only when the coordinating agent explicitly delegates that operation.
Establish The Contract
Infer or obtain:
- the exact scope and base/head refs;
- the written acceptance criteria from the request, plan, issue, ADR, or specification;
- the intended completion horizon;
- the owning branch for each changed responsibility;
- the desired report path, when a durable artifact is required.
An issue is useful evidence when one exists, not a prerequisite for review. If acceptance is ambiguous, name the gap instead of inventing criteria.
Read AGENTS.md, the nearest scoped guidance, governing tenets and ADRs, the lexicon, and affected source or documentation. For Graphite work, inspect the real stack, branch diffs, PR state, CI, and unresolved review threads rather than inferring topology from branch names.
Review The Right Surfaces
Test the scope against the contracts that actually govern it:
- behavior, types, tests, examples, and error handling;
- Trails vocabulary, tenets, ADRs, and architectural ownership;
- generated-output parity and drift checks;
- Graphite branch ownership and dependency-safe placement;
- documentation, migration guidance, and agent-facing instructions;
- Warden, Wayfinder, lock round-trip, changeset, and release-pack expectations when applicable;
- security, destructive effects, external state, and delegated authority;
- the issue, plan, PR description, and implementation telling the same story.
Verify evidence directly. Quote the relevant path and line, command result, PR thread, or runtime observation. Treat unable to verify as a valid result and an invented citation as a hard review failure. An empty search is not proof of absence until its scope, identifier grammar, and plausible alternate homes are checked.
Keep Review Topology Proportional
The builder should inspect its own work before handoff, but self-review does not become independent merely because it is thorough. For substantive agent-produced work, prefer a fresh-context reviewer when the repository or coordinator requires independence and the harness can provide it.
The coordinating agent chooses reviewer topology, report durability, fix ownership, and the final review gate. The user or delegated coordinator retains ready, merge, release, and publication authority.
Within one fix loop, reuse the same reviewer so findings can be rechecked consistently. Use a fresh reviewer for a genuinely independent milestone or full-stack judgment when required.
Grade Findings
- P0: unsafe or impossible to proceed, including security, data loss, destructive behavior, or a broken required release path.
- P1: correctness or contract regression, including broken behavior, public API, migration, or governing doctrine.
- P2: important quality or readiness defect that should be fixed before handoff, including misleading guidance, generated drift, missing release intent, or unresolved review evidence.
- P3: optional polish with no correctness, doctrine, documentation, or release impact.
Lead with findings in severity order. Each finding should include the contract violated, exact evidence, impact, and smallest credible fix. Lower confidence rather than filling an evidence gap with plausible prose.
Report And Recheck
When a goal packet requires a durable report, write it under that packet's reports/ directory or the coordinator-provided scratch path. Otherwise return a concise findings-first review in chat. Do not commit scratch review artifacts unless explicitly directed.
After fixes:
- inspect the new diff on the owning branch;
- rerun the focused evidence that proves the finding is closed;
- check affected upstack branches and generated surfaces;
- update each prior finding as fixed, accepted, rejected, stale, or still open;
- issue a new readiness score without erasing residual risk.
A clean or 5/5 judgment requires no open P0-P2 findings and enough evidence to trust the requested horizon. Keep PRs draft until required local review and hosted checks are green. Do not mark ready or merge unless that authority was delegated, even when the review is clean.
1---2name: trails-local-review3description: Review a Trails branch, Graphite stack, milestone, generated artifact, migration, documentation set, or implementation slice against current repository doctrine and written acceptance. Use for pre-submit review, targeted risk review, review-fix loops, or a final readiness judgment with evidence-backed P0-P3 findings.4---56# Trails Local Review78Review the assigned Trails scope independently and report whether it is ready. Default to read-only review; edit files, mutate Git or Graphite, update a PR, or change tracker state only when the coordinating agent explicitly delegates that operation.910## Establish The Contract1112Infer or obtain:1314- the exact scope and base/head refs;15- the written acceptance criteria from the request, plan, issue, ADR, or specification;16- the intended completion horizon;17- the owning branch for each changed responsibility;18- the desired report path, when a durable artifact is required.1920An issue is useful evidence when one exists, not a prerequisite for review. If acceptance is ambiguous, name the gap instead of inventing criteria.2122Read `AGENTS.md`, the nearest scoped guidance, governing tenets and ADRs, the lexicon, and affected source or documentation. For Graphite work, inspect the real stack, branch diffs, PR state, CI, and unresolved review threads rather than inferring topology from branch names.2324## Review The Right Surfaces2526Test the scope against the contracts that actually govern it:2728- behavior, types, tests, examples, and error handling;29- Trails vocabulary, tenets, ADRs, and architectural ownership;30- generated-output parity and drift checks;31- Graphite branch ownership and dependency-safe placement;32- documentation, migration guidance, and agent-facing instructions;33- Warden, Wayfinder, lock round-trip, changeset, and release-pack expectations when applicable;34- security, destructive effects, external state, and delegated authority;35- the issue, plan, PR description, and implementation telling the same story.3637Verify evidence directly. Quote the relevant path and line, command result, PR thread, or runtime observation. Treat `unable to verify` as a valid result and an invented citation as a hard review failure. An empty search is not proof of absence until its scope, identifier grammar, and plausible alternate homes are checked.3839## Keep Review Topology Proportional4041The builder should inspect its own work before handoff, but self-review does not become independent merely because it is thorough. For substantive agent-produced work, prefer a fresh-context reviewer when the repository or coordinator requires independence and the harness can provide it.4243The coordinating agent chooses reviewer topology, report durability, fix ownership, and the final review gate. The user or delegated coordinator retains ready, merge, release, and publication authority.4445Within one fix loop, reuse the same reviewer so findings can be rechecked consistently. Use a fresh reviewer for a genuinely independent milestone or full-stack judgment when required.4647## Grade Findings4849- **P0:** unsafe or impossible to proceed, including security, data loss, destructive behavior, or a broken required release path.50- **P1:** correctness or contract regression, including broken behavior, public API, migration, or governing doctrine.51- **P2:** important quality or readiness defect that should be fixed before handoff, including misleading guidance, generated drift, missing release intent, or unresolved review evidence.52- **P3:** optional polish with no correctness, doctrine, documentation, or release impact.5354Lead with findings in severity order. Each finding should include the contract violated, exact evidence, impact, and smallest credible fix. Lower confidence rather than filling an evidence gap with plausible prose.5556## Report And Recheck5758When a goal packet requires a durable report, write it under that packet's `reports/` directory or the coordinator-provided scratch path. Otherwise return a concise findings-first review in chat. Do not commit scratch review artifacts unless explicitly directed.5960After fixes:61621. inspect the new diff on the owning branch;632. rerun the focused evidence that proves the finding is closed;643. check affected upstack branches and generated surfaces;654. update each prior finding as fixed, accepted, rejected, stale, or still open;665. issue a new readiness score without erasing residual risk.6768A clean or 5/5 judgment requires no open P0-P2 findings and enough evidence to trust the requested horizon. Keep PRs draft until required local review and hosted checks are green. Do not mark ready or merge unless that authority was delegated, even when the review is clean.