Garfield

Use Garfield only when the user explicitly requests it during implementation. Review the current slice, preserve the user's intent, fix material current-diff problems, and stop when the slice is ready.

1. Capture the Intent

Before delegating review, record:

• requested behavior and intended changes
• compatibility expectations and non-goals
• diff/base and touched files
• repository instructions and relevant specs
• tests, generated artifacts, dependencies, and validation already run

Use this snapshot to judge every finding. Do not let a reviewer redefine the task.

2. Build the Effective Policy Set

Discover applicable repository policies under policies/**/*.md, excluding policy indexes and templates. Compare them with Garfield's bundled policies by intent and scope:

• repository-wide policy for the same concern: use it and omit the bundled policy
• narrower or adjacent policy: keep both
• unrelated policy: ignore it

Bundled policies:

• Read references/code-comments.md when comments or docstrings changed.
• Read references/implementation-minimalism.md when the slice adds guards, fallbacks, adapters, configuration, or defensive tests.
• Read references/interface-design.md when public/module boundaries, lifecycle, ownership, or naming changed.
• Read references/test-quality.md when tests, fixtures, or test obligations changed.

3. Select Review Tasks

Always review:

• behavior and spec alignment
• repository instructions
• validation coverage

Consider specs/docs, dead code, delayering, type boundaries, generated/dependency artifacts, comments, minimalism, interface design, test quality, and effective repository policies. Mark every candidate applicable or skipped from concrete diff evidence.

4. Delegate Reviews

Use one no-edit subagent per applicable task or policy. Give each reviewer only the slice context and policy it needs. Keep at most three Garfield subagents open at once:

1. Start up to three reviewers.
2. Collect and close completed reviewers.
3. Start the next reviewers.
4. Drain review agents before independent verification.

If subagents or required capacity are unavailable, stop and report that Garfield cannot run.

Require findings in this form:

[severity][evidence:<label[,label]> <locator>] path:line - concern. impact: <impact>. fix: <smallest change>.

5. Triage and Fix

Accept a finding only when the current diff introduced or worsened it, made evidence stale, or omitted a required artifact.

• Fix blocker and high findings when the smallest fix preserves intent.
• Fix medium findings only when they are current-diff-caused and local.
• Reject vague, preference-only, or evidence-free findings.
• Defer unrelated hardening, broad cleanup, and out-of-intent behavior changes.
• Preserve unrelated user changes.

After material edits, run targeted validation and repeat only the reviews affected by the change. Use a separate verification advisor when validation is uncertain, the slice is risky, generated/dependency artifacts changed, or this is the final readiness pass.

Stop after repeated findings, three cycles without progress, unavailable subagents, or when the smallest fix requires broad or unclear behavior changes.

Handoff

Report only:

• garfield: pass or garfield: blocked
• validation commands and results
• independent verification result when used
• residual blocker/high/medium concerns
• deferred adjacent improvements or unclear behavior changes

Do not include a cycle diary or generic review advice.

Never

• Never run Garfield for standalone review or non-code iteration.
• Never substitute an agentless review for required subagents.
• Never change APIs, permissions, defaults, validation policy, serialization, or unrelated code outside the captured intent.
• Never revert unrelated user work.