sdlc

Why

Everybody obsesses about the latest raw performance of coder LLMs at satisfying SWE benchmarks. However, much like at one point the size of transistors became a secondary performance factor to CPU cores orchestration and parallelism, we are already experiencing the same with coding agents.

Improving productivity with agents in a way comprehensible by humans, is about orchestration. The word on the street now is that merging is the bottle neck. But I believe that is the case only because work is not done before to create and update a hierarchy of tasks. There is a task tree, which after work becomes a merge (and not just a merge queue). Conflicting drift in code between branches is a function of guardrails, architecture, design, and isolation. Now to splitting plans into tasks, there are two ways : vertical (add payments : frontend, backend, data), horizontal (add views to the frontend for features: a, b, c). The design and task writing agents must be able to look at prior art as required. This requires formalizing data about the agentic software development liffecycle.

My goal is to create a tool that does what Anthropic and OpenAI are building internally, a self improving, software delivery system driven by agents and monitored by humans. Basically attain something close to : you've got a distribution layer with sales, you've got the vertical integrations and the cash, now, you want software quality and speed to be a function of cash and time, with minimal friction. What was unachievable before : more money => faster development, better software, scalable. Now it's achievable in theory, however, agents need tools to coordinate splitting tasks, merging, deploying, analyzing feedback etc. Making humans at the center is in my opinion a fool's errand, they shouldn't be at the center more than a shepherd is at the center of his herd

Where to keep humans

"Humans not at the center" doesn't mean humans nowhere. It means humans only where a signal can't replace them:

• Intent: what to build and why. Every other judgment derives from this.
• Invariants: what must never happen, such as security boundaries, data rules and spending limits.
• Calibrating the judge: spot-checking a sample of decisions the agents made, not reviewing each one.
• Exceptions: the inbox.

The failure mode of taking humans out is intent drift. The system keeps optimizing its proxies, and the proxies slowly diverge from what anyone wanted. The defense isn't more human review. It's making the objective explicit and checkable, which is where your definition-of-done hypothesis becomes load-bearing rather than hygiene.

Distance from here to there

┌───────────────────────────────────────────────┬────────────────────────────────────────────────┐ │ Loop stage │ Status │ ├───────────────────────────────────────────────┼────────────────────────────────────────────────┤ │ Design → split → dispatch → merge │ Built │ ├───────────────────────────────────────────────┼────────────────────────────────────────────────┤ │ Record every attempt │ Built, with deeper audit planned │ ├───────────────────────────────────────────────┼────────────────────────────────────────────────┤ │ Variants and selection │ Hypothesis │ ├───────────────────────────────────────────────┼────────────────────────────────────────────────┤ │ Deploy │ Missing │ ├───────────────────────────────────────────────┼────────────────────────────────────────────────┤ │ Feedback after the merge, attributed to tasks │ Missing. This is the keystone. │ ├───────────────────────────────────────────────┼────────────────────────────────────────────────┤ │ Policies that learn from outcomes │ Missing, and meaningless without the row above │ ├───────────────────────────────────────────────┼────────────────────────────────────────────────┤ │ Hosted, multi-machine control plane │ Planned │ └───────────────────────────────────────────────┴────────────────────────────────────────────────┘

What is it

A Coding harness plugin that takes work from an idea to merged code: design it, split it into tasks, and let agents implement each task in its own git worktree, with a record of who did what and what it cost.

Current plugin compatibility : Claude Code

It is made for projects that last, not only one-off prompts. Work is kept in beads, so a project's designs, tasks and history build up across sessions, days and people, and any session can pick the work back up.

It builds on beads for tasks and worktrunk for worktrees. It works with a human in the loop, or fully autonomously.

For projects that last

A one-off request and a long-running project go through the same flow. What carries a project over time:

• Work outlives sessions. Tasks, dependencies and progress are beads. Close Claude Code, reboot, or come back a week later: /sdlc:dispatch sees what is ready, what is running and what stopped, and carries on.
• New work builds on old work. design reads earlier designs and existing beads as prior art, and says whether the new design reuses, extends or replaces them. split links new tasks to the ones they depend on.
• Work can be added at any time. A new epic with /sdlc:build, one task with /sdlc:create-task, a finer split of an existing bead with /sdlc:split, or a bead created by hand: the queue takes it in.
• Progress stays focused. Epics already in progress go first, so started work gets finished before new work starts.
• The history accumulates. Every worker attempt stays on its task, with session, model, agents, cost and outcome. /sdlc:stats sums it per epic, and /sdlc:logs shows what each attempt did.
• The supervisor holds no state. It's a script, run as a background command of your session; it looks at beads and the running processes fresh each round, so any session, or any person, can take over supervising at any time.

Features

• Design before code. design finds prior art (docs, code, existing beads, and connected sources with your permission), removes ambiguity, and states the design in the session, editing existing docs wherever the design makes them wrong or incomplete.
• Task graphs with real checks. split turns a design, a plan or a prompt into beads tasks. Each task has acceptance criteria, a path scope, dependencies, and a verify command that exercises the behaviour.
• One task, one worktree, one session. dispatch starts a headless Claude Code session per task, in its own worktree. That worker implements the task, delegating to your installed agents when your configuration says so, then merges and closes it.
• Merges that can't skip the checks. A worker merges through one finish step. While holding the branch's merge queue, it rebases, runs the verify command, runs the project's own optional [pre-merge] hooks (type check, lint, tests, from .config/wt.toml, proposed by /sdlc:hooks) and merges. When that fails, the worker, which has the task's context, fixes it.
• Review before merging, when a task asks for it. --review agent sends the diff to a separate reviewer session, which asks for changes or approves; --review human opens a gate that stops the task until a person reviews the diff and resolves it.
• Work order. Epics already in progress come first, then priority. Within an epic, tasks that unblock the most others go first.
• Crash recovery. The session id is stored on the task before the worker starts. After a crash or a reboot, /sdlc:dispatch resumes each worker's own conversation in its worktree.
• Integration modes. Tasks merge straight into main, into an epic branch that is merged at the end, or into an epic branch that ends as a pull request.
• Audit trail in beads. Every attempt records its session, model, agents, cost, duration and outcome on the task, plus an event bead. /sdlc:stats and /sdlc:logs read them back.

Requirements

• Claude Code (developed against 2.1.272)
• beads bd 1.2.2 or later, with the Dolt backend. See Tracker backends for other backends under consideration.
• worktrunk wt 0.77 or later
• git, jq, python3, uuidgen, and setsid and pgrep, found on Linux. macOS isn't supported yet (see the roadmap).
• gh, only for the epic-pr integration mode

Installation

Pick one.

Claude Code plugin (recommended: it includes the hooks, and the skills are named /sdlc:*):

claude plugin marketplace add https://github.com/Igosuki/claude-sdlc && claude plugin install sdlc@claude-sdlc

Skills CLI (skills only, without the hooks, and named without the sdlc: prefix):

npx skills add Igosuki/claude-sdlc

A prompt to paste into Claude Code:

install the sdlc plugin at https://github.com/Igosuki/claude-sdlc

Then, in Claude Code (run /reload-plugins if a session was already open):

/sdlc:setup     # once per machine: checks beads, worktrunk and the other tools, recommends companions
/sdlc:init      # once per project: beads, integration mode, target branch, local settings

To try it from a local clone, for one session only:

claude --plugin-dir /path/to/claude-sdlc

Quick start

The whole workflow in one command:

/sdlc:build add a page that lists the latest orders

1. build enters plan mode, states the design and the doc edits in the plan, and asks for your approval.
2. It then applies the doc edits and commits them if anything changed, splits the plan into tasks and asks you to approve them, and dispatches.

Step by step:

/sdlc:design add a page that lists the latest orders
/sdlc:split
/sdlc:dispatch

After a restart, or to pick up work in progress, run /sdlc:dispatch again. Your first feature walks through a whole run.

Skills

Skill	What it does
/sdlc:setup	Checks this machine for the tools sdlc needs and recommends companions
/sdlc:init	Prepares a project: beads, integration mode, target branch, local settings, wake hooks
/sdlc:hooks	Reads the project and proposes wt hooks for dependency installs and merge checks
/sdlc:build <request>	Design for your approval, split into tasks for your approval, dispatch
/sdlc:design <request>	States a design grounded in prior art, editing docs the design makes wrong
/sdlc:prior-art <topic>	Reports what already settles part of a topic, in the repository, beads and connected sources
/sdlc:split [docs | bead-id] [prompt]	Turns a design, a plan or a prompt into a beads task graph, or splits a bead
/sdlc:create-task <request>	Creates one task that dispatch can run
/sdlc:dispatch [id...]	Supervises the work: starts workers in order, resumes crashed ones, reports when a person is needed
/sdlc:status	Workers, crashed or stopped tasks, the ready queue, the settings
/sdlc:stop [task | epic]	Stops one worker, every worker under an epic, or all of them
/sdlc:recover <task> [instructions]	Resumes, finishes after a fix by hand, starts over, or splits a stopped, failed or crashed task
/sdlc:review <task | epic | pr>	Reviews a diff against its acceptance criteria and resolves a human review gate
/sdlc:verify <task | parent | epic>	Runs the checks that finishing it would run, and explains a failure
/sdlc:analyse [branch]	Finds functions over the complexity thresholds and files refactor tasks
/sdlc:stats [epic]	Cost, duration, models and agents per task and per epic
/sdlc:logs <task>	What a task's workers did
/sdlc:clean	Removes leftover worktrees, branches and merge queues once you approve

The full contract of each skill is in the skills reference.

Configuration

Two places, depending on who has to agree. Per machine, in .claude/sdlc.local.md: how many workers run at a time. Shared through beads: the integration mode, the target branch and the default review level.

bd config set custom.dispatch.integration epic-merge   # direct (default), epic-merge or epic-pr
bd config set custom.dispatch.review human             # agent (default), none or human

Every setting, with its default, is in the settings reference.

Documentation

The docs follow the Divio system: tutorials to learn by doing, how-to guides for a problem you have, reference to look something up, explanation for how it works and why. The index, with one line on when to read each page, is docs/README.md.

Start with your first feature. To change the plugin itself, read CONTRIBUTING.md.

Other harnesses

sdlc runs on Claude Code today. The Claude-specific parts sit in a few places: how a worker session is started and resumed, how its log is read, and the hooks. Codex CLI and OpenCode have close equivalents for each, and Ollama can serve local models to all three. Harness neutrality maps them out.

Roadmap

Highlights from the roadmap:

• GitHub Issues, and other trackers, alongside beads
• worker sessions on Codex CLI and OpenCode, and local models through Ollama
• several machines sharing the queue
• dedicated QA agents, and custom statuses
• deduplication of similar tasks

Inspirations

• metaswarm
• The Claude Protocol

License

MIT