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 --id CR0007

3. You say: “Plan a sprint over it.”

   The breakdown gate checks the batch is ready - refined, sized, criteria written - and refuses if it isn’t. Then it opens the sprint and shows you the plan.

   The explicit form: sprint plan --goal done --write

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. The story reaches Done only when they pass - 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: verify_ac run --id US0012

5. You say: “Review it.”

   A fresh reviewer that did not write the code runs an adversarial pass - does it really refuse deleting someone else’s task? - and files what it finds as evidence. You, or someone other than the author, ratify it. The author can never sign off their own work, so your AI isn’t marking its own homework.

   The explicit form: critic sprint-review then your sign-off

6. You say: “Close the sprint.”

   The close records your sign-off, transitions the stories to Done, marks the epic and the request Complete, validates the retro and extracts its lessons, and runs the gate. One command, the whole ceremony.

   The explicit form: sprint close --apply-signoff --principal "you"

Note

Want it hands-off? You say “take this to done” and the goal-driven autosprint runs the batch to its goal - build, verify, review - and closes with a reconcile and review. 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, 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, sprint planning, two-role review, executable acceptance criteria.