ai-sdlc-claude

Tech lead / architect

Read time: 8 minutes.

What this is

Design review moves to plan mode, before code exists, when changing course is editing a document. Review of the diff is layered: Claude runs identical passes on every PR according to a policy you write, and humans review intent and risk. You own the two files that make this consistent, REVIEW.md and CLAUDE.md, and you approve anything the organisation classes as high risk.

Your commands

/sdlc:status --gate tech-lead     high-risk specs and plans waiting on you
/sdlc:review <PR>                 run the review passes locally
/sdlc:review --tune               monthly: rate last month's findings, tighten REVIEW.md

What you own

REVIEW.md (scaffolded from the course example). It defines the passes (bugs; security; compliance against spec.md, plan.md and design principles), what Important means (would break behaviour, leak data, or breach a policy; everything else is a Nit), the nit cap, and what to skip (generated files, what CI enforces). Findings never approve or block; branch protection still needs a code owner.

CLAUDE.md: one page a new joiner needs on day one. Commands, conventions, architecture, “Things Claude gets wrong”. The rule: a mistake made twice earns a line. Anything stale costs context every session; cut it.

What you approve

Artifacts with risk: high (money movement, auth, PII, regulated data, infrastructure, migrations):

• the spec before the product owner merges it;
• the plan before build starts (Claude stops and says so);
• and you are typically the code owner on the PR. Ask engineers to bring you the plan for high-risk work, not the diff. Interrogate it the way the plan skill does: what could break, riskiest step, options not taken.

Monthly tuning (30 minutes)

/sdlc:review --tune pulls a month of findings. Rate them: Important ones accepted vs noise, useful nits vs churn. Tighten “What Important means”, adjust the nit cap, extend “Do not report”. Findings that repeat a mistake become CLAUDE.md lines; findings that cite a policy skill and keep appearing mean the skill is not triggering or drifted (tell its owner).

What you will see

A review summary ends with SDLC-REVIEW: important=1 nits=2 passes=bugs,security,compliance, a verdict paragraph (“does the change do what the plan intended, is the risk acceptable”), and findings grouped by pass with file:line and a concrete fix.

What only you can do

Define Important vs Nit for this codebase. Approve high-risk designs. Decide what belongs in CLAUDE.md.

What you never have to do

Read every line of every PR. Human attention goes to intent and risk; the mechanical evidence is attached.

This site is open source. Improve this page.