autonomous-sdlc

claude-code-config

A complete, opinionated Claude Code configuration: agents, skills, slash commands, MCP servers, hooks, and observability — engineered to take an idea from one-line concept to merged PR without a human in the loop.

This is the harness behind a multi-agent AGILE pipeline that runs on cmux (native macOS terminal for AI development) with full real-time visibility, parallel worktree execution, and automatic bug triage.

The harness ships as two mirror plugins — autonomous-sdlc for Claude Code (in this repo at plugins/autonomous-sdlc/) and autonomous-sdlc for Codex (in the sibling nix-install repo). Same plugin name, same pipeline shape, same skill IDs — so the SDLC workflow is portable across both runtimes. On Claude Code the plugin's skills surface as bare slash-commands (/brainstorm, /create-story, etc.) labelled (autonomous-sdlc) in the autocomplete; on Codex they're invoked as Use autonomous-sdlc <name>.

We also use the Codex mirror as an automated adversarial review layer for Claude Code work. Claude Code remains the primary builder in this harness; Codex runs the same autonomous-sdlc plugin from the sibling repo to inspect Claude-produced changes, file high-signal issues, and challenge implementation quality from an independent runtime before work is considered done.

---

What this harness achieves

 idea ─▶ /project-init ─▶ git repo + GitHub remote + labels + CLAUDE.md + PROJECT-SEED.md
         │
         ▼
     /brainstorm ─▶ REQUIREMENTS.md  (seed-aware: skips what /project-init already answered)
         │
         ▼
     /generate-epics ─▶ STORIES.md + epic-NN-*.md + NFRs
         │
         ▼
     /build-stories (parallel, autonomous)
         │  ├─ Discovery agent → dependency cohorts
         │  ├─ Build agents   (×5, worktree-isolated, TDD)
         │  ├─ Coverage gate  (×5, enforces 90%+)
         │  ├─ Review agent   (×5, senior-code-reviewer)
         │  └─ Merge agent    (sequential, rebase-before-merge)
         │      └─ Bugfix loop on failure (classify → fix → retry ×2)
         ▼
     E2E gate (Playwright, at epic boundaries)
         │
         ▼
     /project-review · /coverage · /create-project-summary-stats

Every phase emits structured events to a cmux sidebar pill + progress bar + ledger, and mirrors milestones to Telegram so long-running runs can be monitored away from the machine.

---

The workflow, in five phases

Phase 0 — Bootstrap (/project-init)

A lightweight bootstrapper for a brand-new repo. Turns an empty directory into a project the rest of the pipeline can consume — no more, no less.

Pre-flight checks gate the run: empty directory (dotfiles allowed), gh authenticated, no existing .git/. Then a 5-question interactive discovery (objective, tech stack, architecture style, repo visibility, catch-all) — deliberately narrow. Database, testing, CI/CD, and deployment questions are not asked here; those belong to /brainstorm.

Output:

• git init + first commit
• GitHub remote created via gh repo create (public or private per your answer)
• 26 standard labels applied (bug, enhancement, priority:, epic:, etc.) plus any project-specific ones
• .gitignore tailored to the detected tech stack
• CLAUDE.md — lightweight scaffold with placeholders for sections /brainstorm will fill in later (testing strategy, CI/CD, DB, deployment)
• PROJECT-SEED.md — structured handoff file that /brainstorm detects and reads to skip redundant questions

The skill closes by suggesting /brainstorm as the next step. If you already have a repo, skip Phase 0 — /brainstorm runs fine without a seed, just asks the full 8-question set from scratch.

Phase 1 — Discovery (/brainstorm)

A Senior PM persona conducts a structured 8-question interview covering problem space, personas, success metrics, capabilities, scope boundaries, technical constraints, priority, and acceptance criteria. Output: REQUIREMENTS.md. If PROJECT-SEED.md exists (from /project-init), the interview skips questions already answered (objective, stack, architecture) and drills deeper into product/market fit — requirements, user problems, competitive landscape, success metrics. After the interview, CLAUDE.md is updated with any newly determined sections (testing, CI/CD, database, deployment).

Phase 2 — Planning (/generate-epics, /create-epic)

Transforms REQUIREMENTS.md into a modular AGILE structure:

• STORIES.md — master overview
• docs/stories/epic-NN-<name>.md — INVEST-compliant user stories in {Epic}.{Feature}-{NNN} format
• docs/stories/non-functional-requirements.md — perf, security, reliability targets

/create-epic lets you add more epics interactively without redoing discovery.

Phase 3 — Build

Two paths depending on how much control you want: