The Four Project Reviewers

In one line: Four reference reviewer roles use focused checklists; findings and actual invocation are evidence to inspect, not prevention guarantees.

What: Four project-specific reviewer agents provide structured review of declared scope. The checklist examples describe a multi-tenant reference profile, not universal requirements. Model names below are illustrative bindings; select and verify an approved model/version under §5.2. Maintained templates live in templates/agents/; copying a checklist does not prove its checks ran.

API Reviewer (model: Sonnet)

Checks FastAPI endpoints for consistency with established patterns. The checklist covers:

• Pydantic BaseModel for all request/response schemas (not raw dicts)
• response_model declared in route decorators
• Correct HTTP status codes (201 for creation, 404 for not found)
• Authentication via Depends(get_current_user)
• Tenant context via Depends(get_current_tenant)
• Tenant-scoped database access via get_tenant_session(tenant_id)
• Pagination for large responses
• No N+1 query patterns

When to dispatch: After adding or modifying API routes. A generic session helper where tenant-scoped access was intended is a risk to investigate, not proof of leakage by its name. Verify effective roles, policies, tenant-context handling and own/cross/absent-context behavior under §2.4.

Security Reviewer (model: Opus)

Reviews code for authentication bypass, authorization flaws, injection vulnerabilities, and tenant isolation issues. The checklist covers:

• Authentication enforced on all protected endpoints (portal endpoints have token-based auth instead)
• Role-based access control: require_role() guards on admin-only endpoints
• Parameterized SQL queries (:param not f-strings)
• No eval(), exec(), or __import__() with user input
• PII never logged
• MinIO bucket access scoped to case and tenant
• Error messages do not expose internal details

When to dispatch: After changes to user input, access control, data queries or file operations. Evaluate the chosen review binding against representative missed-defect and false-positive cases; a model tier does not establish security assurance.

Compliance Reviewer (model: Opus)

Reviews code for the project's regulatory obligations (where the domain has them). A representative checklist:

• Every AI output has input provenance (what data was the decision based on?)
• Model identification present (which model, version, prompt template?)
• Concise decision rationale, source/evidence references, relevant outputs and tool receipts retained under an approved access/retention policy; never require hidden chain-of-thought
• Confidence scoring with documented methodology
• A version foreign key on AI execution records for traceability
• No PII in log files or error messages
• Audit trail is append-only (never modified)
• Risk-signal changes require accountable review, including false-positive harms; evidence-based correction is allowed through the approved policy path

When to dispatch: After relevant changes to AI decisions, data processing or audit trails. A qualified owner establishes applicable obligations and reviews the interpretation. AI review supports that work; the model label does not establish compliance.

Migration Reviewer (model: Sonnet)

Reviews Alembic database migrations for safety, RLS compliance, and asyncpg compatibility. The checklist covers:

• Classify reversible and irreversible changes; verify forward migration and the approved compatible rollback, roll-forward or restore path
• Existing rows meet new constraints through a reviewed default/backfill/validation strategy; assess locks and mixed-version readers/writers
• For the RLS profile, inspect declarations and test actual effective-role own/cross/absent-context behavior; FORCE does not constrain superuser/BYPASSRLS
• Tenant-context policy handles missing/malformed context and pooled-connection reuse under the selected access model
• For SQLAlchemy textual named binds, exercise the actual binding path; CAST(:param AS jsonb) avoids the adjacent-colon ambiguity, not a general ban on PostgreSQL casts
• Migration revision chain is correct (single head)

When to dispatch: Before integrating a migration under this reference profile. Migration risk includes data, concurrency and recovery semantics, not just syntax; assess the selected reviewer and run the real migration tests.

Evidence: Prior incidents informed these checklists; actual reports must identify the candidate, reviewed scope, findings and gaps. Template presence does not establish invocation or correct interpretation. Use the real SQLAlchemy binding reproducer and migration-built database checks described in the selected profile rather than infer safety from a checklist tick.

---

Skilled implementers — write the brief, then choose the role. The pilot partner reported nineteen dispatches using a generic worker despite fitting specialist roles being available. That is a selection-policy gap, not proof that a typed worker would have performed better. Every authorized dispatch names its worker type and the reason; generic is allowed only when no available skilled type fits, with that reason recorded. The approved brief remains the requirements source. A short life under §7.10 follows the same rule.

Shipped role card	When it fits	Intended capabilities and boundary	Matching review
debugger	Reproduce and diagnose one defect before fixing	Read/search, scoped edits and checks; no guessed fix or unrelated cleanup	Lens matching the actual diff
frontend-implementer	UI, layout, accessibility, design system	Scoped UI edits/checks; no invented business decisions	API/security/compliance as affected; determination lens when applicable
backend-implementer	Services, APIs, async, performance	Scoped service edits/checks; no silent contract or permission changes	API; security for auth/tenant effects
test-writer-fixer	Regression proof, probe honesty, flakiness	Scoped test/fixture changes; no weakening acceptance to obtain green	Lens matching the behavior being verified
deployment-engineer	CI/CD, workflow and merge-forward work	Scoped configuration/checks; no weakening gates or self-authorized deployment	Security; API/migration as affected
data-migration-engineer	Schema, migrations, RLS, backfills	Scoped migration/checks; no unapproved destructive data operation	Migration and security; compliance as affected

Cards live in templates/agents/. Their Read/Grep/Glob/Edit/Write/Bash declarations express intended capabilities, not runtime grants. Bind least privilege through the actual host. Reviewers assess without editing; a shell-capable reviewer is not technically read-only merely because Edit/Write is absent. The existing migration reviewer declaration includes Bash: restrict it at the host or record that enforcement gap.

Host bindings are discovered, not assumed. Where the host exposes matching roles, reference mappings include Debugger, Frontend Developer, Python Expert / Code Architect, Test Writer & Fixer, Deployment Engineer and Database Engineer respectively. These are examples of names a configured host may expose, not a claim about any vendor's built-ins. Otherwise supply the complete role card through the host's supported instruction mechanism, subject to higher-priority instructions; do not pretend it is a system override. Record portable role and actual binding separately.

Receipt and detector: the pre-dispatch checklist in skill:s4u-loop-dispatch requires type + reason and paired reviewer. tests/test_worker_role_cards.py checks packaging, not runtime compliance. Over the next twenty landings, compare turns and review findings per PR by role/binding, controlling for task mix, model, size and unfinished work. The batch-2 receipt is pending; typed workers are not yet shown cheaper or better. The optional adopter-provided ui-determination-reviewer is not a fifth shipped card. See §5.4–5.5, §7.10, appendix-c and appendix-k.