10 Claude Code Projects to Build (With the Exact Prompts)

Three habits make the difference between a project that ships and one that turns into a mess:

• Plan first. Start in plan mode (Shift+Tab or /plan, or claude --permission-mode plan). Claude reads, asks, and proposes, but doesn't edit until you approve. Push back on the plan before any code exists, when changes are cheap.
• One feature per session. Build a piece, check it, commit it, then /clear before the next piece. Long sessions keep paying for old context and drift.
• Always include a check. Every prompt below ends with a "Done means" line: a build, a test run, or a script. Ask Claude for the command it ran and the output, not just "it works".

Replace the parts in square brackets with your own details. If you need the commands, shortcuts, or CLAUDE.md template behind these habits, they're in the Claude Code cheat sheet.

What you build: a fast static site with an intro, a projects grid, and one page per project written in Markdown.

Why it's a good first project: small scope, visible result, and npm run build is a pass or fail check. You also practice the most useful pattern there is: letting Claude interview you first.

Time and difficulty: beginner, 1-2 hours.

Follow-ups:

• "Make the projects grid look less like a template: pick one accent color and one display font and apply them consistently." Anthropic's frontend-design plugin helps: /plugin install frontend-design@claude-plugins-official.
• "Add a GitHub Actions workflow that deploys the site to GitHub Pages on every push to main. Tell me which repo settings I must change by hand."

When Claude says it's done, run /verify yourself: it builds and runs the app to confirm the change works.

I want a personal portfolio site. Before writing any code, interview me:
my name and what I do, 3-5 projects to feature, the tone I want, and links
to include. Ask one group of questions at a time.

Then build it as a static site with Astro:
- Home page: one-paragraph intro, projects grid, contact links
- One page per project, generated from Markdown files in src/content/projects/
- Responsive down to 360px wide, light and dark mode
- No tracking scripts, no UI component library

Done means: npm run build passes with no warnings. Show me the output.

What you build: a command-line tool that does one job on your machine. The example below sorts a messy Downloads folder, but pick your own annoyance: renaming photos by date, converting files, pulling a weekly report from an API.

Why it's a good Claude Code project: a CLI is pure logic, so it's easy to test. When the prompt says "tests pass" is the bar, Claude writes them, runs them, and fixes its own mistakes without you watching.

Time and difficulty: beginner, 1-2 hours.

Follow-ups:

• "Add an undo command that reads the last move log and puts every file back. Write the test first and show me it fails before you implement it."
• "Package it so I can run tidy from anywhere. Give me the install command and add it to the README."

Build a Python CLI called "tidy" that organizes a folder (default ~/Downloads)
into subfolders by file type: images, documents, archives, installers, other.

Requirements:
- Dry run is the default. It prints what would move. --apply actually moves files.
- Never overwrite: if a name exists, add a numeric suffix
- Skip hidden files and anything modified in the last 10 minutes
- Write a log of every move to tidy-log.json so moves can be undone later
- Use uv for the project and pytest for tests. Tests use a temp folder, never my real Downloads

Done means: uv run pytest passes and a dry run against a temp folder prints
sensible output. Show me both outputs.

What you build: an interactive dashboard over a spreadsheet you already have: sales, workouts, personal finances, survey results.

Why it's a good Claude Code project: you hand Claude real evidence (@ the file), and the prompt makes it report what it found and wait. That catches wrong assumptions about columns before they become wrong charts.

Time and difficulty: beginner, 2-3 hours.

The cross-check script matters: a chart can look right and still sum the wrong column. Compare its totals with a quick pivot in your spreadsheet app.

Follow-ups:

• "Add a date range filter and a download button for the filtered rows. Keep summary.py in sync."
• "Let me upload next month's CSV in the app, and show a clear error if columns are missing."

Here is my data: @data/[your-file].csv

Step 1, before building anything: inspect the file and report the columns,
their types, row count, date range, missing values, and anything odd
(duplicates, mixed formats). Then ask me which 3-4 questions the dashboard
should answer. Wait for my answers.

Step 2: build a Streamlit app with one chart per question, plus filters
for the obvious dimensions. Clean the data in a separate load_data()
function, not inside the charts.

Done means: the app starts without errors, and a separate script
summary.py prints the key totals the charts show, so I can cross-check
them against the raw file.

What you build: a small Chrome extension. The example saves all open tabs as a named session to restore later. A reading-time badge or a per-URL note works just as well.

Why it's a good Claude Code project: extensions have strict platform rules (Manifest V3, permissions, storage APIs) that Claude knows well. You also learn what to do when Claude can't run the check itself: ask for a manual test checklist and report back what failed.

Time and difficulty: beginner to intermediate, 2-4 hours.

To try it, open chrome://extensions, turn on Developer mode, and click Load unpacked.

Follow-ups:

• "Step 3 of the checklist failed: [what happened]. Here is the console error: [paste]. Fix it and update the checklist."
• "Add export and import of sessions as a JSON file."

Build a Chrome extension (Manifest V3) called "Tab Sessions".

- Popup with a text field and a "Save session" button that stores the
  URLs and titles of all tabs in the current window under that name
- A list of saved sessions with Restore (opens them in a new window)
  and Delete buttons
- Store data in chrome.storage.local
- Request only the permissions this needs, and explain each one
- Plain JavaScript, no build step, no external libraries

Done means: the folder loads with "Load unpacked" without errors, and you
give me a numbered manual test checklist I can run in 5 minutes.

What you build: a bot for a chat you're already in. The example is a Telegram habit tracker; for Discord, swap the library and the token source.

Why it's a good Claude Code project: it's your first project with a secret (the bot token) and an external API you can't call in tests. You learn to keep secrets out of git and to mock the API so the logic is still tested.

Time and difficulty: intermediate, 2-4 hours.

Get the token from @BotFather (or the Discord Developer Portal) and put it in .env yourself. A deny rule stops Claude from reading that file; the cheat sheet has the snippet.

Follow-ups:

• "Add /remind 20:00 for a daily reminder in each user's time zone. Test the scheduling without waiting for real time to pass."
• "Write a Dockerfile and tell me the cheapest way to run this bot 24/7."

Build a Telegram habit-tracker bot in Python with python-telegram-bot.

Commands:
- /add <habit>: start tracking a habit
- /done <habit>: mark it done today
- /streak: show the current streak for each habit
- /list and /remove <habit>

Store data in SQLite, one row per user per habit per day. Read the bot token
from the TELEGRAM_BOT_TOKEN environment variable via a .env file. Create
.env.example and add .env to .gitignore. Never print or log the token.

Keep the habit and streak logic in a module with no Telegram imports.

Done means: pytest passes, with tests for the streak logic (including
missed days and month boundaries) and the command handlers with the
Telegram API mocked. Show me the test output.

What you build: a real web app with sign-up, login, a database, and pages to create, edit, and delete your core object (projects, invoices, recipes, clients).

Why it's a good Claude Code project: it's too big for one prompt, which is the point. You practice the workflow Anthropic recommends for bigger work: get interviewed into a written spec, then build it milestone by milestone in fresh sessions.

Time and difficulty: intermediate, 2-4 sessions.

The starter prompt only produces SPEC.md. Edit it by hand, then /clear and build one milestone per session:

• "Read SPEC.md. Implement milestone 1 only (auth), starting in plan mode. Done means its acceptance criteria pass as automated tests and the build is clean. Commit when done."
• After the auth milestone, run /security-review and fix what it finds before moving on.

I want to build a small SaaS app: [one sentence, e.g. "freelancers track
clients and send invoices"]. I haven't decided the details yet.

Interview me until you could write the spec. Ask about: users and roles,
the core objects and their fields, what each page does, auth method,
and what's explicitly out of scope for v1.

Then propose a stack (framework, database, auth library, hosting) with a
one-line reason for each, and let me approve it.

Then write SPEC.md with: the data model, the pages, acceptance criteria
written as testable statements, and 3-5 milestones in build order.
Don't write any application code in this session.

What you build: an MCP server that gives Claude tools for something it can't reach today: your notes folder, an internal API, a database, the app you built in project 6.

Why it's a good Claude Code project: you extend the agent you're working with. Once the server is connected with claude mcp add, you test it by asking Claude to use it. You also learn how agents see tools: names, descriptions, and inputs matter more than the code inside.

Time and difficulty: intermediate, 2-3 hours.

Our step-by-step MCP server guide covers the Python SDK, the MCP Inspector, and connecting to Claude Code and Claude Desktop. Anthropic's mcp-server-dev plugin in the official marketplace adds skills for designing MCP servers.

Follow-ups:

• "Give me the claude mcp add command with absolute paths, plus three prompts to test the server after I restart."
• "Add a create_note tool that refuses to overwrite an existing file and returns an error message the model can act on."

Build an MCP server in Python using the official MCP Python SDK that gives
an AI assistant read access to my notes folder at [/absolute/path/to/notes]
(Markdown files).

Tools:
- search_notes(query): file names and matching lines, max 20 results
- read_note(path): full content of one note
- list_recent(days): notes modified in the last N days

Rules:
- Only allow paths inside the notes folder. Reject anything else
- Tool descriptions should tell the model when to use each tool
- Use stdio transport

Done means: pytest passes for all three tools, including a path traversal
attempt like ../../etc/passwd, and you show me how to open the server in
the MCP Inspector.

What you build: a skill (a saved procedure that becomes a slash command) for something you prompt over and over, plus a read-only subagent that reviews the result with fresh eyes. The example prepares a branch for a pull request.

Why it's a good Claude Code project: it's small and makes every future session better. You stop retyping instructions, and the skill lives in the repo, so teammates get it too.

Time and difficulty: intermediate, about 1 hour.

The file formats are in the cheat sheet's subagent and skill templates, but you can just ask Claude to write them, as below. Anthropic's skill-creator plugin helps you test and improve a skill.

Follow-ups:

• "I ran /pr-ready and it [what went wrong]. Update the skill so that doesn't happen again, and keep it under 40 lines."
• "Suggest two more skills worth making based on what I ask for most in this project. Don't create them yet."

Create two things in this repo:

1. A project skill at .claude/skills/pr-ready/SKILL.md, invoked as /pr-ready,
   with disable-model-invocation: true. Steps:
   - run the lint, typecheck, and test commands from CLAUDE.md, stop on failure
   - summarize the diff against main in 3-5 bullets for the PR description
   - list any TODOs or console.log calls the diff adds
   - hand the diff to the pr-reviewer subagent and include its findings

2. A subagent at .claude/agents/pr-reviewer.md with only Read, Glob, and Grep
   tools that reviews a diff for bugs and missing tests. Correctness only,
   skip style.

Show me both files before saving. Then run /pr-ready on the current branch.

What you build: a workflow where Claude Code runs on its own: on a schedule, when an issue is opened, or when someone writes @claude in a PR comment.

Why it's a good Claude Code project: it teaches what changes when nobody is watching. An unattended run needs a definition of done, only the tools it must use, a cap on how long it runs, and a person who reviews the result.

Time and difficulty: advanced, 1-2 hours.

The official action is anthropics/claude-code-action@v1. The fastest setup is /install-github-app inside Claude Code: it installs the Claude GitHub App, saves your API key or subscription token as a repository secret, and opens a pull request with the workflow. Two things to know:

• With a prompt input, the action runs in automation mode and results go to the workflow log by default. A plain-text prompt gets no shell or GitHub API access until you grant tools with --allowedTools in claude_args.
• GitHub runs scheduled workflows only from the default branch.

Test the prompt locally first in headless mode (claude -p "summarize the commits from the last 7 days") and move it to CI once the output is right.

Follow-ups:

• "Add the issue triage workflow from the official examples. Explain which permissions it needs and why."
• "Post the digest as a comment on a pinned 'Weekly digest' issue instead of the run log. Allow only the tool that needs."

Write .github/workflows/weekly-digest.yml for this repo.

- Trigger: every Monday at 08:00 UTC, plus workflow_dispatch so I can run it by hand
- Use anthropics/claude-code-action@v1 in automation mode (with a prompt input)
- Authenticate with anthropic_api_key from the ANTHROPIC_API_KEY secret
- Prompt: summarize last week's commits and list open issues with no
  activity in 30 days, grouped by label
- Grant only the GitHub MCP tools that needs via --allowedTools in
  claude_args, and set --max-turns 10
- Least-privilege job permissions, plus id-token: write for app auth
- Job timeout of 10 minutes

Before writing the file, check the official docs or the action's examples
folder to confirm the inputs. Then explain every line I might want to change.

What you build: tests around an old module nobody wants to touch, then a refactor that keeps behavior identical. Use an internal repo at work or an open-source project you like.

Why it's a good Claude Code project: this is where Claude Code earns its money at work. Reading unfamiliar code fast is what it's best at, and characterization tests (tests that pin down what the code does today, bugs included) give it a safety net before any change.

Time and difficulty: advanced, 1-3 sessions.

Anthropic's docs recommend /effort high for code you didn't write, where edge cases are easy to miss. Work in plan mode and keep each step small enough to review in one sitting.

Follow-ups, each in a fresh session:

• "Implement step 1 of the plan only. Run the characterization tests after every file you change. If one fails, stop and tell me instead of updating the test."
• When the diff is ready, run /code-review, which reviews it in a fresh subagent that never saw your reasoning.

I need to refactor [src/billing/] safely. Don't change any behavior yet.

1. Read the module and explain what it does, who calls it, and which
   parts are risky. List anything that looks like a bug, but don't fix it.
2. Write characterization tests that pin down current behavior, including
   the odd cases and any bugs you found. Mark those tests clearly.
3. Run them and show me the output. They must all pass against the
   current code.
4. Propose a refactor plan in small steps, each one safe to commit alone.

Stop after step 4 and wait for my approval.

The same five patterns repeat across all ten prompts. Use them on any project:

1. Spec first. For anything bigger than an afternoon, have Claude interview you and write SPEC.md, then build from it in a fresh session. It's also what you review against later.
2. Acceptance criteria. End every prompt with "Done means": a command that passes or fails, and a request to see its output. Without it, Claude stops when the work looks done.
3. "Ask me questions first." Claude fills gaps with guesses. Asking it to question you turns those guesses into choices you make.
4. Test-driven loop. "Write the failing test, show me it fails, then make it pass" keeps Claude honest on logic-heavy code.
5. Fresh-eyes review. Use /code-review or a reviewer subagent with "skip style", so you get bugs instead of nitpicks.

Two more from Anthropic's best practices: say "be ambitious" when you want edge cases and polish, not the smallest working version. And after two failed corrections, /clear and write one better prompt instead of a third correction.

A reusable template that combines them:

Goal: [what you want, in one or two sentences]
Context: [files to read with @, constraints, things Claude can't see]
Out of scope: [what not to touch]

Before you start, ask me anything you'd otherwise have to guess.
Then show me a short plan and wait.

Done means: [command] passes. Show me the command and its output.

These are the sources worth bookmarking. All were checked on November 5, 2026.

• Anthropic's docs: Best practices and Common workflows have tested prompt examples straight from the team that builds Claude Code.
• anthropics/claude-code-action examples: ready-to-use workflow files for PR review, issue triage, issue deduplication, CI failure auto-fix, and test failure analysis.
• anthropics/skills: Anthropic's public skill examples, including mcp-builder, frontend-design, webapp-testing, and skill-creator. Read them to see how a good SKILL.md is structured.
• anthropics/claude-plugins-official: the official plugin marketplace. It's added automatically the first time you start an interactive session; run /plugin to browse it.
• awesome-claude-code: the largest community list of skills, subagents, hooks, slash commands, and tooling. Not affiliated with Anthropic, so read anything before you install it, especially hooks, which run shell commands.

Pick one project from the list and finish it before starting another. A shipped portfolio teaches you more than three half-built SaaS apps.

• New to Claude Code itself? Start with our Claude Code tutorial, then keep the cheat sheet open while you build.
• Want structured learning with feedback? See the best Claude Code courses.
• Want to build agents, not just use one? Our free AI Agents with PydanticAI course teaches the same building blocks (tools, memory, loops) in Python.