How to Set Up Claude Projects and Skills the Right Way
Anthropic's updated best practices for structuring Claude Projects and writing Skills, and why old prompting advice now backfires.
What changed in Anthropic’s guidance for Claude Projects?
Anthropic’s current advice for structuring Claude Projects is simpler and stricter than what worked a year ago: one project per workstream, short instructions instead of exhaustive rule lists, and instructions gathered through interview rather than written from scratch. The newer Claude models (the Opus/Claude 5 generation) follow short, clear instructions better than long master prompts, and they already self-verify, so old habits like giant instruction files and manual “double check your work” steps now work against you instead of for you.
TL;DR
- Long master prompts stuffed with every rule now hurt performance because newer Claude models follow short, clear instructions better and get confused by bloated files.
- Explicit verification instructions are on Anthropic’s own “old habits to drop” list since current models already check their own work, so asking them to re-verify just adds a slower, redundant pass.
- Projects should be scoped to one workstream each (copywriting, accounting, personal projects, etc.) rather than one giant catch-all project, because each project bundles its own instructions, reference files, memory, and scheduled tasks.
- Project instructions work better when they’re brief and include the reasoning behind a rule, not just the rule itself, since the model can use the justification to handle edge cases you didn’t think to specify.
- You shouldn’t write your own project instructions from a blank page. Letting Claude interview you (via its ask-user-questions capability) produces a cleaner, more complete instruction set.
- The golden rule for testing any prompt or instruction set is the colleague test: if a colleague with zero context would be confused by it, Claude probably will be too.
- The
/goalcommand lets Claude work autonomously toward a measurable end state, with a separate model checking whether a “definition of done” has been met after each turn, which turns a supervised session into one you can walk away from.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
How should you structure a Claude Project?
Anthropic’s guidance boils down to three rules.
One project per workstream. A Claude Project bundles four things together: custom instructions, reference files, memory, and any scheduled tasks tied to that project. Mixing unrelated work (client deliverables and personal writing, for instance) inside a single project means Claude has to guess which context applies to which task, and that guesswork shows up as inconsistent output. Keeping projects separate by function (copywriting, accounting, a specific client, a personal project) means each one carries only the context relevant to that work.
Keep instructions brief, not exhaustive. The old approach was to build one enormous master prompt covering every rule, edge case, and preference in exhaustive detail. That approach now works against you. Current models follow short, clear instructions better than long lists, and if Claude is breaking a rule inside a project, the likely cause isn’t that the rule needs repeating, it’s that the instruction file itself has gotten too long and the signal is getting diluted.
Let Claude interview you instead of writing instructions yourself. Rather than trying to articulate every preference upfront, you can use Claude’s ask-user-questions capability to have it interview you about the project: who you are, what the project is for, who the work serves, what “done” looks like, what voice or tone to use, and what standard operating procedures apply. This tends to surface a more complete and better-organized instruction set than most people write unprompted, and it naturally keeps things succinct because the interview format discourages rambling.
A useful add-on: separate your voice/tone guidance into its own reference file rather than embedding it directly in the instructions, then reference that file. It keeps the core instructions short while still giving Claude detailed style guidance when it needs it.
Why does explicit verification now hurt instead of help?
For a long stretch of Claude’s development, telling the model to double-check its own output against a source (a spreadsheet, a brief, a set of requirements) was good practice. It caught errors the model would otherwise miss.
That’s no longer necessary with the newest models, and Anthropic’s own Opus 5 guidance explicitly lists verification instructions under “old habits to drop.” Current models verify their own work without being told to. Adding a line like “double check every number against the spreadsheet” doesn’t add safety anymore, it adds a second verification pass that’s slower, more expensive, and can even contradict the first pass since the model is essentially grading itself twice with slightly different framing each time.
The practical takeaway: if your prompts or project instructions still contain manual verification steps left over from older workflows, removing them will likely make responses faster and cheaper without hurting accuracy.
How do you write prompts that actually work with newer Claude models?
Three principles show up consistently in Anthropic’s current prompting guidance:
Other agents ship a demo. Remy ships an app.
Real backend. Real database. Real auth. Real plumbing. Remy has it all.
Say what to do, not what to avoid. Negative instructions (“don’t use bullet points”) tend to confuse the model because it has to infer the positive alternative on its own. Positive framing (“write it as a flowing paragraph”) tells it directly what the output should look like.
Give the reasoning, not just the rule. A rule like “never use ellipses” works, but “never use ellipses because this will be read aloud by a text-to-speech engine and it can’t interpret them” works dramatically better. The justification lets the model generalize: once it understands the output is going through a TTS engine, it can infer other formatting choices that would also cause problems, without you having to enumerate every one.
Apply the colleague test. Anthropic frames this as a golden rule: if you showed the prompt to a colleague who had zero context on the task, would they be confused? If yes, Claude will likely be confused too. This flags two common problems: instructions that are too prescriptive (forcing a rigid step order the model can’t deviate from, even when a case doesn’t fit) and instructions that omit the “why” (leaving the model to guess at intent).
A workable prompt template follows this shape: describe what you’re working on and who it’s for, explain the outcome the work needs to enable (the justification), then state the specific task and what “done” looks like for it. Strip out rigid step-by-step instructions and phrases like “this is important, follow this process exactly,” since those tend to overtrigger the model into extra, unrequested work.
What does the /goal command do, and when is it useful?
/goal is a command that lets Claude keep working autonomously toward a stated end condition rather than stopping after one turn for review. You give it a measurable end state and a way to prove it’s been reached. After each turn, a separate, faster model reads the conversation and returns one of three verdicts on whether the “definition of done” has been met. If it hasn’t, Claude takes that feedback as guidance and continues working with the added context. If it has, the process finishes and moves into verification.
Using a separate model to judge completion (distinct from the model doing the work) matters here: it avoids the same model marking its own homework in a way that’s biased toward “yes, I’m done.”
A practical template for writing a /goal command: state one measurable end state, specify how to prove it (verification criteria and expected output), add constraints, and set a turn limit so it stops if it can’t finish within a reasonable budget. This last part matters for cost control since an unbounded autonomous loop can burn tokens indefinitely if the end condition is ambiguous.
This only works properly in autonomous/auto mode, where Claude can bypass step-by-step permission prompts. Running it with manual approval at every step defeats the purpose of setting it up to work unattended.
Is it worth rebuilding your existing Claude setup around these rules?
Remy doesn't build the plumbing. It inherits it.
Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.
Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want.
If your current projects rely on long, exhaustive instruction files or your prompts still include manual verification steps, yes. Both were sound advice for older models and now actively work against the newer ones: bloated instructions get followed less reliably, and redundant verification passes cost time and money without adding accuracy. Restructuring around shorter, justification-rich instructions and one project per workstream is a low-effort change with a fairly immediate payoff in response quality and cost.
Frequently Asked Questions
Do I need to rewrite all my old Claude prompts?
Not entirely, but any prompt containing explicit verification steps (“check your work,” “double check against the source”) should have those lines removed for current models, since they now self-verify. Prompts with negative instructions (“don’t do X”) are also worth rephrasing as positive instructions.
How many projects should I have in Claude?
As many as you have distinct workstreams, with no fixed ideal number. The rule is separation by function (a copywriting project, an accounting project, a personal project) rather than one large project covering everything, since mixing contexts leads to less consistent responses.
What should go in a Claude Project’s instructions versus its reference files?
Keep the core instructions short: who you are, what the project is for, the intended outcome, and key priorities. Move longer material like detailed voice/tone guides or standard operating procedures into separate reference files that the instructions point to, rather than embedding everything in one long instruction block.
What is the “definition of done” and why does it matter?
It’s a clear, specific description of what a completed task looks like, including how to verify it. It matters most for autonomous work like the /goal command, because without a concrete completion check, Claude has no way to know when to stop and can loop indefinitely.
Does giving Claude the reasoning behind a rule actually change its output?
Yes, according to Anthropic’s current prompting guidance. A rule stated with its justification lets the model apply that reasoning to situations you didn’t explicitly cover, rather than treating the rule as a rigid, literal instruction.