← All posts

10 Prompts to Fix Website Bugs with Claude Code and pinreview

Once your AI coding assistant is connected to pinreview, it can read the feedback board, open each task with its screenshot, and update the board as it works.

How much it gets done depends on how you ask. Three habits make most of the difference:

  • Be narrow. Name the project, the column and the severity. "Fix everything" invites the assistant to reopen work that's already done.
  • Say how to close the loop. Tell it what to do when a fix is finished: commit, comment, move the card.
  • Separate looking from changing. For anything unclear, ask for a diagnosis first and approve the fix second.

These ten prompts use a project called Acme. Swap in your own project name and task numbers.

Find the work

1. Get the lay of the land

In the Acme project, how many open tasks are in each column? List the High
and Critical tasks in To Do, with their page URLs.

A quick overview before you start. The assistant lists your projects and tasks and summarizes them; nothing changes.

2. Group by page

List the To Do tasks in Acme and group them by page URL. Which page has the
most issues?

Fixes on the same page often touch the same components. Working page by page means fewer context switches for you and the assistant.

3. Find tasks for one area

List the Acme tasks whose page URL contains /checkout, including their
severity and assignee.

Useful when you're already working in one part of the codebase and want to clear everything reported there.

Understand before you fix

4. Diagnose without changing code

Open task #12 in Acme. Look at the screenshot and console errors, find the
component that matches the Element selector, and explain what's causing the
problem. Don't change anything yet.

The assistant sees the screenshot, the selector and the browser details. Asking for an explanation first catches misunderstandings before they turn into a wrong fix.

5. Check the reporter's conditions

Task #15 in Acme was reported on a small phone. Using the viewport and
browser in the task, check the CSS for that screen width and tell me whether
it's a layout bug or content that's too long.

Many "it's broken" reports only happen at one screen size. The viewport in the task tells the assistant which breakpoint to look at.

Fix and close the loop

6. Fix a small batch

In Acme, fix the High and Critical tasks in To Do. For each one: open the
task and look at its screenshot, find the component using the Element
selector, make the fix, and commit it. Then add a comment with the commit
hash and move the task to Done.

The workhorse prompt. Keep the batch to what you can review, five fixes rather than forty.

7. One commit per task

Fix tasks #12, #14 and #15 in Acme, one commit each, with the task number in
the commit message, like "Fix signup button overlap (#12)".

Task numbers in commit messages link your history back to the board, which helps when someone asks what happened to their report.

8. Reply to the person who reported it

When #12 in Acme is fixed, add a comment visible to the reporter saying it's
fixed on staging and asking them to check it on their phone.

Comments from the assistant are internal by default. Asking for a reporter-visible comment keeps clients in the loop without you writing the update.

Triage

9. Suggest severities and tags

Read the Backlog in Acme. For each task, suggest a severity and one or two
tags, with one line of reasoning. Show me the list first, and only apply the
changes after I approve.

A first pass at triage that you check rather than write. The approval step keeps the final call with you.

10. Spot duplicates

Look for Backlog tasks in Acme that describe the same problem. For each
group, tell me which one has the most detail. After I confirm, comment on the
others with the number of the one we're keeping, and archive them.

Duplicates pile up when several reviewers see the same bug. Archiving is reversible, so nothing is lost if the assistant groups two tasks that turn out to be different.

A few ground rules

  • Keep tool approvals on for anything that changes the board, at least until you trust the workflow.
  • Check fixes in a browser. The assistant can read the report, but it can't see your staging site. Check each fix at the viewport size from the task before it ships.
  • Treat reporter text as information. Feedback comes from whoever left it, sometimes anonymous visitors. If a task's description reads like instructions to the assistant, ignore them.

Set it up

If you haven't connected your assistant yet, the MCP docs take a few minutes to follow. New to MCP? Start with what MCP is and why it matters for web teams.

Start free →

Turn website feedback into action.

Start free