Planning, permissions and working with Git

In module 11 you installed Claude Code and in module 12 you taught it your project. Now comes the week-two question: how do I let an agent change real things without a mistake ending up on the site my customers see? The answer is not a prompting trick. It is a process, the one software teams have used for decades, to which Claude Code adds a mode for planning without touching anything and a permission system.

What this module says about Claude Code is verified against the official documentation as of October 2026; if something does not match, the docs win.

Why plan before the agent touches anything?

Ask a coding agent to "add a contact form" and it starts editing files within seconds. Sometimes it solves the wrong problem: the one it understood, not the one you had. Anthropic’s best practices guide says it in those words: letting Claude jump straight to coding can produce code that solves the wrong problem. That is why it recommends separating research and planning from implementation.

The tool is plan mode: Claude reads files, runs commands to explore and writes a plan, but edits nothing until you approve. There are three ways in:

• Shift+Tab inside a session, more than once if needed, until the status bar shows "⏸ plan mode on". The same key cycles through the permission modes in the next section.
• /plan at the start of a single message, to plan that request and nothing else.
• claude --permission-mode plan when you open the session from the terminal.

The loop the documentation proposes has four steps: explore (have it read the parts of the project that matter), plan (have it list which files it will change and in what order), implement (you approve the plan and let it build) and commit (tests, build and a commit with a clear message). When the plan is ready, Claude offers three choices: approve and continue in auto mode (or auto-accepting edits, depending on your session), approve and review each edit one by one, or "No, keep planning". Ctrl+G opens the plan in your text editor so you can correct it by hand.

That moment, the plan on screen and nothing touched, is where your business judgment is worth the most. Read it like a contractor’s proposal: did it understand what I asked? Will it touch something it should not? How will it check that it worked? Fixing a plan costs one message; fixing an implementation, an afternoon.

I want to make this change: [DESCRIBE THE CHANGE IN ONE OR TWO SENTENCES, WITH THE RESULT YOU EXPECT TO SEE].

Before editing anything:
1. Explore the project and explain to me in plain language how the part we are about to change works today.
2. List every file you will modify or create, and what you will change in each one.
3. Tell me what could break with this change and which parts of the project you will NOT touch.
4. Propose how we will check it worked: which tests you run, which build command, what I should look at in the browser.
5. If anything I asked for is ambiguous, ask me before assuming.

Do not make any edits until I approve the plan.

What is Claude Code allowed to do, and how do I control it?

Every action that could change your system goes through a permission system you configure, and the program enforces it, not the model: an instruction in your CLAUDE.md shapes what Claude tries to do, but does not change what Claude Code lets it do. In Manual mode (the one the docs call default), reading and searching inside the project folder never prompts; editing files, running commands (except a fixed read-only set, such as listing folders or the read-only forms of git) and searching the web do.

When you approve a command with "Yes, and don’t ask again", Claude Code saves that rule in a project file and stops asking for that command in that repository. On top of that there are modes that move the line of what runs without asking:

• Manual (default): only reads run without asking. For sensitive work.
• acceptEdits: also accepts file edits and common folder commands (create, move, copy).
• plan: the plan mode from the previous section.
• auto: a second model, a classifier, reviews each action instead of you and blocks what looks risky: going beyond the scope of what you asked, merging a pull request no human has approved, pushing secrets to a public repository. Today it is the mode terminal sessions start in. If you say in the conversation "don’t push until I review", the classifier treats that as a boundary.
• bypassPermissions: everything runs with no prompts and no checks. The docs are blunt: only in isolated environments like containers or VMs without internet access, where Claude Code cannot damage your host system. On your work computer, never.

Rules refine any mode. They are evaluated in this order: deny (forbidden, in every mode, even bypassPermissions), ask (always prompts) and allow (runs without asking); a deny always beats an allow. They are written as the tool plus a pattern: `Bash(npm run *)` allows any npm script, `Bash(git push *)` as an ask rule forces a prompt before code leaves your machine, `Read(./.env)` as a deny rule stops it reading the file where your keys live. You view and edit them with /permissions, and they live in three files:

• ~/.claude/settings.json: you, in every project.
• .claude/settings.json inside the project: everyone who works in that folder. You commit it to the repository so the team gets the same rules and hooks.
• .claude/settings.local.json inside the project: only you, only there. It is where Claude Code saves your "don’t ask again" approvals; when it creates the file it keeps it out of Git, and if you create it by hand, add it to .gitignore yourself.

What is Git, and why should you understand it even if you do not code?

Git keeps a project’s history. In the words of the official Pro Git book, every time you save, Git takes a picture of what all your files look like at that moment and keeps that series of snapshots. It is your safety net and your audit trail: you see what changed, go back to any earlier snapshot and work on a draft without touching what is published. Six words are enough, and a contract analogy makes them concrete:

• Repository. The project folder with its entire history. The contract file: the version in force, every earlier version and who changed what.
• Commit. A saved snapshot with a message. "Version 4: payment clause moved to the 5th". A good message says what and why; the how is already in the files.
• Branch. A working copy where you change things without touching the version in force. The main branch (usually called main) is the signed contract; your branch is the draft with tracked changes.
• Pull request. The formal proposal to bring your branch into the main one. GitHub defines it as a proposal to merge code changes into a project, with room to discuss and review them first. It is the review before signing: it shows every line that changes, and someone other than the author approves.
• Merge. Incorporating the approved changes into the main branch. The draft becomes the contract in force. In many projects, ours included, that act triggers publication.
• Revert. Undoing a commit with a new commit that reverses it, without erasing history. Like an amendment that voids a clause: the record is kept, which is what you want when you need to explain what happened.

You do not need to memorize commands: Claude Code runs them, and with GitHub’s gh tool installed it knows how to open pull requests and read comments. What you need is the vocabulary: "create a branch for this", "commit what we have", "open a pull request", and to review what it generated before submitting.

How do I undo something that went wrong?

You have two safety nets. The first lives inside Claude Code: checkpoints. Every message of yours that starts a turn creates a checkpoint with how the files looked. With /rewind, or by pressing Esc twice with the input box empty, you open a menu listing your messages from the session and choose: restore code and conversation, conversation only, or code only. It is ideal for "that last idea did not work, let’s go back".

But it has limits the docs spell out: it only tracks edits made with Claude’s file tools, not what a terminal command changed (an rm, an mv); it usually does not restore what a subagent edited; and the snapshots are deleted after a while. It is not a replacement for version control. The practical rule: within a session, rewind; across sessions, or for anything already published, Git (a branch you discard, a revert, going back to a commit).

What is the safe workflow, end to end?

This is what you will repeat every time an agent changes something real. With practice it is twenty minutes for a medium change.

1. 1New branch. "Create a branch called contact-form". From here, nothing touches the published version.
2. 2Plan. Plan mode with the prompt above. You read the plan as a proposal, correct it, approve it.
3. 3Implement. Leave plan mode and let it build. If you see something odd, Esc and redirect.
4. 4Tests and build. "Run the tests and the build, and show me the output". The guide insists on giving Claude a check it can run: tests, a build that passes or fails, a screenshot to compare. If you can’t verify it, don’t ship it.
5. 5Review the diff. /diff shows you everything that changed without leaving the session. Read it with the review prompt below, or ask a subagent to review it in a clean context: whoever did not write the code judges it more coldly.
6. 6Commit. A message explaining what and why. Claude writes it; you read it.
7. 7Pull request. "Open a pull request" with what changes, how it was tested and what the reviewer should look at.
8. 8Review. Someone other than the author approves. If you work alone, that is you the next morning, or a second agent with reviewer instructions; the human in the loop from module 9 has a name here.
9. 9Merge and deploy. Merging into the main branch publishes. If deployment is automatic, the merge is the "send to customer" button.

Who reviews what: the agent reviews consistency, code errors and whether the tests pass; you review that the change is the one you asked for, that it did not touch what it should not, and that what customers see says the right thing. That half is not delegated, because it is Diligence: whoever merges answers for what got published. And the whole workflow depends on how well you described the task; module 17 turns that description into a specification with acceptance criteria and tests as the contract.

Review the current diff of this project as a demanding reviewer who did not write the code. The goal of the change was: [GOAL IN ONE SENTENCE].

Answer point by point:
1. Does the change do exactly what was asked, no more and no less? List any modified file or function that is not needed for the goal.
2. What could break? Edge cases, empty data, text in both languages, small screens.
3. Is there anything a customer would see wrong: copy, prices, links, spelling?
4. Is there any sensitive data, key or path from my computer that should not be in the code?
5. Do the tests cover the change? If not, which test would you add?

Report only findings that affect correctness or the goal, not style preferences. For each one: file, line and what you would do.

Prepare the commit and the pull request for the current change.

Commit message: a first line of at most 70 characters saying what changed, in [LANGUAGE], then two or three sentences with the why. Do not describe how (that is in the code).

Pull request description, with these sections:
- What changes and why (for someone who did not see the conversation).
- How it was tested: commands you ran and their result, and what I checked by hand.
- What the reviewer should look at, in order of risk.
- What does NOT change, to narrow the review.

Show me both texts before running anything. Do not push until I say so.

The next module, "Skills, commands, hooks and subagents", makes what you just did by hand repeatable: the review prompt as a command of your own, the tests before every commit as a hook that cannot be skipped, and a reviewer subagent with its own instructions.