바로 쓰는 Claude 프롬프트 템플릿과 실전 체크리스트

Stabilizing the quality of your prompts shouldn't be left to your personal taste. Frequently performed tasks should be created as templates, and missing conditions should be checked with a checklist before starting the task.

This article is a collection of templates for repeated use of Claude in practice. It is designed so that it can be used directly for analysis, code review, agent coding, document summarization, and front-end creation tasks.

Analysis date: 2026-05-02 Series: Claude Prompt Practical Guide Scope of this article: Copy templates, operational checklists, troubleshooting

Key takeaways

• Templates are not a tool for writing longer prompts, but rather a device for reducing omissions.
• Fixing the goals, inputs, rules, output formats, and verification criteria for each task type ensures stable results.
• Code reviews and coding agent prompts should explicitly discourage test weakening, hardcoding, and out-of-scope refactoring.
• Document summaries and research prompts should separate formal facts from interpretation.
• Frontend creation prompts should be more specific about users, domains, densities, and banning patterns than just being “pretty”.

1. General analysis prompt

This is a basic template used when analyzing documents, meeting minutes, research notes, and market data.

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- For items that require up-to-date information, indicate that you need to check official sources.24</rules>25 26<output_format>27## Key Summary28## Confirmed facts29## Practice implications30## Risk31## Recommended actions32## Confirmation required33</output_format>

The key to this template is not “summary” but “judgment criteria.” It can be applied to executive reporting, product decision-making, and technical reviews alike.

2. Code review prompt

Code reviews should look for actual bugs, security risks, and possible test failures before style preferences.

1<comment>example</comment>2<role>3You are a senior software engineer performing production code reviews.4</role>5 6<review_goal>7The goal of this step is to broadly discover possible problems.8Report issues of low importance or confidence, and indicate confidence and severity for each item.9</review_goal>10 11<rules>12- Don't guess before you see the code.13- Prioritize actual bugs, possible test failures, incorrect results, and security risks.14- For simple style preferences, separate them into minor.15- Please do not suggest weakening or eliminating tests.16- Provide evidence based on line number and file path.17</rules>18 19<output_format>20| location | problem | Impact | Edit Proposal | severity | confidence |21|---|---|---|---|---|---|22</output_format>

If your review prompt tells you to “just say what’s important” too strongly, your model may miss low-confidence issues. It is better to broaden the scope of discovery in the initial exploration phase and then prioritize it in the next phase.

3. Agent coding prompt

Operations that require modifying files require permissions and verification loops.

1<comment>example</comment>2<task>3Implement {{FEATURE_OR_BUGFIX}}.4</task>5 6<constraints>7- Do not refactor outside the scope of the request.8- Change function signatures and public APIs only when necessary.9- Do not delete or weaken existing tests.10- Add new dependencies only when there is a clear benefit.11- If you create temporary files, delete them at the end of the task.12</constraints>13 14<workflow>151. Check the project structure and related files.162. Make a short revision plan.173. Modify only the files you need.184. Run tests and lints if possible.195. If there is a failure, analyze the cause and correct it.206. Summarize changes, test results, and remaining risks.21</workflow>22 23<safety>24Do not delete, force push, reset, change DB, or distribute without user confirmation.25Do not print out your private key or personal information.26Don't hard code just for test cases.27</safety>

This template is based on “execution” rather than “suggestion”. Conversely, if you still want to see the design, you should clearly indicate “Do not modify the file yet.”

4. Document summary prompt

When summarizing release notes, policy documents, pricing documents, and API change documents, you need to separate facts from interpretation.

1<comment>example</comment>2<task>3Please summarize the document below for sharing with your development team.4</task>5 6<summary_goal>7The goal is to quickly identify changes that will impact your team's work this week.8</summary_goal>9 10<document>11{{DOCUMENT}}12</document>13 14<rules>15- First, find important supporting sentences.16- Prioritize breaking changes, pricing, security, and API changes.17- Do not assume anything that is not in the document.18- Mark “confirmation required” for unconfirmed content.19- Separate official facts from the author's interpretation.20</rules>21 22<output_format>23## Key Summary24## supporting sentence25## Development Impact26## Risk27## Recommended actions28## Confirmation required29</output_format>

In long documents, it is safer to ask people to find supporting sentences first rather than asking them to summarize first.

5. Frontend creation prompt

Claude is also strong in front-end creation, but requests like “clean and modern” result in generic results. Visual directions and prohibition patterns must be specifically given.

1<comment>example</comment>2<task>3Implement {{PAGE_TYPE}} of {{PRODUCT_NAME}}.4</task>5 6<audience>7The primary user is {{TARGET_USER}}.8The purpose of this screen is {{USER_GOAL}}.9</audience>10 11<visual_direction>12- Mood: {{MOOD}}13- Background: {{BACKGROUND}}14- Color: {{COLOR_PALETTE}}15- Typography: {{TYPOGRAPHY}}16- Layout: {{LAYOUT}}17- Information density: {{DENSITY}}18- Motion: {{MOTION}}19</visual_direction>20 21<controls_and_states>22- Loading status23- empty state24- Error status25- Mobile layout26- Keyboard accessibility27</controls_and_states>28 29<avoid>30- Typical AI SaaS card layout31- Overuse of purple gradients32- Decorative images without context33- Layouts where text spills over buttons or cards34</avoid>35 36<output>37{{HTML_CSS_OR_REACT}}38</output>

In the frontend prompt, you must use “feature” and “experience” together. The screen doesn't just end with the correct code; it must be something that users can use repeatedly.

6. Checklist before applying prompts

1# example2[ ] The purpose of the work was defined in one sentence.3[ ] The reader or user is specified.4[ ] Input data and instructions are separated.5[ ] Specifies the desired output format.6[ ] I wrote down the success criteria.7[ ] Specifies prohibited actions and out-of-scope operations.8[ ] Directed to separate official facts from interpretation.9[ ] For items requiring up-to-date information, conditions for confirming official sources were added.10[ ] For tasks that require examples, 3 to 5 examples were included.11[ ] Long input is divided into XML tags.12[ ] An appropriate effort level was selected for complex tasks.13[ ] Conditions for using tools and prohibiting hazardous work are specified.14[ ] In the coding agent work, we checked the git status and testing strategy.15[ ] There is a loop to review the output and iteratively improve the prompt.

Checklists may seem cumbersome, but they actually save time on repetitive tasks. The cost of correcting missing conditions later is greater.

7. Troubleshooting

Claude's answer is too long

Both length standards and omission standards are provided.

1# example2Please answer in 5 sentences or less.3Skip the background and include only the conclusion, reasons, and next action.4Please provide only one example.

Claude only makes suggestions and does not edit them himself.

Clearly state your intention to execute.

1# example2Don't just make suggestions - edit the code yourself.3After editing, summarize which files you changed, why you changed them, and the results of your tests.

Conversely, if you just want a suggestion, you should add “Don’t edit yet.”

Claude uses too many tools

Restrict the terms of use of the tool.

1# example2If there is enough information in your input, answer directly instead of using a tool.3Check official sources only when you need information that may change, such as pricing, legal, release notes, or up-to-date documentation.

Claude uses too few tools

Specifies the items that require confirmation.

1# example2Be sure to open and verify the relevant files before making any claims about the code.3Please check the official documentation for the latest model name, price, and API parameters.4If you can run the test, make the modifications and then run the test.

Do I have to use XML tags?

Not necessary for simple questions. But the moment you mix directives, examples, long input and output formats, and prohibition conditions, XML tags become useful.

Coding agent refactors excessively

Be more specific about the scope of work and prohibitive conditions.

1# example2Make only the minimum changes necessary to fix the requested bug.3Don't clean up the surrounding code, change the structure, or add new abstractions.4Avoid adding comments, types, or documentation to unmodified code.

I want to prevent hard coding that only passes tests.

Specifies that the test is not exhaustive of the requirements.

1# example2Don't hard code just for test cases.3Implement a generic solution that works for all valid inputs.4If you think a test is wrong, don't bypass it and report the problem.

8. How your team manages prompts

For individual users, a few templates are sufficient. But if your team puts Claude on task, he shouldn't leave the prompts as personal know-how.

As a team, it's a good idea to document the following:

Prompts are also operational assets. Like code, you must version it, leave reasons for changes, and reflect failures.

9. Practical example: Turning code review templates into operational rules

When you turn your template into actual team rules, you need to lock together the inputs, judgment criteria, prohibited actions, and output format, not just "give me a good answer." For example, if you were to entrust Claude with back-end PR reviews, you could divide the work into units like this:

A practical example could be written like this: First, put the PR description, change file list, and failed test log as<context>. Next,<review_rules>writes, "Look at actual operational bugs and possible regressions first, and mark unsubstantiated security claims as Needs Verification." Lastly,<output_format>requires a table, but be sure to include the file path and line reference in each line. This ensures that the review results are action items that can be moved to tickets rather than just comments for a meeting.

Cases of failure are also clear. All you need to do is “review it thoroughly” on your template, and the model can talk at length about low-risk items like code style, naming, and comments. Conversely, if you just say "just tell me what's important," you may miss boundary conditions that have low confidence but can lead to real failures. So it is safer to separate the initial navigation prompt and the final cleanup prompt. The first prompt expands the scope of discovery, while the second prompt sorts by severity and reproducibility.

10. Comparison point: personal template and team template

Quick iteration is important with personal templates. It's okay if it's a bit vague, since you can read and correct the results right away. However, team templates require a version, an owner, coverage, and a validation method because others need to get similar results from the same input.

In order for your team to apply it right away, you must also write down “when not to use” for each template. For example, during failure response, a short template that asks for logs, recent deployments, and reproducibility conditions first is better than a long analysis template. Conversely, for architectural decisions, a template that requires alternative comparison tables and rollback conditions is more appropriate than a quick answer template. The quality of a template should be judged by whether it fits the task at hand, not by its sentence length.

finish

A good Claude prompt is not a long sentence. An operational template that repeatably contains task objectives, context, success criteria, output formats, tool usage conditions, and safety boundaries.

If you are an individual, you can template 3 to 5 frequently used tasks. If you are a team, you must manage prompts along with official documents and operate model, effort, and tool policies together. That way, Claude can be used as part of a real work system rather than just an “occasionally helpful chatbot.”

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
• Building with extended thinking:https://platform.claude.com/docs/en/build-with-claude/extended-thinking
• Tool use with Claude:https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview