Files
wehub-resource-sync a1fa97429b
Release / Tag + GitHub Release (push) Waiting to run
Deploy Documentation to Pages / build (push) Waiting to run
Deploy Documentation to Pages / deploy (push) Blocked by required conditions
Sync Codex Skills Symlinks / sync (push) Waiting to run
chore: import upstream snapshot with attribution
2026-07-13 12:41:47 +08:00

3.8 KiB

description, argument-hint
description argument-hint
Backend engineering review — walks the 7 Matt Pocock forcing questions (read/write ratio + QPS, tenancy, sync vs async, data sensitivity, pattern, RPO/RTO, SLO), picks the language + pattern profile, forks into specialists (api-design-reviewer, database-designer, migration-architect, slo-architect). Invokes the cs-backend-engineer agent with context fork. <problem or service to review>

/cs:backend-review — Backend engineering review

Use the cs-backend-engineer agent (uses context: fork) to handle this inquiry:

$ARGUMENTS

Forcing-question library

Canonical source: engineering-team/skills/senior-backend/references/forcing_questions.md (7 questions, one-per-turn, recommendation + canon citation per question).

  1. Read/write ratio + one-year p99 QPS
  2. Tenancy model (single / shared / isolated multi-tenant)
  3. Sync request/response vs async (queue) vs event-driven
  4. Data sensitivity tier (public / internal / PII / PHI / PCI)
  5. Monolith / modular monolith / microservices (team-size justification)
  6. RPO and RTO
  7. SLO + named error-budget consumer

Routing protocol

  1. Walk the 7 forcing questions in engineering-team/skills/senior-backend/references/forcing_questions.md. One per turn. Recommend with cited canon. Track in /tmp/backend-grill-<date>.md.
  2. Surface kill criteria — e.g., "microservices, team size 5" trips (Newman's MonolithFirst). STOP and resolve.
  3. Run the deterministic profile picker:
    python engineering-team/skills/senior-backend/scripts/backend_decision_engine.py \
      --team-size <N> --qps-p99 <N> --read-write-ratio <ratio> \
      --tenancy <single-tenant|shared-multi-tenant|isolated-multi-tenant> \
      --data-sensitivity <public|pii|phi|pci> \
      --pattern <monolith|modular-monolith|domain-bounded-services|microservices|serverless> \
      --language-preference <typescript|python|go|rust|java|kotlin|dotnet>
    
  4. Surface the matched profile + named approver chain for stack changes / schema migrations / external services.
  5. Fork into specialists in dependency order:
    • slo-architect FIRST — no SLO, no design
    • api-design-reviewer — API contract
    • database-designer + database-schema-designer — schema + ERD
    • migration-architect — only if changing existing schema
    • observability-designer — golden signals + alerts
    • ci-cd-pipeline-builder — pipeline matching cadence target
    • senior-security + adversarial-reviewer — before public launch
    • ra-qm-team/* — if data sensitivity is PHI / PCI / regulated
    • cs-karpathy-reviewer — before any commit

Output expectations (≤ 200-word digest)

  • Matched profile + reason
  • Three SLO targets (p50, p99 latency + uptime)
  • RPO + RTO
  • Named approver chain (tech-lead + on-call + DBA + ...)
  • List of specialists invoked + artifact paths
  • Recommended next sub-skill

Anti-patterns

  • Recommending Kafka / event-driven before naming the second team that needs it.
  • Recommending microservices without team-size ≥ 30 + platform team + bounded-context independence.
  • Designing the API without forking into api-design-reviewer.
  • Recommending a DB without QPS + read/write ratio (Q1 unanswered).
  • Auto-approving a production schema migration. Always name the on-call + DBA.

Customization

Profiles live at engineering-team/skills/senior-backend/profiles/. Four built-in: node-express, fastapi-python, django-monolith, go-or-rust-microservice. Copy one to <your-org>.json and adjust constraints / SLO floor / approver chain.

  • /cs:fullstack-review — full-stack lens (parent)
  • /cs:frontend-review — for API consumer side
  • /cs:engineer-grill — cross-role 21-question grill
  • /slo-design — explicit SLO design via slo-architect
  • /karpathy-check — Karpathy 4-principle review