sdlc-kit GitHub

sdlc-kit

Four phases for AI that builds software: understand first, prove last.

AI tools that write software are fast, and being wrong is still expensive. They guess what you meant and grade their own work. With sdlc-kit the AI confirms what you asked, explores before it changes anything, has its work checked by separate AIs, and lets a score decide whether it is done.

See how it works How to set it up

Claude Code·Codex·Gemini·pi
Works in any project and any field, with any AI tool for writing software that can read files and run commands.

Four phases, with checkpoints between them

Each phase writes down what it did, and the next one starts only when its checkpoint opens. The red arrows show where work goes back when something fails.

1 · Intent 2 · Plan 3 · Build 4 · Evidence Deliver A person checkpoint · a person confirms plan approved risk flag · a person approves review passes · goes on plan wrong or incomplete, or the same failure twice all must-pass scenarios passed, and at least 95% of all no place to run scenarios, and that blocks delivery gaps found: 1–2 rounds review fails: fix, review again anything else: the change failed

  1. 1 · Intent what you asked

    The AI writes down what you asked, what it understood, and the risks in that understanding. It rates how clear the request is, and below 90% it keeps working before going on: it reads the code, reproduces the bug, checks the spec, or asks whoever made the request, right on their ticket. It asks only the questions whose answers would change what gets built.

  2. 2 · Plan one plan page

    Helper AIs explore the rules, the data, the logic and how users reach it today. One plan page holds before and after, side effects and the scenarios to test. A separate AI checks it for gaps.

  3. 3 · Build the smallest complete change

    The AI makes the smallest change that fully does what the plan says. A separate AI reviews it, assuming it is wrong. A failed review sends it back to be fixed and reviewed again; after three failures the work stops for a person.

  4. 4 · Evidence scored proof

    The project's real checks run first, then every scenario is played as its user. A script scores the result, so the AI cannot grade its own work. Failures go back to Plan or Build, depending on the cause.

The score is checked from top to bottom. Each kind of return happens at most three times, then a person decides. A scenario that could not run counts as failed, and only a person can remove a scenario.

What you get

The AI follows the same written rules in every phase. Here is what they give you.

You confirm what matters
The AI records your approval only after you say so plainly. Silence, "continue" or its own judgement do not count. If an approved page is edited later, its checkpoint and every one after it close again.
Side effects found before any change
The helpers look at everything else that reads or writes the same data before anything is changed, and each side effect gets a scenario that checks it. Facts that earlier work verified are kept, and the next job reads them first.
Separate AIs check the work
The helpers who explore, the reviewer and the tester each start fresh. None of them is the AI that wrote what it checks, and none of them changes it. If no separate helper is available, that gap is written down.
Proof behind every "passed"
Every pass points to the record of what was run or seen. If there is nowhere to try something, it is marked as blocked, never as passed. A bug fix needs a test that failed before the fix and passes after it, and a test for new behavior is seen failing once without it. The list of scenarios becomes your own checklist.
Delivered means what was verified
Closing a job is refused if what was delivered differs from the version that was checked. Risky work always needs your word first, under every setting: deleting data, reshaping stored data, changing what other systems rely on, security, infrastructure, and sending the work beyond this computer. What the AI reads along the way counts as information; it takes instructions only from you.

What it cannot do

The kit records and counts; it never runs an AI itself, so the work is only as careful as the AI tool you use. It saves the words of each approval but cannot prove who said them. A scenario with nowhere to run cannot pass, so some work stops and waits for you. The records stay on the computer where the work runs and are not saved with the project, so back them up.

For the person who sets it up

This part uses commands. Three steps set it up in a project, and the README on GitHub has the details. After that, ask for a change in plain words.

  1. git clone https://github.com/cskwork/sdlc-kit ~/sdlc-kit ln -s ~/sdlc-kit ~/.claude/skills/sdlc-kit

    Once per computer. The link is for Claude Code; use your tool's skills folder. Without one, add For SDLC work, read ~/sdlc-kit/SKILL.md and follow it. to AGENTS.md, CLAUDE.md or GEMINI.md.

  2. cd /path/to/your-project ~/sdlc-kit/sdlc.sh init

    Once per project, or per shipping unit of a monorepo. Creates .sdlc/, which git ignores. On Windows, run sdlc.sh in Git Bash or WSL.

  3. $EDITOR .sdlc/config.md

    The only project-specific file: the build, test, lint, run and e2e commands, the qa tool, human_gates (default intent; add plan to approve every plan) and the memory folder.