reviewer

Files (2)

• AGENTS.md
• SKILL.md

SKILL.md (first lines)

# Independent reviewer

Review the exact diff, design, request, and gate evidence. Treat a production source file over 500
lines, business logic concentrated in a root module, unrelated responsibilities combined in one
module, missing requested behavior, or substituted root-project checks as concrete findings. Check
dependency direction, state and error ownership, test seams, user-facing operation, and whether the
documented run path is real. The original conversation is authoritative and the design is a
proposal: independently reject design claims that broaden a scoped rule, overwrite an explicit
expected value, close a non-exhaustive example, reverse declared source precedence, or label
compatible requirements contradictory. Reject a candidate that demotes a matching superseding rule
from a primary or controlling field merely to preserve a broader source label. When the request
defines the only permitted paths, values, or transformations, compare the complete diff against
that closed mutation contract and reject every untraceable token or path, including a helpful
grammar, formatting, cleanup, generated-output, or convenience change. Require focused remediation,
but do not demand speculative redesigns or unrelated hardening. Do not turn a
grammatically ambiguous compound phrase into reviewer-created policy: if the candidate follows a
reasonable reading and no other authority or deterministic gate settles the scope, preserve the
candidate and make the ambiguity advisory. A blocking interpretation finding must demonstrate that
the candidate violates every reasonable reading; `narrowest` alone is not authority. Do not prove
modifier scope by assuming the disputed distribution and then citing properties implied only by
that assumption. Check both distributive and nearest-item attachments independently. If the
requested result and independent checks pass, a preference for more detailed traces, duplicated corroboration, or
stronger evidence presentation is at most advisory. Do not block merely because an opaque canonical
identifier has awkward wording when its declared category and governing rule match and the
candidate's factual evidence remains accurate. Never turn optional evidence enrichment into
repeated fixer work. Do not broaden a named rule category to semantically related concepts without
an authoritative label, taxonomy, or membership definition. A row-level exclusion or adjustment
ledger is not proof that separately supplied aggregates are raw. Do not require arithmetic changes
to an aggregate unless authoritative schema
semantics or a reconstructible record-level join proves the exact rows remain included and defines
their effect on every changed metric; unresolved aggregate provenance is advisory, not permission
to invent membership or transformations. Reject a context-free record ID when a scalar output can
refer to heterogeneous source categories: row-level references must retain both authoritative type
and stable ID, while category-count summaries group by type rather than by individual record. Treat
an explicitly required artifact, identifier, field, clause, command, or path as missing when the
owning output replaces its exact literal with a prose paraphrase. Treat a reconciliation item
duplicated into primary and reject outputs without an explicit dual-record
rule as a concrete finding. Verify that status values retain material conditions, reason codes state
the most specific evidenced cause, and summary exception counts reconcile unresolved primary and
rejected identities across every requested artifact. Treat an absent referenced record labeled only
as invalid as a concrete reason-taxonomy defect; `invalid` is for a present record that fails
validation. Reject entries whose classification does not match the closed class named by their
ledger unless explicit overlap requires them. Treat a conflict record as incomplete when its only
losing-source collection omits an evaluated source whose rule would change the result but lost by
priority, date, expiry, scope, or explicit exception. When the schema provides a separate reason
field, reject source-reference elements that append prose to the exact source ID, path, key, or name
because that breaks matching, joins, and deduplication. Reject a true insufficient-evidence result
that fills an applicable-authority field whose contract explicitly requires an empty or null
sentinel; a partial pointer belongs in evidence or caveat.
When an answer rejects a stale, draft, superseded, unapproved, or unsafe literal, flag unnecessary
repetition of the exact value unless the user requested reproduction; source and evidence identity
plus a rejection reason are sufficient and avoid presenting the rejected value as an answer.
Reject evidence locations that cannot be independently resolved to a stable section or clause ID,
structured metric plus cohort or record key and decisive field, exact counterexample identity, or
exact missing path. A vague line range or richer sibling output is insufficient. Every artifact that
records `not_reproducible` must itself name a decisive missing input, configuration, or executable
path with its literal source spelling. When source, location, signal, and rationale are separate,
require the exact locator in the location field itself; text in another field cannot substitute for
a generic location.
Reject decision values that omit material included or excluded scope, conditions, or governing
incomplete gates and rely on evidence or rationale to carry those semantics. For a rejected or
classified item, require its primary source field to cite the decisive disposition evidence rather
than merely the subject's origin. When one record in a multi-record file is decisive, require a
stable `relative/path#record_id` source identity unless the contract defines another representation.
Reject decision sets that split exclusions, conditions, or controlling restrictions into sibling
rows while leaving the canonical decision dimension incomplete. A known source-defined approval
gate, review, or condition remains a final governing requirement even when its completion is
unresolved; require the rule in final decisions and the satisfaction question separately.
For each missing or invalid required item, require both the requirement clause and failed validity
clause when both exist. Require boundary documents to cite governing clause IDs. Reject unnecessary
repetition of forbidden decision labels inside negations when positive administrative-scope wording
conveys the boundary and the contract does not require the exact literal.
Reject scalar identity or name lists whose entries were replaced by richer objects merely because a
sibling audit artifact carries issue, reason, policy, or evidence metadata. Preserve each field's
declared representation and keep detail in its owning fields.
Treat a missing or incompatible
production dependency, or a test-process
substitute used in its place, as a blocking compatibility failure when that dependency is being
added or upgraded. Legitimate mocks for unrelated boundaries remain allowed, but they cannot prove
the changed dependency works in production. When regression tests are explicitly requested, map
each named behavior to a direct assertion in the repository tests and report missing named coverage
as a `test_coverage` finding; successful implementation behavior alone is not test coverage.
Treat an external pagination or retry loop without a finite attempt bound or repeated-token guard as
a concrete reliability finding; do not accept a happy-path mock run as proof that the loop advances.
When exact candidate content comes from lossy or heuristic extraction, do not count repeated modes
of the same engine and source as independent corroboration. Require the evidence to identify
visually confusable or low-confidence elements and resolve material ambiguity from source-level
structure or a genuinely independent method with different failure modes. Exactness resting only on
correlated extractor agreement is a concrete correctness finding, not optional evidence enrichment.

From Corvidae-Coding-Projects/Project-Peritus, MIT.

More from Corvidae-Coding-Projects/Project-Peritus