Playbooks · Coding agents

Ship a first feature with Claude Code

A solo builder adds one small feature to an existing project with Claude Code, on a branch, with the change reviewed before it merges.

Audience: Solo builder · Stack: An existing project in a git repo, any language · Tool: Claude Code (terminal CLI)

Before you start

A project you already have on your machine, with git set up, and a working way to run it (its own start or build command).
Claude Code installed. On macOS or Linux, the author README gives curl -fsSL https://claude.ai/install.sh | bash; Homebrew is brew install --cask claude-code. On Windows, the README gives irm https://claude.ai/install.ps1 | iex in PowerShell or winget install Anthropic.ClaudeCode.
A Claude subscription or Console account, or access through a supported cloud provider, as the author quickstart requires. Check the price and plan on the author's own pricing page before you start; this page states no price.
A clean working tree. Run git status and commit or stash anything unrelated first, so the feature diff is the only diff.
One written sentence describing the feature: what the user does, and what changes on screen or in output. If you cannot write that sentence, the task is not ready for the agent.

Steps

Create a branch for the feature: git checkout -b feature/short-name. One feature per branch, so you can abandon it without touching your main branch.
Start Claude Code in the project directory with claude. On first use it prompts you to log in; follow those prompts. Run claude --version first if you want to confirm the install prints a version number, as the author docs describe.
Ask for a plan before any code changes. Type /plan to enter plan mode, then describe the feature in your one sentence plus the files or area you expect it to touch. Read the plan. Correct anything wrong before approving it.
Let the agent implement only the approved plan, one piece at a time. When it asks before making a change, read the proposed change and select Yes only for changes you understand. The author quickstart notes that the session's permission mode sets which actions Claude can take without asking first, and that Shift+Tab switches that mode — stay in a mode that asks you, for a first feature.
After each piece, run the project's own run or build command yourself and look at the result. Do not accept the agent's report that it works as a substitute for seeing it run.
When the feature works, ask the agent to summarise the diff, then read the diff yourself with git diff. Remove anything the plan did not ask for.
Commit on the branch with a message you wrote or checked line by line, then open a pull request or merge it using your normal process. Keep the branch until the merged result is confirmed working.

Worked example

A solo builder has a small notes app and wants a search box that filters the note list as you type. The one-sentence brief is: “Add a search box above the note list that filters visible notes by title as the user types, with no change to how notes are stored.” In plan mode the agent proposes touching only the list view and its filter logic. The builder approves that scope, runs the app after the change, types a query, checks that a note with no matching title disappears and reappears when the query is cleared, reads the diff, and commits on feature/note-search. The “no change to storage” line in the brief is what stops the plan from drifting into a data-model change.

What can go wrong

The plan touches files outside the feature. Fix: stop, say which files are out of scope, and ask for a revised plan before any edits.
The agent reports the feature works but you have not run it. Fix: run the app yourself. A report is not a test.
The diff contains extra cleanups or refactors. Fix: ask for those to be reverted, or move them to a separate branch. A first feature should contain one thing.
You lose track of what changed. Fix: type /clear to clear conversation history and start a fresh, smaller task, or use claude -r to resume a previous conversation, both listed in the author quickstart.

Limits

The agent can propose a plan that looks tidy but misunderstands your codebase. The plan review step exists because of this, not as decoration.
The agent cannot know your release process, your users, or what “done” means for your project. You supply that in the brief.
Approval prompts only help if you read them. Approving every prompt without reading turns the agent into an unsupervised editor.

Time and cost: NOT_MEASURED. This page gives no time or cost figure because the tool docs fetched for it state none that applies to this task.

Verification

Checked 2026-10-23 against the author's own docs. The workflow on this page was not run end to end; every command, flag, and capability claim was checked against an author doc or repo fetched that day.

Cut from this page, with reason:

No time or cost figure: the author docs fetched state no task time or price that applies here, so the figure is NOT_MEASURED rather than estimated.
No model name: the page names no model, because the task does not require one and naming one would add an unverified choice.
No auto-accept mode recommended: the author docs describe permission modes, but this playbook keeps the asking mode on for a first feature.

If a step here does not match what your installed tool shows, trust the tool's own docs for your version and stop before approving a change you cannot read.

Back to: Coding playbooks hub · Skills index