prprompts-flutter-generator
Version:
AI-powered Flutter development with full automation + official extension support - Generate 32 security-audited guides & auto-implement in 2-3 hours. NEW v5.1: Official Claude Code plugin with hooks, Gemini TOML commands, Qwen MCP settings. Features: Comp
927 lines (740 loc) • 30.4 kB
Markdown
name: Generate PRPROMPTS
description: Generate all 32 PRPROMPTS files from PRD with strict PRP pattern
author: PRPROMPTS Generator
version: 2.0.0
tags: [prprompts, generator, flutter, clean-architecture, bloc]
# Generate Complete PRPROMPTS Folder
**IMPORTANT**: Generate a complete, secure, and adaptive `PRPROMPTS/` folder for a large-scale Flutter project using Clean Architecture, BLoC/Cubit, and dynamic team structuring.
## DEFINITIONS
### PRP (Prompt Reference Pattern)
Every file MUST follow this exact structure:
```markdown
## FEATURE
What this guide helps you accomplish
## EXAMPLES
Real code with actual file paths (e.g., lib/features/login/presentation/login_page.dart)
## CONSTRAINTS
✅ DO / ❌ DON'T rules
## VALIDATION GATES
Manual checklist + automated CI checks
## BEST PRACTICES
Junior-friendly explanations with "Why?" sections
## REFERENCES
Official docs, compliance guides, internal ADRs
```
### Clean Architecture
Uncle Bob's layered approach:
- **Presentation Layer**: UI, BLoC/Cubit, Widgets
- **Domain Layer**: Entities, Use Cases, Repository Interfaces
- **Data Layer**: Repository Implementations, Data Sources, Models
### JWT in Flutter (CRITICAL)
- ❌ **NEVER** sign tokens in Flutter
- ✅ **Backend signs** tokens (e.g., Node.js with `node-jsonwebtoken`, RS256)
- ✅ **Flutter only verifies** tokens using public key (`dart_jsonwebtoken` package)
- ❌ **NEVER** store private keys or secrets in Flutter code
- ✅ Always verify claims: `aud`, `iss`, `exp`, `sub`
**Example (Backend - Node.js)**:
```javascript
const token = jwt.sign(payload, privateKey, {
algorithm: 'RS256',
expiresIn: '15m',
audience: 'my-flutter-app',
issuer: 'api.example.com'
});
```
**Example (Flutter - Verification Only)**:
```dart
import 'package:dart_jsonwebtoken/dart_jsonwebtoken.dart';
Future<bool> verifyToken(String token) async {
try {
final jwt = JWT.verify(
token,
RSAPublicKey(publicKeyString),
audience: Audience(['my-flutter-app']),
issuer: 'api.example.com',
);
return jwt.payload['exp'] > DateTime.now().millisecondsSinceEpoch / 1000;
} catch (e) {
return false;
}
}
```
### Integrated Tools
1. **Structurizr** - C4 model as code
- Generates interactive architecture diagrams
- DSL format: `workspace.dsl`
- Example: `structurizr-cli export -workspace workspace.dsl -format plantuml`
2. **Serena MCP** - Semantic code analysis for Flutter
- Context-aware refactoring
- Flutter-specific rules
- Example: `serena analyze lib/features/`
3. **GitHub CLI** - AI-powered commands
- `/fix-github-issue 123` - Auto-fix issues
- `gh pr create --fill` - Auto PR descriptions
- `gh copilot suggest "add unit tests"`
## INPUT
Read and parse: `docs/PRD.md`
Extract YAML frontmatter for customization:
- `project_name`, `project_type`
- `platforms`, `auth_method`
- `compliance`, `sensitive_data`
- `team_size`, `team_composition`
- `offline_support`, `real_time`
- `state_management`, `database`
## OUTPUT DIRECTORY
**IMPORTANT**: All generated files MUST go inside the `PRPROMPTS/` folder.
### Folder Structure
```
PRPROMPTS/
├── 01-feature_scaffold.md
├── 02-responsive_layout.md
├── 03-bloc_implementation.md
├── ... (29 more numbered files)
├── 32-lessons_learned_engine.md
└── README.md
```
### Generation Steps
1. **First**: Create the `PRPROMPTS/` directory (if it doesn't exist)
2. **Then**: Generate all 32 numbered markdown files inside `PRPROMPTS/`
3. **Finally**: Generate `PRPROMPTS/README.md` as the index file
**Total**: 33 files (32 guides + 1 README), all inside `PRPROMPTS/` folder
## DELIVERY STRATEGY
Generate in **3 phases** to ensure completeness and avoid token limits.
## PHASE 1: Core Architecture (Files 1–10)
### 1. feature_scaffold.md
**Focus**: Clean Architecture + BLoC pattern for new features
**Required Sections**:
- FEATURE: Step-by-step scaffold for `lib/features/{feature_name}/`
- EXAMPLES: Full file paths for presentation/domain/data layers
- CONSTRAINTS: Dependency rules (domain → no imports)
- VALIDATION GATES: Tests required (unit, widget, integration)
- BEST PRACTICES: Why Clean Architecture? (testability, independence)
- REFERENCES: Uncle Bob's Clean Architecture book, Flutter BLoC docs
**Length**: 500-600 words
### 2. responsive_layout.md
**Focus**: Adaptive UI for mobile/tablet/desktop
**Required Sections**:
- FEATURE: `LayoutBuilder`, `MediaQuery`, breakpoints
- EXAMPLES: `lib/core/ui/responsive/responsive_layout.dart`
- CONSTRAINTS: ✅ DO use adaptive widgets, ❌ DON'T hardcode sizes
- VALIDATION GATES: Test on 3 screen sizes (phone/tablet/desktop)
- BEST PRACTICES: Why responsive? (user experience, App Store requirements)
- REFERENCES: Material Design responsive guidelines
**Length**: 500-600 words
### 3. bloc_implementation.md
**Focus**: BLoC vs Cubit decision matrix
**Required Sections**:
- FEATURE: When to use BLoC (complex state) vs Cubit (simple state)
- EXAMPLES: Login (Cubit), Search (BLoC with transformers)
- CONSTRAINTS: ✅ DO use `on<Event>`, ❌ DON'T emit in constructor
- VALIDATION GATES: 80%+ test coverage for BLoCs
- BEST PRACTICES: Why BLoC? (predictability, time-travel debugging)
- REFERENCES: BLoC library docs, state management comparison
**Length**: 500-600 words
### 4. api_integration.md
**Focus**: HTTP clients, JWT verification, error handling
**CRITICAL**: Include JWT verification (Flutter side only!)
**Required Sections**:
- FEATURE: Dio/Retrofit setup, interceptors, JWT verification
- EXAMPLES:
```dart
// lib/core/network/api_client.dart
class ApiClient {
final Dio dio;
Future<Response> get(String path) async {
final token = await _storage.getToken();
if (!await _verifyToken(token)) throw UnauthorizedException();
return dio.get(path, options: Options(headers: {'Authorization': 'Bearer $token'}));
}
}
```
- CONSTRAINTS: ✅ DO verify tokens client-side, ❌ DON'T trust expired tokens
- VALIDATION GATES: Test unauthorized scenarios (401/403)
- BEST PRACTICES: Why verify locally? (reduce server load, faster UX)
- REFERENCES: Dio docs, JWT RFC 7519, OWASP API Security
**Length**: 500-600 words
### 5. testing_strategy.md
**Focus**: Unit/Widget/Integration tests pyramid
**Required Sections**:
- FEATURE: Test structure, mocking, golden tests
- EXAMPLES:
```dart
// test/features/login/presentation/login_bloc_test.dart
blocTest<LoginBloc, LoginState>('emits [Loading, Success] on valid login',
build: () => LoginBloc(mockAuthRepository),
act: (bloc) => bloc.add(LoginSubmitted('user@email.com', 'pass123')),
expect: () => [Loading(), Success()],
);
```
- CONSTRAINTS: ✅ 70% unit, 20% widget, 10% integration
- VALIDATION GATES: 80%+ coverage required for merge
- BEST PRACTICES: Why test pyramid? (fast feedback, reliable builds)
- REFERENCES: Flutter testing docs, `bloc_test` package
**Length**: 500-600 words
### 6. design_system_usage.md
**Focus**: Shared theme, typography, spacing
**Required Sections**:
- FEATURE: `lib/core/theme/app_theme.dart`, Material 3
- EXAMPLES: `AppColors.primary`, `AppTextStyles.heading1`
- CONSTRAINTS: ✅ DO use theme constants, ❌ DON'T hardcode colors
- VALIDATION GATES: Design review required for new components
- BEST PRACTICES: Why design system? (consistency, maintainability)
- REFERENCES: Material Design 3, Figma design tokens
**Length**: 500-600 words
### 7. onboarding_junior.md
**Focus**: Step-by-step guide for new developers
**Required Sections**:
- FEATURE: Setup (Flutter SDK, IDE, Git), first PR workflow
- EXAMPLES: Checklist format with commands
- CONSTRAINTS: ✅ DO ask questions, ❌ DON'T commit to master
- VALIDATION GATES: Complete checklist before first PR
- BEST PRACTICES: Why structured onboarding? (faster ramp-up, culture)
- REFERENCES: Flutter setup docs, team coding standards
**Length**: 500-600 words
### 8. accessibility_a11y.md
**Focus**: WCAG 2.1 Level AA compliance
**Required Sections**:
- FEATURE: `Semantics` widget, screen readers, color contrast
- EXAMPLES:
```dart
Semantics(
label: 'Submit login form',
button: true,
child: ElevatedButton(onPressed: _submit, child: Text('Login')),
);
```
- CONSTRAINTS: ✅ 4.5:1 contrast ratio, ❌ DON'T rely on color alone
- VALIDATION GATES: TalkBack/VoiceOver testing required
- BEST PRACTICES: Why accessibility? (legal compliance, 15% of users)
- REFERENCES: WCAG 2.1 guidelines, Flutter accessibility docs
**Length**: 500-600 words
### 9. internationalization_i18n.md
**Focus**: Multi-language support (intl, ARB files)
**Required Sections**:
- FEATURE: `flutter_localizations`, ARB workflow
- EXAMPLES:
```dart
// lib/l10n/app_en.arb
{
"loginButton": "Login",
"@loginButton": { "description": "Text for login button" }
}
```
- CONSTRAINTS: ✅ DO use ARB descriptions, ❌ DON'T hardcode strings
- VALIDATION GATES: All user-facing strings must be in ARB
- BEST PRACTICES: Why i18n? (global reach, user preference)
- REFERENCES: Flutter i18n docs, ISO 639 language codes
**Length**: 500-600 words
### 10. performance_optimization.md
**Focus**: Build times, FPS, memory
**Required Sections**:
- FEATURE: `const` constructors, lazy loading, profiling
- EXAMPLES:
```dart
// Use const for stateless widgets
const Text('Static text'); // ✅
Text('Static text'); // ❌ (creates new instance)
```
- CONSTRAINTS: ✅ 60 FPS target, ❌ DON'T block UI thread
- VALIDATION GATES: DevTools profiler check before merge
- BEST PRACTICES: Why optimize? (battery life, user retention)
- REFERENCES: Flutter performance docs, Dart analyzer
**Length**: 500-600 words
## PHASE 2: Quality, Security & Team (Files 11–22)
### 11. git_branching_strategy.md
**Focus**: Git workflow (feature branches, PR reviews)
**Required Sections**:
- FEATURE: Branch naming (`feature/`, `fix/`, `hotfix/`), merge strategy
- EXAMPLES: `git checkout -b feature/login-screen`
- CONSTRAINTS: ✅ DO squash commits, ❌ DON'T force-push to main
- VALIDATION GATES: 2 approvals required for merge
- BEST PRACTICES: Why feature branches? (parallel work, rollback)
- REFERENCES: Git Flow, GitHub Flow, team Git standards
**Length**: 500-600 words
### 12. progress_tracking_workflow.md
**Focus**: Sprint planning, issue tracking
**Required Sections**:
- FEATURE: Jira/Linear/GitHub Projects, story points
- EXAMPLES: Issue template with acceptance criteria
- CONSTRAINTS: ✅ DO link PRs to issues, ❌ DON'T work without tickets
- VALIDATION GATES: All PRs must reference an issue
- BEST PRACTICES: Why tracking? (transparency, velocity metrics)
- REFERENCES: Agile manifesto, Scrum guide
**Length**: 500-600 words
### 13. multi_team_coordination.md
**Focus**: Cross-team dependencies, sync meetings
**Required Sections**:
- FEATURE: API contracts, feature flags, shared libraries
- EXAMPLES: `lib/shared/` for cross-team code
- CONSTRAINTS: ✅ DO document breaking changes, ❌ DON'T break downstream
- VALIDATION GATES: Downstream team approval for API changes
- BEST PRACTICES: Why coordination? (avoid blockers, reduce duplication)
- REFERENCES: API design guidelines, RFC process
**Length**: 500-600 words
### 14. security_audit_checklist.md
**Focus**: Pre-release security validation
**Required Sections**:
- FEATURE: Checklist (no secrets in code, HTTPS only, etc.)
- EXAMPLES:
```bash
# Check for secrets
git secrets --scan
# Check dependencies
flutter pub outdated
```
- CONSTRAINTS: ✅ DO use `.env` files, ❌ DON'T commit API keys
- VALIDATION GATES: Security audit before production deploy
- BEST PRACTICES: Why audit? (compliance, reputation risk)
- REFERENCES: OWASP Mobile Top 10, Flutter security best practices
**Length**: 500-600 words
### 15. release_management.md
**Focus**: App Store submission, versioning
**Required Sections**:
- FEATURE: Release notes, screenshots, beta testing (TestFlight/Firebase)
- EXAMPLES: `pubspec.yaml` version bump (1.0.0+1 → 1.0.1+2)
- CONSTRAINTS: ✅ DO test on real devices, ❌ DON'T skip beta
- VALIDATION GATES: QA signoff required
- BEST PRACTICES: Why staged rollout? (early bug detection)
- REFERENCES: App Store Connect docs, Google Play Console docs
**Length**: 500-600 words
### 16. security_and_compliance.md ⭐ **PRD-SENSITIVE**
**Focus**: HIPAA/PCI-DSS/GDPR compliance (if applicable)
**CRITICAL**: Adapt based on PRD's `compliance` field
**Required Sections**:
- FEATURE: Encryption (AES-256-GCM), audit logging, JWT verification
- EXAMPLES (if HIPAA):
```dart
// Encrypt PHI before storage
final encrypted = await _encryptor.encrypt(
patientData,
key: await _secureStorage.getEncryptionKey(),
);
await _db.insert('patients', {'data': encrypted});
```
- EXAMPLES (if PCI-DSS):
```dart
// NEVER store full credit card numbers
final last4 = cardNumber.substring(cardNumber.length - 4);
await _db.insert('cards', {'last4': last4, 'token': stripeToken});
```
- CONSTRAINTS: ✅ DO use `flutter_secure_storage`, ❌ DON'T log sensitive data
- VALIDATION GATES: Compliance audit before production
- BEST PRACTICES: Why encrypt at rest? (HIPAA §164.312(a)(2)(iv) requirement)
- REFERENCES: HIPAA Security Rule, PCI-DSS v4.0, GDPR Article 32
**Length**: 500-600 words
### 17. performance_optimization_detailed.md
**Focus**: Advanced profiling (DevTools, memory leaks)
**Required Sections**:
- FEATURE: Timeline view, memory snapshots, `compute()` for heavy tasks
- EXAMPLES:
```dart
// Offload JSON parsing to isolate
final data = await compute(parseJsonInBackground, response.body);
```
- CONSTRAINTS: ✅ DO profile on low-end devices, ❌ DON'T optimize prematurely
- VALIDATION GATES: < 100ms jank frames on profiling
- BEST PRACTICES: Why isolates? (avoid blocking UI thread)
- REFERENCES: Flutter DevTools docs, Dart isolates guide
**Length**: 500-600 words
### 18. quality_gates_and_code_metrics.md
**Focus**: Coverage, complexity, linting
**Required Sections**:
- FEATURE: `lcov` reports, cyclomatic complexity, `dart analyze`
- EXAMPLES:
```yaml
# .github/workflows/quality.yml
- run: flutter test --coverage
- run: genhtml coverage/lcov.info -o coverage/html
- uses: codecov/codecov-action@v3
```
- CONSTRAINTS: ✅ 80%+ coverage, ❌ DON'T ignore lints
- VALIDATION GATES: CI must pass before merge
- BEST PRACTICES: Why metrics? (technical debt visibility)
- REFERENCES: Dart analyzer rules, SonarQube for Flutter
**Length**: 500-600 words
### 19. localization_and_accessibility.md
**Focus**: Combined i18n + a11y best practices
**Required Sections**:
- FEATURE: RTL support, screen reader labels in multiple languages
- EXAMPLES:
```dart
// lib/l10n/app_ar.arb (Arabic - RTL)
{
"loginButton": "تسجيل الدخول",
"@loginButton": { "description": "زر تسجيل الدخول" }
}
```
- CONSTRAINTS: ✅ DO test RTL layouts, ❌ DON'T assume LTR
- VALIDATION GATES: Native speaker review for each language
- BEST PRACTICES: Why RTL testing? (Arabic, Hebrew user experience)
- REFERENCES: Unicode bidirectional algorithm, Flutter RTL docs
**Length**: 500-600 words
### 20. versioning_and_release_notes.md
**Focus**: Semantic versioning, changelog automation
**Required Sections**:
- FEATURE: `pubspec.yaml` versioning, `CHANGELOG.md` format
- EXAMPLES:
```markdown
## [1.2.0] - 2024-03-15
### Added
- Dark mode support
### Fixed
- Login crash on iOS 12
```
- CONSTRAINTS: ✅ DO follow semver (MAJOR.MINOR.PATCH)
- VALIDATION GATES: Changelog updated before release
- BEST PRACTICES: Why semver? (dependency management clarity)
- REFERENCES: semver.org, Keep a Changelog
**Length**: 500-600 words
### 21. team_culture_and_communication.md
**Focus**: Async-first communication, documentation
**Required Sections**:
- FEATURE: Slack/Discord best practices, RFC process
- EXAMPLES: RFC template for architectural decisions
- CONSTRAINTS: ✅ DO document decisions, ❌ DON'T rely on tribal knowledge
- VALIDATION GATES: ADR (Architecture Decision Record) for major changes
- BEST PRACTICES: Why async? (global teams, deep work time)
- REFERENCES: Remote work guides, ADR templates
**Length**: 500-600 words
### 22. autodoc_integration.md
**Focus**: Auto-generate docs from code comments
**Required Sections**:
- FEATURE: `dartdoc`, JSDoc for APIs, Swagger/OpenAPI
- EXAMPLES:
```dart
/// Logs in a user with [email] and [password].
///
/// Throws [UnauthorizedException] if credentials are invalid.
/// Returns a [User] object on success.
Future<User> login(String email, String password) async { ... }
```
- CONSTRAINTS: ✅ DO document public APIs, ❌ DON'T over-comment private methods
- VALIDATION GATES: `dartdoc` must build without warnings
- BEST PRACTICES: Why doc comments? (IDE autocomplete, onboarding)
- REFERENCES: Effective Dart: Documentation, JSDoc spec
**Length**: 500-600 words
## PHASE 3: Advanced Systems (Files 23–32 + README)
### 23. ai_pair_programming_guide.md
**Focus**: Claude Code, GitHub Copilot integration
**Required Sections**:
- FEATURE: AI-assisted refactoring, test generation
- EXAMPLES:
```dart
// Prompt: "Add null safety checks to this function"
// Copilot suggests:
if (user?.email == null) throw ArgumentError('Email required');
```
- CONSTRAINTS: ✅ DO review AI suggestions, ❌ DON'T blindly accept
- VALIDATION GATES: Human review required for AI-generated code
- BEST PRACTICES: Why AI? (faster boilerplate, learning tool)
- REFERENCES: GitHub Copilot docs, Claude Code documentation
**Length**: 500-600 words
### 24. dashboard_and_analytics.md
**Focus**: Firebase Analytics, Crashlytics, custom metrics
**Required Sections**:
- FEATURE: Event tracking, crash reports, performance monitoring
- EXAMPLES:
```dart
await FirebaseAnalytics.instance.logEvent(
name: 'login_success',
parameters: {'method': 'email'},
);
```
- CONSTRAINTS: ✅ DO track user flows, ❌ DON'T log PII
- VALIDATION GATES: Privacy review for analytics events
- BEST PRACTICES: Why analytics? (data-driven decisions, bug prioritization)
- REFERENCES: Firebase docs, GDPR consent guidelines
**Length**: 500-600 words
### 25. tech_debt_and_refactor_strategy.md
**Focus**: Tracking debt, scheduled refactors
**Required Sections**:
- FEATURE: Debt scoring (High/Medium/Low), refactor sprints
- EXAMPLES: GitHub Issues labeled `tech-debt`
- CONSTRAINTS: ✅ DO allocate 20% sprint capacity, ❌ DON'T ignore warnings
- VALIDATION GATES: Quarterly tech debt review
- BEST PRACTICES: Why track debt? (compound interest analogy)
- REFERENCES: Martin Fowler on refactoring, Code Complete
**Length**: 500-600 words
### 26. demo_environment_setup.md ⭐ **PRD-SCENARIO BASED**
**Focus**: Demo-specific data, workflows
**Adapt based on PRD's `project_type`**:
- Healthcare: Pre-populated patient records
- Fintech: Test credit card numbers (4242...)
- Education: Sample courses and students
**Required Sections**:
- FEATURE: Demo database seeding, mock APIs
- EXAMPLES:
```dart
// lib/core/demo/demo_data.dart
final demoPatientsHealthcare = [
Patient(id: '1', name: 'John Doe', condition: 'Diabetes'),
];
final demoCardsFintech = [
CreditCard(last4: '4242', brand: 'Visa', expiryMonth: 12, expiryYear: 2025),
];
```
- CONSTRAINTS: ✅ DO use "Demo" badges, ❌ DON'T mix with prod data
- VALIDATION GATES: QA approval of demo scenarios
- BEST PRACTICES: Why demo mode? (sales presentations, user testing)
- REFERENCES: Feature flags guide, environment configs
**Length**: 500-600 words
### 27. demo_progress_tracker.md
**Focus**: Client-facing dashboard for demos
**Required Sections**:
- FEATURE: Sprint burn-down, completed features list
- EXAMPLES: Public-facing `/demo-status` page
- CONSTRAINTS: ✅ DO update weekly, ❌ DON'T show internal metrics
- VALIDATION GATES: PM approval before publishing
- BEST PRACTICES: Why transparency? (builds client trust)
- REFERENCES: Agile reporting tools, burndown chart templates
**Length**: 500-600 words
### 28. demo_branding_and_visuals.md
**Focus**: Client-specific theming for demos
**Required Sections**:
- FEATURE: Logo replacement, color scheme overrides
- EXAMPLES:
```dart
// lib/core/theme/demo_theme.dart
final clientATheme = AppTheme.copyWith(primaryColor: Color(0xFF1E88E5));
```
- CONSTRAINTS: ✅ DO use feature flags, ❌ DON'T hardcode client names
- VALIDATION GATES: Design review for each client theme
- BEST PRACTICES: Why custom themes? (shows product flexibility)
- REFERENCES: Material Design theming, brand guidelines
**Length**: 500-600 words
### 29. demo_deployment_automation.md
**Focus**: CI/CD for demo builds
**Required Sections**:
- FEATURE: GitHub Actions for demo.example.com deployments
- EXAMPLES:
```yaml
# .github/workflows/deploy-demo.yml
on:
push:
branches: [demo]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- run: flutter build web
- uses: peaceiris/actions-gh-pages@v3
```
- CONSTRAINTS: ✅ DO use separate Firebase projects, ❌ DON'T deploy to prod accidentally
- VALIDATION GATES: Smoke tests after deployment
- BEST PRACTICES: Why automate? (consistent demos, faster iterations)
- REFERENCES: GitHub Actions docs, Firebase hosting
**Length**: 500-600 words
### 30. client_demo_report_template.md
**Focus**: Weekly/biweekly demo summaries
**Required Sections**:
- FEATURE: Template with screenshots, video links, next sprint goals
- EXAMPLES:
```markdown
## Demo Report - Week 12
**Completed**:
- Login screen with biometric auth
**In Progress**:
- Offline sync implementation
**Next**:
- Dashboard analytics
```
- CONSTRAINTS: ✅ DO include visuals, ❌ DON'T use technical jargon
- VALIDATION GATES: PM review before sending to client
- BEST PRACTICES: Why reports? (stakeholder alignment, issue early detection)
- REFERENCES: Project status report templates
**Length**: 500-600 words
### 31. project_role_adaptation.md ⭐ **PRD-DRIVEN**
**Focus**: Dynamic role assignment based on team size/composition
**Adapt based on PRD's `team_size` and `team_composition`**:
- Small (5-10): Generalists, rotated roles
- Medium (11-25): Dedicated QA, DevOps
- Large (26-50+): Specialized teams (iOS, Android, Backend, etc.)
**Required Sections**:
- FEATURE: RACI matrix, role definitions
- EXAMPLES:
```markdown
## Team: Medium (15 devs)
- Tech Lead (1)
- Senior Developers (3) - architecture reviews, mentoring
- Mid-level Developers (6) - feature implementation
- Junior Developers (3) - bug fixes, tests
- QA Engineer (1)
- DevOps Engineer (1)
```
- CONSTRAINTS: ✅ DO cross-train, ❌ DON'T silo knowledge
- VALIDATION GATES: Quarterly role review
- BEST PRACTICES: Why adapt roles? (scale efficiency, prevent bottlenecks)
- REFERENCES: Spotify model, team topologies
**Length**: 500-600 words
### 32. lessons_learned_engine.md
**Focus**: Retrospectives, continuous improvement
**Required Sections**:
- FEATURE: Retro format (Start/Stop/Continue), action items tracking
- EXAMPLES:
```markdown
## Sprint 10 Retro
**Start**: Pair programming for complex features
**Stop**: Last-minute PRs on Fridays
**Continue**: Weekly design reviews
**Actions**:
- [ ] @john Schedule pairing sessions in calendar
- [ ] @team Enforce PR deadline: Thursday 5pm
```
- CONSTRAINTS: ✅ DO make retros blameless, ❌ DON'T skip action items
- VALIDATION GATES: Follow-up on previous retro actions
- BEST PRACTICES: Why retros? (team morale, process optimization)
- REFERENCES: Agile Retrospectives book, Retro formats
**Length**: 500-600 words
### PRPROMPTS/README.md
**Focus**: Index of all 32 files with usage guide
**Required Sections**:
- Overview of PRP pattern
- File structure (numbered list with descriptions)
- How to use (e.g., "Reference during feature development", "Pre-merge checklist")
- Customizations applied (based on PRD)
- Tools integrated (Structurizr, Serena MCP, GitHub CLI)
**Length**: 300-400 words
## CUSTOMIZATION RULES
Apply these rules based on PRD YAML metadata:
### Compliance-Based Customization
- **HIPAA** (`compliance: ["hipaa"]`):
- `16-security_and_compliance.md`: Add PHI encryption, audit logging
- `04-api_integration.md`: Add HTTPS-only validation
- `24-dashboard_and_analytics.md`: Warn against logging PHI
- **PCI-DSS** (`compliance: ["pci-dss"]`):
- `16-security_and_compliance.md`: Add payment tokenization (Stripe/PayPal)
- `04-api_integration.md`: Add TLS 1.2+ requirement
- `14-security_audit_checklist.md`: Add PCI SAQ checklist
- **GDPR** (`compliance: ["gdpr"]`):
- `16-security_and_compliance.md`: Add consent management, right to erasure
- `24-dashboard_and_analytics.md`: Add cookie consent
### Auth Method Customization
- **JWT** (`auth_method: "jwt"`):
- `04-api_integration.md`: Add JWT verification example (Flutter side only!)
- `16-security_and_compliance.md`: Add token refresh flow
- **OAuth2** (`auth_method: "oauth2"`):
- `04-api_integration.md`: Add OAuth2 flow (Google/GitHub)
- `16-security_and_compliance.md`: Add PKCE requirement
- **Firebase** (`auth_method: "firebase"`):
- `04-api_integration.md`: Add Firebase Auth example
- `24-dashboard_and_analytics.md`: Add Firebase Console integration
### Offline Support Customization
- **Offline Mode** (`offline_support: true`):
- `04-api_integration.md`: Add retry logic, queue sync
- `10-performance_optimization.md`: Add offline-first patterns
- `26-demo_environment_setup.md`: Add offline demo scenario
### Team Size Customization
- **Small** (`team_size: "5-10"`):
- `31-project_role_adaptation.md`: Generalist roles, rotated responsibilities
- `13-multi_team_coordination.md`: Simplified, single team focus
- **Large** (`team_size: "26-50|50+"`):
- `31-project_role_adaptation.md`: Specialized roles (iOS/Android/Backend)
- `13-multi_team_coordination.md`: Cross-team API contracts, RFC process
### State Management Customization
- **BLoC** (`state_management: "bloc"`):
- `03-bloc_implementation.md`: Full BLoC examples with events/states
- `05-testing_strategy.md`: Use `bloc_test` package
- **Riverpod** (`state_management: "riverpod"`):
- `03-bloc_implementation.md`: Rename to `state_management.md`, use Riverpod
- `05-testing_strategy.md`: Use `ProviderContainer` for tests
## QUALITY REQUIREMENTS
### Per File:
- ✅ **Length**: 500-600 words (README: 300-400)
- ✅ **Format**: Strict PRP sections (FEATURE, EXAMPLES, CONSTRAINTS, VALIDATION GATES, BEST PRACTICES, REFERENCES)
- ✅ **Examples**: Real Flutter paths (e.g., `lib/features/login/presentation/login_page.dart`)
- ✅ **Junior-Friendly**: Explain "why" (e.g., "We verify `aud` to prevent token reuse across services")
- ✅ **Validation Gates**: Tests/docs/reviews required before merge
- ❌ **NO PLACEHOLDERS**: Replace all `[...]`, `{feature_name}`, `TODO` with actual content
### Critical Technical Corrections:
1. **JWT**: NEVER show Flutter signing tokens. Only verification with public key.
2. **PCI-DSS**: NEVER store full credit card numbers. Use tokenization.
3. **HIPAA**: Always encrypt PHI at rest (AES-256-GCM).
4. **State Management**: BLoC for complex, Cubit for simple.
## SUCCESS MESSAGE
After generating all files:
```
✅ Generated 33 files in PRPROMPTS/
Files created:
- 01-feature_scaffold.md through 32-lessons_learned_engine.md
- README.md
Customizations applied based on PRD:
[List customizations, e.g.:]
- HIPAA compliance: PHI encryption in security_and_compliance.md
- JWT auth: Token verification in api_integration.md
- Offline support: Sync strategies in performance_optimization.md
- Team size (26-50): Specialized roles in project_role_adaptation.md
Integrated Tools:
- Structurizr C4 diagrams
- Serena MCP for semantic analysis
- GitHub CLI AI commands
Next steps:
1. Review: cat PRPROMPTS/README.md
2. Start feature: cat PRPROMPTS/01-feature_scaffold.md
3. Reference during development: grep "jwt" PRPROMPTS/*.md
Quality checklist:
✅ All files 500-600 words
✅ All sections follow PRP pattern
✅ No placeholders or TODOs
✅ Real code examples with file paths
✅ Junior-friendly "why" explanations
✅ Validation gates specified
```
## IMPORTANT NOTES
1. **Generate in 3 phases** to avoid token limits
2. **Read PRD first** to extract customization metadata
3. **Apply customizations** based on compliance, auth, team size, etc.
4. **No placeholders** - all content must be complete and actionable
5. **Junior-friendly** - explain the "why" behind every rule
6. **Security-critical** - double-check JWT, PCI-DSS, HIPAA examples
## BEGIN GENERATION
**IMPORTANT FOR GEMINI CLI**: You have access to file creation tools. Use them directly to create files - do NOT try to run shell commands.
### Step 1: Read PRD
First, look for and read one of these files:
- `PRD.md` (root directory)
- `docs/PRD.md`
- Any `.md` file with "PRD" in the name
Extract the YAML frontmatter to understand:
- project_name, project_type
- platforms, auth_method
- compliance requirements
- team_size, state_management
### Step 2: Generate Files Directly
**Use your WriteFile tool to create each file in the PRPROMPTS/ directory.**
Start with Phase 1 (files 01-10), then Phase 2 (11-22), then Phase 3 (23-32), then README.
For each file:
1. Create the file using WriteFile with path: `PRPROMPTS/01-feature_scaffold.md`
2. Include all required PRP sections (FEATURE, EXAMPLES, CONSTRAINTS, VALIDATION GATES, BEST PRACTICES, REFERENCES)
3. Make it 500-600 words with real Flutter code examples
4. Move to the next file
### File Generation Pattern
```
WriteFile: PRPROMPTS/01-feature_scaffold.md
WriteFile: PRPROMPTS/02-responsive_layout.md
WriteFile: PRPROMPTS/03-bloc_implementation.md
...
WriteFile: PRPROMPTS/32-lessons_learned_engine.md
WriteFile: PRPROMPTS/README.md
```
### Example File Paths
```
PRPROMPTS/01-feature_scaffold.md ✅ Correct
PRPROMPTS/16-security_and_compliance.md ✅ Correct
PRPROMPTS/32-lessons_learned_engine.md ✅ Correct
PRPROMPTS/README.md ✅ Correct
```
**DO NOT** try to run commands like:
- `mkdir PRPROMPTS` ❌
- `gemini gen-phase-1` ❌
- Shell commands ❌
**INSTEAD** directly create files with your WriteFile tool ✅