A first change (quick taster)

You drive the whole lifecycle in plain language - you say what you want, the agent works out what you mean, and the discipline holds underneath. Here is one feature - adding the ability to delete a task - from a raw idea to a closed, reviewed sprint, told the way you would actually experience it: what you say, and what your team does.

Note

This is the two-minute version, and it assumes a project already exists. For the full journey from nothing, see the greenfield walkthrough (build a task-management app from an empty repo); to adopt code you already have, see the brownfield walkthrough.

Tip

You never have to memorise commands. Everything below also has an explicit command (shown as the explicit form) for when you prefer it - but the point is that you don’t need it.

1. You say: “Add a delete function to the task list.”

   The request is filed in the discovery backlog - an idea, not committed work yet. It is cheap and unsized. (For a bigger design question - “should deletes be soft or permanent?” - you’d say “open an RFC” to weigh the options first.)

   The explicit form: cr create

2. You say: “Refine that into work.”

   refine breaks the request into an epic and sized stories, each with plain, checkable acceptance criteria - for example:

   US: A user can delete their own task
     AC1  Given a signed-in user with a task,
          When they delete it, Then it is removed from their list
     AC2  Given a task they do not own,
          When they try to delete it, Then it is refused

   Now it is delivery work. If the criteria are still rough, you say “tidy up the acceptance criteria” and the team makes each one concrete.

   The explicit form: refine apply --request CR0007

3. You say: “Plan a sprint over it, so a user can delete their own tasks.”

   The breakdown gate checks the batch is ready - refined, sized, criteria written - and refuses if it isn’t. Then it opens the sprint with its Sprint Goal - one sentence, 20 words or fewer, which the close will judge - and shows you the plan.

   The explicit form: sprint plan --stories Ready --goal done --write --sprint-goal "A user can delete their own tasks, and nobody else's"

4. You say: “Build the first story.”

   Dani (your Engineering seat) writes the failing test first, implements the delete, and runs the story’s acceptance criteria. Passing is what lets the story reach Done later, when you sign the run - so “done” is a fact the tool checked, not a claim.

   verify_ac run --id US0012   ->   ac=2 pass=2 fail=0

   The explicit form: story implement --story US0012, then verify_ac run --id US0012

5. You say: “Review it.”

   A fresh reviewer that did not write the code - Sam, your QA seat - is briefed from the story itself, runs an adversarial pass - does it really refuse deleting someone else’s task? - and records one verdict. A REJECT gets one more round, from the same reviewer, once the fixes are in; a story still rejected after that is carried to a later run, not argued over. The author never reviews their own work, so your AI isn’t marking its own homework.

   The explicit form: critic brief --unit US0012 --seat qa, then critic record --unit US0012 --verdict approve --reviewer Sam --author Dani

6. You say: “Close the sprint.”

   The first close scaffolds the retro and stops, so you can fill its Keep, Stop and Try. The second runs once: it records your judgement of the sprint goal, validates the retro and extracts its lessons, runs the gate, reconciles, and files a one-page sprint report that names every known issue rather than hiding one.

   The explicit form: sprint close, then sprint close --retro RETRO0001 --goal-verdict achieved --note "an owner can delete a task; anyone else is refused"

7. You say: “Sign it.”

   You read the report and sign the run, once. Signing moves the stories to Done, each gated on its criteria having passed, closes the epic and the request above it, and records one signature. It refuses a signer who wrote or reviewed a story in the run.

   The explicit form: sprint sign --report RPT0001 --principal "you"

Note

Want it hands-off? You say “take this to done” and the goal-driven sprint runs the batch to its goal - build, verify, review - closes once, and hands you the report to sign. You set the goal and the acceptance criteria; the team drives the proven lifecycle to it.

What you are left with

The delete feature, shipped: every story Done against passing criteria, a review record naming a reviewer who wasn’t the author, a retro with its lessons, a signed sprint report, and the request marked Complete - all as plain files under sdlc-studio/, true to the code that was actually built. You got there by talking.

Next: the concepts behind each step - the two-backlog model, the sprint, review, close and signature, executable acceptance criteria.