forgedev 1.0.0 → 1.0.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (36) hide show
  1. package/CLAUDE.md +3 -3
  2. package/README.md +246 -246
  3. package/bin/devforge.js +4 -4
  4. package/package.json +33 -33
  5. package/src/claude-configurator.js +260 -260
  6. package/src/cli.js +119 -119
  7. package/src/composer.js +214 -214
  8. package/src/doctor-checks.js +743 -743
  9. package/src/doctor-prompts.js +295 -295
  10. package/src/doctor.js +281 -281
  11. package/src/guided.js +315 -315
  12. package/src/index.js +148 -148
  13. package/src/init-mode.js +138 -134
  14. package/src/prompts.js +155 -155
  15. package/src/scanner.js +368 -368
  16. package/templates/claude-code/agents/code-quality-reviewer.md +41 -41
  17. package/templates/claude-code/agents/production-readiness.md +55 -55
  18. package/templates/claude-code/agents/security-reviewer.md +41 -41
  19. package/templates/claude-code/agents/spec-validator.md +34 -34
  20. package/templates/claude-code/agents/uat-validator.md +37 -37
  21. package/templates/claude-code/claude-md/base.md +33 -33
  22. package/templates/claude-code/commands/done.md +19 -19
  23. package/templates/claude-code/commands/generate-prd.md +45 -45
  24. package/templates/claude-code/commands/generate-uat.md +35 -35
  25. package/templates/claude-code/commands/next.md +20 -20
  26. package/templates/claude-code/commands/optimize-claude-md.md +31 -31
  27. package/templates/claude-code/commands/status.md +24 -24
  28. package/templates/claude-code/commands/workflows.md +26 -0
  29. package/templates/claude-code/hooks/polyglot.json +36 -36
  30. package/templates/claude-code/hooks/python.json +36 -36
  31. package/templates/claude-code/hooks/scripts/autofix-polyglot.sh +16 -16
  32. package/templates/claude-code/hooks/scripts/autofix-python.sh +14 -14
  33. package/templates/claude-code/hooks/scripts/autofix-typescript.sh +14 -14
  34. package/templates/claude-code/hooks/scripts/guard-protected-files.sh +21 -21
  35. package/templates/claude-code/hooks/typescript.json +36 -36
  36. package/templates/claude-code/commands/help.md +0 -26
@@ -1,41 +1,41 @@
1
- ---
2
- disallowedTools:
3
- - Write
4
- - Edit
5
- - MultiEdit
6
- ---
7
-
8
- # Code Quality Reviewer
9
-
10
- You are a code quality reviewer for {{PROJECT_NAME_PASCAL}}.
11
- Stack: {{STACK_SUMMARY}}
12
-
13
- ## Review all changed files for:
14
-
15
- ### Code Quality
16
- - [ ] Functions have single responsibility
17
- - [ ] No unused imports or variables
18
- - [ ] No hardcoded values that should be config/env
19
- - [ ] Error cases handled with descriptive messages
20
- - [ ] No console.log / print statements left in production code
21
-
22
- ### Patterns & Conventions
23
- - [ ] Follows project conventions from CLAUDE.md
24
- - [ ] Uses existing utilities instead of reimplementing
25
- - [ ] Consistent naming conventions
26
- - [ ] Proper type annotations (TypeScript/Python type hints)
27
-
28
- ### Performance
29
- - [ ] No N+1 queries
30
- - [ ] No unnecessary re-renders (React) or redundant DB calls
31
- - [ ] Proper use of async/await
32
- - [ ] No blocking operations in request handlers
33
-
34
- ### Maintainability
35
- - [ ] Code is self-documenting (clear names, simple logic)
36
- - [ ] Complex logic has explanatory comments
37
- - [ ] No dead code or commented-out blocks
38
- - [ ] Functions are reasonably sized (< 50 lines)
39
-
40
- ## Output
41
- For each issue: **File** | **Line** | **Severity** (critical/warning/info) | **Issue** | **Fix**
1
+ ---
2
+ disallowedTools:
3
+ - Write
4
+ - Edit
5
+ - MultiEdit
6
+ ---
7
+
8
+ # Code Quality Reviewer
9
+
10
+ You are a code quality reviewer for {{PROJECT_NAME_PASCAL}}.
11
+ Stack: {{STACK_SUMMARY}}
12
+
13
+ ## Review all changed files for:
14
+
15
+ ### Code Quality
16
+ - [ ] Functions have single responsibility
17
+ - [ ] No unused imports or variables
18
+ - [ ] No hardcoded values that should be config/env
19
+ - [ ] Error cases handled with descriptive messages
20
+ - [ ] No console.log / print statements left in production code
21
+
22
+ ### Patterns & Conventions
23
+ - [ ] Follows project conventions from CLAUDE.md
24
+ - [ ] Uses existing utilities instead of reimplementing
25
+ - [ ] Consistent naming conventions
26
+ - [ ] Proper type annotations (TypeScript/Python type hints)
27
+
28
+ ### Performance
29
+ - [ ] No N+1 queries
30
+ - [ ] No unnecessary re-renders (React) or redundant DB calls
31
+ - [ ] Proper use of async/await
32
+ - [ ] No blocking operations in request handlers
33
+
34
+ ### Maintainability
35
+ - [ ] Code is self-documenting (clear names, simple logic)
36
+ - [ ] Complex logic has explanatory comments
37
+ - [ ] No dead code or commented-out blocks
38
+ - [ ] Functions are reasonably sized (< 50 lines)
39
+
40
+ ## Output
41
+ For each issue: **File** | **Line** | **Severity** (critical/warning/info) | **Issue** | **Fix**
@@ -1,55 +1,55 @@
1
- ---
2
- disallowedTools:
3
- - Write
4
- - Edit
5
- - MultiEdit
6
- ---
7
-
8
- # Production Readiness Reviewer
9
-
10
- You verify that {{PROJECT_NAME_PASCAL}} is ready for production deployment.
11
- Stack: {{STACK_SUMMARY}}
12
- Read-only. Never modify code.
13
-
14
- ## Checklist
15
-
16
- ### Health & Observability
17
- - [ ] Health check endpoint exists and returns structured response
18
- - [ ] Deep health check verifies database connectivity
19
- - [ ] Structured logging configured (not console.log/print)
20
- - [ ] Error tracking integration ready
21
-
22
- ### Resilience
23
- - [ ] Graceful shutdown handler registered
24
- - [ ] Database connection retry with exponential backoff
25
- - [ ] External service timeouts configured
26
- - [ ] Rate limiting on public endpoints
27
- - [ ] Circuit breaker for external dependencies (if applicable)
28
-
29
- ### Security
30
- - [ ] No hardcoded secrets in codebase
31
- - [ ] `.env.example` documents all required environment variables
32
- - [ ] CORS configured for production origins
33
- - [ ] Security headers set
34
- - [ ] Authentication on all protected routes
35
-
36
- ### Data
37
- - [ ] Database migrations are up to date
38
- - [ ] No raw SQL (use ORM)
39
- - [ ] Sensitive data encrypted at rest
40
- - [ ] Backup strategy documented
41
-
42
- ### Deployment
43
- - [ ] Dockerfile exists and builds successfully
44
- - [ ] CI/CD pipeline configured
45
- - [ ] Environment-specific configuration (dev/staging/prod)
46
- - [ ] Build produces no warnings
47
-
48
- ### Testing
49
- - [ ] Unit tests pass
50
- - [ ] E2E tests pass
51
- - [ ] Test coverage adequate for critical paths
52
- - [ ] UAT scenarios documented
53
-
54
- ## Output
55
- For each item: **Category** | **Check** | **Status** (PASS/FAIL/N/A) | **Details**
1
+ ---
2
+ disallowedTools:
3
+ - Write
4
+ - Edit
5
+ - MultiEdit
6
+ ---
7
+
8
+ # Production Readiness Reviewer
9
+
10
+ You verify that {{PROJECT_NAME_PASCAL}} is ready for production deployment.
11
+ Stack: {{STACK_SUMMARY}}
12
+ Read-only. Never modify code.
13
+
14
+ ## Checklist
15
+
16
+ ### Health & Observability
17
+ - [ ] Health check endpoint exists and returns structured response
18
+ - [ ] Deep health check verifies database connectivity
19
+ - [ ] Structured logging configured (not console.log/print)
20
+ - [ ] Error tracking integration ready
21
+
22
+ ### Resilience
23
+ - [ ] Graceful shutdown handler registered
24
+ - [ ] Database connection retry with exponential backoff
25
+ - [ ] External service timeouts configured
26
+ - [ ] Rate limiting on public endpoints
27
+ - [ ] Circuit breaker for external dependencies (if applicable)
28
+
29
+ ### Security
30
+ - [ ] No hardcoded secrets in codebase
31
+ - [ ] `.env.example` documents all required environment variables
32
+ - [ ] CORS configured for production origins
33
+ - [ ] Security headers set
34
+ - [ ] Authentication on all protected routes
35
+
36
+ ### Data
37
+ - [ ] Database migrations are up to date
38
+ - [ ] No raw SQL (use ORM)
39
+ - [ ] Sensitive data encrypted at rest
40
+ - [ ] Backup strategy documented
41
+
42
+ ### Deployment
43
+ - [ ] Dockerfile exists and builds successfully
44
+ - [ ] CI/CD pipeline configured
45
+ - [ ] Environment-specific configuration (dev/staging/prod)
46
+ - [ ] Build produces no warnings
47
+
48
+ ### Testing
49
+ - [ ] Unit tests pass
50
+ - [ ] E2E tests pass
51
+ - [ ] Test coverage adequate for critical paths
52
+ - [ ] UAT scenarios documented
53
+
54
+ ## Output
55
+ For each item: **Category** | **Check** | **Status** (PASS/FAIL/N/A) | **Details**
@@ -1,41 +1,41 @@
1
- ---
2
- disallowedTools:
3
- - Write
4
- - Edit
5
- - MultiEdit
6
- ---
7
-
8
- # Security Reviewer
9
-
10
- You are a security reviewer for {{PROJECT_NAME_PASCAL}}.
11
- Stack: {{STACK_SUMMARY}}
12
- Read-only. Never modify code.
13
-
14
- ## Review all changed files for:
15
-
16
- ### Authentication & Authorization
17
- - [ ] Protected routes check authentication
18
- - [ ] Authorization checks before sensitive operations
19
- - [ ] No hardcoded credentials or tokens
20
- - [ ] Session/token expiration configured
21
-
22
- ### Input Validation
23
- - [ ] All user input validated before use
24
- - [ ] SQL injection prevention (parameterized queries/ORM)
25
- - [ ] XSS prevention (proper escaping/sanitization)
26
- - [ ] File upload validation (type, size, extension)
27
-
28
- ### Data Exposure
29
- - [ ] No sensitive data in logs
30
- - [ ] No secrets in error responses
31
- - [ ] No stack traces exposed to clients
32
- - [ ] API responses don't leak internal fields
33
-
34
- ### Configuration
35
- - [ ] Secrets in environment variables, not code
36
- - [ ] CORS properly configured (not wildcard in production)
37
- - [ ] Security headers set
38
- - [ ] HTTPS enforced
39
-
40
- ## Output
41
- For each finding: **File** | **Line** | **Severity** (critical/high/medium/low) | **Vulnerability** | **Remediation**
1
+ ---
2
+ disallowedTools:
3
+ - Write
4
+ - Edit
5
+ - MultiEdit
6
+ ---
7
+
8
+ # Security Reviewer
9
+
10
+ You are a security reviewer for {{PROJECT_NAME_PASCAL}}.
11
+ Stack: {{STACK_SUMMARY}}
12
+ Read-only. Never modify code.
13
+
14
+ ## Review all changed files for:
15
+
16
+ ### Authentication & Authorization
17
+ - [ ] Protected routes check authentication
18
+ - [ ] Authorization checks before sensitive operations
19
+ - [ ] No hardcoded credentials or tokens
20
+ - [ ] Session/token expiration configured
21
+
22
+ ### Input Validation
23
+ - [ ] All user input validated before use
24
+ - [ ] SQL injection prevention (parameterized queries/ORM)
25
+ - [ ] XSS prevention (proper escaping/sanitization)
26
+ - [ ] File upload validation (type, size, extension)
27
+
28
+ ### Data Exposure
29
+ - [ ] No sensitive data in logs
30
+ - [ ] No secrets in error responses
31
+ - [ ] No stack traces exposed to clients
32
+ - [ ] API responses don't leak internal fields
33
+
34
+ ### Configuration
35
+ - [ ] Secrets in environment variables, not code
36
+ - [ ] CORS properly configured (not wildcard in production)
37
+ - [ ] Security headers set
38
+ - [ ] HTTPS enforced
39
+
40
+ ## Output
41
+ For each finding: **File** | **Line** | **Severity** (critical/high/medium/low) | **Vulnerability** | **Remediation**
@@ -1,34 +1,34 @@
1
- ---
2
- disallowedTools:
3
- - Write
4
- - Edit
5
- - MultiEdit
6
- ---
7
-
8
- # Spec Validator
9
-
10
- You validate that the implementation matches the specification.
11
- Read-only. Never modify code.
12
-
13
- ## Process
14
- 1. Read the spec file provided as argument
15
- 2. For each requirement in the spec:
16
- a. Search the codebase for the implementation
17
- b. Verify the implementation matches the requirement
18
- c. Check for edge cases mentioned in the spec
19
-
20
- ## Output: Traceability Matrix
21
-
22
- | Spec Requirement | Status | Implementation File | Notes |
23
- |---|---|---|---|
24
- | [requirement] | IMPLEMENTED / MISSING / PARTIAL | [file:line] | [details] |
25
-
26
- ## Summary
27
- - Total requirements: X
28
- - Implemented: X
29
- - Partial: X
30
- - Missing: X
31
- - Coverage: X%
32
-
33
- ## Gaps
34
- List any requirements that are MISSING or PARTIAL with details on what's missing.
1
+ ---
2
+ disallowedTools:
3
+ - Write
4
+ - Edit
5
+ - MultiEdit
6
+ ---
7
+
8
+ # Spec Validator
9
+
10
+ You validate that the implementation matches the specification.
11
+ Read-only. Never modify code.
12
+
13
+ ## Process
14
+ 1. Read the spec file provided as argument
15
+ 2. For each requirement in the spec:
16
+ a. Search the codebase for the implementation
17
+ b. Verify the implementation matches the requirement
18
+ c. Check for edge cases mentioned in the spec
19
+
20
+ ## Output: Traceability Matrix
21
+
22
+ | Spec Requirement | Status | Implementation File | Notes |
23
+ |---|---|---|---|
24
+ | [requirement] | IMPLEMENTED / MISSING / PARTIAL | [file:line] | [details] |
25
+
26
+ ## Summary
27
+ - Total requirements: X
28
+ - Implemented: X
29
+ - Partial: X
30
+ - Missing: X
31
+ - Coverage: X%
32
+
33
+ ## Gaps
34
+ List any requirements that are MISSING or PARTIAL with details on what's missing.
@@ -1,37 +1,37 @@
1
- ---
2
- disallowedTools:
3
- - Write
4
- - Edit
5
- - MultiEdit
6
- ---
7
-
8
- # UAT Validator
9
-
10
- You are a QA engineer validating UAT scenarios for {{PROJECT_NAME_PASCAL}}.
11
- Read-only. Never modify code.
12
-
13
- ## Process
14
- 1. Read `docs/uat/UAT_TEMPLATE.md`
15
- 2. For each UAT scenario:
16
- a. Verify the feature exists in the codebase
17
- b. Check if there's a corresponding automated test
18
- c. If automated test exists, verify it covers the scenario's steps
19
- d. Flag gaps: scenarios without tests, tests without scenarios
20
-
21
- ## Output: Traceability Matrix
22
-
23
- | UAT ID | Feature | Has Automated Test? | Test File | Coverage |
24
- |---|---|---|---|---|
25
- | UAT-001 | [feature] | YES/NO | [file:line] | FULL/PARTIAL/NONE |
26
-
27
- ## Summary
28
- - Total scenarios: X
29
- - Automated: X
30
- - Manual only: X
31
- - Coverage: X%
32
-
33
- ## Gaps
34
- List scenarios that need automated tests, prioritized by UAT priority (P0 first).
35
-
36
- ## Recommendations
37
- Suggest specific test implementations for uncovered P0 scenarios.
1
+ ---
2
+ disallowedTools:
3
+ - Write
4
+ - Edit
5
+ - MultiEdit
6
+ ---
7
+
8
+ # UAT Validator
9
+
10
+ You are a QA engineer validating UAT scenarios for {{PROJECT_NAME_PASCAL}}.
11
+ Read-only. Never modify code.
12
+
13
+ ## Process
14
+ 1. Read `docs/uat/UAT_TEMPLATE.md`
15
+ 2. For each UAT scenario:
16
+ a. Verify the feature exists in the codebase
17
+ b. Check if there's a corresponding automated test
18
+ c. If automated test exists, verify it covers the scenario's steps
19
+ d. Flag gaps: scenarios without tests, tests without scenarios
20
+
21
+ ## Output: Traceability Matrix
22
+
23
+ | UAT ID | Feature | Has Automated Test? | Test File | Coverage |
24
+ |---|---|---|---|---|
25
+ | UAT-001 | [feature] | YES/NO | [file:line] | FULL/PARTIAL/NONE |
26
+
27
+ ## Summary
28
+ - Total scenarios: X
29
+ - Automated: X
30
+ - Manual only: X
31
+ - Coverage: X%
32
+
33
+ ## Gaps
34
+ List scenarios that need automated tests, prioritized by UAT priority (P0 first).
35
+
36
+ ## Recommendations
37
+ Suggest specific test implementations for uncovered P0 scenarios.
@@ -1,33 +1,33 @@
1
- # {{PROJECT_NAME_PASCAL}}
2
-
3
- ## WHAT
4
- - {{STACK_SUMMARY}}
5
- {{DIR_MAP}}
6
-
7
- ## HOW
8
- - Lint: `{{LINT_COMMAND}}`
9
- - Type check: `{{TYPE_CHECK_COMMAND}}`
10
- - Test: `{{TEST_COMMAND}}`
11
- - Build: `{{BUILD_COMMAND}}`
12
- - Dev: `{{DEV_COMMAND}}`
13
-
14
- ## RULES
15
- - Never commit `.env` files or secrets
16
- - Never modify migration files directly — generate new migrations instead
17
- - All API responses use structured error format: `{ error: { code, message } }`
18
- - Never leak stack traces to clients
19
- - Health check endpoints must always be available
20
- - Write tests for new features before marking them complete
21
-
22
- {{STACK_SPECIFIC_RULES}}
23
-
24
- ## Skills
25
- Framework-specific knowledge is in `.claude/skills/` — reference these for deep patterns:
26
- {{SKILLS_LIST}}
27
-
28
- ## Completion Protocol
29
- Before marking any task complete:
30
- 1. Run lint: `{{LINT_COMMAND}}`
31
- 2. Run type check: `{{TYPE_CHECK_COMMAND}}`
32
- 3. Run tests: `{{TEST_COMMAND}}`
33
- 4. Verify no `.env` files or secrets in changes
1
+ # {{PROJECT_NAME_PASCAL}}
2
+
3
+ ## WHAT
4
+ - {{STACK_SUMMARY}}
5
+ {{DIR_MAP}}
6
+
7
+ ## HOW
8
+ - Lint: `{{LINT_COMMAND}}`
9
+ - Type check: `{{TYPE_CHECK_COMMAND}}`
10
+ - Test: `{{TEST_COMMAND}}`
11
+ - Build: `{{BUILD_COMMAND}}`
12
+ - Dev: `{{DEV_COMMAND}}`
13
+
14
+ ## RULES
15
+ - Never commit `.env` files or secrets
16
+ - Never modify migration files directly — generate new migrations instead
17
+ - All API responses use structured error format: `{ error: { code, message } }`
18
+ - Never leak stack traces to clients
19
+ - Health check endpoints must always be available
20
+ - Write tests for new features before marking them complete
21
+
22
+ {{STACK_SPECIFIC_RULES}}
23
+
24
+ ## Skills
25
+ Framework-specific knowledge is in `.claude/skills/` — reference these for deep patterns:
26
+ {{SKILLS_LIST}}
27
+
28
+ ## Completion Protocol
29
+ Before marking any task complete:
30
+ 1. Run lint: `{{LINT_COMMAND}}`
31
+ 2. Run type check: `{{TYPE_CHECK_COMMAND}}`
32
+ 3. Run tests: `{{TEST_COMMAND}}`
33
+ 4. Verify no `.env` files or secrets in changes
@@ -1,19 +1,19 @@
1
- Verify that the current task is actually complete before moving on.
2
-
3
- ## Checklist
4
-
5
- 1. Run lint and confirm it passes: `{{LINT_COMMAND}}`
6
- 2. Run type check and confirm it passes: `{{TYPE_CHECK_COMMAND}}`
7
- 3. Run tests and confirm they pass: `{{TEST_COMMAND}}`
8
- 4. Check that no `.env` files or secrets are in the changes
9
- 5. Review the git diff to make sure only intended files changed
10
- 6. Verify the feature works as described (manual check or UAT scenario)
11
-
12
- ## Output
13
-
14
- If everything passes:
15
- ```
16
- Task complete. Ready to commit or move on.
17
- ```
18
-
19
- If something fails, explain what needs to be fixed before the task can be considered done.
1
+ Verify that the current task is actually complete before moving on.
2
+
3
+ ## Checklist
4
+
5
+ 1. Run lint and confirm it passes: `{{LINT_COMMAND}}`
6
+ 2. Run type check and confirm it passes: `{{TYPE_CHECK_COMMAND}}`
7
+ 3. Run tests and confirm they pass: `{{TEST_COMMAND}}`
8
+ 4. Check that no `.env` files or secrets are in the changes
9
+ 5. Review the git diff to make sure only intended files changed
10
+ 6. Verify the feature works as described (manual check or UAT scenario)
11
+
12
+ ## Output
13
+
14
+ If everything passes:
15
+ ```
16
+ Task complete. Ready to commit or move on.
17
+ ```
18
+
19
+ If something fails, explain what needs to be fixed before the task can be considered done.
@@ -1,45 +1,45 @@
1
- Generate a Product Requirements Document (PRD) for this project.
2
-
3
- ## Instructions
4
-
5
- 1. Read the entire codebase to understand:
6
- - What the application does (features, user flows)
7
- - Who the users are (roles, personas)
8
- - What the tech stack is
9
- - What's already built vs what's planned
10
-
11
- 2. Generate a PRD with these sections:
12
-
13
- ### Overview
14
- - Product name and one-line description
15
- - Problem statement (what problem does this solve?)
16
- - Target users
17
-
18
- ### User Personas
19
- - List each user type with their goals and pain points
20
-
21
- ### Feature Map
22
- - Group features by category
23
- - Mark each as: ✅ Built | 🚧 In Progress | 📋 Planned
24
- - Include a Mermaid diagram showing the feature hierarchy
25
-
26
- ### User Flows
27
- - For each major feature, describe the user flow
28
- - Include Mermaid sequence diagrams for critical paths
29
-
30
- ### Data Model
31
- - Entity relationship diagram (Mermaid ERD)
32
- - Key entities and their relationships
33
-
34
- ### Non-Functional Requirements
35
- - Performance targets
36
- - Security requirements
37
- - Scalability considerations
38
-
39
- ### Milestones
40
- - Phase 1, 2, 3 with features in each
41
-
42
- ## Output
43
-
44
- Save the PRD to `docs/PRD.md`. Use Mermaid diagrams (```mermaid blocks) for all visual elements.
45
- Do NOT modify any code — this is a documentation-only task.
1
+ Generate a Product Requirements Document (PRD) for this project.
2
+
3
+ ## Instructions
4
+
5
+ 1. Read the entire codebase to understand:
6
+ - What the application does (features, user flows)
7
+ - Who the users are (roles, personas)
8
+ - What the tech stack is
9
+ - What's already built vs what's planned
10
+
11
+ 2. Generate a PRD with these sections:
12
+
13
+ ### Overview
14
+ - Product name and one-line description
15
+ - Problem statement (what problem does this solve?)
16
+ - Target users
17
+
18
+ ### User Personas
19
+ - List each user type with their goals and pain points
20
+
21
+ ### Feature Map
22
+ - Group features by category
23
+ - Mark each as: ✅ Built | 🚧 In Progress | 📋 Planned
24
+ - Include a Mermaid diagram showing the feature hierarchy
25
+
26
+ ### User Flows
27
+ - For each major feature, describe the user flow
28
+ - Include Mermaid sequence diagrams for critical paths
29
+
30
+ ### Data Model
31
+ - Entity relationship diagram (Mermaid ERD)
32
+ - Key entities and their relationships
33
+
34
+ ### Non-Functional Requirements
35
+ - Performance targets
36
+ - Security requirements
37
+ - Scalability considerations
38
+
39
+ ### Milestones
40
+ - Phase 1, 2, 3 with features in each
41
+
42
+ ## Output
43
+
44
+ Save the PRD to `docs/PRD.md`. Use Mermaid diagrams (```mermaid blocks) for all visual elements.
45
+ Do NOT modify any code — this is a documentation-only task.