Claude Prompts for Coding: Examples You Can Verify

Good Claude prompts for coding state the behavior you want, point to the relevant code, limit the change, and define how to verify it. Use the examples below for investigation, small fixes, tests, and review. Replace the bracketed inputs with facts from your project before you ask the assistant to act.

A reusable prompt is only part of the context. fenbs can keep the project’s approved rules and reviewed prompts available to connected assistants, so a fresh coding session can start from the same instructions. Keep the source code and executable checks in your repository.

What context should you give Claude before coding?

Name the language, framework, relevant version, and package manager. Include the expected behavior, the observed behavior, and the smallest useful set of files or excerpts. A bug report that says “the save button does nothing after the second click” gives a better starting point than “fix the app.”

Distinguish a chat with pasted code from a coding environment that can inspect files and run commands. Ask what evidence the assistant can actually access. If it cannot read the repository, provide the relevant code and command output yourself instead of asking it to infer unseen files.

For complex inputs, Anthropic’s prompting guidance↗ (opens in a new tab) recommends separating instructions, context, and examples with descriptive tags. Tags are labels, not magic words. Their value is making the task, the source material, and the requested output visibly distinct.

<project>
Language and framework: [facts]
Relevant paths or supplied excerpts: [sources]
Existing commands for checks: [commands]
</project>
<task>
Expected behavior: [observable result]
Current behavior: [reproduction and evidence]
</task>
<constraints>
Change only [scope]. Follow existing patterns.
Ask before changing dependencies, public interfaces, or stored data.
</constraints>
<output>
Explain the change, checks actually run, results, and unresolved limits.
</output>

Avoid sending every file by default. Start with the failing path and its immediate dependencies, then let the assistant identify what else it needs. The Claude Code overview explains that working environment; these prompts focus on describing a checkable task within whichever environment you use.

How do you prompt Claude to investigate a bug first?

Ask for a diagnosis before a patch when the cause is unclear. Supply a reproducible sequence, actual output, and the expected result. Require the assistant to separate what the code shows from what it merely suspects, and to name the next observation that would distinguish competing explanations.

Investigate [bug] using [paths or excerpts]. Do not edit yet.
Reproduction: [steps]. Expected: [result]. Actual: [result].
Trace the relevant path and identify the smallest likely cause.
For each hypothesis, cite the code or output supporting it.
List missing evidence and the next check that would distinguish causes.
Return: observed facts, hypotheses, proposed check, and likely fix scope.

For example, an empty list might come from filtering, a failed request, or a valid response with no records. A useful investigation identifies where those paths diverge. If the assistant cannot reproduce the behavior, its conclusion should remain a hypothesis rather than being written as a confirmed cause.

Stop and correct a wrong premise early. If the assistant assumes a database when the supplied code reads a local file, restate the actual path before it builds a solution around the assumption. The goal is an explanation you can trace through the evidence, not the longest diagnosis.

How do you request a small implementation safely?

Describe the change as observable behavior and specify what remains outside its scope. Name existing patterns to follow, such as the current error handling or shared formatter. This gives the assistant a way to preserve the surrounding application instead of replacing nearby code to make the example easier.

Implement [single behavior] in [scope].
Acceptance examples:
- Given [input], when [action], then [result].
- Given [edge case], then [result].
Use the existing [pattern or helper]. Preserve [public behavior].
First inspect the relevant code and state the intended change.
Then make the smallest coherent implementation.
Run [existing checks] if command execution is available.
Report changed files, actual check results, and anything unverified.
Do not commit, publish, or change live data.

Use the final boundary to match your real authorization. A local prototype and a production service need different limits. When the work reaches a missing product decision, ask for the decision explicitly; a coding prompt should not quietly turn a model’s preference into the project’s agreed behavior.

When you improve the prompt after a real review, save the version and the reason for the change. fenbs keeps reusable coding prompts beside project Decisions and rules, which helps the next assistant follow the same work context.

How do you ask for tests that catch the actual bug?

Request a check tied to an externally visible result. A test that repeats the implementation can pass while the original bug remains. Ask why the proposed case would fail before the fix, which edge case matters, and which existing test style the project already uses.

Design a regression check for [behavior] in [existing test suite].
Identify a case that fails with the current bug and passes after the fix.
Assert the observable result, not the internal implementation.
Cover [specific edge case] if it follows a distinct path.
Explain what the test proves and what it does not prove.
If you can run it, report the exact command and observed result.
Otherwise provide the proposed test and label it unrun.

Anthropic’s Claude Code best practices↗ (opens in a new tab) emphasize giving Claude a way to verify its work. Put the relevant command or expected result in the task. A statement that tests should pass is different from evidence that the command ran successfully in the actual environment.

Match the check to the change. A corrected calculation needs representative input and output; a responsive layout needs inspection at useful screen sizes. Do not ask for a new testing system just to validate a small fix when the project already has an appropriate way to check it.

How do you prompt for a useful code review?

Give the reviewer a defined change and ask for concrete failures. Include the intended behavior so it can judge whether the implementation matches the task. Require each finding to identify the relevant path, the triggering condition, and the practical consequence; this makes findings easier to verify and act on.

Review [diff or supplied code] against [acceptance criteria].
Focus on correctness, access checks, data handling, and regressions.
For each finding, give the location, triggering input or sequence,
expected behavior, actual risk, and a proposed way to verify it.
Separate confirmed defects from questions requiring more context.
If you find no actionable issue, say so and list the limits of the review.
Do not edit files during this review.

A second assistant can still share the first assistant’s blind spots. Run the relevant checks and review important behavior yourself. Ask the reviewer to explain a plausible failure with evidence, rather than requiring a fixed number of findings that encourages it to invent problems.

How should you adapt these prompts for ChatGPT?

Keep the goal, scope, and verification criteria. Replace references to tools the current session cannot use with instructions to return a proposed patch or ask for command output. These can serve as ChatGPT prompts for coding without assuming both sessions have the same repository access.

When switching, carry over the verified facts, current diff, checks already run, and unresolved question. Avoid transferring only a confident summary. The Claude and ChatGPT coding comparison covers the broader choice; the practical test here is whether the next assistant can explain the current task accurately.

For nearby needs, see the Claude system prompt explanation and separate examples for students, teachers, lawyers, and productivity.

How to do this with fenbs

1. Create a free account and add the coding project and its current task.
2. Save one reviewed template in Skills and prompts. Include the required code context, allowed scope, and expected verification report.
3. Record the project rules people have agreed to, such as approval requirements for live changes, in Decisions and rules.
4. Connect a supported AI app and ask it to read the context and relevant prompt, then confirm the task and available evidence before coding.
5. Record the actual check results on the task and save progress before stopping. Add a lesson if a failed suggestion reveals a mistake future sessions should avoid.

fenbs keeps the reusable work record; it does not compile or execute your repository’s tests. For a one-off code question, a direct chat may be enough. Use the AI prompts topic hub when you need another repeatable task pattern.