Day 1 wrap-up

Day 1: From chat to spec · Wrap-up · 10 min

Three hours ago a task was a question you asked and an answer you pasted. It is now an assignment written in four parts, and when it matters it is a file in the repository.

What you learned

Lesson 1: an agent has tools, a working directory and a loop, so the unit of work is a diff, and done is the verification command plus the output line carrying its verdict.
Lesson 2: a prompt is goal, bounds, verification, stop; the parts you leave out get invented, and your uncertainty goes in the stop condition, as a question rather than a guess.
Lesson 3: plan mode (Shift+Tab, /plan, claude --permission-mode plan) shows the proposal while rejecting it is free; reject on a stated defect, and press Ctrl+G instead when the plan is mostly right and one step needs fixing.
Lesson 4: those four parts, numbered and in a file, are a spec, and non-goals do more work than goals.
Lesson 5: a criterion that cannot make a command exit non-zero is a hope; keep each binary, one command and one assertion, and give the undecidable ones a human name.
Lesson 6: CLAUDE.md is a standing charge on every turn, so cut lines whose removal causes no nameable mistake, move file-specific ones to .claude/rules/<name>.md with a paths: glob, run /context before deciding the file is ignored (often it never loaded, or another instruction file sits beside it), and /clear between unrelated tasks.

Review

Answer these from memory first. There is no answer key on purpose: the ones you cannot answer name the lesson worth re-reading, and that signal goes the moment you scroll to a solution. The recap gives the short answer to most; each question names the lesson with the full one.

Name the three things an agent has that a chat session does not, and what actually decides which files it may change. (Lesson 1)
What two pieces of evidence do you paste into a pull request to show an agent's change is done? (Lesson 1)
List the four parts of an agent prompt, and what the agent does with each part you omit. (Lesson 2)
Where does your uncertainty about an unfamiliar codebase belong in a prompt, and what does a good version look like? (Lesson 2)
Give three ways to enter plan mode and one way to make it a project's default. (Lesson 3)
What does Ctrl+G do at the plan approval step, and when is it a better answer than No, keep planning? (Lesson 3)
What is in a spec that is never in a plan, and what is in a plan that is never in a spec? (Lesson 4)
Rewrite this as a criterion that can fail: pending transactions are handled sensibly in the daily summary. (Lesson 5)
A requirement has no command that can decide it. What do you do with it, and what must you not do with it? (Lesson 5)
You suspect your CLAUDE.md is being ignored. What do you run first, and what are the two most likely findings? (Lesson 6)

Challenges

No reveals, no solutions; one is enough.

1. The rest of LEDGER-7

The ticket logs two more complaints — the Bahraini dinar row, LK-015 in the fixture, and the sign on the LK-013 refund — and rules that neither is a defect.

First decide whether that ruling holds. Then write the spec for your decision at specs/ledger-7-rest.md: goal, non-goals, numbered criteria, the criterion-to-command grid, bounds, verification, stop, done. If Exercise 3 ran out of time at step 5, bounds and verification belong here.

The spec covers only the branch you chose. If the ruling holds, its deliverable is the non-goals and a criterion pinning today's strings. If it does not, its bounds must admit you are editing tests that pass today.

One snag: the gated run is already red when you start. Redo Exercise 2's fix or scope the spec to the plain command, and say in verification which one decides.

2. Thirty lines of a file you actually depend on

Get a CLAUDE.md from a repository you work in under 30 lines with the line test. Prove it twice: the same real task run against both files with the diffs compared, and the whole /context breakdown saved for both. Then write down the one line you cut that you were wrong about.

3. A plan that passes and still lies

Construct a plan that passes every item on the Exercise 2 checklist in ../work/plan.md and still produces wrong code. Then write the single spec line that would have caught it, and which of the four prompt parts it belongs to.

Before you close the laptop

Day 2 starts from the shipped sandbox/ lane, which nothing today edited, so what you built inside day1-work does not travel. ../work is the one directory no reset or end-of-day command here touches.

Save. Copy the keepers (your trimmed CLAUDE.md, your rules files, and specs/daily-summary.md if it is still there) into ../work with the save line from Exercise 4's reset, if you have not already.

Reset for a clean copy to work the challenges in, from inside day1-work:

Swift lane

cd .. && rm -rf day1-work && cp -R sandbox/swift day1-work && cd day1-work

Kotlin lane

cd .. && rm -rf day1-work && cp -R sandbox/kotlin day1-work && cd day1-work

Clean up when you are done for the day, from inside day1-work. This removes day1-work and keeps ../work, as every Day 1 cleanup does: Day 2 and Day 3 write there too, and the Day 3 wrap-up removes it when you are done for good.

cd .. && rm -rf day1-work

Day 1 finished: recap read, ten questions answered from memory.

Sources

cc-core-01 through cc-core-06 and cc-core-33 — Shift+Tab, /plan, --permission-mode plan, Ctrl+G, the approval answers, defaultMode in .claude/settings.json, and plan mode proposing without editing, from Permission modes.
cc-core-12, cc-core-15, cc-core-40 — @path/to/import and .claude/rules/<name>.md with a paths: list; such a rule loads when Claude reads a matching file, and imports load at launch, so they do not reduce context (accessed 2026-09-23), from Manage Claude's memory.
cc-core-18, cc-core-19 — /context and /clear, from Slash commands.
cc-core-35, cc-core-36 — CLAUDE.md loading at startup before your first message, and reloading automatically after a compaction, from Explore the context window.
cc-core-32 — the version checked against, from the Claude Code changelog.