ai-sdlc-claude

Platform engineer

Read time: 15 minutes. You can change the repo, CI, branch protection and (for regulated orgs) managed settings.

What this is

You install the loop once per repository and own the machinery that makes it safe to run fast: the config file, the hooks, CI automation, evals, monitoring, sandboxing, and the rollback path. After setup, each other role has one or two commands and never touches YAML.

Install (30 minutes)

# Claude Code
/plugin marketplace add bibutikoley/ai-sdlc-claude
/plugin install sdlc@ai-sdlc            # or a trial: claude --plugin-dir /path/to/ai-sdlc-claude

# in the product repo
/sdlc:setup --dry-run                   # shows every file it would create
/sdlc:setup                             # asks: platform, tracker, chat, monitoring, commands, protected paths, roles

Re-running is safe: existing files are never overwritten; a changed template lands beside the original as <file>.sdlc-new; --force overwrites. Your existing sdlc.config.json values win on upgrade.

Then the printed human checklist:

CI secrets: ANTHROPIC_API_KEY (or Bedrock / Vertex / Foundry variables), plus tokens named in .mcp.json.
Branch protection on the default branch: PRs only, code owner review required, no direct pushes (bots included).
A production environment with required reviewers = release managers (GitHub) or a protected environment whose deployers are the release managers (GitLab).
CODEOWNERS from the example: CLAUDE.md, REVIEW.md, sdlc.config.json, .claude/**, workflows.
Policy skill templates in .claude/skills/ handed to their owners to fill in.
Regulated org: tailor managed-settings.example.json and deploy via MDM / admin console.

What you own

| Thing | File(s) | Notes | |—|—|—| | Config | sdlc.config.json | commands, healthy outputs, test globs, protected paths, secret paths, environments, thresholds, roles. Itself a protected path. | | Hooks | plugin hooks/; repo .claude/settings.json for extras | protected-paths, test-guard, secrets-guard, format-on-edit, production-gate, plan-sync, session-context. Bash + jq, < 200 ms, all tested. Decisions log to .sdlc/gate.log. | | Managed settings | managed-settings.example.json + README | deny lists, sandbox, allowManagedHooksOnly (re-declare the gates there), approved marketplace, minimum version. | | CI (GitHub) | .github/workflows/sdlc-*.yml | spec-on-intent, review (claude-code-action; pin to a SHA), @claude mention, evals, ci-triage (reusable), control-band, deploy (+ weekly rollback rehearsal). | | CI (GitLab) | .gitlab/sdlc/.gitlab-ci.sdlc.yml | same jobs; include it; schedules with SDLC_SCHEDULE=evals|control_band|rehearse_rollback; SDLC_BOT_TOKEN with Developer role. | | Evals | evals/ | 20–50 real tasks; run.sh gates config changes at evals.passThreshold. | | Monitoring | monitoring/bands.yaml, detect.py, sources.py | deterministic detection (Western Electric rules); adapters github_ci, gitlab_ci, prometheus, sentry, grafana. Unit tests ship with it. | | Connectors | .mcp.json | only the chosen ones; least-privilege scopes in docs/mcp-connectors.md. | | Rollback | environments.*.rollback | one command per environment, rehearsed weekly in staging by CI. Prove it before anyone needs it. | | Sandboxing | CI runners / managed settings | agent jobs in containers, short-lived scoped tokens, no standing production credentials. |

Model access

Direct API by default. To keep traffic on your cloud agreement: claude-code-action inputs use_bedrock, use_vertex, use_foundry; for claude -p jobs set the provider environment variables. Non-interactive runs act under the agent’s own identity so pipeline logs separate what the agent did from who triggered it.

Order of rollout

docs/adoption-roadmap.md. Foundation first (config, CLAUDE.md, one-command checks), then plan mode + guardrail hooks, then AI review, then intent/spec at the front, then gates + pipeline, then evals/autonomy, then control bands.

Verifying your install

tests/run.sh                                  # in the plugin repo: hooks, scaffold, metrics, detector
python3 -m unittest monitoring/test_detect.py # in the product repo
/sdlc:status                                  # sees the worked example change

Then walk one small change through /sdlc:intent → /sdlc:spec → /sdlc:plan → /sdlc:build and watch a hook block an edit to a protected path. Do this before filling in roles in sdlc.config.json — once any roles.* list is populated, the role-gate hook enforces it, and /sdlc:spec//sdlc:plan//sdlc:build are not the platform engineer’s own commands (add yourself to roles.engineers too if you want to keep running them).

What only you can do

Change sdlc.config.json, hooks, CI, managed settings, protected paths, environments. Add a hook behind a policy that must hold without exception.

If something goes wrong

Hooks not firing: the plugin must be installed/enabled for the session (/plugin list), or in regulated orgs allowManagedHooksOnly is on and the gates must be declared in managed settings.
CI job cannot open PRs: enable “Allow GitHub Actions to create and approve pull requests” or use a bot token.
Detector noisy: tune window_points and tiers in bands.yaml; dismissals from the service owner should arrive as PRs against it.

This site is open source. Improve this page.