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.
<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.- For items that require up-to-date information, indicate that you need to check official sources.</rules> <output_format>## Key Summary## Confirmed facts## Practice implications## Risk## Recommended actions## Confirmation required</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.
<comment>example</comment><role>You are a senior software engineer performing production code reviews.</role> <review_goal>The goal of this step is to broadly discover possible problems.Report issues of low importance or confidence, and indicate confidence and severity for each item.</review_goal> <rules>- Don't guess before you see the code.- Prioritize actual bugs, possible test failures, incorrect results, and security risks.- For simple style preferences, separate them into minor.- Please do not suggest weakening or eliminating tests.- Provide evidence based on line number and file path.</rules> <output_format>| location | problem | Impact | Edit Proposal | severity | confidence ||---|---|---|---|---|---|</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.
<comment>example</comment><task>Implement {{FEATURE_OR_BUGFIX}}.</task> <constraints>- Do not refactor outside the scope of the request.- Change function signatures and public APIs only when necessary.- Do not delete or weaken existing tests.- Add new dependencies only when there is a clear benefit.- If you create temporary files, delete them at the end of the task.</constraints> <workflow>1. Check the project structure and related files.2. Make a short revision plan.3. Modify only the files you need.4. Run tests and lints if possible.5. If there is a failure, analyze the cause and correct it.6. Summarize changes, test results, and remaining risks.</workflow> <safety>Do not delete, force push, reset, change DB, or distribute without user confirmation.Do not print out your private key or personal information.Don't hard code just for test cases.</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.
<comment>example</comment><task>Please summarize the document below for sharing with your development team.</task> <summary_goal>The goal is to quickly identify changes that will impact your team's work this week.</summary_goal> <document>{{DOCUMENT}}</document> <rules>- First, find important supporting sentences.- Prioritize breaking changes, pricing, security, and API changes.- Do not assume anything that is not in the document.- Mark “confirmation required” for unconfirmed content.- Separate official facts from the author's interpretation.</rules> <output_format>## Key Summary## supporting sentence## Development Impact## Risk## Recommended actions## Confirmation required</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.
<comment>example</comment><task>Implement {{PAGE_TYPE}} of {{PRODUCT_NAME}}.</task> <audience>The primary user is {{TARGET_USER}}.The purpose of this screen is {{USER_GOAL}}.</audience> <visual_direction>- Mood: {{MOOD}}- Background: {{BACKGROUND}}- Color: {{COLOR_PALETTE}}- Typography: {{TYPOGRAPHY}}- Layout: {{LAYOUT}}- Information density: {{DENSITY}}- Motion: {{MOTION}}</visual_direction> <controls_and_states>- Loading status- empty state- Error status- Mobile layout- Keyboard accessibility</controls_and_states> <avoid>- Typical AI SaaS card layout- Overuse of purple gradients- Decorative images without context- Layouts where text spills over buttons or cards</avoid> <output>{{HTML_CSS_OR_REACT}}</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
# example[ ] The purpose of the work was defined in one sentence.[ ] The reader or user is specified.[ ] Input data and instructions are separated.[ ] Specifies the desired output format.[ ] I wrote down the success criteria.[ ] Specifies prohibited actions and out-of-scope operations.[ ] Directed to separate official facts from interpretation.[ ] For items requiring up-to-date information, conditions for confirming official sources were added.[ ] For tasks that require examples, 3 to 5 examples were included.[ ] Long input is divided into XML tags.[ ] An appropriate effort level was selected for complex tasks.[ ] Conditions for using tools and prohibiting hazardous work are specified.[ ] In the coding agent work, we checked the git status and testing strategy.[ ] 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.
# examplePlease answer in 5 sentences or less.Skip the background and include only the conclusion, reasons, and next action.Please provide only one example.Claude only makes suggestions and does not edit them himself.
Clearly state your intention to execute.
# exampleDon't just make suggestions - edit the code yourself.After 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.
# exampleIf there is enough information in your input, answer directly instead of using a tool.Check 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.
# exampleBe sure to open and verify the relevant files before making any claims about the code.Please check the official documentation for the latest model name, price, and API parameters.If 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.
# exampleMake only the minimum changes necessary to fix the requested bug.Don't clean up the surrounding code, change the structure, or add new abstractions.Avoid 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.
# exampleDon't hard code just for test cases.Implement a generic solution that works for all valid inputs.If 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:
| item | Management reasons |
|---|---|
| Templates by task type | Output Consistency |
| Model and effort defaults | Cost and quality forecasts |
| Tool usage policy | Security and operational stability |
| prohibited behavior | accident prevention |
| Verification Procedure | Maintain quality standards |
| Change history | Prompt regression tracking |
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:
| step | What to put in the prompt | Problems that arise when failure occurs |
|---|---|---|
| input | diff, related tests, purpose of change | The model infers the surrounding context |
| Judgment criteria | Prioritize bugs, security, data loss, missing tests | There are a lot of style comments |
| prohibited behavior | No dropping tests, no irrelevant refactoring, no extrapolating conclusions. | Reviews flow into implementation suggestions |
| output of power | Location, Impact, Direction of Correction, Confidence | Difficult for developers to handle immediately |
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.
| division | personal use | team management |
|---|---|---|
| purpose | Save repetitive input | Standardize result quality |
| management | Notes or snippets | Repository documentation and change history |
| verification | sense of self | Sample PRs, failure cases, regression checks |
| update | Fix when needed | Record the reason and impact of the change |
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
댓글
GitHub 계정으로 로그인하면 댓글을 남길 수 있습니다. 댓글은 GitHub Discussions를 통해 운영됩니다.