Session 2 of 8

Session 2: Agile Sprint One: Prompts, a Backlog & the First Slice

Last session the agent got things wrong. This session's claim: most of those wrongs were in the prompt, not the agent. The agent can't read your mind, it fills every gap in your request with a guess, and every wrong guess is a gap you left. And your wrongs list is about to earn its keep, because in this session project two begins, and project two is the same product. Agile is what happens when a one-shot needs more than one shot: instead of describing everything again, you grow it, plan one slice, build it, ship it, learn, repeat. By the end of in this session your product has its first properly planned slice live on the internet, and that's not the demo, that's just how agile ships.

Here's the loop you're about to live, every box below is yours by the end of Session 3, and then it just repeats, sprint after sprint:

Blue = gstack commands · yellow = documents · grey = things you do · green = the gate. The two side boxes are Sprint 2's special slices.

Part 1: Pick up where you left off (~15 min)

Open Claude Code in your project and run:

/context-restore

Watch it re-read last session's saved state and carry on as if the conversation never ended. Now the why behind the save/restore ritual:

The agent's context window is its entire short-term memory: every message, every file it reads, every command output, all in one window of limited size, measured in tokens. Two consequences:

1. It fills up fast. One debugging session or one "read all my files" moment burns tens of thousands of tokens.
2. Performance degrades as it fills. A crowded context means your actual instructions compete with noise. The agent starts "forgetting" earlier instructions and making sloppier decisions. This is context rot.

Run /context now, a fuel gauge for that window. Glance at it every session. The habits that follow from it live on the context hygiene cheatsheet; the two that matter in this session:

• /clear between unrelated tasks. New task, clean memory.
• The two-corrections rule: corrected the same thing twice and it's still wrong? Stop, every failed attempt sits in the window, actively making the next attempt worse. Revert, /clear, write one better prompt that includes what the failures taught you.

And now /context-save makes sense: it's how you get a fresh window without losing the plot, many short, sharp sessions passing a clean baton, instead of one long session slowly losing its mind.

Part 2: The anatomy of a good prompt (~20 min)

A good prompt for an agent has up to four parts:

1. Intent: what you want and why (the why lets it make good judgement calls on everything you forgot to say)
2. Constraints, what it must/mustn't do: "one HTML file", "no external services", "keep the existing design"
3. Acceptance criteria: what "done" looks like, concretely. "When I paste text with no blank lines, it should still produce cards" beats "handle edge cases"
4. Examples: a sample input and expected output is worth 100 words of description

Compare:

❌ "add a search feature"

✅ "Add a search box above the card list that filters cards as I type. Matching is case-insensitive and looks in both question and answer text. When nothing matches, show 'no cards found' rather than an empty page. Don't change anything about how cards are created."

The second one isn't cleverer. It's just decided. Prompt engineering is mostly deciding what you want before you ask. Keep the four parts in hand, in about twenty minutes you'll be writing slices for your backlog, and a slice is exactly this shape.

Two more habits:

• One change at a time. Five requests in one prompt means five half-done things tangled together. Small prompt → check → commit → next.
• Ask it to verify: end prompts with "…and show me it working" or "run it and check X".

Part 3: Plan mode: look before it leaps (~10 min)

Claude Code has a plan mode (press Shift+Tab to cycle modes): the agent reads and thinks but changes nothing until you approve its written plan.

Use it when the change is big, vague, or touches things you care about. The plan is where you catch the wrong guess before it becomes wrong code, reading a plan takes one minute; untangling wrong code takes a session. (If you could describe the change in one sentence, skip planning and just ask.)

File this away: plan mode is the built-in primitive that gstack's fancier planning commands are built on top of. You'll meet the industrial version in this session.

Part 4: Sprint 1 planning (~25 min)

Agile plans in sprints, fixed time-boxes that each end with something shipped. Yours are session-sized. The moving parts, all on the sprint board template:

• The backlog, everything the product might someday need, as slices, roughly ordered. You already wrote its first draft: your wrongs list. Ask Claude to turn the wrongs list plus your own ambitions for the page into a backlog; expect 10–15 items; don't polish it. Backlogs are living documents.
• This sprint: the 2–3 slices you commit to in this session. Smallest valuable version first.
• The Definition of Done, the quality bar every slice must clear. Yours is on the template, and it has teeth: QA'd clean, deployed, canary green.

Now spec the first slice:

/spec [the first slice only]

Spec the slice, not the system. Five minutes, not sixty; you're only deciding what in this session needs decided. Notice the interview it runs: intent, constraints, acceptance criteria, Part 2's anatomy, asked back at you. Then:

/autoplan

Watch closely: it convenes four reviewers, a CEO asking if it's worth building, an engineer asking if the plan is sound, a designer asking if it'll be usable, a developer-experience critic asking if the repo will stay pleasant to work in, and makes the judgement calls automatically, by written principles. Read its decisions as they scroll past; if it rules against something you'd have kept, override it; it's your project. For slice-sized stakes, a delegated review board is exactly right. Later in the course, for the big project, you'll open this machine's hood and sit in all four chairs yourself.

Part 5: Build, QA, deploy: the agile loop (~40 min)

Build the slice. Then the fix-as-you-find sibling of last session's tester:

/qa

Where /qa-only handed you a report and left the verdicts to you, /qa finds bugs and fixes them on the spot, agile wants the slice done in this session, not filed for later. Same robot, different temperament. (The report-only version still matters: some processes want findings recorded rather than quietly fixed. You'll meet one that insists on it before the course is out.)

Then live, for real. One-time setup first:

/setup-deploy

While you're configuring: the professional secrets pattern, before your first paid API rather than after. Keys and passwords live in a file called .env; .env is listed in .gitignore so git can never see it; nothing secret is ever typed into a prompt or committed to a repo. Say to Claude: "set up a .env pattern for this project and make sure it can never be committed." Then:

/land-and-deploy

/canary

Land-and-deploy takes the slice through checks and out to the live site; canary then watches the deployment, because professionals don't ship and walk away, they ship and observe. Green canary, slice moves to Done, Definition of Done satisfied. That whole chain, spec → autoplan → build → qa → deploy → canary, is one increment, and it's the loop you'll run again solo before the next session.

/context-save. Sprint 1 is open; the board is yours.

---

What you just learned without noticing

Requirements writing (intent, constraints, acceptance criteria, examples, exactly what professional specs and user stories contain), working memory as a finite resource (true of agents, teams, and you in an exam), and Scrum, roughly, sprints, a backlog, increments, a Definition of Done, plus continuous deployment and canary releases, which is how the biggest sites on the internet ship many times a day.