vibe-fabric 0.3.1 → 0.3.3
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/prompts/analyze/assess.md +208 -0
- package/.claude/prompts/analyze/synthesize.md +239 -0
- package/.claude/prompts/analyze/task-analyze-repo.md +260 -0
- package/.claude/prompts/gaps/assess.md +203 -0
- package/.claude/prompts/gaps/synthesize.md +180 -0
- package/.claude/prompts/gaps/task-analyze-module.md +198 -0
- package/.claude/prompts/prd/assess.md +156 -0
- package/.claude/prompts/prd/synthesize.md +191 -0
- package/.claude/prompts/prd/task-capture-feature.md +133 -0
- package/.claude/prompts/prd/task-deprecate.md +84 -0
- package/.claude/prompts/prd/task-document-code.md +110 -0
- package/.claude/prompts/prd/task-fix-format.md +102 -0
- package/.claude/prompts/prd/task-update-status.md +89 -0
- package/.claude/prompts/scope/assess.md +201 -0
- package/.claude/prompts/scope/synthesize.md +270 -0
- package/.claude/prompts/scope/task-analyze-prd.md +125 -0
- package/.claude/prompts/scope/task-check-deps.md +188 -0
- package/.claude/prompts/scope/task-create-scope.md +207 -0
- package/.claude/prompts/scope/task-recommend.md +146 -0
- package/.claude/prompts/scope/task-review-scope.md +191 -0
- package/.claude/prompts/scope/task-validate.md +203 -0
- package/dist/core/planning.d.ts.map +1 -1
- package/dist/core/planning.js +10 -4
- package/dist/core/planning.js.map +1 -1
- package/dist/core/project.d.ts.map +1 -1
- package/dist/core/project.js +49 -1
- package/dist/core/project.js.map +1 -1
- package/package.json +2 -1
|
@@ -0,0 +1,156 @@
|
|
|
1
|
+
# PRD Assessment
|
|
2
|
+
|
|
3
|
+
## Variables
|
|
4
|
+
|
|
5
|
+
| Variable | Description | Required |
|
|
6
|
+
|----------|-------------|----------|
|
|
7
|
+
| {PROJECT_PATH} | Path to the project directory | Yes |
|
|
8
|
+
| {OUTPUT_FILE} | Path to write the assessment output | Yes |
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
## Context
|
|
13
|
+
|
|
14
|
+
You are helping manage a Product Requirements Document (PRD) for a software project.
|
|
15
|
+
|
|
16
|
+
Project: {PROJECT_PATH}
|
|
17
|
+
|
|
18
|
+
---
|
|
19
|
+
|
|
20
|
+
## Your Task
|
|
21
|
+
|
|
22
|
+
Analyze the current PRD state and help the user with PRD management.
|
|
23
|
+
|
|
24
|
+
### Step 1: Analyze Current State
|
|
25
|
+
|
|
26
|
+
Read and analyze:
|
|
27
|
+
- `docs/prd/` - Current PRD structure and content
|
|
28
|
+
- `docs/scopes/completed/` - Completed work (to identify status updates needed)
|
|
29
|
+
- `docs/sync-cache/` - Implementation data (if available)
|
|
30
|
+
|
|
31
|
+
Identify:
|
|
32
|
+
- **Format issues**: Missing fields, invalid IDs, inconsistent structure
|
|
33
|
+
- **Status mismatches**: Requirements that should be marked 'implemented' based on completed scopes
|
|
34
|
+
- **Coverage gaps**: Areas that may need documentation
|
|
35
|
+
- **Overall health**: Module count, requirement count, coverage percentage
|
|
36
|
+
|
|
37
|
+
### Step 2: Present Findings
|
|
38
|
+
|
|
39
|
+
Summarize your findings clearly:
|
|
40
|
+
- How many modules and requirements exist
|
|
41
|
+
- Coverage percentage (implemented vs total)
|
|
42
|
+
- Number and types of issues found
|
|
43
|
+
- Status updates needed
|
|
44
|
+
|
|
45
|
+
### Step 3: Ask User Intent
|
|
46
|
+
|
|
47
|
+
Ask the user: **"What brings you here today?"**
|
|
48
|
+
|
|
49
|
+
Listen for signals like:
|
|
50
|
+
- "add a feature" → task-capture-feature
|
|
51
|
+
- "fix issues" → task-fix-format
|
|
52
|
+
- "update statuses" → task-update-status
|
|
53
|
+
- "just checking" → no tasks, show summary only
|
|
54
|
+
|
|
55
|
+
### Step 4: Create Task List
|
|
56
|
+
|
|
57
|
+
Based on findings and user intent, create a list of tasks:
|
|
58
|
+
|
|
59
|
+
**Task Types:**
|
|
60
|
+
- `task-fix-format` - Fix format issues (non-interactive)
|
|
61
|
+
- `task-update-status` - Update statuses from scopes (non-interactive)
|
|
62
|
+
- `task-capture-feature` - Capture new feature requirements (interactive)
|
|
63
|
+
- `task-document-code` - Document undocumented code (non-interactive)
|
|
64
|
+
- `task-deprecate` - Mark deprecated features (non-interactive)
|
|
65
|
+
|
|
66
|
+
---
|
|
67
|
+
|
|
68
|
+
## Output Format
|
|
69
|
+
|
|
70
|
+
Write to: {OUTPUT_FILE}
|
|
71
|
+
|
|
72
|
+
```json
|
|
73
|
+
{
|
|
74
|
+
"complexity": "S|M|L",
|
|
75
|
+
"assessment": {
|
|
76
|
+
"prd_exists": true,
|
|
77
|
+
"module_count": 5,
|
|
78
|
+
"requirement_count": 23,
|
|
79
|
+
"coverage_percentage": 68,
|
|
80
|
+
"format_issues": 2,
|
|
81
|
+
"status_updates_needed": 5,
|
|
82
|
+
"user_intent": "add payments feature"
|
|
83
|
+
},
|
|
84
|
+
"tasks": [
|
|
85
|
+
{
|
|
86
|
+
"id": 1,
|
|
87
|
+
"name": "fix-format",
|
|
88
|
+
"description": "Fix 2 format issues in PRD files",
|
|
89
|
+
"prompt": "task-fix-format",
|
|
90
|
+
"interactive": false,
|
|
91
|
+
"context": {
|
|
92
|
+
"issues": ["REQ-AUTH-001: missing priority", "REQ-USER-003: invalid AC format"]
|
|
93
|
+
}
|
|
94
|
+
},
|
|
95
|
+
{
|
|
96
|
+
"id": 2,
|
|
97
|
+
"name": "update-status",
|
|
98
|
+
"description": "Update 5 requirement statuses from completed scopes",
|
|
99
|
+
"prompt": "task-update-status",
|
|
100
|
+
"interactive": false,
|
|
101
|
+
"context": {
|
|
102
|
+
"updates": [
|
|
103
|
+
{"req": "REQ-AUTH-001", "scope": "SCOPE-001", "status": "implemented"}
|
|
104
|
+
]
|
|
105
|
+
}
|
|
106
|
+
},
|
|
107
|
+
{
|
|
108
|
+
"id": 3,
|
|
109
|
+
"name": "capture-payments",
|
|
110
|
+
"description": "Capture requirements for payments feature",
|
|
111
|
+
"prompt": "task-capture-feature",
|
|
112
|
+
"interactive": true,
|
|
113
|
+
"context": {
|
|
114
|
+
"feature": "payments",
|
|
115
|
+
"hints": ["payment processing", "subscriptions", "billing"]
|
|
116
|
+
}
|
|
117
|
+
}
|
|
118
|
+
]
|
|
119
|
+
}
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
---
|
|
123
|
+
|
|
124
|
+
## Rules
|
|
125
|
+
|
|
126
|
+
- Focus ONLY on PRD management
|
|
127
|
+
- Maximum 10 tasks (group related work if needed)
|
|
128
|
+
- Always fix format issues first
|
|
129
|
+
- Always update statuses from completed scopes
|
|
130
|
+
- Only add capture tasks if user requests new features
|
|
131
|
+
- Be concise in your analysis - don't overwhelm the user
|
|
132
|
+
- If no issues and no user requests, output empty tasks array
|
|
133
|
+
|
|
134
|
+
---
|
|
135
|
+
|
|
136
|
+
## Examples
|
|
137
|
+
|
|
138
|
+
**User says "just checking":**
|
|
139
|
+
```json
|
|
140
|
+
{
|
|
141
|
+
"complexity": "S",
|
|
142
|
+
"assessment": {...},
|
|
143
|
+
"tasks": []
|
|
144
|
+
}
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
**User says "add authentication feature":**
|
|
148
|
+
```json
|
|
149
|
+
{
|
|
150
|
+
"complexity": "M",
|
|
151
|
+
"assessment": {...},
|
|
152
|
+
"tasks": [
|
|
153
|
+
{"id": 1, "name": "capture-auth", "prompt": "task-capture-feature", "interactive": true, ...}
|
|
154
|
+
]
|
|
155
|
+
}
|
|
156
|
+
```
|
|
@@ -0,0 +1,191 @@
|
|
|
1
|
+
# PRD Synthesis and Approval
|
|
2
|
+
|
|
3
|
+
## Variables
|
|
4
|
+
|
|
5
|
+
| Variable | Description | Required |
|
|
6
|
+
|----------|-------------|----------|
|
|
7
|
+
| {PROJECT_PATH} | Path to the project directory | Yes |
|
|
8
|
+
| {TASK_OUTPUTS} | JSON array of task output file paths | Yes |
|
|
9
|
+
| {TOTAL_TASKS} | Number of tasks completed | Yes |
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## Context
|
|
14
|
+
|
|
15
|
+
You are reviewing all changes from the PRD operation and getting user approval.
|
|
16
|
+
|
|
17
|
+
Project: {PROJECT_PATH}
|
|
18
|
+
Task outputs: {TASK_OUTPUTS}
|
|
19
|
+
Total tasks: {TOTAL_TASKS}
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Your Task
|
|
24
|
+
|
|
25
|
+
Present all changes for user approval and apply approved changes.
|
|
26
|
+
|
|
27
|
+
### Step 1: Load All Task Outputs
|
|
28
|
+
|
|
29
|
+
Read each file in {TASK_OUTPUTS} and combine the results.
|
|
30
|
+
|
|
31
|
+
### Step 2: Present Summary
|
|
32
|
+
|
|
33
|
+
Group changes by category and present clearly:
|
|
34
|
+
|
|
35
|
+
```
|
|
36
|
+
╔════════════════════════════════════════════════════════════════════╗
|
|
37
|
+
║ CHANGES TO APPLY ║
|
|
38
|
+
╠════════════════════════════════════════════════════════════════════╣
|
|
39
|
+
║ ║
|
|
40
|
+
║ ✓ FORMAT FIXES (2) ║
|
|
41
|
+
║ • REQ-AUTH-001: Added priority P1 ║
|
|
42
|
+
║ • REQ-USER-003: Fixed AC format ║
|
|
43
|
+
║ ║
|
|
44
|
+
║ ✓ STATUS UPDATES (5) ║
|
|
45
|
+
║ • REQ-AUTH-001: draft → implemented ║
|
|
46
|
+
║ • REQ-AUTH-002: draft → implemented ║
|
|
47
|
+
║ • REQ-USER-001: draft → implemented ║
|
|
48
|
+
║ ... ║
|
|
49
|
+
║ ║
|
|
50
|
+
║ ✓ NEW MODULE: payments ║
|
|
51
|
+
║ • 4 user needs ║
|
|
52
|
+
║ • 6 business rules ║
|
|
53
|
+
║ • 12 acceptance criteria ║
|
|
54
|
+
║ ║
|
|
55
|
+
║ ⚠ DRAFTED (needs review): 3 requirements ║
|
|
56
|
+
║ • PaymentService → REQ-PAY-010 ║
|
|
57
|
+
║ ... ║
|
|
58
|
+
║ ║
|
|
59
|
+
╚════════════════════════════════════════════════════════════════════╝
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
### Step 3: Get User Decision
|
|
63
|
+
|
|
64
|
+
Ask user:
|
|
65
|
+
- **"Accept all"** - Apply all changes
|
|
66
|
+
- **"Accept partial"** - Let user specify what to include/exclude
|
|
67
|
+
- **"Reject"** - Discard all changes
|
|
68
|
+
- **"Show details"** - Show full content of specific change
|
|
69
|
+
|
|
70
|
+
### Step 4: Apply Approved Changes
|
|
71
|
+
|
|
72
|
+
For approved changes:
|
|
73
|
+
1. Write modified files
|
|
74
|
+
2. Create new module directories if needed
|
|
75
|
+
3. Create new requirement files if needed
|
|
76
|
+
4. Update module `_index.md` files
|
|
77
|
+
|
|
78
|
+
### Step 5: Generate Summary
|
|
79
|
+
|
|
80
|
+
After applying changes:
|
|
81
|
+
- List all files modified
|
|
82
|
+
- List all files created
|
|
83
|
+
- Show updated coverage percentage
|
|
84
|
+
|
|
85
|
+
---
|
|
86
|
+
|
|
87
|
+
## Output Format
|
|
88
|
+
|
|
89
|
+
No file output needed - changes are applied directly to PRD files.
|
|
90
|
+
|
|
91
|
+
Display to user:
|
|
92
|
+
```
|
|
93
|
+
Applied changes:
|
|
94
|
+
✓ Modified 7 files
|
|
95
|
+
✓ Created 4 files
|
|
96
|
+
✓ Coverage: 68% → 75%
|
|
97
|
+
|
|
98
|
+
Files modified:
|
|
99
|
+
• docs/prd/modules/auth/login.md
|
|
100
|
+
• docs/prd/modules/auth/registration.md
|
|
101
|
+
• ...
|
|
102
|
+
|
|
103
|
+
Files created:
|
|
104
|
+
• docs/prd/modules/payments/_index.md
|
|
105
|
+
• docs/prd/modules/payments/processing.md
|
|
106
|
+
• ...
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
---
|
|
110
|
+
|
|
111
|
+
## Rules
|
|
112
|
+
|
|
113
|
+
- NEVER apply changes without user approval
|
|
114
|
+
- If user says "reject", discard ALL changes
|
|
115
|
+
- If user says "accept partial", only apply specified items
|
|
116
|
+
- Drafted requirements (status: inferred) need explicit approval
|
|
117
|
+
- Create proper directory structure for new modules
|
|
118
|
+
- Update `_index.md` files when adding new requirements
|
|
119
|
+
- Preserve existing formatting in modified files
|
|
120
|
+
- Use consistent ID numbering (REQ-XXX-NNN)
|
|
121
|
+
|
|
122
|
+
---
|
|
123
|
+
|
|
124
|
+
## Module Structure
|
|
125
|
+
|
|
126
|
+
When creating new modules:
|
|
127
|
+
|
|
128
|
+
```
|
|
129
|
+
docs/prd/modules/{module-name}/
|
|
130
|
+
├── _index.md # Module overview
|
|
131
|
+
└── {feature}.md # Individual requirements
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
**_index.md template:**
|
|
135
|
+
```markdown
|
|
136
|
+
# {Module Name}
|
|
137
|
+
|
|
138
|
+
## Overview
|
|
139
|
+
|
|
140
|
+
[Brief description]
|
|
141
|
+
|
|
142
|
+
## Requirements
|
|
143
|
+
|
|
144
|
+
| ID | Title | Status | Priority |
|
|
145
|
+
|----|-------|--------|----------|
|
|
146
|
+
| REQ-XXX-001 | Title | draft | P1 |
|
|
147
|
+
|
|
148
|
+
## Related
|
|
149
|
+
|
|
150
|
+
- [Requirement 1](./requirement.md)
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
**Requirement template:**
|
|
154
|
+
```markdown
|
|
155
|
+
# REQ: {Title}
|
|
156
|
+
|
|
157
|
+
## Metadata
|
|
158
|
+
|
|
159
|
+
| Field | Value |
|
|
160
|
+
|-------|-------|
|
|
161
|
+
| **ID** | `REQ-XXX-001` |
|
|
162
|
+
| **Module** | `module-name` |
|
|
163
|
+
| **Status** | `draft` |
|
|
164
|
+
| **Priority** | `P1` |
|
|
165
|
+
| **Last Updated** | YYYY-MM-DD |
|
|
166
|
+
| **Covered By** | - |
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
## Context
|
|
171
|
+
|
|
172
|
+
[Background]
|
|
173
|
+
|
|
174
|
+
---
|
|
175
|
+
|
|
176
|
+
## User Needs
|
|
177
|
+
|
|
178
|
+
- **UN-1:** [Description]
|
|
179
|
+
|
|
180
|
+
---
|
|
181
|
+
|
|
182
|
+
## Business Rules
|
|
183
|
+
|
|
184
|
+
- **BR-1:** [Description]
|
|
185
|
+
|
|
186
|
+
---
|
|
187
|
+
|
|
188
|
+
## Acceptance Criteria
|
|
189
|
+
|
|
190
|
+
- **AC-1:** Given [context], when [action], then [result]
|
|
191
|
+
```
|
|
@@ -0,0 +1,133 @@
|
|
|
1
|
+
# Capture Feature Requirements
|
|
2
|
+
|
|
3
|
+
## Variables
|
|
4
|
+
|
|
5
|
+
| Variable | Description | Required |
|
|
6
|
+
|----------|-------------|----------|
|
|
7
|
+
| {PROJECT_PATH} | Path to the project directory | Yes |
|
|
8
|
+
| {OUTPUT_FILE} | Path to write task output | Yes |
|
|
9
|
+
| {TASK_NAME} | Name of this task | Yes |
|
|
10
|
+
| {TASK_DESCRIPTION} | Description of feature to capture | Yes |
|
|
11
|
+
| {FEATURE} | Feature name | Yes |
|
|
12
|
+
| {HINTS} | Hints about what the feature might include | No |
|
|
13
|
+
| {PREVIOUS_OUTPUTS} | Paths to previous task outputs | Yes |
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Context
|
|
18
|
+
|
|
19
|
+
You are capturing requirements for a new feature through conversation.
|
|
20
|
+
|
|
21
|
+
Project: {PROJECT_PATH}
|
|
22
|
+
Task: {TASK_NAME}
|
|
23
|
+
Feature: {FEATURE}
|
|
24
|
+
Hints: {HINTS}
|
|
25
|
+
|
|
26
|
+
---
|
|
27
|
+
|
|
28
|
+
## Your Task
|
|
29
|
+
|
|
30
|
+
Have a focused conversation to capture detailed requirements for {FEATURE}.
|
|
31
|
+
|
|
32
|
+
### Conversation Flow
|
|
33
|
+
|
|
34
|
+
**1. Understanding the Problem**
|
|
35
|
+
- "What problem does {FEATURE} solve?"
|
|
36
|
+
- "Who will use this feature?"
|
|
37
|
+
- "What happens today without it?"
|
|
38
|
+
|
|
39
|
+
**2. User Needs (UN)**
|
|
40
|
+
- "What should users be able to do with {FEATURE}?"
|
|
41
|
+
- "What are the must-have capabilities?"
|
|
42
|
+
- "What would be nice-to-have?"
|
|
43
|
+
|
|
44
|
+
Capture as User Needs:
|
|
45
|
+
```
|
|
46
|
+
- UN-1: User needs to [action] so that [benefit]
|
|
47
|
+
- UN-2: User needs to [action] so that [benefit]
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
**3. Business Rules (BR)**
|
|
51
|
+
- "Are there any constraints or limits?"
|
|
52
|
+
- "What should NOT be allowed?"
|
|
53
|
+
- "Are there compliance requirements?"
|
|
54
|
+
|
|
55
|
+
Capture as Business Rules:
|
|
56
|
+
```
|
|
57
|
+
- BR-1: [Rule statement]
|
|
58
|
+
- BR-2: [Rule statement]
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
**4. Acceptance Criteria (AC)**
|
|
62
|
+
Derive from User Needs:
|
|
63
|
+
```
|
|
64
|
+
- AC-1: Given [context], when [action], then [result] (validates UN-1)
|
|
65
|
+
- AC-2: Given [context], when [action], then [result] (validates UN-1)
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
**5. Out of Scope**
|
|
69
|
+
- "What should this feature NOT include?"
|
|
70
|
+
- "What's for future versions?"
|
|
71
|
+
|
|
72
|
+
### Keep the Session Focused
|
|
73
|
+
|
|
74
|
+
- Stay on the {FEATURE} topic
|
|
75
|
+
- Don't expand scope to other features
|
|
76
|
+
- 10-15 minutes maximum
|
|
77
|
+
- Be concise in questions
|
|
78
|
+
- Confirm understanding before moving on
|
|
79
|
+
|
|
80
|
+
---
|
|
81
|
+
|
|
82
|
+
## Output Format
|
|
83
|
+
|
|
84
|
+
Write to: {OUTPUT_FILE}
|
|
85
|
+
|
|
86
|
+
```json
|
|
87
|
+
{
|
|
88
|
+
"task": "capture-feature",
|
|
89
|
+
"status": "complete",
|
|
90
|
+
"feature": "{FEATURE}",
|
|
91
|
+
"module_path": "docs/prd/modules/{feature}/",
|
|
92
|
+
"requirements": {
|
|
93
|
+
"user_needs": [
|
|
94
|
+
{
|
|
95
|
+
"id": "UN-1",
|
|
96
|
+
"description": "User needs to [action] so that [benefit]",
|
|
97
|
+
"priority": "P1"
|
|
98
|
+
}
|
|
99
|
+
],
|
|
100
|
+
"business_rules": [
|
|
101
|
+
{
|
|
102
|
+
"id": "BR-1",
|
|
103
|
+
"description": "[Rule statement]"
|
|
104
|
+
}
|
|
105
|
+
],
|
|
106
|
+
"acceptance_criteria": [
|
|
107
|
+
{
|
|
108
|
+
"id": "AC-1",
|
|
109
|
+
"user_need": "UN-1",
|
|
110
|
+
"given": "context",
|
|
111
|
+
"when": "action",
|
|
112
|
+
"then": "result"
|
|
113
|
+
}
|
|
114
|
+
],
|
|
115
|
+
"out_of_scope": [
|
|
116
|
+
"Item 1",
|
|
117
|
+
"Item 2"
|
|
118
|
+
]
|
|
119
|
+
},
|
|
120
|
+
"notes": "Additional context captured during conversation"
|
|
121
|
+
}
|
|
122
|
+
```
|
|
123
|
+
|
|
124
|
+
---
|
|
125
|
+
|
|
126
|
+
## Rules
|
|
127
|
+
|
|
128
|
+
- Focus ONLY on {FEATURE}
|
|
129
|
+
- Every User Need must have at least one Acceptance Criterion
|
|
130
|
+
- Use clear, testable language
|
|
131
|
+
- Don't invent requirements - capture what user tells you
|
|
132
|
+
- If user is unsure, note it and move on
|
|
133
|
+
- Keep it practical - avoid over-engineering requirements
|
|
@@ -0,0 +1,84 @@
|
|
|
1
|
+
# Deprecate Removed Features
|
|
2
|
+
|
|
3
|
+
## Variables
|
|
4
|
+
|
|
5
|
+
| Variable | Description | Required |
|
|
6
|
+
|----------|-------------|----------|
|
|
7
|
+
| {PROJECT_PATH} | Path to the project directory | Yes |
|
|
8
|
+
| {OUTPUT_FILE} | Path to write task output | Yes |
|
|
9
|
+
| {TASK_NAME} | Name of this task | Yes |
|
|
10
|
+
| {TASK_DESCRIPTION} | Description of what to deprecate | Yes |
|
|
11
|
+
| {DEPRECATED_ITEMS} | JSON array of requirements to deprecate | Yes |
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## Context
|
|
16
|
+
|
|
17
|
+
You are marking requirements as deprecated because the code has been removed.
|
|
18
|
+
|
|
19
|
+
Project: {PROJECT_PATH}
|
|
20
|
+
Task: {TASK_NAME}
|
|
21
|
+
|
|
22
|
+
Items to deprecate:
|
|
23
|
+
{DEPRECATED_ITEMS}
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## Your Task
|
|
28
|
+
|
|
29
|
+
Mark requirements as deprecated (don't delete them - maintain history).
|
|
30
|
+
|
|
31
|
+
### Step 1: Verify Removal
|
|
32
|
+
|
|
33
|
+
For each item, verify:
|
|
34
|
+
- The code is truly removed (not in current maps)
|
|
35
|
+
- The requirement exists in the PRD
|
|
36
|
+
|
|
37
|
+
### Step 2: Update Status
|
|
38
|
+
|
|
39
|
+
Change status to `deprecated` and add deprecation note:
|
|
40
|
+
|
|
41
|
+
```markdown
|
|
42
|
+
| **Status** | `deprecated` |
|
|
43
|
+
|
|
44
|
+
> **Deprecated:** Feature removed as of [date]. Code no longer exists in codebase.
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
### Step 3: Update Module Index
|
|
48
|
+
|
|
49
|
+
If all requirements in a module are deprecated, note in the module's `_index.md`.
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Output Format
|
|
54
|
+
|
|
55
|
+
Write to: {OUTPUT_FILE}
|
|
56
|
+
|
|
57
|
+
```json
|
|
58
|
+
{
|
|
59
|
+
"task": "deprecate",
|
|
60
|
+
"status": "complete",
|
|
61
|
+
"deprecated": [
|
|
62
|
+
{
|
|
63
|
+
"requirement": "REQ-LEGACY-001",
|
|
64
|
+
"file": "docs/prd/modules/legacy/old-feature.md",
|
|
65
|
+
"reason": "Feature removed - code no longer exists",
|
|
66
|
+
"old_status": "implemented",
|
|
67
|
+
"new_status": "deprecated"
|
|
68
|
+
}
|
|
69
|
+
],
|
|
70
|
+
"files_modified": [
|
|
71
|
+
"docs/prd/modules/legacy/old-feature.md"
|
|
72
|
+
]
|
|
73
|
+
}
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
---
|
|
77
|
+
|
|
78
|
+
## Rules
|
|
79
|
+
|
|
80
|
+
- NEVER delete requirements - only deprecate
|
|
81
|
+
- Always add deprecation note with reason
|
|
82
|
+
- Preserve all existing content
|
|
83
|
+
- If requirement still has code coverage, don't deprecate
|
|
84
|
+
- If unsure, skip and note in output
|
|
@@ -0,0 +1,110 @@
|
|
|
1
|
+
# Document Undocumented Code
|
|
2
|
+
|
|
3
|
+
## Variables
|
|
4
|
+
|
|
5
|
+
| Variable | Description | Required |
|
|
6
|
+
|----------|-------------|----------|
|
|
7
|
+
| {PROJECT_PATH} | Path to the project directory | Yes |
|
|
8
|
+
| {OUTPUT_FILE} | Path to write task output | Yes |
|
|
9
|
+
| {TASK_NAME} | Name of this task | Yes |
|
|
10
|
+
| {TASK_DESCRIPTION} | Description of what to document | Yes |
|
|
11
|
+
| {UNDOCUMENTED_ITEMS} | JSON array of code items without PRD coverage | Yes |
|
|
12
|
+
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
## Context
|
|
16
|
+
|
|
17
|
+
You are drafting requirements for code that exists but isn't documented in the PRD.
|
|
18
|
+
|
|
19
|
+
Project: {PROJECT_PATH}
|
|
20
|
+
Task: {TASK_NAME}
|
|
21
|
+
|
|
22
|
+
Undocumented items:
|
|
23
|
+
{UNDOCUMENTED_ITEMS}
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
## Your Task
|
|
28
|
+
|
|
29
|
+
Create draft requirements for undocumented code.
|
|
30
|
+
|
|
31
|
+
### Step 1: Analyze Code
|
|
32
|
+
|
|
33
|
+
For each undocumented item:
|
|
34
|
+
- Read the relevant map file (from `docs/sync-cache/`)
|
|
35
|
+
- Understand what the code does
|
|
36
|
+
- Identify the module it belongs to
|
|
37
|
+
|
|
38
|
+
### Step 2: Infer Requirements
|
|
39
|
+
|
|
40
|
+
Based on code analysis, infer likely:
|
|
41
|
+
- User Needs: What capability does this provide?
|
|
42
|
+
- Business Rules: What constraints are enforced?
|
|
43
|
+
- Acceptance Criteria: What behavior is expected?
|
|
44
|
+
|
|
45
|
+
### Step 3: Create Draft Documents
|
|
46
|
+
|
|
47
|
+
Mark all inferred requirements as:
|
|
48
|
+
- Status: `inferred`
|
|
49
|
+
- Note: "Inferred from existing code - please review"
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Output Format
|
|
54
|
+
|
|
55
|
+
Write to: {OUTPUT_FILE}
|
|
56
|
+
|
|
57
|
+
```json
|
|
58
|
+
{
|
|
59
|
+
"task": "document-code",
|
|
60
|
+
"status": "complete",
|
|
61
|
+
"drafted": [
|
|
62
|
+
{
|
|
63
|
+
"code_item": "PaymentService",
|
|
64
|
+
"source": "docs/sync-cache/backend/maps/services.json",
|
|
65
|
+
"module": "payments",
|
|
66
|
+
"drafted_requirement": {
|
|
67
|
+
"id": "REQ-PAY-010",
|
|
68
|
+
"status": "inferred",
|
|
69
|
+
"title": "Payment Processing",
|
|
70
|
+
"user_needs": [
|
|
71
|
+
{
|
|
72
|
+
"id": "UN-1",
|
|
73
|
+
"description": "User needs to process payments",
|
|
74
|
+
"priority": "P1"
|
|
75
|
+
}
|
|
76
|
+
],
|
|
77
|
+
"business_rules": [
|
|
78
|
+
{
|
|
79
|
+
"id": "BR-1",
|
|
80
|
+
"description": "Payments must be validated before processing"
|
|
81
|
+
}
|
|
82
|
+
],
|
|
83
|
+
"acceptance_criteria": [
|
|
84
|
+
{
|
|
85
|
+
"id": "AC-1",
|
|
86
|
+
"given": "valid payment details",
|
|
87
|
+
"when": "payment is submitted",
|
|
88
|
+
"then": "payment is processed successfully"
|
|
89
|
+
}
|
|
90
|
+
],
|
|
91
|
+
"note": "Inferred from existing code - please review"
|
|
92
|
+
}
|
|
93
|
+
}
|
|
94
|
+
],
|
|
95
|
+
"files_to_create": [
|
|
96
|
+
"docs/prd/modules/payments/processing.md"
|
|
97
|
+
]
|
|
98
|
+
}
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
---
|
|
102
|
+
|
|
103
|
+
## Rules
|
|
104
|
+
|
|
105
|
+
- Mark ALL drafted requirements as status: "inferred"
|
|
106
|
+
- Add note explaining these are inferred
|
|
107
|
+
- Don't assume features that aren't in the code
|
|
108
|
+
- Keep requirements minimal - better to understate than overstate
|
|
109
|
+
- User will review and approve before these are added
|
|
110
|
+
- If code purpose is unclear, note uncertainty in output
|