ai-sdlc-claude

Security, compliance, brand, UX, and other policy owners

Read time: 8 minutes. You own a written policy. You do not need Claude Code; an engineer pairs with you once.

What this is

Your policy becomes a skill: a short file Claude loads whenever it does work your policy covers (writing a spec, planning an API, generating UI copy). The policy is applied while the work is done, so violations become rare, and conflicts are flagged for you in the spec instead of discovered in a review weeks later. Where the policy must hold without exception, a hook or a review pass sits behind the skill and makes violation close to impossible.

Your artifact

.claude/skills/<your-policy>/SKILL.md, from the templates the platform engineer scaffolded (security-policy, compliance-policy, brand-guidelines, ux-standards, secure-api-review). Each starts with a header: source of truth (link), owner (you), last reviewed (date). The body is the policy in instructions Claude can act on, one page at most.

Example (from the course):

---
name: secure-api-review
description: Apply the API security standard. Use whenever creating or modifying an external-facing endpoint...
---
1. Authentication: every endpoint requires the gateway JWT; no anonymous routes outside /health.
2. Input validation: validate request bodies against the OpenAPI schema and reject unknown fields.
3. Audit: every state-changing endpoint emits an audit event with actor, action, entity and timestamp.
4. Data classification: fields tagged pii must never appear in logs or error messages.

Your first hour (with an engineer)

1. Pick the one rule that is enforced inconsistently today.
2. Write it into the template from your source of truth; the engineer uses Claude to help phrase it.
3. Test it triggers: ask Claude to do the relevant task three different ways and confirm the skill loads.
4. Open the PR. You approve it; it merges; every engineer has it in their next session.

What you decide

• Flagged concerns. Every spec starts with a table of conflicts that cite policies. The product owner brings you the rows that cite yours. You decide; the decision is written in the table; the spec cannot be accepted until every row has one. Claude never resolves a policy conflict on its own.
• Skill changes. When the policy changes, the skill changes in a PR you approve. No rollout campaign.
• What needs a hook. If your rule must hold without exception (secrets in the repo, edits to migrations without a ticket, production without authorization, a command outside someone’s role), ask the platform engineer for a hook. The plugin already ships secrets-guard, protected-paths, production-gate, test-guard, role-gate.

What you will see

• Review findings tagged with your policy’s name in the Security or Compliance pass.
• /sdlc:metrics (ask your platform engineer or leadership for the report, or /sdlc:status for your own gates): findings citing your policy should fall toward zero once the skill applies it at build time. If they do not, the skill is not triggering or its text drifted from the official policy.

Regulated enterprises

With the platform team, tailor managed-settings.example.json: deny lists (secrets, network egress), sandbox, credentials protection, managed-only hooks (re-declare the gates there), approved marketplace, minimum version. managed-settings.README.md explains each key in control terms. Engineers cannot override any of it.

What only you can do

Say what the policy is and approve its encoding. Decide flagged concerns.

What you never have to do

Review every change for your policy by hand, or attend a review board to catch violations after the fact.

This site is open source. Improve this page.