Push standards to reviewers, pull-only for implementers
Push standards to reviewers, pull-only for implementers
Two feed mechanisms
| Mode | Mechanism | Cost |
|---|---|---|
| PUSH | CLAUDE.md auto-import, system prompt, explicit prompt injection | Permanent context tax |
| PULL | Skills, knowledge/ lookup, MCP tools, on-demand grep |
Zero baseline; token cost only when fetched |
Rule
| Agent | Standards feed | Why |
|---|---|---|
| Implementer | pull (skills, knowledge/) |
Save token budget for code |
| Reviewer | push (CLAUDE.md, prompt) | Standards ARE reviewer's yardstick |
| Planner | mixed | Push architecture rules, pull style rules |
Why the asymmetry
Implementer job = write code. Code fills context. Standards compete with code for tokens. Pull only relevant subset per task.
Reviewer job = compare code against standards. Standards absent from context = reviewer invents them = drift. No comparison possible without both sides loaded.
Concrete
/code-reviewskill → EMBED standards list in skill prompt (push)/security-reviewskill → EMBED OWASP + security rules (push)- Implementer skills (
develop-userscripts,frontend-design) → LINK standards, agent pulls on need okf-prompt-lookuphook = pull mechanism for implementers
Applies to
- Code review — style, correctness, complexity standards
- Security review — OWASP, threat-model rules
- Accessibility review — WCAG rules
- Performance review — perf budgets, big-O expectations
- Design review — palette, type, signature rules
Anti-patterns
- Reviewer skill that says "look up standards in knowledge/" — reviewer won't; drift certain
- Implementer prompt with all 87 rules pushed — code budget starved
- Standards duplicated across push + pull → maintenance burn; single source, dual feed
Source
Matt Pocock workshop 2026-07-03.
Cross-refs
- [[delegate-to-subagents-by-default]] — reviewers ARE subagents with fresh context
- [[review-in-fresh-context]] — combine push standards + fresh context for cleanest review
- [[okf-lookup-before-acting]] — pull mechanism at work