scriptoriumadmin/claude-skills
1
0
Fork 0
mirror of https://github.com/alirezarezvani/claude-skills.git synced 2026-08-28 04:24:58 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
claude-skills/commands/cs-backend-review.md
Claude 5954dfcce1
cleanup(engineering): address remaining 7 polish items from PR #718 bot review 
Bundle of low-medium-severity follow-ups that were deferred when PR #720
landed the 3 blocking bugs. None of these silently break correctness —
they're discoverability, consistency, and convention gaps.

Bugs / code-quality:

1. fullstack_decision_engine.py: asymmetric cadence matching
   `inputs.cadence in target or target in inputs.cadence` produced
   asymmetric results — "per-pr" matched "per-pr-with-gates" but not
   vice versa. Profile cadences are intentional alternatives joined
   by "-or-" (e.g. "weekly-or-on-demand" → {weekly, on-demand}); now
   parsed explicitly with "-with-..." modifier suffixes stripped.

   Verified:
     cadence=per-pr → matches per-pr, per-pr-with-gates, daily-or-per-pr
     cadence=daily  → matches daily-or-per-pr (only)
     cadence=on-demand → matches weekly-or-on-demand

2. fullstack_decision_engine.py: rename weight_total/weight_matched
   to w_total/w_matched. Backend and frontend engines already use the
   short form; this aligns the three files as a family.

3. sync-gemini-skills.py: 3-way name collision in dedup logic
   The naive `if name in seen_names: name = parent-name` handled one
   collision but not two. Three "status" skills under "skills" parent
   dirs produced two entries both named "skills-status". Now suffixes
   with -2, -3, ... so each entry has a unique index name. Eliminates
   the duplicate-name ambiguity surfaced when checking PR #713.

Discoverability:

4. senior-fullstack/SKILL.md: surface fullstack_decision_engine.py in
   the labeled "Tools" section at the top. Previously only mentioned
   inline in the body (5 references buried in the Stack Decision Matrix
   section); not findable when scanning the SKILL.md.

Conventions / v2.8.0 compliance:

5. commands/cs-{fullstack,backend,frontend}-review.md: add explicit
   "## Forcing-question library" section header per the v2.8.0
   convention. Each lists the 7 questions inline with a pointer to
   the canonical reference file.

6. agents/engineering/cs-{fullstack,backend,frontend}-engineer.md:
   alphabetize the specialist list in the description field (annotated
   that workflow body order remains dependency-driven). Makes the
   three agent descriptions consistent as a family.

7. agents/engineering/cs-{backend,frontend}-engineer.md: promote the
   "Cross-agent invocation" content out of Workflow 3 into a dedicated
   "## When invoked as fork target" section with an explicit question-
   skip table per parent agent (cs-fullstack-engineer, cs-cto-advisor,
   cs-vpe-advisor, cs-ciso-advisor for backend; cs-fullstack-engineer,
   cs-content-creator, cs-product-manager for frontend). Closes the
   cross-agent contract gap the bot flagged.

Not changed:

- CLAUDE.md plugin-schema section (already corrected in #715; bot's
  "stale text" claim was incorrect — it was reading the cumulative diff)
- Workflow body specialist order (intentional dependency order; would
  break the SLO-first → API → DB → migration → observability sequence)

Verification:
- All 3 decision engines: --sample → exit 0
- Cadence matching: 3 test cases pass cleanly
- check_plugin_json.py --all → 0 FAIL, 0 WARN, 69 OK
- sync-gemini-skills.py → 392 unique names (was 391 unique / 1 dupe)
2026-05-21 13:47:08 +00:00

3.8 KiB
Raw Blame History

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.

Related commands

  • /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