Claude Code Prompts for Planning, Debugging, and Review

Useful Claude Code prompts name the behavior you want, point to relevant files, limit the permitted changes, and define how success will be checked. The templates below cover planning, debugging, implementation, and review. fenbs keeps approved prompts and the lessons behind later revisions available to your connected assistants.

Replace every bracketed field before using a template. The examples describe hypothetical repositories; their file paths and commands are placeholders, not instructions to run in your project. If you are new to the tool, start with what Claude Code does before giving it a task that changes files. For coding help in a regular conversation, use the separate Claude coding prompts.

What context should you provide before any coding prompt?

1. Describe one observable outcome. Say what a person should see before and after the change, rather than only naming a feature.
2. Point to the project instructions, the relevant implementation, and one existing example to follow. Include a short reproduction for a bug.
3. Set the scope. Name allowed files or areas and identify actions that require separate approval.
4. Specify acceptance checks and the final report. Include what the assistant should say when a check is blocked.

Do not paste the entire repository into the request. Give Claude a starting point and ask it to inspect the surrounding code. Include a screenshot, error output, or sample input when that evidence explains the issue more precisely than a paragraph. Remove credentials and private customer information from any example.

Anthropic’s prompting guidance for Claude Code↗ (opens in a new tab) emphasizes specific context and verification. The practical question is simple: could someone else use your request to decide whether the change is correct? If the answer depends on an unstated expectation, add it before work begins.

Which prompt helps you plan a change before editing?

Goal: [observable result].
Read the project instructions and inspect [starting files].
Explain the current behavior and the smallest useful change.
List the files you expect to change, assumptions, and risks.
For each acceptance criterion, name a check.
Do not edit files yet. Flag decisions that need my input.
Finish with a plan I can review before implementation.

Use this when the approach is uncertain or the change crosses several areas. Read the proposed plan for hidden expansion: replacing a library, changing a public response, or modifying permissions may be a separate decision. Ask for a smaller first step if the plan contains several changes you cannot independently assess.

A request to avoid edits is useful guidance. For a planning session, also choose the appropriate controls described in Anthropic’s permission modes↗ (opens in a new tab). A prose prompt does not replace tool restrictions. Approve a plan only after its assumptions and acceptance checks are clear.

What prompt keeps debugging focused on evidence?

Observed behavior: [what happens].
Expected behavior: [what should happen].
Reproduction: [steps and safe sample input].
Evidence: [error message or relevant log excerpt].
Start in [files or component].
First investigate without changing code. Separate observed facts
from hypotheses. Identify the smallest reproduction or focused test.
Then propose a fix and the check that would disprove your diagnosis.
Do not suppress the error or broaden the scope without explaining why.

Give the assistant the first meaningful error and the action that produced it. A later stack trace may only show where the failure became visible. Ask it to trace the input through the relevant code and explain where actual behavior diverges from the expected result.

If it offers several possible causes, choose the cheapest check that distinguishes them. A failed hypothesis is progress when the evidence rules something out. Avoid asking for five speculative fixes at once; then neither you nor the assistant can tell which change addressed the cause.

Keep a useful failure lesson with the project. In fenbs, Lessons learned can record what went wrong, what the investigation established, and what the next similar task should do differently.

How do you ask for implementation without an unwanted rewrite?

Implement this approved plan: [plan or task reference].
Allowed scope: [files or area].
Preserve: [public behavior and unrelated work].
Acceptance criteria: [specific outcomes].
Follow the existing pattern in [example file].
Use the project's existing dependencies unless I approve a change.
Run [focused checks] and fix failures caused by your change.
Finish with changed behavior, evidence, and anything unverified.
Do not commit, publish, deploy, or change live data.

Make the boundary match your actual authorization. A blanket prohibition copied into every prompt can be just as confusing as an absent boundary if your current task explicitly includes that action. Tell the assistant what it may do now and which later actions still need a person.

Before accepting the result, inspect the diff and compare it with the plan. Count behavior changes, not just files. A one-line fallback can alter the meaning of an API, while several test files may support one narrow fix. The completion report should explain that distinction.

Which prompt produces a review you can act on?

Review [diff, branch, or files] against [requirements].
Do not modify files. Look for behavior regressions, missing edge cases,
incorrect assumptions, and tests that pass for the wrong reason.
For each finding, give file and line, a concrete failure scenario,
the likely impact, and the evidence supporting it.
Separate confirmed findings from questions.
If you find no supported issues, say so and name review limitations.

A good review connects a code location to an actual failure scenario. Ask for the input or sequence of actions that exposes the problem. If a finding relies on an assumption about another service, check its source rather than treating confident wording as confirmation.

Do not demand a fixed number of findings. That encourages weak objections when the change is sound. A useful answer may contain one serious issue, several questions, or no supported defect. Keep review and implementation separate until you decide which findings warrant a change.

How do you adapt a template to a real acceptance check?

Say you maintain a hypothetical appointment form that accepts an empty email address. “Fix validation” is too broad. Describe the failure: submitting the form without an email currently creates an appointment, but it should show a clear message and create nothing. Name the existing validation component and the server handler so the investigation covers both entry points.

Then define separate checks. The interface should show the intended message, and a direct request without an email should be rejected by the server. A valid submission should still work. These checks make the requirement observable without dictating an implementation before the assistant reads the code.

Keep the scope narrow: preserve the current email format policy and avoid changing unrelated appointment fields. A reviewer can now distinguish the requested fix from a broader redesign. If the assistant discovers that the server already rejects empty addresses, update the diagnosis and plan using that evidence. The prompt should help investigate the real system rather than force the first explanation to be true.

How should a coding session finish?

Ask for a compact handoff: the behavior changed, checks run and their results, remaining uncertainty, and the next action. Distinguish “not run” from “failed.” If a check requires a service that was unavailable, the report should identify that dependency instead of saying everything passed.

Before relying on undo behavior, read the Claude Code checkpoints documentation↗ (opens in a new tab) and understand the boundaries of restoration. Our checkpoints guide and sandbox guide cover those separate controls. Prompt templates are instructions for a workflow, not a backup system.

How to do this with fenbs

1. Create a free account and add the coding project you will use for your first prompt.
2. Save the chosen template in Skills and prompts, with a short description of the task it is intended for.
3. Put the specific goal, accepted plan, and acceptance checks on the relevant task. Keep them separate from the reusable template.
4. Ask your connected assistant to read project context and the saved prompt before working. Before stopping, save progress and the actual verification result.
5. Record a recurring mistake as a lesson, then review whether the prompt needs a small change. Explore more examples in the AI prompts guides.

fenbs is free for one person, with no credit card. If your only need is a handful of local prompts used by one tool, repository files may be sufficient. fenbs is useful when the prompts, decisions, and progress should remain available across connected assistants.