garfield

Garfield

Run a skeptical, concise implementation hardening loop after each meaningful code slice. Focus on concrete flaws caused by the current diff, avoid unnecessary work, and preserve the core user or PR intent.

Never activate Garfield unless the user explicitly invokes it. If review-only subagents or required capacity are unavailable, stop and report that Garfield cannot run as specified.

Frame the slice

Before review, inspect:

• repository status, diff/base, and changed files
• applicable repository instructions
• the request, relevant specs and docs, tests, and known non-goals
• generated artifacts, schemas, migrations, lockfiles, manifests, and dependencies
• available validation commands and intentional tradeoffs
• source-app policies from sorted policies/**/*.md, excluding any README.md or policy-template.md

Snapshot the requested behavior, intended behavior changes, compatibility expectations, touched areas, and non-goals. Scope review to the current diff and directly related files. Preserve unrelated dirty-worktree changes.

Build the effective review plan

Compare each bundled policy with discovered source-app policies by intent and scope before choosing reviewers. A repo-wide local policy supersedes a bundled policy governing substantially the same concern even when names differ. A narrower or adjacent local policy supplements it. Omit superseded bundled policies completely; never send one to a reviewer or use it for findings.

Classify every candidate below as applicable or skipped with a concrete diff-based reason. Confidence that the code looks safe is not a skip reason.

• behavior/spec — always
• repository instructions — always
• validation sufficiency — always
• specs/docs — behavior or documented contracts changed or should have changed
• dead code — paths were replaced, removed, or refactored
• delayering — wrappers, flags, adapters, abstractions, indirection, or ownership changed
• type boundaries — typed interfaces, casts, nullable values, any, unknown, or serialization changed
• generated/dependencies — an API/storage schema, migration, generated/reference output, manifest, lockfile, dependency, package artifact, CI dependency surface, or eval recording changed or should change
• code comments — comments/docstrings changed or new non-obvious code makes references/code-comments.md material
• implementation minimalism — guards, fallbacks, wrappers, configuration, edge cases, or supporting tests make references/implementation-minimalism.md material
• interface design — public/module interfaces, lifecycle, naming, ownership, or platform boundaries make references/interface-design.md material
• test quality — tests/fixtures changed or behavior creates a concrete obligation under references/test-quality.md
• each effective source-app policy — its scope governs the slice