Générer un projet
/generate-pr-reviewTout d'abord, découvrez les caractéristiques du projet à partir de plusieurs sources :
description: Generate project-specific PR review automation that combines global rules with project conventions
allowed-tools: Read, Glob, Grep, Write, Bash(git:), Bash(npm:), Bash(cat:*)
Generate Project-Specific PR Review Automation
You are generating a customized PR review configuration for this project. This combines:
- Global rules from CLAUDE.md (TDD, TypeScript strict, functional patterns)
- Project-specific rules discovered from codebase analysis
Step 1: Analyze the Project
First, discover the project's characteristics from multiple sources:
AI/LLM Configuration Files
Critical: Check for existing AI assistant configurations that define project rules:
# Claude Code
.claude/CLAUDE.md
.claude/settings.json
.claude/agents/*.md
.claude/skills/*/SKILL.md
CLAUDE.md (root level)
# Cursor
.cursorrules
.cursor/rules/*.md
# GitHub Copilot
.github/copilot-instructions.md
# Aider
.aider.conf.yml
.aiderignore
# Codeium
.codeium/config.json
# Other common patterns
.ai-rules
.llm-config
AGENTS.md
CONTRIBUTING.md (often contains coding standards)Extract rules, patterns, and conventions from these files - they represent explicit project decisions.
Project Documentation
Check for documented conventions:
# Architecture Decision Records
docs/adr/*.md
docs/decisions/*.md
adr/*.md
architecture/decisions/*.md
# General documentation
docs/*.md
README.md
CONTRIBUTING.md
DEVELOPMENT.md
CODING_STANDARDS.md
STYLE_GUIDE.md
# API documentation
docs/api/*.md
API.mdParse ADRs for architectural decisions that affect code review (e.g., "We use Zod for all validation").
CI Pipeline Detection
Check for CI configuration files and document the pipeline:
# GitHub Actions
.github/workflows/*.yml
# Forgejo Actions
.forgejo/workflows/*.yml
# Woodpecker
.woodpecker/*.yml
# Other
Jenkinsfile
.circleci/config.yml
.gitlab-ci.ymlExtract: pipeline steps, execution order, Node/runtime versions, environment variables, and any known differences from local development.
Tech Stack Detection
Check for:
package.json- Dependencies, scripts, type of projecttsconfig.json- TypeScript configuration (notestrict,noUncheckedIndexedAccess, and other strict flags).eslintrc.*oreslint.config.*- Linting rulesjest.config.*orvitest.config.*- Testing setupbiome.json- Biome configuration.prettierrc*- Formatting rules
Framework/Library Detection
Look for:
- React/Vue/Angular/Svelte in dependencies
- Express/Fastify/Hono for backend
- Testing libraries (Jest, Vitest, Testing Library)
- State management (Redux, Zustand, etc.)
- Schema libraries (Zod, io-ts, Yup, etc.)
Existing Code Conventions
Search for:
- Existing code patterns in
src/ - Test file organization
- Naming conventions
- Import patterns
Step 2: Create Project Review Configuration
Based on analysis, create .claude/agents/pr-reviewer.md in the project:
---
name: pr-reviewer
description: >
Project-specific PR review combining global standards with [PROJECT_NAME] conventions.
Use proactively for review guidance or reactively to analyze PRs.
tools: Read, Grep, Glob, Bash
model: sonnet
color: cyan
---
# [PROJECT_NAME] PR Review
This reviewer enforces:
1. **Global standards** - TDD, TypeScript strict, functional patterns
2. **Project conventions** - [Discovered patterns]
## Global Rules (Non-Negotiable)
### TDD Compliance
- Every production code change needs corresponding tests
- Tests come BEFORE implementation (test-first)
- Tests verify behavior, not implementation
### Testing Quality
- Test through public API only
- No `let`/`beforeEach` - use factory functions
- Factory functions validate with real schemas (don't redefine)
- No spying on internal methods
- No 1:1 mapping between test files and implementation files
### TypeScript Strictness
- No `any` types - ever
- No type assertions without justification
- `type` for data structures, `interface` for behavior contracts
- Schema-first at trust boundaries (Zod/Standard Schema)
- `readonly` on immutable data
[IF noUncheckedIndexedAccess IS ENABLED: - All indexed access returns `T | undefined` — use optional chaining or explicit guards, never non-null assertions]
[ADD ANY OTHER STRICT FLAGS DETECTED FROM tsconfig.json]
### Functional Patterns
- No data mutation (no `.push()`, `.splice()`, property assignment)
- Pure functions (no side effects)
- Early returns (no nested if/else)
- Array methods over loops
- Options objects over positional parameters
- No comments (self-documenting code)
### General Quality
- No `console.log` or debug statements
- No TODO comments without linked issues
- No hardcoded secrets
- Small, focused changes
---
## Project-Specific Rules
[GENERATED BASED ON PROJECT ANALYSIS]
### Rules from Existing Configuration
[Extract from .cursorrules, CLAUDE.md, .github/copilot-instructions.md, CONTRIBUTING.md, etc.]
**Source files found:**
- [L
