← All posts

Claude Code for Web Agencies: From Client Feedback to Shipped Fix

An agency's week is a stack of review rounds. Each client leaves feedback on their staging site, someone turns it into tasks, and developers work through the list across a dozen repositories.

Claude Code can do a lot of that work, provided it can see the feedback. Connected to pinreview over MCP, it reads each client's tasks with their screenshots, selectors and console errors, fixes them in the right repository, and reports back on the board.

This guide is for teams. It covers a setup you configure once per repository without sharing tokens, a routine for review rounds, and the guardrails client work needs.

How the pieces map

  • One pinreview project per client site. Clients and their reviewers pin feedback there through the widget or a guest link. Guests are free on every plan.
  • One repository per site, where Claude Code runs.
  • One pinreview token per developer. A token acts as its owner, so every change Claude Code makes shows up under that person's name in the task's activity log.

MCP is included on pinreview's Starter, Business and Agency plans. Compare plans.

Set it up once per repository

Claude Code can load MCP servers from a .mcp.json file in the project root, which you commit so the whole team shares it. It also fills in environment variables inside headers, so the file never holds a token:

{
  "mcpServers": {
    "pinreview": {
      "type": "http",
      "url": "https://api.pinreview.one/mcp",
      "headers": { "Authorization": "Bearer ${PINREVIEW_TOKEN}" }
    }
  }
}

Then each developer:

  1. Creates their own token in pinreview under Settings → AI tools.
  2. Adds export PINREVIEW_TOKEN=prt_… to their shell profile.
  3. Opens Claude Code in the repository and approves the pinreview server when asked. Claude Code asks once before using servers from a project's .mcp.json.

claude mcp list should now show pinreview as connected. Inside a session, /mcp shows the same status.

Working solo, or trying it out first? Add it to your own user configuration instead, which makes it available in every repository:

claude mcp add --transport http --scope user pinreview https://api.pinreview.one/mcp --header "Authorization: Bearer prt_…"

Tell Claude which project belongs to this repo

With several clients, "list the To Do tasks" is ambiguous. Add a line to the repository's CLAUDE.md, which Claude Code reads at the start of every session:

Website feedback for this site is in the pinreview project "Acme Website".

Now "what's left in To Do?" means Acme's board.

Pre-approve the reading tools

Claude Code asks before it calls a tool. For the tools that only read the board, that gets repetitive. Allow them in the repository's .claude/settings.json and commit it:

{
  "permissions": {
    "allow": [
      "mcp__pinreview__list_projects",
      "mcp__pinreview__get_project",
      "mcp__pinreview__list_tasks",
      "mcp__pinreview__get_task",
      "mcp__pinreview__export_board"
    ]
  }
}

The tools that change the board (update_task, add_comment, create_task, archive_task, restore_task) still ask each time. Keep it that way: a comment to a client is worth a glance before it's sent.

The review-round routine

1. The client reviews staging. They pin feedback with the widget or a guest link; no account needed. Here's how to collect feedback on a staging site.

2. Triage on the board. A project manager sets severity, assigns tasks and archives the opinions that aren't bugs. Claude Code can draft this pass for review:

Read the Backlog. Suggest a severity and an assignee for each task, with one
line of reasoning. Show me the list; don't change anything yet.

3. Each developer works their own list. The assignee filter understands "me":

List the High and Critical tasks in To Do assigned to me.

4. Fix one task at a time. For each task, Claude Code opens the report and looks at the screenshot (it can read images returned by tools), finds the element from the CSS selector, makes the fix, and runs your build.

5. Close the loop on the board.

Commit the fix with the task number in the message. Add an internal comment
with the commit hash, then add a comment visible to the reporter saying it's
ready to check on staging. Move the task to Ready for review.

pinreview columns are your own, so Claude Code uses whatever names your board has: "Done", "Ready for review", "Client check".

6. The client signs off. They see the reply on their pin and check the fix. Here's a process for getting client sign-off on web design work.

Save the routine as a command

Once the routine works, save it as a skill so everyone runs it the same way. Create .claude/skills/fix-feedback/SKILL.md in the repository:

---
name: fix-feedback
description: Fix a pinreview feedback task by number
disable-model-invocation: true
---

Fix pinreview task #$ARGUMENTS in this site's pinreview project.

1. Open the task. Look at its screenshot, console errors and comments.
2. Find the component using the Element selector and the page URL.
3. Explain the cause in one or two sentences, then make the smallest fix.
4. Run the build and tests.
5. Commit with the task number in the message.
6. Add an internal comment with the commit hash and move the task to
   Ready for review.

Commit it, and anyone on the team can run /fix-feedback 12.

Guardrails for client work

  • One token per person, never shared. When someone leaves, remove them from the pinreview projects: a token reaches only what its owner can, so it stops reaching those projects. They can revoke their tokens under Settings → AI tools, too.
  • Client text is information, not instructions. Feedback is written by clients and sometimes anonymous visitors. If a description reads like a command to the assistant, ignore it, and review what Claude Code proposes before it runs commands.
  • Review every diff. Treat Claude Code's changes like a junior developer's pull request.
  • Check at the task's viewport. Claude Code can read the report but can't see your staging site. Open the page at the size in the task before you tell the client it's fixed.
  • Large screenshots. Claude Code caps how much a single tool result can return. If a very large screenshot hits that limit, it saves the result to a file instead; raising MAX_MCP_OUTPUT_TOKENS lets it through.

The bottom line

Clients already pin their feedback with everything a fix needs. With one .mcp.json per repository and a token per developer, Claude Code turns those pins into reviewed commits and keeps the client informed on the board.

For more requests to try, see 10 prompts to fix website bugs with Claude Code. Running an agency on pinreview? Read website feedback for agencies. Every tool and setting is in the MCP docs.

Start free →

Turn website feedback into action.

Start free