// Generate pull request descriptions following Grey Haven Studio standards with clear summary, motivation, implementation details, testing strategy, and comprehensive checklist. Use when creating or reviewing pull requests.
Multi-mode code quality analysis covering security reviews (OWASP Top 10), clarity refactoring (readability rules), synthesis analysis (cross-file issues), and DDD/DRY lenses (flags mechanical naming, primitive obsession, domain rules leaking into infrastructure, and premature abstractions via the three-occurrences-same-concept rule). Supports team-mode parallel analysis when invoked from quality-pipeline. Use when reviewing code for security vulnerabilities, improving code readability, conducting quality audits, pre-deployment checks, or when user mentions 'code quality', 'code review', 'security review', 'refactoring', 'code smell', 'OWASP', 'code clarity', 'primitive obsession', 'value object', 'ubiquitous language', 'DRY', 'premature abstraction', or 'quality audit'.
Comprehensive performance analysis and optimization for algorithms (O(n²)→O(n)), databases (N+1 queries, indexes), React (memoization, virtual lists), bundles (code splitting), API caching, and memory leaks. 85%+ improvement rate. Use when application is slow, response times exceed SLA, high CPU/memory usage, performance budgets needed, or when user mentions 'performance', 'slow', 'optimization', 'bottleneck', 'speed up', 'latency', 'memory leak', or 'performance tuning'.
Design RESTful APIs following Grey Haven standards - FastAPI routes, Pydantic schemas, HTTP status codes, pagination, filtering, error responses, OpenAPI docs, and multi-tenant patterns. Use when creating API endpoints, designing REST resources, implementing server functions, configuring FastAPI, writing Pydantic schemas, setting up error handling, implementing pagination, or when user mentions 'API', 'endpoint', 'REST', 'FastAPI', 'Pydantic', 'server function', 'OpenAPI', 'pagination', 'validation', 'error handling', 'rate limiting', 'CORS', or 'authentication'.
Automate developer onboarding with personalized plans, Linear integration, knowledge base setup, and milestone tracking. Use when onboarding new developers, planning team expansion, or managing role transitions.
Handle production incidents with SRE best practices including detection, investigation, mitigation, recovery, and postmortems. Use when dealing with production outages, SEV1/SEV2 incidents, creating postmortems, or updating runbooks.
Master TDD orchestration with multi-agent coordination, strict red-green-refactor enforcement, a Layer-0 domain-modeling gate (DDD) that blocks Red until concepts are named in domain vocabulary and primitives promoted to types, and principled DRY enforcement at Refactor (same-concept repetition ≥3 sites only). Automated test generation, coverage tracking, >90% coverage quality gates. Supports Claude Teams for parallel TDD workflows with plan approval gates, or falls back to sequential subagent coordination. Use when implementing features with TDD workflow, coordinating multiple TDD agents, enforcing test-first development, modeling a domain, orchestrating TDD teams, or when user mentions 'TDD workflow', 'test-first', 'TDD orchestration', 'multi-agent TDD', 'domain modeling', 'value object', 'ubiquitous language', 'DRY', 'test coverage', or 'red-green-refactor'.
| name | pr-template |
| description | Generate pull request descriptions following Grey Haven Studio standards with clear summary, motivation, implementation details, testing strategy, and comprehensive checklist. Use when creating or reviewing pull requests. |
| skills | ["code-style","testing-strategy"] |
| allowed-tools | ["Read","Bash","Grep","Glob","TodoWrite"] |
Create comprehensive, informative pull request descriptions that help reviewers understand the changes, context, and testing approach.
Every pull request should follow this structure:
## Summary
[Concise 2-4 sentence description of changes]
## Motivation
[Why these changes are needed - business value, user impact, problem solved]
## Implementation Details
[Technical approach, key decisions, trade-offs considered]
## Testing
[Test strategy: unit/integration/e2e/benchmark, manual testing steps]
## Checklist
- [ ] Code follows Grey Haven style guidelines (90 char TS, 130 char Python)
- [ ] Type hints added (Python) or types maintained (TypeScript)
- [ ] Tests added/updated (unit, integration, e2e, benchmark)
- [ ] Database migrations tested (up and down)
- [ ] Multi-tenant isolation verified (tenant_id/RLS)
- [ ] Pre-commit hooks passing
- [ ] Documentation updated
- [ ] No breaking changes (or documented with migration guide)
Purpose: Provide a brief, clear overview of what changed.
Guidelines:
GREY-123Example:
## Summary
This PR adds magic link authentication using better-auth with email verification.
Users can now sign in via emailed links instead of passwords. Addresses Linear
issue GREY-234 and integrates with multi-tenant RLS policies.
Purpose: Explain why these changes are necessary.
Guidelines:
GREY-123Example:
## Motivation
Users reported frustration with password-based auth (GREY-234). Analytics show
35% abandon signup at password creation. Magic links offer passwordless auth,
better security, reduced support burden, and built-in email verification.
Aligns with Q1 goal of improving onboarding conversion by 20%.
Purpose: Explain how the changes work at technical level.
Guidelines:
Example:
## Implementation Details
### Authentication Flow
1. Added magic link server function in [lib/server/functions/auth.ts:45](lib/server/functions/auth.ts#L45)
2. Created email template with Resend integration
3. Implemented token verification route at `/auth/verify`
### Key Changes
- **Server Functions**: New `sendMagicLink` and `verifyMagicLink` with tenant context
- **Database Schema**: Added `magic_link_tokens` table (snake_case, tenant_id, RLS)
- **Routes**: Magic link verification page with TanStack Router navigation
### Design Decisions
- Token expiry: 15 minutes (security vs UX balance)
- Single-use tokens with unique constraint
- Tenant isolation via RLS policies
- Email via Resend (better deliverability)
Purpose: Describe testing strategy and manual testing steps.
Guidelines:
Example:
## Testing
### Automated Tests
- **Unit tests** (18 new): Token generation, validation, expiry logic
- **Integration tests** (6 new): Email sending, database operations
- **E2e tests** (3 new): Full magic link flow with Playwright
### Manual Testing
1. Request magic link from login page
2. Verify email received within 30 seconds
3. Click link in email
4. Verify successful auth and redirect
5. Test expired token (wait 16 minutes)
6. Test single-use token (use link twice)
### Coverage
- New code: 94% coverage
- Critical paths: 100% coverage
Use this checklist before requesting review:
All supporting files are under 500 lines per Anthropic best practices:
examples/ - Complete PR examples
templates/ - Copy-paste ready templates
checklists/ - Pre-PR validation
Always include migration guide:
## Breaking Changes
**BREAKING:** User IDs are now UUIDs instead of sequential integers.
### Migration Guide
1. Update API clients to handle UUID format
2. Run database migration: `bun run db:migrate`
3. Update any hardcoded user IDs in tests
4. Verify multi-tenant isolation still works
### Timeline
- Migration available: 2025-01-15
- Required by: 2025-02-01
Include up and down testing:
## Database Migration
### Changes
- Add `tenant_id` column to `organizations` table
- Create RLS policies for tenant isolation
- Add index on `tenant_id`
### Testing
- ✅ Migration up: Successful
- ✅ Migration down: Successful
- ✅ Data backfill: Verified for 1000+ records
- ✅ RLS policies: Tested with different tenants
Use this skill when:
These standards come from Grey Haven's actual templates: