git:20260914.dbab098 to git:20260915.3d7652b

27 added, 156 removed. Audit A to A.

---

name: repo-review

- description: "Use when Worktree changes or a fixed snapshot/range need coordinated read-only Standards and Spec findings, documentation-authority review, completed provider-evidence integration, or selected-source visual-completion review; use repo-audit for bounded domain audits and a host security workflow for security-only review."

+ description: "Use when Worktree changes or a fixed snapshot/range need coordinated read-only Standards and Spec findings, documentation-authority review, provider-evidence integration, or selected-source visual-completion review; use repo-audit for no-change-basis audits."

---

# Repository Review

- ## Overview

- Review changes read-only. Select the basis first: Worktree reads current changes;

- fixed-basis review normalizes snapshots, ranges, and pull requests to immutable SHAs.

- Consume `urn:skills:review-request:v1`; the portable output is

- `urn:skills:review-findings:v1`. A compatible immutable

- PackageManifest is the preferred dirty/untracked review identity; graph impact queries

- bound consumers, while native source/contracts and the selected package remain proof.

- The review produces typed findings/Observations, not Requirement state or a Receipt.

- ## Review Basis

- Select exactly one basis before conclusions:

- - **Worktree/index:** current tracked, untracked, staged, and unstaged state.

- - **Fixed snapshot/range:** one resolved SHA or explicit immutable `base..head`; a pull request is normalized to complete metadata plus resolved base/head SHAs.

- - **Review package:** immutable PackageManifest with base/result identity, every

- in-scope file status/hash/mode/bytes including untracked files, aggregate hash,

- exclusions, and validation marker.

- Do not mix evidence between bases. Current-worktree content is contamination when reviewing another SHA unless explicitly included in the basis.

- ## Workflow

- 1. Read effective repository guidance and record the requested review object, scope, output, and non-goals.

- 2. Fix the basis before conclusions:

- - for Worktree, run status, diff stat/name-status, and cached equivalents when staged content exists;

- - for fixed-basis review, resolve full SHAs and complete changed-file evidence; for a package, verify its manifest and hashes.

- - For every fixed commit or range, apply the immutable parent/object procedure in

- [references/checklist.md](references/checklist.md). A root-style review is valid

- only when raw commit metadata has no parent and the commit is not a shallow-clone

- boundary that truncates parent history. Missing basis objects fail closed as

- `Not verified`; keep current-source observations separate from basis attribution.

- 3. Build the smallest complete read set from changed or explicitly owned paths. Use a

- compatible graph reverse-impact/consumer query when available, verify its snapshot

- basis matches the package, and recheck referenced source. A stale graph, query miss,

- or derived map view is never review proof or proof of no downstream impact.

- 4. In Worktree mode, inventory full status but deeply classify only the requested scope and necessary interface closure. Classify every changed file and mixed hunk only for requested commit-readiness.

- 5. Trace registrations, callers, types, data shaping, persistence, generated artifacts,

- runtime config, tests, docs, CI/deploy, and stale references. Load only applicable

- conditional references listed below. For Product/UI/DESIGN/project-map changes, load

- [documentation authority](references/documentation-authority-review.md), resolve

- `<design-root>/DESIGN.md`, and keep Product/UI/DESIGN/Map ownership distinct.

- A projection is relevant only when a named owner, producer, non-LLM consumer,

- semantic version, executable validator, drift policy, and retirement rule are evidenced;

- otherwise reject it as copied authority.

- Adopted component/token review must retain project-native negative tests; optional

- assets remain `Not applicable` when the project has not adopted them.

- 6. Evaluate two independent axes:

- - **Standards:** repository guidance, architecture, correctness, security, performance, maintainability, and applicable domain conventions.

- - **Spec:** originating requirements, decisions, acceptance criteria, missing behavior, wrong behavior, and unrequested scope.

- If no trustworthy spec exists, mark Spec `Not verified`; do not infer one from the diff.

- A requirement, ADR, schema, test, or acceptance artifact added by the reviewed

- basis is intent evidence unless an independent authority or prior approved contract

- establishes it. It cannot by itself clear replacement, compatibility, migration,

- rollout, or rollback risk.

- Use [Standards and Spec](references/standards-and-spec.md) for axis-specific evidence,

- security confidence, frontend authority tracing, and conditional profile routing.

- 7. Keep the two evidence passes independent. They may run in parallel only when delegation is available, both scopes are read-only and fixed, and the coordinator can verify and integrate their results.

- 8. Select only applicable profiles. Delegate bounded frontend, Java, or Rust work only

- when requested or necessary. Route security-only work to a host security workflow.

- Verify completed provider evidence against this basis before integrating it, and

- record its execution containment grade (`sandbox-isolated` or `prompt-constrained`)

- per [review integration](references/review-integration.md).

- 9. Resolve documented path mismatches at the selected basis. If a path or parent is

- absent, ascend to the nearest existing ancestor and search only the relevant

- subtree; report graph drift for a later `repository.asset.scan` refresh without

- mutating graph or documentation during review.

- 10. Reject speculative, unreachable, style-only, duplicate, or already-resolved findings. Consolidate both axes into P0-P3 findings from concrete impact and urgency while retaining each finding's axis.

- 11. Run only non-mutating repository checks needed for the selected basis and risk.

- After any fix, freeze a new complete Worktree or immutable basis and replay the

- affected checks; a verdict from the old basis cannot clear new changes.

- 12. Produce semantic groups, commit messages, and exact staging guidance only when the Worktree commit-readiness profile was requested. Add the Release profile only for an explicit release candidate/readiness question.

- 13. Report exclusions, residual risks, failed checks, and every `Not found` or `Not verified` gap. Keep an authorized external-review status separate from the local verdict: a submitted request with no attributed response neither creates nor clears a finding.

- 14. Freeze the local verdict before optional external retention or Forgeway delivery

- integration. Load [review integration](references/review-integration.md) only when

- either path is active; neither path may change the frozen local verdict.

- ## Modes

+ ## Entry Gate

- - **Worktree review:** full status inventory and bounded findings; optionally activate commit-readiness for ownership, mixed hunks, logical groups, exact staging guidance, and messages.

- - **Fixed-basis review:** one immutable snapshot or `base..head` range; normalize a pull request to this basis before findings.

- - **Review-package assessment:** package integrity and evidence coverage before findings.

- - **Release profile (conditional):** for explicit release readiness, add compatibility, migrations, generated artifacts, packaging, CI, deployment, rollback, and security configuration to a fixed basis.

+ Review one current Worktree or one immutable range/snapshot/review package. Freeze the

+ selected basis before conclusions; preserve read-only authority and stop when it or its

+ required objects cannot be verified.

- ## Do Not Use For

+ ## Route Map

- - Repository mapping or repo-map maintenance; use `repo-map`.

- - Future implementation planning; use the host's built-in planning.

- - Business-domain modeling without a change basis; use `domain-modeling`.

- - Root-cause diagnosis of a concrete failure; use the host's built-in diagnosis under effective instructions.

- - A direct bounded frontend-only, Java-only, or Rust-only audit with no Worktree/index, immutable review basis, or cross-surface coordination; use `repo-audit` with its matching language profile. When a review basis exists, keep `repo-review` as coordinator.

- - Security-only repository/path scans or Git change scans; use the matching host

- security workflow. Keep this Skill when security is one axis of a broader review or

- when integrating completed scan evidence into its fixed-basis verdict.

- - Implementing accepted fixes; use the matching `dev-*` skill.

- - Staging, commits, pushes, squash, cleanup, or other Git mutation; use `repo-delivery` after explicit authorization.

- - External ChatGPT sending or browser/client operation; use the matching operations skill.

+ | Request condition | Read | Result |

+ | --- | --- | --- |

+ | Immutable commit/range/snapshot or verified review package | [fixed-basis checklist](references/checklist.md) and [Standards/Spec](references/standards-and-spec.md) | Fixed-basis P0-P3 findings/observations |

+ | Current Worktree review | [worktree checklist](references/worktree-checklist.md) and [Standards/Spec](references/standards-and-spec.md) | Worktree P0-P3 findings/observations |

+ | Product/UI/DESIGN/map authority changes apply | [documentation authority](references/documentation-authority-review.md) | Authority closure review |

+ | Frontend visual/layout/motion change applies | [visual evidence](references/frontend-visual-evidence.md), [CSS governance](references/frontend-css-governance.md), [components/tokens](references/ui-components-and-tokens.md), and/or [motion review](references/interaction-motion-review.md) | Conditional visual review |

+ | OpenAPI/protocol, cross-boundary, or external provider evidence applies | [protocol contracts](references/protocol-contracts.md), [OpenAPI governance](references/openapi-contract-governance.md), [project grounding](references/project-grounding.md), and/or [review integration](references/review-integration.md) | Qualified evidence integration |

+ | Design/quality or Worktree example is needed | [codebase design](references/codebase-design.md) and/or [worktree examples](references/worktree-examples.md) | Bounded analysis |

- ## Hard Rules

+ ## Invariants

- - Keep every review read-only. Do not edit, format, stage, unstage, commit, push, change refs, post comments, or create issues/PRs.

- - State the review basis and resolved SHAs before immutable conclusions; state complete status/index evidence before Worktree conclusions.

- - Never use current-worktree files to clear a finding at another SHA.

- - Inventory full Worktree status, preserve unrelated changes, and reserve complete ownership/mixed-hunk classification for commit-readiness.

- - Mark mixed files `mixed-hunk`; never recommend whole-file staging unless every hunk belongs to the group.

- - Do not recommend `git add .`, `git add -A`, directory-wide adds, or broad wildcards unless explicitly approved.

- - Do not claim whole-repository, PR, release, or package coverage from partial evidence.

- - Do not report findings without reachable evidence and concrete impact.

- - Do not block or approve from diff size, annotations, file names, literals, or scanner

- matches alone; use them only to activate bounded evidence checks.

- - Treat scanner matches, dangerous APIs, dependency presence, and incomplete

- source-to-sink paths as candidates, not validated vulnerabilities. Verify any

- provider result against this review basis before it affects the verdict.

- - Do not turn unchanged repository debt, optional lint advice, code size, or a

- language/framework signal into a finding against the selected basis. Prove

- whether the basis introduces, expands, exposes, or directly depends on it. Label

- the relationship as `introduced`, `expanded`, `exposed`, `pre-existing but

- blocking`, or `Not verified`; do not attribute nearby debt to the basis.

- - Do not approve structural add/reuse/move/rename/delete work while manifests, exports, commands, tests, CI/deploy, docs, indexes, migrations, generated files, consumers, or stale references disagree.

- - Treat runtime, CI, deployment, external services, branch policy, and package completeness as `Not verified` unless directly evidenced.

- - A pending, timed-out, empty, or unattributed external review cannot change the local

- verdict; report that axis separately `Not verified`. Final-result retention is not

- an external review axis and cannot add, clear, or reprioritize findings.

- - Do not activate frontend design compliance merely because a repository contains

- frontend files. It is conditional on visual or UI-contract change scope, does not

- create another review profile, and does not require `repo-audit`.

- - Apply visual completion, OpenAPI, frontend CSS/components, documentation authority,

- motion, code quality, and project-grounding gates only through their applicable

- references. Static checks never replace required runtime evidence, and optional

- profiles remain `Not applicable` when their activation conditions are absent.

- - Distinguish a real sample-repository defect (`fail` verdict with a P0-P3 finding)

- from a Skill failure (the review process itself broke) and from `Not verified`

- (basis or evidence is incomplete). A real defect is a finding with reachable

- evidence and concrete impact attributed to the selected basis; `Not verified` is

- an honest gap, not a finding. Never fabricate a finding to satisfy a quota or

- convert a basis limitation into a defect.

+ - Do not mix evidence between bases; current content does not prove another SHA.

+ - A review package, graph, test, or provider output is evidence only after basis verification.

+ - Findings require concrete reachability/impact and exact owner; do not mutate source or Git.

- ## Output Contract

+ ## Output Map

- Lead with capability, typed refs, mode, basis, scope, exclusions, checks, and P0-P3

- findings labeled `Standards`, `Spec`, or both. Preserve finding evidence, impact,

- remediation, verification, acceptance refs, and limitations. Report both verdicts;

- missing Spec authority stays `Not verified`. Add profile-specific evidence only when

- that profile was selected. Finish with the frozen local verdict, separate external

- status, residual risks, and gaps.

+ Return basis/scope, standards and spec disposition, findings/observations, evidence,

+ checks, exclusions, and `Not verified` gaps.

- ## References

+ ## Reference Map

- - Basis: [usage](references/usage.md), [Worktree](references/worktree-checklist.md),

- [fixed basis](references/checklist.md), [Standards/Spec](references/standards-and-spec.md),

- [examples](references/worktree-examples.md).

- - Conditional profiles: [protocols](references/protocol-contracts.md),

- [OpenAPI governance](references/openapi-contract-governance.md),

- [frontend CSS governance](references/frontend-css-governance.md),

- [documentation](references/documentation-authority-review.md),

- [motion](references/interaction-motion-review.md),

- [visual evidence](references/frontend-visual-evidence.md),

- [code quality](references/code-quality.md), [design](references/codebase-design.md),

- [UI components and tokens](references/ui-components-and-tokens.md),

- [grounding](references/project-grounding.md).

- - Integration: [external evidence, final-result sync, and Forgeway](references/review-integration.md).

- - [Eval cases](references/eval-cases.md).

+ - Read [fixed-basis checklist](references/checklist.md) for immutable commit/range/snapshot or verified-package review; read [worktree checklist](references/worktree-checklist.md) for current Worktree review. Do not combine their basis acquisition rules.

+ - Read [Standards/Spec](references/standards-and-spec.md) for every review.

+ - Load each conditional reference named in the Route Map only when its condition applies, including [code quality](references/code-quality.md) for maintainability findings.

+ - Read [usage](references/usage.md) for review modes and boundaries.

+ - Maintainers only: read [eval cases](references/eval-cases.md); do not load it during ordinary runtime.