prepare-plan-for-review

📁 skinnyandbald/fish-skills 📅 8 days ago
3
总安装量
2
周安装量
#55986
全站排名
安装命令
npx skills add https://github.com/skinnyandbald/fish-skills --skill prepare-plan-for-review

Agent 安装分布

github-copilot 2
claude-code 2
mcpjam 1
kilo 1
windsurf 1
zencoder 1

Skill 文档

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:

  1. 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
  2. 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.

  3. 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.