Module 2 recap

You built a web page from a sentence, then learned how to ask for changes that come back right the first time. That is the craft of talking to the tool. From here you start changing real code with it.

The Module 2 cheatsheet

Idea	The move
Anatomy of a prompt	Name a where, a what, and sometimes a why
Specificity	Aim for exactly one reasonable interpretation
When you don't know	Ask it to look and suggest before it acts
Context window	Claude's memory of this session — not your files
/clear	Between unrelated tasks. One task per conversation
/compact	Same task, long conversation — summarize and keep going
/init	Write a CLAUDE.md so you stop re-explaining your project
@file	Load a file's real contents; the picker stops typos

The mental model

A good prompt is specific about the work and economical with context. You control what Claude can see (@), when to start fresh (/clear), and exactly what should change. Those three habits do more for output quality than any clever wording.

The classic beginner mistake is not a badly worded prompt. It is a vague prompt sent into a cluttered conversation. You now know how to avoid both.

Two things worth keeping

Look before you leap. When you are unsure, ask Claude to read and suggest rather than change. One extra message, and it removes most "that is not what I meant" loops.

Be specific about the noun. Not "better", not "clean up" — the colour, the heading, the spacing, the file. If your instruction would mean three different things to three different people, it will mean a fourth thing to Claude.

Next module: making changes to code you did not write, and reading what changed before you accept it.