The first criterion for writing Claude reliably is to write your prompts as statements of work rather than “questions.”
As the model becomes smarter, even if you roughly use it, you will get some answers. However, in practice, “repeatable and verifiable results” are more important than “plausible answers.” Especially when the output goes into actual work, such as APIs, coding agents, document summarization, research, and customer support automation, the prompts become requirements documents.
Date of analysis: 2026-05-02 Key references: Anthropic Claude prompting best practices, Models overview, Extended thinking, Tool use Document series: Claude prompting practice guide Scope of this article: Clear instructions, providing context, success criteria, example designs
Key takeaways
- Claude When it comes to prompts, it's more important to reduce the possibility of misunderstanding than to keep them short.
- A good prompt brings together the purpose of the task, audience, output format, success criteria, and prohibited actions.
- “Take care of it” is a request that leaves the guessing to the model. Practical prompts should be specifications that reduce guesswork.
- Examples are the most powerful way to fix both output format and judgment criteria.
- More complex tasks require “what not to do” within the prompt.
1. Why should you view a prompt as a statement of work?
Claude is good at reading context, but it doesn't automatically know your organization, codebase, customers, documentation conventions, and quality standards. This is key.
For example, the following request is simple on the surface:
# examplePlease improve this code.But in reality, there are too many interpretations.
| Interpretability | What Claude Can Do | problem |
|---|---|---|
| Performance improvements | Change algorithm or cache | Risk of change in behavior |
| Improved readability | Change function and variable names | Unnecessary increase in diff |
| Stability improvements | Added verification logic | Existing callers may break |
| Test enrichment | Added test file | May not be in the range desired by the user |
| structural improvement | Sharing modules | Excessive refactoring possible |
The word “improvement” is ambiguous even among people. The same goes for models. Good prompts narrow the path for improvement.
# exampleReduce the chance of runtime errors in the TypeScript functions below. range:- Do not change function signatures- Do not add external libraries- Prevent existing tests from breaking- Do not refactor surrounding code output of power:1. Summary of problematic points2. Modified code3. Reason for change4. Test cases that are good to addThis prompt is much more reliable. It provides both task objectives, constraints, and output order. Claude doesn’t have to guess “how far you can go.”
2. Minimum composition of clear instructions
Practical prompts usually have a stable quality when they contain five.
| composition | question | example |
|---|---|---|
| target | what to do | “Summary of release notes focusing on development impact” |
| context | Where are the results used? | “For this week’s sprint planning meeting.” |
| form | what should it look like | “1 table, 3 risks, 3 actions” |
| standard | How do you judge success? | “Show breaking changes first” |
| boundary | What not to do | “We do not assume anything that is not in the document.” |
There is no need to write about these five things at length. The important thing is to write everything thoroughly.
# exampleSummarize this document for executive reporting. target:- Select the issues necessary for decision-making rather than translating the entire translation. Context:- Readers are interested in cost, schedule, and risk rather than technical details of implementation. output of power:- 5 key takeaways- 3 items that require decision making- Risk and countermeasure table boundary:- Do not create figures or schedules that are not in the document.- Estimation is indicated as “estimate.”Just adding this amount will make a big difference in the results.
3. Context is not a decoration, but a criterion for judgment.
Context is not a description to be kind to the model. It is a judgment standard that tells us what choice to make in an ambiguous moment.
For example, a request to “give me a short answer” is not enough. Because there is no reason it has to be short.
# exampleThis answer goes into the help tooltip of the mobile app.Users need to read it within 5 seconds, so keep it to 2 sentences or less.Avoid jargon and write in a way that lets users know right away what to do next.This prompt sets the meaning of “short.” Rather than simply reducing the number of characters, it allows you to choose the information density that suits your mobile UI.
Context is especially important in the following tasks:
| work | context needed |
|---|---|
| Document Summary | Audience, purpose of use, information that can be omitted |
| code review | Deployment environment, compatibility, testing criteria |
| Customer Support | Product policies, prohibited expressions, and escalation conditions |
| research | Based on dates, reliable sources, and judgment criteria. |
| Create frontend | Users, Domains, Brand Tone, Density |
4. Inserting success criteria makes the results verifiable.
Prompts without success criteria make it difficult to evaluate the results. The model gives an answer, but there is no standard to judge whether the answer is good or bad.
<comment>example</comment><task>Please summarize the release notes below to share with your development team.</task> <context>The goal is not to translate the entire content perfectly;The idea is to quickly identify any changes that may impact this week's sprint.</context> <success_criteria>- Show breaking change first- Separate API changes, authentication changes, and cost changes- Items that require confirmation should be marked as “Confirmation Required”- Do not mix estimates with official facts.</success_criteria> <output_format>Write in Markdown.Organize the sections in that order: “Key Summary,” “Development Impact,” “Confirmation Required,” and “Recommended Action.”</output_format>This structure is great for repeated use across teams. Even when multiple people summarize the same document, the standards for the results remain similar.
5. Examples are stronger than explanations
Claude is strong on examples. Although it is necessary to explain the output format, tone, and judgment criteria verbally, providing actual examples makes it easier to follow along.
An example of a customer inquiry triage task would be:
<comment>example</comment><instructions>Categorize your next customer inquiry.For classification, use only one of bug, billing, feature_request, account, or other.</instructions> <examples><example><input>I made a payment but did not receive a receipt.</input><output>billing</output></example><example><input>When I log in, the screen turns white.</input><output>bug</output></example><example><input>It would be nice to have a permission management function for each team.</input><output>feature_request</output></example></examples> <input>{{USER_MESSAGE}}</input>Examples are not just samples. A pattern is sent to the model: “Make this judgment in this format.” Examples are almost essential for tasks where consistency is important, such as classification, extraction, code review, policy ruling, and customer support response.
6. Standards for including examples
A good example satisfies three conditions:
| condition | explanation |
|---|---|
| relevance | Should resemble actual input |
| manifold | Includes both normal and borderline cases |
| structured | Clearly distinguish between input and output |
Bad examples actually lower the quality. For example, if all the examples are too short, Claude may only try to give short answers even with long input. If every example is a positive one, you may miss situations that require rejection or escalation.
In practice, it is better to start with 3 to 5 examples. Too few and the pattern will be weak, too much and the prompt will be bloated.
7. “Don’ts” are also part of the specification
Accidents in AI work usually occur when “how far you can go” is more ambiguous than “what to do.”
Coding agents require the following boundaries:
# exampleprohibition:- No refactoring outside the scope of the request- Do not remove or weaken tests- Prohibition of printing secret keys, tokens, or personal information- Force push, reset, distribution without user confirmation prohibited- No hard coding to hide failuresEven document summarization requires boundaries.
# exampleprohibition:- Do not assume prices, schedules, or model names that are not in the document.- Do not mix official facts and the author's interpretation in one paragraph.- Do not write uncertain information definitively.Good boundaries don't make models frustrating, they make the output workable.
8. Basic template to use right away
The templates below are ready to use for most analysis tasks.
<comment>example</comment><role>You are a senior consultant analyzing this topic from a practical perspective.</role> <context>This analysis will be used by {{AUDIENCE}} for decision making.The goal is to create actionable judgment criteria rather than a simple summary.</context> <input>{{CONTENT}}</input> <task>Analyze input to summarize key issues, practice implications, risks, and recommended actions.</task> <rules>- Separate confirmed facts from interpretation.- Mark “Confirmation Required” for unclear information.- Avoid exaggerated expressions and speak according to the level of evidence.</rules> <output_format>## Key Summary## Confirmed facts## Practice implications## Risk## Recommended actions## Confirmation required</output_format>The key isn't the tag itself. It's about separating goals, context, inputs, rules, and output formats. XML is a tool that makes that separation visible.
finish
The starting point for Claude's prompts is not to find a magic sentence. The idea is to reduce the parts the model has to guess and provide criteria for evaluating the results.
The next article will cover more specifically how to use XML tags and output formats in complex prompts. The key is a structure that makes Claude less confusing when mixing directives, examples, long documents, and variable input.
References
- Anthropic Claude Prompting Best Practices:https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
- Use XML tags to structure your prompts:https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags
- Models overview:https://platform.claude.com/docs/en/about-claude/models/overview
Practical example: Prompt converted to statement of work
Bad requests are as short as “Please review this code.” A good request, even if it is short, provides a purpose for the task and criteria for success. For example, if you write, "Review the possibility of duplicate payments in the payment callback handler. The changed files are A and B, first look at the missing idempotency key, retry, and transaction boundaries. Provide the output as a severity order table." This creates a judgment standard for Claude to look at.
| missing information | Common mistakes models make |
|---|---|
| Purpose of change | Flow to style review |
| readers or users | Description level is incorrect |
| success criteria | Difficult to verify results |
| prohibition condition | Out-of-scope refactoring suggestions |
Boundary cases are information that changes, such as updated documents or prices. Simply writing “as of best current” in the prompt allows the model to rely on memory. The statement of work should include information source conditions, such as "Check the official documentation and mark any unconfirmed information as needing confirmation." A clear prompt is not a long prompt, but rather a prompt that sets the point at which the model must stop judging.
댓글
GitHub 계정으로 로그인하면 댓글을 남길 수 있습니다. 댓글은 GitHub Discussions를 통해 운영됩니다.