Claude 프롬프트는 질문이 아니라 작업 명세서다

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:

1# example2Please improve this code.

But in reality, there are too many interpretations.

The word “improvement” is ambiguous even among people. The same goes for models. Good prompts narrow the path for improvement.

1# example2Reduce the chance of runtime errors in the TypeScript functions below.3 4range:5- Do not change function signatures6- Do not add external libraries7- Prevent existing tests from breaking8- Do not refactor surrounding code9 10output of power:111. Summary of problematic points122. Modified code133. Reason for change144. Test cases that are good to add

This 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.

There is no need to write about these five things at length. The important thing is to write everything thoroughly.

1# example2Summarize this document for executive reporting.3 4target:5- Select the issues necessary for decision-making rather than translating the entire translation.6 7Context:8- Readers are interested in cost, schedule, and risk rather than technical details of implementation.9 10output of power:11- 5 key takeaways12- 3 items that require decision making13- Risk and countermeasure table14 15boundary:16- Do not create figures or schedules that are not in the document.17- 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.

1# example2This answer goes into the help tooltip of the mobile app.3Users need to read it within 5 seconds, so keep it to 2 sentences or less.4Avoid 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:

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.

1<comment>example</comment>2<task>3Please summarize the release notes below to share with your development team.4</task>5 6<context>7The goal is not to translate the entire content perfectly;8The idea is to quickly identify any changes that may impact this week's sprint.9</context>10 11<success_criteria>12- Show breaking change first13- Separate API changes, authentication changes, and cost changes14- Items that require confirmation should be marked as “Confirmation Required”15- Do not mix estimates with official facts.16</success_criteria>17 18<output_format>19Write in Markdown.20Organize the sections in that order: “Key Summary,” “Development Impact,” “Confirmation Required,” and “Recommended Action.”21</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:

1<comment>example</comment>2<instructions>3Categorize your next customer inquiry.4For classification, use only one of bug, billing, feature_request, account, or other.5</instructions>6 7<examples>8<example>9<input>I made a payment but did not receive a receipt.</input>10<output>billing</output>11</example>12<example>13<input>When I log in, the screen turns white.</input>14<output>bug</output>15</example>16<example>17<input>It would be nice to have a permission management function for each team.</input>18<output>feature_request</output>19</example>20</examples>21 22<input>23{{USER_MESSAGE}}24</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:

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:

1# example2prohibition:3- No refactoring outside the scope of the request4- Do not remove or weaken tests5- Prohibition of printing secret keys, tokens, or personal information6- Force push, reset, distribution without user confirmation prohibited7- No hard coding to hide failures

Even document summarization requires boundaries.

1# example2prohibition:3- Do not assume prices, schedules, or model names that are not in the document.4- Do not mix official facts and the author's interpretation in one paragraph.5- 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.

1<comment>example</comment>2<role>3You are a senior consultant analyzing this topic from a practical perspective.4</role>5 6<context>7This analysis will be used by {{AUDIENCE}} for decision making.8The goal is to create actionable judgment criteria rather than a simple summary.9</context>10 11<input>12{{CONTENT}}13</input>14 15<task>16Analyze input to summarize key issues, practice implications, risks, and recommended actions.17</task>18 19<rules>20- Separate confirmed facts from interpretation.21- Mark “Confirmation Required” for unclear information.22- Avoid exaggerated expressions and speak according to the level of evidence.23</rules>24 25<output_format>26## Key Summary27## Confirmed facts28## Practice implications29## Risk30## Recommended actions31## Confirmation required32</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.

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.