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.
- package/CLAUDE.md +3 -3
- package/README.md +246 -246
- package/bin/devforge.js +4 -4
- package/package.json +33 -33
- package/src/claude-configurator.js +260 -260
- package/src/cli.js +119 -119
- package/src/composer.js +214 -214
- package/src/doctor-checks.js +743 -743
- package/src/doctor-prompts.js +295 -295
- package/src/doctor.js +281 -281
- package/src/guided.js +315 -315
- package/src/index.js +148 -148
- package/src/init-mode.js +138 -134
- package/src/prompts.js +155 -155
- package/src/scanner.js +368 -368
- package/templates/claude-code/agents/code-quality-reviewer.md +41 -41
- package/templates/claude-code/agents/production-readiness.md +55 -55
- package/templates/claude-code/agents/security-reviewer.md +41 -41
- package/templates/claude-code/agents/spec-validator.md +34 -34
- package/templates/claude-code/agents/uat-validator.md +37 -37
- package/templates/claude-code/claude-md/base.md +33 -33
- package/templates/claude-code/commands/done.md +19 -19
- package/templates/claude-code/commands/generate-prd.md +45 -45
- package/templates/claude-code/commands/generate-uat.md +35 -35
- package/templates/claude-code/commands/next.md +20 -20
- package/templates/claude-code/commands/optimize-claude-md.md +31 -31
- package/templates/claude-code/commands/status.md +24 -24
- package/templates/claude-code/commands/workflows.md +26 -0
- package/templates/claude-code/hooks/polyglot.json +36 -36
- package/templates/claude-code/hooks/python.json +36 -36
- package/templates/claude-code/hooks/scripts/autofix-polyglot.sh +16 -16
- package/templates/claude-code/hooks/scripts/autofix-python.sh +14 -14
- package/templates/claude-code/hooks/scripts/autofix-typescript.sh +14 -14
- package/templates/claude-code/hooks/scripts/guard-protected-files.sh +21 -21
- package/templates/claude-code/hooks/typescript.json +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.
|