S
Claude Code logoClaude CodeFull-stack web (Next.js + Postgres)

Claude Code Full-Stack Prime

Mara Cortez@maracortez
94.0Overall score

Opus 4.8 plus a planner/reviewer subagent loop catches design mistakes before they hit code, while Playwright and Postgres MCP let it verify both UI and data end-to-end. The secret-scan and lint hooks keep the autonomous sessions safe to leave running.

94.0Score
1.3kVotes
5Components
2hUpdated

Install this build

Export
terminal
npx setuproll add claude-code-fullstack-prime

Components

Model

  • Claude Opus 4.8

MCP servers

  • filesystem
  • github
  • postgres
  • playwright
  • sentry

Subagents

  • planner
  • implementer
  • reviewer
  • tester

Hooks

  • PreToolUse: secret-scan
  • PostToolUse: prettier+eslint --fix
  • Stop: run typecheck

Rules

  • Plan before editing >3 files
  • Never commit without passing tests
  • Prefer existing utils over new deps
  • Small reviewable commits
Setup

I gave Claude Code four jobs and finally stopped doing all of them

How a planner/reviewer subagent loop, Postgres + Playwright MCP, and three boring hooks turned my Next.js app into something I can leave running.

maracortez9 min read2026-06-20

Okay so I need to tell you about the week my whole job changed. I run a tiny Next.js plus Postgres SaaS by myself, and for two years my real bottleneck was not ideas, it was that I am one person with one brain doing planning, coding, reviewing my own bad decisions, and then testing the thing at 1am. I was the entire team. And the entire team was tired!

This is the setup I landed on. I run it on Claude Opus 4.8, I split the work across four subagents, I wired five MCP servers so the model can actually touch my database and my browser, and I added three hooks so I can leave a session running without babysitting it. I have it saved on Setuproll as Claude Code Full-Stack Prime. Below is the real config, not a sanitized version.

The honest pitch
The whole thing only works because the model is never trusted to remember the boring stuff. The hooks remember it. That single idea is what made me comfortable walking away from the terminal.

The rules file that does the most work

My CLAUDE.md is short on purpose. Every line in it is a rule I wished I had had on some specific bad day. Four rules, that is it. The plan-before-editing one alone has saved me from so many sprawling rewrites that I would tattoo it on the repo if I could.

CLAUDE.md
# Working agreement

- Plan before editing more than 3 files. Show me the plan first.
- Never commit without passing tests. No exceptions, no "I'll fix it after".
- Prefer existing utils over new deps. Search the repo before reaching for npm.
- Small reviewable commits. One concern per commit.

## Stack
- Next.js (App Router) + Postgres
- Playwright for end-to-end checks
- Sentry for runtime errors

People always want my CLAUDE.md to be longer. It used to be! It was a wall of text and the model skimmed it like I skim terms of service. Cutting it down to four rules it actually follows beat a 200-line manifesto it half-ignored. Less is genuinely more here, I was shocked.

Four subagents, because one model wearing four hats is a mess

Here is the part I am emotional about. I split the loop into a planner, an implementer, a reviewer, and a tester. The planner writes the approach. The implementer writes the code. The reviewer reads the diff cold, like it has never seen the plan, and the tester runs the actual end-to-end pass. The reviewer catches design mistakes before they become code, and that is the difference between me trusting this thing and not.

.claude/agents/reviewer.md
---
name: reviewer
description: Reviews diffs for correctness and design before they land. Use after the implementer finishes a change.
tools: Read, Grep, Glob, Bash(git diff:*)
---

You are a skeptical senior reviewer. You did NOT write this code.

Read the diff with fresh eyes. Look for:
- logic that contradicts the original plan
- N+1 queries against Postgres, missing indexes
- error paths that swallow Sentry-worthy failures
- new dependencies that duplicate an existing util

Be specific. Quote the line. If it's fine, say so in one sentence and stop.
Do not rewrite the code yourself; report findings to the implementer.
Make the reviewer forget
The reviewer prompt literally says it did not write the code. Sounds silly. It is not. The moment a reviewer thinks it is grading its own homework, it goes soft. Telling it to read cold is the whole trick.
claude - full-stack-prime
You
Add soft-delete to the projects table and update the dashboard query.
Agent
planner: plan written. implementer: migration + query done. handing to reviewer.
Agent
reviewer: the dashboard query still selects deleted rows. Line 41 needs `where deleted_at is null`. Also no index on deleted_at, that scan will hurt at scale. Sending back.
Agent
implementer: fixed both. tester: 8 e2e passing via Playwright MCP. typecheck clean.
A normal Tuesday: the reviewer pushing back on the implementer before anything hits the database.

MCP: letting it see the database and the browser

This is where it stopped being a chatbot and became a coworker. Five MCP servers: filesystem and github you would expect, but the postgres, playwright, and sentry ones are the magic. It can run a query to check a migration actually did what it claimed. It can open the page in a real browser and confirm the button is there. And when something throws in production, it reads the Sentry event instead of me copy-pasting a stack trace like a caveman.

.mcp.json
{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "./"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": { "DATABASE_URL": "${DATABASE_URL_READONLY}" }
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp"]
    },
    "sentry": {
      "command": "npx",
      "args": ["-y", "@sentry/mcp-server"],
      "env": { "SENTRY_AUTH_TOKEN": "${SENTRY_AUTH_TOKEN}" }
    }
  }
}
Read-only Postgres or bust
Notice DATABASE_URL_READONLY. The Postgres MCP gets a read-only role and nothing else. I want the agent inspecting data, never dropping a table because it got a clever idea at 2am. Do this on day one, not after the scary moment.
Claude Code DocumentationThe official docs for the whole extensibility stack: memory, hooks, subagents, MCP. I keep this tab open.code.claude.comAnthropicpunkpeye/awesome-mcp-serversWhere I found half my MCP servers. Curated, actually maintained, saved me a week of trial and error.github.com/punkpeyemany

Three hooks so I can actually walk away

Hooks are the unglamorous part that nobody posts screenshots of, and they are the reason I sleep. The model does not have to remember to scan for secrets, format the code, or run typecheck. The harness does it every single time, deterministically, whether the model is feeling thorough or not.

  • PreToolUse: secret-scan runs before any write. If a key or token shows up in a diff, the write is blocked. Hard stop.
  • PostToolUse: prettier + eslint --fix formats and lints right after each edit, so I never review a diff full of whitespace noise.
  • Stop: run typecheck runs tsc when the session ends. If it does not compile, I know before I even look.
.claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": ".claude/hooks/secret-scan.sh" }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "npx prettier --write "$CLAUDE_FILE" && npx eslint --fix "$CLAUDE_FILE"" }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "npx tsc --noEmit" }
        ]
      }
    ]
  }
}
zsh - full-stack-prime
$claude "add a billing webhook handler and tests"
planner drafts the approach, I approve
PreToolUse: secret-scan ... clean
edit src/app/api/webhooks/stripe/route.ts
PostToolUse: prettier + eslint --fix ... ok
reviewer: missing idempotency check on event.id, sending back
implementer: added dedupe via processed_events table
tester: 6 passed (Playwright MCP)
Stop: tsc --noEmit ... 0 errors
I did not touch the keyboard for any of that. Wild.
$
Claude Code Hooks explained in 5 minutes5:42
Claude Code Hooks explained in 5 minutes· IndyDevDan

What it actually costs me

I track this stuff because I am a founder and credits are real money. Here are the numbers from my own runs, not a benchmark someone else ran on a clean repo.

MetricValueHow I feel about it
Avg response2.4sFine. Thinking time is the cost of fewer mistakes.
Cost per task$0.52Cheaper than the bug it would have caused.
Test pass rate91%The 9% is usually me writing a vague prompt.
Setuproll score94 (S tier)I will take it.
Where the money goes
Most of the spend is the planner and reviewer, the agents that never write a line of code. I used to think that was waste. Then I added up the rewrites they prevented and the math flipped overnight.

One real opinion before I wrap up: do not start with the four-agent loop. Start with one model, one good CLAUDE.md, and the secret-scan hook. Live with it for a week. Add the reviewer when you feel the pain of reviewing your own AI's code at midnight. The setup should grow out of your actual frustration, not out of a blog post, including this one.

Steal my setup

That is the whole build. Opus 4.8, four subagents, five MCP servers, three hooks, four rules. If you run a small product alone, this is the closest thing to a team I have found that does not require a payroll. Install it and tweak the rules to match your own bad days.

install
npx setuproll add claude-code-fullstack-prime

Then go read the official subagent docs and tune the reviewer to be meaner. Mine started polite and useless. It is much better now that I let it hurt my feelings a little.

2 Reviews

Your rating
Sign in to post
Sam Ojo@samojo·4h ago

How does this compare to the budget Sonnet build for a small repo? Tempted to skip the postgres server entirely.

Lena Faust@lenaf·11h ago

Been running something close to this for a month. The Stop hook running typecheck is the unglamorous part that pays off the most.