Generate Plan Peer Review Prompt

Step 1: Resolve the plan path

If $ARGUMENTS contains a path, resolve it to its absolute path and skip the interactive selection below.

If no argument was provided, auto-detect plan candidates and present an interactive selection:

Detect candidates (run these in parallel):

• Check git diff --name-only for recently modified plan/doc files

• Check git log --oneline -5 --diff-filter=AM -- 'docs/plans/**/*.md' for recently added/modified plans

• Look for plan files/directories matching docs/plans/**/*.md

• Check if a plan file was recently read or discussed in this session

ALWAYS present an AskUserQuestion multiple-choice UI with up to 4 detected candidates. Never just ask a text question — always use the interactive chip UI. Example:

AskUserQuestion(questions: [{ question: "Which plan do you want to review?", header: "Plan", options: [ { label: "phase-15-transcript-import/", description: "Modified 2 mins ago — 8 files" }, { label: "phase-14-streaming.md", description: "Modified 3 days ago" }, { label: "phase-13-host-notes.md", description: "Modified 1 week ago" } ], multiSelect: false }])

The user can always select "Other" (built into AskUserQuestion) to type a custom path.

If zero candidates are found, still use AskUserQuestion with 2 common locations as options:

options: [ { label: "docs/plans/", description: "Browse the plans directory" }, { label: "Browse recent files", description: "Show recently modified .md files" } ]

After selection, resolve the chosen path:

• If it's a file, use the absolute file path directly.

• If it's a directory, use the absolute directory path with a trailing / . The model will read all files in it — no need to enumerate individual files.

• If the path is relative, resolve it to absolute.

Verify the path exists.

Step 2: Load or detect the project's tech stack

Check for cached stack profile first: Read .claude/stack-profile.md in the project root. If it exists, use it directly — skip detection entirely.

If no cache exists, detect the stack by reading package.json , CLAUDE.md , README.md , and config files (tsconfig.json , next.config.* , biome.json , etc.) to identify:

• Framework (e.g. Next.js 16, Remix, Express, FastAPI, Rails)

• Language (e.g. TypeScript 5.9, Python 3.12)

• Database (e.g. Supabase/PostgreSQL, Prisma, Drizzle, MongoDB)

• API layer (e.g. tRPC, REST, GraphQL)

• Auth (e.g. Supabase Auth, Auth.js, Clerk)

• Validation (e.g. Zod, Yup, io-ts)

• Testing (e.g. Vitest, Jest, Playwright, agent-browser)

• Linting/Formatting (e.g. Biome, ESLint+Prettier)

• UI (e.g. Tailwind, Radix, shadcn/ui, MUI)

• Key patterns (e.g. RSC, Server Actions, App Router)

Then save the result to .claude/stack-profile.md with this format:

Stack Profile

<!-- Auto-generated by /prepare-plan-for-review. Edit to customize. -->

Tech Stack

Next.js 16, TypeScript 5.9, tRPC 11, Supabase, Zod 4, Vitest, Tailwind 4

Analysis Scope

• Backend: tRPC procedures, Supabase database operations, auth flows
• Frontend: React Server Components, Client Components, form validation with Zod
• Integration: End-to-end type safety, API contract validation

Best Practices

• TypeScript strict mode compliance (no 'any' types)
• Server Component usage prioritized over Client Components
• tRPC end-to-end type safety implementation
• Zod schema validation in both client and server
• Supabase RLS policies and migration best practices

Analysis Format

• Use TypeScript code examples matching the project's patterns
• Reference specific files: src/server/api/routers/*.ts, src/app/*/page.tsx
• Include test file examples: __tests__/*, *.test.ts
• Provide before/after code comparisons where applicable

Tell the user the profile was saved and can be edited at .claude/stack-profile.md if they want to tweak it.

Use the detected/cached values to fill in all placeholders below.

Step 3: Output the prompt

Your output MUST start with a line containing ONLY three backticks, then the prompt content, then end with a line containing ONLY three backticks. Like this:

[prompt content here]

This is critical — the user needs to see the literal backtick fences to know where to copy from and to.

Here is the template to fill in and output:

You are an AI development consultant specializing in Test-Driven Development implementation. Conduct a comprehensive end-to-end TDD implementation analysis of this proposed plan:

TECH STACK: <TECH STACK — one-liner, e.g. "Next.js 16, TypeScript 5.9, tRPC 11, Supabase, Zod 4, Vitest, Tailwind 4">

ANALYSIS SCOPE: <ANALYSIS SCOPE — 3-5 bullet points derived from the detected stack, e.g.:

• Backend: tRPC procedures, Supabase database operations, auth flows
• Frontend: React Server Components, Client Components, form validation with Zod
• Integration: End-to-end type safety, API contract validation>

REQUIRED DELIVERABLES:

1. Test Coverage Assessment (30-40% of analysis):

   • Unit tests: procedures, utility functions, validation schemas
   • Integration tests: Database operations, auth flows
   • E2E tests: Complete user journeys
   • Coverage gaps with specific file/function references

2. TDD Cycle Compliance Review (25-30% of analysis):

   • Red phase: Failing tests written first with clear assertions
   • Green phase: Minimal code to pass tests
   • Refactor phase: Code improvement while maintaining test pass
   • Evidence of proper cycle adherence per feature

3. Stack Best Practices Validation (25-30% of analysis): <BEST PRACTICES — 4-6 bullet points specific to detected stack, e.g.:

   • TypeScript strict mode compliance (no 'any' types)
   • Server Component usage prioritized over Client Components
   • tRPC end-to-end type safety implementation
   • Zod schema validation in both client and server
   • Supabase RLS policies and migration best practices>

4. Actionable Recommendations (15-20% of analysis):

   • Specific code examples for missing tests
   • Implementation steps for TDD cycle improvements
   • Technology-specific optimization suggestions

ANALYSIS FORMAT: <ANALYSIS FORMAT — 4-5 bullet points with file path patterns from the actual project, e.g.:

• Use TypeScript code examples matching the project's patterns
• Reference specific files: src/server/api/routers/*.ts, src/app/*/page.tsx
• Include test file examples: __tests__/*, *.test.ts
• Provide before/after code comparisons where applicable>
• DO NOT test the actual implemented codebase, you're purely giving feedback on the proposed plan

Plan: <FILE PATH TO PLAN>

SUCCESS CRITERIA:

• 90%+ test coverage on critical paths
• Complete Red-Green-Refactor cycle evidence
• Zero TypeScript 'any' types in production code
• End-to-end type safety from database to UI

IMPORTANT: Replace ALL angle-bracket placeholders with real values. The output must be a clean, ready-to-copy prompt with no placeholders remaining.

After outputting the code block, tell the user it's ready to copy into Cursor.