What makes a Claude Code prompt do a week of work
The Claude Code prompts that do a week of work in a day all share the same shape. They are not clever wording. They give the agent a clear goal, a finish line, and something to verify against. Weak prompts ask for help. Strong prompts hand over a whole job and a way to know it is done.
I call this the CCC prompt formula: Goal plus Finish line plus Check. The Goal is the outcome in plain words. The Finish line is the 'done' state the agent should reach. The Check is the test, the build, or the output the agent uses to confirm it actually got there. Drop any one of the three and the agent wanders.
The 10 Claude Code prompts, ready to copy
Here are the 10 Claude Code prompts I reach for most. Each one names a job, gives you the exact text to paste, and tells you when to run it. Open the desktop app, point Claude Code at your repo, paste the prompt, and let the loop work. Swap the bracketed parts for your own details.
- Codebase audit - paste this on day one of any project so you understand it before you touch it: "Read this whole repository and give me a map of it. List the main folders and what each one does, the entry points, the key data models, how data flows from request to response, and the riskiest or most confusing parts. Do not change any code. End with the five files I should read first to understand this project."
- Write tests - run this when a critical file has no coverage: "Look at [path/to/file] and write a focused test suite for it using the test framework already in this repo. Cover the happy path, the edge cases, and the error cases. Run the tests and keep fixing them until they all pass. Show me the final test output."
- Refactor safely - run this when a file has grown messy but works: "Refactor [path/to/file] for readability without changing its behavior. First run the existing tests and confirm they pass. Make the changes in small steps. After each step, run the tests again. If any test fails, undo that step. Finish only when the file is cleaner and every test still passes."
- Fix a failing build - run this the moment CI or your local build breaks: "The build is failing. Run the build command, read the full error output, find the root cause, and fix it. Do not silence the error or skip the broken step. Re-run the build after each change and keep going until it passes cleanly. Tell me what was actually wrong."
- Write the docs - run this before you hand a project to anyone else: "Read this repository and write a clear README. Include what the project does, how to install and run it locally, the environment variables it needs, the main commands, and how to run the tests. Use simple language a new developer could follow on their first day. Save it as README.md."
- Set up a project - run this on an empty folder to skip the boilerplate: "Set up a new [language or framework] project in this folder. Add a sensible folder structure, a starter config, a test runner, a lint setup, and a .gitignore. Create one tiny passing test so I can confirm the tooling works. Run it and show me the green result."
- Build a small feature end to end - run this when you know the outcome you want: "Build [feature, described in plain words] in this codebase. Follow the patterns already used here. Add or update the tests for it. Run the tests and the build, fix anything that breaks, and stop when both pass. Pause and ask me before doing anything destructive or irreversible."
- Review a PR - run this on a branch before you merge it: "Review the changes on this branch against the main branch. Tell me what changed and why, flag bugs, security issues, and missing tests, and rate each issue as must-fix, should-fix, or nice-to-have. Do not change code yet. Give me a short, prioritized review I could paste into a pull request."
- Migrate or upgrade a dependency - run this when a library is out of date: "Upgrade [dependency] from its current version to [target version] in this repo. Read the changelog for breaking changes, update the code to match the new version, run the tests and the build, and fix anything that breaks. Stop when everything passes and summarize exactly what you changed."
- Turn a repeated task into a skill - run this once you have done the same thing twice: "I keep asking you to [describe the repeated task]. Turn this into a reusable Claude Code skill. Write the skill so I can trigger it by name, document what inputs it needs, and include a short example. Save it in the right place and tell me how to run it next time."
When to run each prompt at a glance
Most of these prompts map to a moment in a project. Use this table to grab the right one fast instead of rereading the list. The 'Check' column is the verify step that keeps the loop honest.
The 10 prompts by job, trigger, and what the agent checks against
| Prompt | Run it when | Check |
|---|---|---|
| Codebase audit | You inherit or open an unfamiliar repo | A readable map, no code changed |
| Write tests | A critical file has no coverage | All new tests pass |
| Refactor safely | Code works but is messy | Behavior unchanged, tests still green |
| Fix a failing build | CI or local build breaks | Build passes cleanly |
| Write the docs | Before handing off a project | A README a new dev can follow |
| Set up a project | Starting from an empty folder | One tiny passing test |
| Build a feature | You know the outcome you want | Tests and build both pass |
| Review a PR | Before merging a branch | A prioritized review, no edits yet |
| Migrate a dependency | A library is out of date | Tests and build pass on the new version |
| Make a skill | You have done the same task twice | A named, reusable skill |
How to adapt these prompts to your own repo
These prompts work on any codebase once you make three swaps. The wording is a starting point, not a script. Adapt it and the agent fits your project instead of fighting it.
- Swap the brackets. Replace [path/to/file], [dependency], and [feature] with the real names in your repo. The more specific you are, the better the Gather step reads the right context.
- Name your verify command. If your project uses a specific test or build command, say it out loud in the prompt. The agent then has a concrete Check instead of guessing.
- Set the blast radius. Add a line like 'only touch files inside [folder]' so the agent stays scoped to the task and does not edit things you did not mean to change.
- Add a checkpoint. For anything risky, end with 'pause and confirm before deleting, migrating data, or pushing'. That one sentence keeps a fast prompt from becoming an expensive mistake.
The skill that makes all of this faster is writing the goal sharply the first time. I go deep on that in [how to use Claude Code like a pro](/blog/how-to-use-claude-code-like-a-pro). The difference between an okay result and a week-of-work result is almost always the clarity of the prompt, not the model.
Turn your best prompt into a repeatable skill
The real leverage is not running a great prompt once. It is never typing it again. When a prompt earns its keep, turn it into a Claude Code skill so you trigger it by name from then on. Prompt number 10 above is the prompt that does exactly that.
A skill captures your winning prompt, its inputs, and its checks so the whole team runs it the same way every time. Your codebase audit becomes a one-word command. Your PR review becomes a habit. To see which skills are worth setting up first, read [the Claude Code skills to install first](/blog/claude-code-skills-to-install-first).
Frequently asked questions
What are the best Claude Code prompts for getting real work done?
The best Claude Code prompts give the agent a clear goal, a finish line, and something to verify against - what we call the CCC prompt formula. The 10 prompts in this post cover the highest-leverage jobs: auditing a codebase, writing tests, refactoring safely, fixing a failing build, writing docs, setting up a project, building a feature, reviewing a PR, upgrading a dependency, and turning a repeated task into a skill.
Do I need the terminal to use these Claude Code prompts?
No. Every prompt here runs in the Claude Code desktop app. You open the app, point it at a real project folder, paste the prompt, and let the agent loop through the work. The same prompts also work in the web app, your IDE, or the terminal if you prefer them.
Why do my Claude Code prompts give vague results?
Usually the prompt is missing a finish line or a way to verify success. Add a clear 'done' state and a concrete check like 'run the tests and stop when they pass'. Naming the exact file, command, or outcome you want also sharpens the result far more than longer wording.
How do I adapt these prompts to my own codebase?
Swap the bracketed parts for the real names in your repo, name your actual test or build command, set the blast radius so the agent only touches the files you intend, and add a checkpoint before anything risky. Those four edits make any prompt here fit your project.
How do I save a prompt so I do not have to retype it?
Turn it into a Claude Code skill. Once a prompt proves its value, ask Claude Code to convert it into a named, reusable skill that documents its inputs and checks. After that you trigger the whole job by name. Prompt number 10 in this post does exactly this.
Are these prompts safe to run on a live project?
They are safer when you scope them. Tell the agent which files or folders it may touch, and add a line that makes it pause and confirm before anything destructive like deleting files, migrating data, or pushing. With those guardrails in place, these prompts are designed to verify their own work before they finish.
Last reviewed by David Iya on June 24, 2026
