Claude Opus 5 has triggered another round of discussion, but this time the reason is not a benchmark screenshot or a dramatic demo.
The more interesting topic for developers is system context. Public reporting and community discussion have focused on what appears to be a very large Claude Opus 5 system prompt, including tool instructions, safety boundaries, copyright rules, memory behavior, and tool-call formats.
The natural reaction is:
Is this the full-power prompt?
Should I copy something like this into my own agent?
Is this the full-power prompt?
Should I copy something like this into my own agent?
That reaction is understandable. Anyone who has used Claude Code, Cursor, Codex, or Cline has seen how much behavior can change with different prompts and project rules.
But the better lesson is almost the opposite.
In the era of stronger models, many CLAUDE.md files, system prompts, and Skill instructions are not too short. They are too noisy.
Longer context is not automatically better context. If the rules conflict, repeat, or include irrelevant platform-level instructions, the model may become slower, more expensive, and less decisive.
Anthropic’s own context-engineering guidance for Claude 5-generation models points in the same direction: do not treat system prompts as giant operations manuals. Stronger models need clear boundaries, not endless reminders.
This article does not reproduce leaked prompts or suggest copying product-level system instructions. Instead, it answers a practical question:
If you use Claude Code, Cursor, OpenCode, Cline, or a custom agent with Claude API, how should project rules be written so the agent is more stable, cheaper, and easier to control?
If you use Claude Code, Cursor, OpenCode, Cline, or a custom agent with Claude API, how should project rules be written so the agent is more stable, cheaper, and easier to control?
A 130k-character system prompt does not mean your project needs one
A product-level system prompt and your project’s CLAUDE.md are not the same thing.
Large commercial AI products need to handle many scenarios at once:
- normal chat
- coding tasks
- tool calls
- search
- file processing
- copyright boundaries
- safety policy
- long-session memory
- regional compliance
- client-specific behavior
That context is long because the product has to serve many users, many tools, many risks, and many surfaces.
Your project is narrower.
A coding agent inside one repository usually needs to know:
- what the project does
- which directories can be edited
- which directories must not be touched
- coding style and test habits
- how changes should be verified
- when to stop and ask a human
- which tasks deserve strong models and which should use cheaper models
Those items are more useful than copying a giant general-purpose system prompt.
Platform prompts also contain broad fallback rules. If you paste them into a small project, they can make the agent more hesitant. Asking an agent to change one frontend component while also loading copyright policy, browser constraints, memory rules, safety rules, and dozens of tool schemas is like asking a coworker to change button copy after reading an 80-page employee handbook.
They may comply, but they will not necessarily move faster.
Strong models suffer from conflicting rules
Many teams grow CLAUDE.md by appending every past incident.
The agent broke styles, so someone adds:
Do not modify styles casually.
Do not modify styles casually.
The agent missed tests, so someone adds:
Always add tests after every change.
Always add tests after every change.
The agent wrote noisy comments, so someone adds:
Do not add unnecessary comments.
Do not add unnecessary comments.
The agent did not explain a change, so someone adds:
Always explain every change in detail.
Always explain every change in detail.
After a few weeks, a 30-line file becomes 300 lines.
The problem is that those rules often conflict:
- “do not modify styles” vs. “keep the visual design consistent”
- “do not add comments” vs. “explain important logic”
- “explain in detail” vs. “keep responses concise”
- “finish the task automatically” vs. “ask before risky actions”
- “follow existing implementation” vs. “refactor duplicated logic”
The model will not show an error saying rule 17 conflicts with rule 83. It will just behave inconsistently.
Sometimes it becomes too cautious. Sometimes it edits unrelated files. Sometimes it preserves an old bug because another instruction said to follow existing logic.
The answer is not to add another rule. The answer is to compress incidents into stable principles.
Instead of:
Do not edit package-lock.json.
Do not edit pnpm-lock.yaml.
Do not edit yarn.lock.
Do not edit generated files.
Do not edit dist files.
Do not edit build artifacts.
Do not edit package-lock.json.
Do not edit pnpm-lock.yaml.
Do not edit yarn.lock.
Do not edit generated files.
Do not edit dist files.
Do not edit build artifacts.
Use:
By default, modify only source code and documentation directly related to the task.
Lock files, build artifacts, generated files, and migration files require an explanation and human confirmation before editing.
By default, modify only source code and documentation directly related to the task.
Lock files, build artifacts, generated files, and migration files require an explanation and human confirmation before editing.
That is easier for an agent to apply and easier for a human to review.
CLAUDE.md is a project contract, not a wish list
Weak project rules often sound like this:
Think carefully.
Be very careful.
Write code like a senior engineer.
Do not be lazy.
Do not make basic mistakes.
Always produce high-quality code.
Think carefully.
Be very careful.
Write code like a senior engineer.
Do not be lazy.
Do not make basic mistakes.
Always produce high-quality code.
These instructions express intent, but they do not define behavior.
What does “careful” mean? What counts as a “basic mistake”? How should “high-quality” be checked?
Good project rules should be inspectable.
Replace:
Write high-quality code.
Write high-quality code.
with:
Before finishing a code change, check:
1. Only task-related files were modified.
2. Existing public APIs and data structures are preserved unless explicitly changed.
3. Empty, error, and loading states are handled when relevant.
4. Existing tests, lint, or build checks were run, or the reason for not running them is stated.
5. The final response lists changed files and verification results.
Before finishing a code change, check:
1. Only task-related files were modified.
2. Existing public APIs and data structures are preserved unless explicitly changed.
3. Empty, error, and loading states are handled when relevant.
4. Existing tests, lint, or build checks were run, or the reason for not running them is stated.
5. The final response lists changed files and verification results.
Replace:
Do not change things randomly.
Do not change things randomly.
with:
The following actions require confirmation first:
- deleting files or directories
- renaming public interfaces
- modifying database schema
- changing authentication, payment, or permission logic
- adding new dependencies
- formatting or refactoring more than 5 files
The following actions require confirmation first:
- deleting files or directories
- renaming public interfaces
- modifying database schema
- changing authentication, payment, or permission logic
- adding new dependencies
- formatting or refactoring more than 5 files
These rules do not make the model smarter. They make it a more reliable collaborator.
Reduce CLAUDE.md to six useful sections
If your current CLAUDE.md is long, do not rewrite it from scratch. First reorganize it into these six sections.
1. What the project is
Keep it under five lines:
This is an API access and usage-management dashboard for small teams.
The frontend uses Next.js, the backend uses Node.js, and the database is PostgreSQL.
The core user jobs are model selection, API key management, usage visibility, and billing reconciliation.
This is an API access and usage-management dashboard for small teams.
The frontend uses Next.js, the backend uses Node.js, and the database is PostgreSQL.
The core user jobs are model selection, API key management, usage visibility, and billing reconciliation.
The agent needs orientation, not a business plan.
2. Directory boundaries
Tell the agent where it may work and where it should be careful:
Common directories:
- app/: pages and routes
- components/: reusable UI
- lib/: business logic and API clients
- docs/: documentation
Do not modify by default:
- migrations/
- generated/
- dist/
- lock files
- .env or any secret file
Common directories:
- app/: pages and routes
- components/: reusable UI
- lib/: business logic and API clients
- docs/: documentation
Do not modify by default:
- migrations/
- generated/
- dist/
- lock files
- .env or any secret file
Agents often fail not because they cannot write code, but because the current task boundary was never stated.
3. Risky actions
List actions that require confirmation:
The following actions require confirmation:
- deleting or moving files
- changing database schema
- changing payment, login, or permission logic
- replacing core dependencies
- running destructive commands
- refactoring more than 5 files
The following actions require confirmation:
- deleting or moving files
- changing database schema
- changing payment, login, or permission logic
- replacing core dependencies
- running destructive commands
- refactoring more than 5 files
This is especially useful for teams because different people have different risk thresholds. Do not make the model guess.
4. Acceptance criteria
Every project should have a common verification baseline:
Before finishing:
- run the relevant lint, test, or build command when practical
- cover error states for new logic
- preserve the existing UI language
- avoid unrelated refactors
- final response must include what changed, what was verified, and remaining risks
Before finishing:
- run the relevant lint, test, or build command when practical
- cover error states for new logic
- preserve the existing UI language
- avoid unrelated refactors
- final response must include what changed, what was verified, and remaining risks
Do not require full test suites every time if they are slow. Prefer relevant validation, and require the model to explain when validation cannot be run.
5. Tool usage
Write down known commands:
Common commands:
- npm run lint: check code style
- npm run test -- user: run user-related tests
- npm run build: run production build check
Do not guess deployment commands.
Deployment, database migration, and production configuration changes require human confirmation.
Common commands:
- npm run lint: check code style
- npm run test -- user: run user-related tests
- npm run build: run production build check
Do not guess deployment commands.
Deployment, database migration, and production configuration changes require human confirmation.
Many agent failures come from tool misuse, not reasoning failure. If the project uses pnpm, say so. If a script writes production data, say so.
6. Cost and model strategy
Many teams still omit this, but it matters once agents use APIs regularly.
Model strategy:
- simple classification, formatting, short rewriting: use a lightweight model
- code review, complex refactoring, long-chain reasoning: use Sonnet / Opus-class models
- large parallel sub-tasks: prefer lower-cost models and limit output length
- long-document tasks: use caching or staged summarization when possible
Model strategy:
- simple classification, formatting, short rewriting: use a lightweight model
- code review, complex refactoring, long-chain reasoning: use Sonnet / Opus-class models
- large parallel sub-tasks: prefer lower-cost models and limit output length
- long-document tasks: use caching or staged summarization when possible
Cost problems usually come from many small repeated tasks, not one dramatic call. Write routing strategy early.
Keep Skills, but do not load all Skills every time
The Opus 5 system prompt discussion also highlights another issue: tools and Skills can be heavy.
If an agent system loads every tool description, every Skill, and every historical preference at once, the context looks complete but becomes wasteful.
Use routing.
Suppose your team has Skills for:
- writing WeChat articles
- extracting content from WeChat links
- generating cover-image prompts
- optimizing website SEO
- rewriting for CSDN
- compliance review
- FAQ generation
They should not all enter context for every task.
If the task is “fix a login button style,” the article-writing Skill should not appear. If the task is “add FAQ to a website article,” the image-generation Skill is irrelevant.
Your CLAUDE.md only needs routing rules:
If the task involves content writing, use writing-related Skills.
If the task involves a WeChat link, extract the article body before writing.
If the task involves a technical website article, add an FAQ section at the end.
If the task involves images, first provide image placement and generation prompts; do not insert nonexistent images.
If the task involves content writing, use writing-related Skills.
If the task involves a WeChat link, extract the article body before writing.
If the task involves a technical website article, add an FAQ section at the end.
If the task involves images, first provide image placement and generation prompts; do not insert nonexistent images.
As teams add Skills, the failure mode changes. A single Skill may work well, but many always-loaded Skills can make the agent slower, more expensive, and more likely to mix workflows.
The fix is not deleting Skills. The fix is creating entry rules so the agent loads the right tool at the right time.
A copyable CLAUDE.md starter
Use this as a baseline. It is intentionally plain.
# Project collaboration rules
## Project background
This is a developer-facing web project containing frontend pages, backend APIs, documentation, and configuration.
The priority is stability, maintainability, and verifiable changes, not one-shot large refactors.
## Default workflow
- Understand the task goal first, then inspect relevant files.
- By default, modify only files directly related to the task.
- Do not perform unrelated refactors.
- Do not change the technology stack, directory structure, or core dependencies without confirmation.
- If requirements are unclear, make the smallest reasonable change based on existing code and state assumptions in the final response.
## Actions requiring confirmation
The following actions require explanation and confirmation first:
- deleting, moving, or bulk-renaming files
- modifying database schema, migration scripts, or production configuration
- changing authentication, payment, permission, or billing logic
- adding new dependencies or upgrading core frameworks
- running commands that may destroy or overwrite data
- formatting or refactoring more than 5 files
## Code requirements
- Preserve existing code style.
- Prefer existing components, utilities, and type definitions.
- New logic should handle error, empty, and boundary states.
- Do not add meaningless comments; use short comments only for complex reasoning.
## Verification requirements
- Prefer running lint, test, or build commands relevant to the change.
- If verification cannot be run, explain why.
- Final response must include: changes made, verification results, and uncovered risks.
## Output requirements
- Keep responses concise, but do not omit critical risks.
- If there are multiple options, recommend one and explain the tradeoff.
- If the task involves a technical website article, add an FAQ section at the end.
# Project collaboration rules
## Project background
This is a developer-facing web project containing frontend pages, backend APIs, documentation, and configuration.
The priority is stability, maintainability, and verifiable changes, not one-shot large refactors.
## Default workflow
- Understand the task goal first, then inspect relevant files.
- By default, modify only files directly related to the task.
- Do not perform unrelated refactors.
- Do not change the technology stack, directory structure, or core dependencies without confirmation.
- If requirements are unclear, make the smallest reasonable change based on existing code and state assumptions in the final response.
## Actions requiring confirmation
The following actions require explanation and confirmation first:
- deleting, moving, or bulk-renaming files
- modifying database schema, migration scripts, or production configuration
- changing authentication, payment, permission, or billing logic
- adding new dependencies or upgrading core frameworks
- running commands that may destroy or overwrite data
- formatting or refactoring more than 5 files
## Code requirements
- Preserve existing code style.
- Prefer existing components, utilities, and type definitions.
- New logic should handle error, empty, and boundary states.
- Do not add meaningless comments; use short comments only for complex reasoning.
## Verification requirements
- Prefer running lint, test, or build commands relevant to the change.
- If verification cannot be run, explain why.
- Final response must include: changes made, verification results, and uncovered risks.
## Output requirements
- Keep responses concise, but do not omit critical risks.
- If there are multiple options, recommend one and explain the tradeoff.
- If the task involves a technical website article, add an FAQ section at the end.
This template is not the final answer. A useful CLAUDE.md should grow with the project.
Review it weekly:
- Which rules were triggered often?
- Which rules were never used?
- Which rules conflict with the real workflow?
- Which repeated failures should become one clearer principle?
Keep rules that reduce incidents. Delete rules that only express anxiety.
Clean up the API access layer too
For an individual developer running Claude Code locally, the problem is limited.
For a team, the stack becomes more complex:
- Claude Code
- Cursor / Cline / OpenCode
- Dify
- n8n
- Open WebUI
- content automation
- batch document summarization
- support bots
- custom agents
At that point, project rules are only the first layer.
The second layer is access governance:
- how keys are issued
- which models are allowed
- how usage is tracked
- how bills are reconciled
- how abnormal requests are debugged
- who owns each workflow
This is why some teams use apito.ai as a unified Claude API access layer. The value is not just a different domain name. It is putting model entry points, usage records, billing, and team collaboration in one manageable place.
If an existing tool already uses an older claudeapi.com endpoint, migration may only require changing the request domain from:
claudeapi.com
claudeapi.com
to:
apito.ai
apito.ai
In many configurations, the key, model ID, request parameters, and calling pattern do not need to change. Always verify this against the specific tool and the current console.
Actual model availability, price, quota, and routing should follow the apito.ai console. apito.ai / ClaudeAPI is an independent third-party technical service, not an official Anthropic channel.
The pattern is the same as CLAUDE.md:
Strong models solve capability.
Clear rules solve collaboration.
Unified access solves management.
Strong models solve capability.
Clear rules solve collaboration.
Unified access solves management.
Missing any one of the three makes agent workflows less stable.
A 10-minute cleanup you can do today
If you already use Claude Code, do this today:
- Open your project’s
CLAUDE.md. - Delete repeated “do not,” “must,” and “always” lines.
- Convert emotional instructions into checkable acceptance criteria.
- Add an “actions requiring confirmation” section.
- Write down common test commands.
- Remove outdated paths, old tech-stack notes, and unused scripts.
- Move long background material into docs and ask the agent to read it only when needed.
- Add routing rules for content, code, images, and deployment Skills.
- State which tasks use lightweight models and which use strong models.
- If your team uses unified API access, document request domains, key ownership, and usage-log locations.
This will not make the model smarter. It will give it a cleaner workbench.
Many unstable agent workflows are not caused by weak models. They are caused by unclear instructions, noisy context, and unmanaged access.
The Opus 5 system prompt discussion looks like a prompt leak story. The better engineering lesson is simpler:
Strong models do not need more noise.
They need cleaner boundaries.
Strong models do not need more noise.
They need cleaner boundaries.
FAQ
Should I copy the Claude Opus 5 system prompt into my project?
No. Product-level system prompts contain platform rules, tool schemas, safety policies, and general fallback logic that most projects do not need. Copying them increases context noise and may make simple tasks slower or less decisive.
Should CLAUDE.md be as short as possible?
Not necessarily. Short is not the goal; clarity is. A good CLAUDE.md should cover project background, directory boundaries, risky actions, verification, tools, and output requirements. Keep executable rules. Remove vague anxiety.
Where should Claude Code project rules go?
Usually in the project root as CLAUDE.md. If modules have very different rules, add local guidance in subdirectories, but avoid repeating the same rule in many places.
What is the difference between Skills and CLAUDE.md?
CLAUDE.md is best for long-term project rules: directories, commands, boundaries, verification, and risk actions. Skills are better for reusable workflows such as article writing, SEO checks, image prompt generation, compliance review, or format conversion.
Which tasks deserve Opus 5 or other strong models?
Use stronger models for complex refactoring, long-chain agent tasks, cross-file reasoning, difficult debugging, and deep document analysis. Use lightweight models for classification, formatting, short rewriting, and repetitive extraction.
Why does a team need to care about the API access layer?
Because team usage requires more than model quality. You need key management, usage logs, billing reconciliation, error debugging, and model routing. A unified access layer reduces configuration drift and makes cost easier to explain.
Is migrating from claudeapi.com to apito.ai complicated?
In many existing tools, migration only requires changing the request domain from claudeapi.com to apito.ai. Keep the same key, model ID, and request parameters if the console and tool configuration confirm compatibility. Always test with a small request before switching production traffic.
Sources
- Claude Blog: The new rules of context engineering for Claude 5-generation models
- Claude Code Docs: Memory and CLAUDE.md
- Claude Code Docs: Settings
- Claude Code Docs: Permissions
- Anthropic: Introducing Claude Opus 5
- Claude Platform Docs: Prompting Claude Opus 5
Disclosure
ClaudeAPI / apito.ai is an independent third-party API service and is not affiliated with Anthropic.
