herdr-reviewer-profile

Read and apply Courier architecture decision records. Use when planning, reviewing, or implementing changes with architecture, infrastructure, interface, routing, or cross-service impact.

Enforces the Linear proof boundary for planning, implementation, review, readiness, and merge. Use for multi-surface work, ownership or plan changes, exact-head evidence, Scope Review, or moving a ticket to Done.

Use only when Gabriel explicitly requests an Oracle review or remote Mac canary.

Adversarial cross-model review of a GitHub PR or architecture plan/blueprint via the local pi-review CLI driving pi. Use for PR review, cross-model review, second-model review, plan review, blueprint review, or architecture-document review — including GitHub PR URLs, local Markdown files, and Notion blueprint links. Oracle is used only when Gabriel explicitly requests it.

Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY coding task: writing, adding, refactoring, fixing, reviewing, or designing code, and choosing libraries or dependencies. Also use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT use for non-coding requests (general knowledge, prose, translation, summaries, recipes).

Bounded adversarial read-only review.

Courier TypeScript standards for style, error handling, async work, imports, and tests. Use before writing or reviewing TypeScript in backend, services, or related repos.