@ngocsangairvds/vsaf 3.1.0 → 3.1.1
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/skills/graphify/SKILL.md +1 -1
- package/.claude/skills/vsaf-build/SKILL.md +94 -64
- package/.claude/skills/vsaf-discover/SKILL.md +56 -56
- package/.claude/skills/vsaf-doc/SKILL.md +9 -9
- package/.claude/skills/vsaf-doc-prd/SKILL.md +32 -32
- package/.claude/skills/vsaf-doc-srs/SKILL.md +88 -88
- package/.claude/skills/vsaf-docs/SKILL.md +50 -50
- package/.claude/skills/vsaf-onboard/SKILL.md +60 -25
- package/.claude/skills/vsaf-plan/SKILL.md +76 -54
- package/.claude/skills/vsaf-retro/SKILL.md +94 -0
- package/.claude/skills/vsaf-ship/SKILL.md +83 -50
- package/.claude/skills/vsaf-sprint/SKILL.md +42 -42
- package/.claude/skills/vsaf-test/SKILL.md +159 -41
- package/README.md +300 -153
- package/bin/vsaf.js +2 -9
- package/package.json +3 -3
- package/src/global.js +0 -15
- package/src/project.js +0 -9
- package/src/status.js +0 -3
- package/src/workflow.js +1 -16
- package/.claude/skills/vsaf-memory-protocol.md +0 -51
|
@@ -1,86 +1,116 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: vsaf-build
|
|
3
|
-
description: Implement code
|
|
3
|
+
description: Implement code following existing PRD + SRS + testcases. Use after /vsaf-doc-srs and /vsaf-test. Brainstorm before plan, TDD with verification after each task.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# VSAF Build
|
|
7
7
|
|
|
8
|
-
##
|
|
9
|
-
Implement code
|
|
8
|
+
## Objective
|
|
9
|
+
Implement code strictly following PRD, SRS, and testcases, one task at a time, with TDD — ensuring each commit has tests passing AND is verified against spec.
|
|
10
10
|
|
|
11
|
-
##
|
|
12
|
-
-
|
|
13
|
-
-
|
|
14
|
-
-
|
|
11
|
+
## Prerequisites
|
|
12
|
+
- Have run `/vsaf-doc-prd` and have an approved PRD
|
|
13
|
+
- Have run `/vsaf-doc-srs` and have an approved SRS
|
|
14
|
+
- Have run `/vsaf-test` and have testcase docs (implementation readiness = PASS)
|
|
15
|
+
- User has confirmed the implementation scope
|
|
15
16
|
|
|
16
|
-
##
|
|
17
|
+
## Execution Steps
|
|
17
18
|
|
|
18
|
-
###
|
|
19
|
-
-
|
|
20
|
-
-
|
|
19
|
+
### Step 0 — Check Superpowers (mandatory check)
|
|
20
|
+
- Check whether the Superpowers plugin is installed in Claude Code
|
|
21
|
+
- If **not installed** → display:
|
|
21
22
|
```
|
|
22
|
-
⚠️ Superpowers
|
|
23
|
-
Superpowers
|
|
24
|
-
|
|
23
|
+
⚠️ Superpowers is not installed.
|
|
24
|
+
Superpowers improves implementation quality (TDD execution, plan execution, debugging, code review).
|
|
25
|
+
To install, run in Claude Code:
|
|
25
26
|
/plugin install superpowers@claude-plugins-official
|
|
26
|
-
|
|
27
|
+
Then restart Claude Code.
|
|
27
28
|
|
|
28
|
-
→
|
|
29
|
+
→ Continuing build without Superpowers (fallback mode).
|
|
29
30
|
```
|
|
30
|
-
-
|
|
31
|
+
- If **installed** → record `HAS_SUPERPOWERS = true`, display:
|
|
31
32
|
```
|
|
32
|
-
✓ Superpowers available —
|
|
33
|
+
✓ Superpowers available — will use: brainstorming, writing-plans, executing-plans, test-driven-development, verification-before-completion
|
|
33
34
|
```
|
|
34
35
|
|
|
35
|
-
###
|
|
36
|
-
-
|
|
37
|
-
-
|
|
38
|
-
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
- **
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
-
|
|
47
|
-
-
|
|
48
|
-
|
|
49
|
-
- **
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
-
|
|
54
|
-
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
-
|
|
62
|
-
-
|
|
63
|
-
-
|
|
64
|
-
|
|
65
|
-
###
|
|
66
|
-
- **
|
|
67
|
-
-
|
|
68
|
-
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
36
|
+
### Step 1 — Read PRD + SRS + testcase (mandatory — must read all 3 fully)
|
|
37
|
+
- Read the PRD file in `docs/project/planning-artifacts/` — understand WHY and WHAT
|
|
38
|
+
- Read the SRS file in `docs/project/srs/` — understand HOW, FRs/NFRs
|
|
39
|
+
- Read the testcase file in `docs/project/testcases/` — understand acceptance criteria
|
|
40
|
+
- Confirm FR/NFR → testcase mapping before starting
|
|
41
|
+
- If a gap is found (FR/NFR without testcase, or testcase contradicts SRS): NOTIFY USER before continuing
|
|
42
|
+
- **Do NOT start coding without having read all 3 documents**
|
|
43
|
+
|
|
44
|
+
### Step 1b — Brainstorm implementation approaches (mandatory)
|
|
45
|
+
- **If HAS_SUPERPOWERS**: use `superpowers:brainstorming` — structured exploration:
|
|
46
|
+
- Brainstorm 2-3 implementation approaches
|
|
47
|
+
- Evaluate trade-offs, risks, constraints for each approach
|
|
48
|
+
- Choose the best approach before committing to a plan
|
|
49
|
+
- **If not**: brainstorm manually — list at least 2 approaches, choose 1 with clear reasoning
|
|
50
|
+
- **Do NOT jump straight into planning without brainstorming**
|
|
51
|
+
|
|
52
|
+
### Step 2 — Generate plan from SRS (with/without Superpowers)
|
|
53
|
+
- **If HAS_SUPERPOWERS**: use `superpowers:writing-plans` to generate an atomic task list from SRS + testcase
|
|
54
|
+
- **If not**: manually create a task list from FR/NFR → testcase mapping
|
|
55
|
+
- Each task must:
|
|
56
|
+
- Map to ≥1 FR/NFR
|
|
57
|
+
- Have a clear verification step
|
|
58
|
+
- Be small enough for 1 commit
|
|
59
|
+
|
|
60
|
+
### Step 2b — Subagent dispatch (large plans, optional)
|
|
61
|
+
- If plan has ≥ 20 tasks AND HAS_SUPERPOWERS: use `superpowers:subagent-driven-development`
|
|
62
|
+
- Dispatch tasks to sub-agents with a two-phase review pipeline
|
|
63
|
+
- Each sub-agent still runs its own TDD cycle (RED → GREEN → REFACTOR)
|
|
64
|
+
- Review phase ensures consistent output
|
|
65
|
+
|
|
66
|
+
### Step 3 — Implement each task (TDD + Verification)
|
|
67
|
+
- **If HAS_SUPERPOWERS**: use `superpowers:executing-plans` — automatically runs TDD cycles following the plan
|
|
68
|
+
- Superpowers will call `superpowers:test-driven-development` for each task
|
|
69
|
+
- **If not**: implement manually following TDD:
|
|
70
|
+
1. **RED**: Write test first, run test → must fail
|
|
71
|
+
2. **GREEN**: Write minimal code to make the test pass
|
|
72
|
+
3. **REFACTOR**: Clean up code, keep tests passing
|
|
73
|
+
|
|
74
|
+
- After each task, run sequentially:
|
|
75
|
+
1. `mcp__gitnexus__detect_changes` — verify only the expected files changed
|
|
76
|
+
2. **Verification against spec** (mandatory):
|
|
77
|
+
- **If HAS_SUPERPOWERS**: use `superpowers:verification-before-completion` — confirm outcome matches SRS intent, not just "tests pass"
|
|
78
|
+
- **If not**: self-verify: re-read the corresponding FR/NFR in SRS, confirm behavior is correct, record verification result
|
|
79
|
+
3. Commit: `git commit -m "<type>: <task description>"`
|
|
80
|
+
|
|
81
|
+
### Step 3.5 — Checkpoint review (every 3-5 tasks)
|
|
82
|
+
- After every 3-5 completed tasks: use skill `bmad-checkpoint-preview`
|
|
83
|
+
- Purpose: human-in-the-loop review — "walk me through changes so far"
|
|
84
|
+
- Checkpoint will:
|
|
85
|
+
- Summarize: what was done, which files changed, tests status
|
|
86
|
+
- Highlight: points of concern, potential issues
|
|
87
|
+
- Ask user: continue / adjust / stop?
|
|
88
|
+
- **Skip checkpoint if**: plan has < 5 tasks total (only checkpoint at the end)
|
|
89
|
+
|
|
90
|
+
### Step 4 — Handling failures or scope drift
|
|
91
|
+
- **If HAS_SUPERPOWERS**: use `superpowers:systematic-debugging` — mandatory hypothesis → experiment → conclusion
|
|
92
|
+
- **If not**: try a different approach manually
|
|
93
|
+
- Fail 3 times on the same task: **STOP** — this is an architecture problem, not an execution one. Re-read SRS + testcase, redesign the task. If still failing: go back to `/vsaf-plan`
|
|
94
|
+
- **If scope drift is detected** (feature requires major changes compared to SRS):
|
|
95
|
+
- Use skill `bmad-correct-course` to assess impact + propose adjustments
|
|
96
|
+
- If requirements have changed → STOP, update SRS first (`/vsaf-doc-srs` EDIT mode), re-run `/vsaf-test`
|
|
97
|
+
- STOP and present to user: continue with adjustments / go back to `/vsaf-plan` to re-plan
|
|
98
|
+
|
|
99
|
+
### Step 5 — Output after each task
|
|
74
100
|
```
|
|
75
|
-
✓ Task [N]: [
|
|
76
|
-
-
|
|
101
|
+
✓ Task [N]: [task name]
|
|
102
|
+
- FR/NFR: [mapped requirement IDs]
|
|
103
|
+
- Files changed: [list]
|
|
77
104
|
- Tests: [X passed]
|
|
105
|
+
- Verification: [PASS — outcome matches SRS intent / FAIL — details]
|
|
78
106
|
- Commit: [hash]
|
|
79
|
-
- Superpowers: [
|
|
107
|
+
- Superpowers: [brainstorming ✓ / writing-plans ✓ / executing-plans ✓ / verification ✓]
|
|
80
108
|
- Checkpoint: [due at task N+X / completed]
|
|
81
109
|
```
|
|
82
110
|
|
|
83
|
-
##
|
|
84
|
-
- 1 commit = 1 task,
|
|
85
|
-
-
|
|
86
|
-
-
|
|
111
|
+
## Notes
|
|
112
|
+
- 1 commit = 1 task, do not bundle multiple tasks into 1 commit
|
|
113
|
+
- Do not modify files outside the scope of the current task
|
|
114
|
+
- Brainstorm is mandatory before planning — do not skip
|
|
115
|
+
- Verification is mandatory after each task — do not skip
|
|
116
|
+
- After completing all tasks: run `/vsaf-test run` then `/vsaf-ship`
|
|
@@ -1,70 +1,70 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: vsaf-discover
|
|
3
|
-
description: Product discovery —
|
|
3
|
+
description: Product discovery — research domain, market, feasibility before planning a feature. Use when starting a new project or exploring product development directions.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# VSAF Discover
|
|
7
7
|
|
|
8
|
-
##
|
|
9
|
-
|
|
8
|
+
## Objective
|
|
9
|
+
Thoroughly understand the domain, market, user needs, and technical feasibility before committing to any feature. Ensure we build the right thing.
|
|
10
10
|
|
|
11
11
|
## Input
|
|
12
|
-
`$ARGUMENTS` —
|
|
12
|
+
`$ARGUMENTS` — description of the product/domain to explore (e.g.: "order management platform for SMEs")
|
|
13
13
|
|
|
14
|
-
##
|
|
15
|
-
-
|
|
16
|
-
-
|
|
17
|
-
-
|
|
14
|
+
## When to Use
|
|
15
|
+
- Starting a new project (no PRD/SRS yet)
|
|
16
|
+
- Exploring new product development directions
|
|
17
|
+
- Before running `/vsaf-plan` for a large feature where the domain is not well understood
|
|
18
18
|
|
|
19
|
-
##
|
|
19
|
+
## Execution Steps
|
|
20
20
|
|
|
21
|
-
###
|
|
22
|
-
-
|
|
21
|
+
### Step 1 — Domain Research
|
|
22
|
+
- Use skill `bmad-domain-research` to deep dive into the domain/industry
|
|
23
23
|
- Output: terminology, business rules, regulatory constraints, domain patterns
|
|
24
|
-
-
|
|
24
|
+
- Save to `docs/project/planning-artifacts/domain-research-[topic].md`
|
|
25
25
|
|
|
26
|
-
###
|
|
27
|
-
-
|
|
28
|
-
- Competition landscape:
|
|
26
|
+
### Step 2 — Market Research
|
|
27
|
+
- Use skill `bmad-market-research` to analyze:
|
|
28
|
+
- Competition landscape: who is doing what, strengths/weaknesses
|
|
29
29
|
- Customer needs: pain points, underserved segments
|
|
30
|
-
- Market trends:
|
|
31
|
-
-
|
|
30
|
+
- Market trends: which directions are growing
|
|
31
|
+
- Save to `docs/project/planning-artifacts/market-research-[topic].md`
|
|
32
32
|
|
|
33
|
-
###
|
|
34
|
-
-
|
|
33
|
+
### Step 3 — Technical Feasibility
|
|
34
|
+
- Use skill `bmad-technical-research` to assess:
|
|
35
35
|
- Tech stack options + trade-offs
|
|
36
36
|
- Integration constraints
|
|
37
37
|
- Performance/scale requirements
|
|
38
38
|
- Build vs buy decisions
|
|
39
|
-
-
|
|
40
|
-
|
|
41
|
-
###
|
|
42
|
-
-
|
|
43
|
-
- Product brief =
|
|
44
|
-
-
|
|
45
|
-
|
|
46
|
-
###
|
|
47
|
-
-
|
|
48
|
-
-
|
|
49
|
-
-
|
|
50
|
-
-
|
|
51
|
-
|
|
52
|
-
###
|
|
53
|
-
-
|
|
54
|
-
- John
|
|
55
|
-
- PRD
|
|
56
|
-
-
|
|
57
|
-
-
|
|
58
|
-
-
|
|
59
|
-
|
|
60
|
-
###
|
|
61
|
-
-
|
|
62
|
-
- PM (John)
|
|
63
|
-
- Analyst (Mary)
|
|
64
|
-
- Architect (Winston)
|
|
65
|
-
-
|
|
66
|
-
|
|
67
|
-
###
|
|
39
|
+
- Save to `docs/project/planning-artifacts/tech-research-[topic].md`
|
|
40
|
+
|
|
41
|
+
### Step 4 — Product Brief
|
|
42
|
+
- Use skill `bmad-product-brief` to synthesize findings into a product brief
|
|
43
|
+
- Product brief = summary of: what problem, for whom, what solution, why now
|
|
44
|
+
- Save to `docs/project/planning-artifacts/product-brief-[name].md`
|
|
45
|
+
|
|
46
|
+
### Step 5 — PRFAQ Challenge (Working Backwards)
|
|
47
|
+
- Use skill `bmad-prfaq` to stress-test the product concept
|
|
48
|
+
- Write a simulated press release: if the product succeeds, what would the article say?
|
|
49
|
+
- Write FAQ: internal FAQ (what the team would ask) + external FAQ (what customers would ask)
|
|
50
|
+
- Purpose: discover weak concepts **before** investing time in code
|
|
51
|
+
|
|
52
|
+
### Step 6 — Create PRD (Product Requirements Document)
|
|
53
|
+
- Use skill `bmad-agent-pm` (John) to lead the PRD creation process
|
|
54
|
+
- John will call skill `bmad-create-prd` to generate a standard PRD from the product brief
|
|
55
|
+
- PRD includes: vision, goals, FRs, NFRs, epics, user stories, success metrics
|
|
56
|
+
- After creation: use skill `bmad-validate-prd` to validate the PRD meets standards
|
|
57
|
+
- If validation FAILs: John will use `bmad-edit-prd` to fix issues immediately
|
|
58
|
+
- Save to `docs/project/planning-artifacts/prd-[name].md`
|
|
59
|
+
|
|
60
|
+
### Step 7 — Multi-agent Review (Party Mode)
|
|
61
|
+
- Use skill `bmad-party-mode` to organize a roundtable:
|
|
62
|
+
- PM (John) presents the PRD
|
|
63
|
+
- Analyst (Mary) challenges requirements
|
|
64
|
+
- Architect (Winston) challenges feasibility
|
|
65
|
+
- Record consensus and open questions
|
|
66
|
+
|
|
67
|
+
### Step 8 — Output to user
|
|
68
68
|
```
|
|
69
69
|
## Discovery Complete: [product/domain]
|
|
70
70
|
|
|
@@ -76,17 +76,17 @@ Hiểu rõ domain, market, user needs, và technical feasibility trước khi co
|
|
|
76
76
|
- PRD: docs/project/planning-artifacts/prd-[name].md
|
|
77
77
|
|
|
78
78
|
### Key findings
|
|
79
|
-
- [3-5 bullet
|
|
79
|
+
- [3-5 bullet point summary]
|
|
80
80
|
|
|
81
81
|
### Open questions
|
|
82
|
-
- [
|
|
82
|
+
- [Items that need further validation]
|
|
83
83
|
|
|
84
84
|
### Recommended next steps
|
|
85
|
-
-
|
|
86
|
-
-
|
|
85
|
+
- Run /vsaf-sprint to break PRD into epics + stories
|
|
86
|
+
- Or: run /vsaf-plan <first-feature> to start the first feature
|
|
87
87
|
```
|
|
88
88
|
|
|
89
|
-
##
|
|
90
|
-
-
|
|
91
|
-
-
|
|
92
|
-
- Commit docs
|
|
89
|
+
## Notes
|
|
90
|
+
- This flow **does not generate code** — research + documentation only
|
|
91
|
+
- If the domain is too broad: suggest focusing on 1 vertical/segment first
|
|
92
|
+
- Commit docs after each step: `git commit -m "docs: discovery [topic]"`
|
|
@@ -1,22 +1,22 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: vsaf-doc
|
|
3
|
-
description: DEPRECATED —
|
|
3
|
+
description: DEPRECATED — Has been split into 2 separate commands. Use /vsaf-doc-prd to write the PRD, then /vsaf-doc-srs to write the SRS.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# VSAF Doc — DEPRECATED
|
|
7
7
|
|
|
8
|
-
|
|
8
|
+
This skill has been split into 2 separate commands:
|
|
9
9
|
|
|
10
|
-
1. `/vsaf-doc-prd` —
|
|
11
|
-
2. `/vsaf-doc-srs` —
|
|
10
|
+
1. `/vsaf-doc-prd` — Write PRD (Product Requirements Document) from `/vsaf-plan` output
|
|
11
|
+
2. `/vsaf-doc-srs` — Write SRS (Software Requirements Specification) from the existing PRD
|
|
12
12
|
|
|
13
|
-
##
|
|
13
|
+
## New Workflow
|
|
14
14
|
|
|
15
15
|
```
|
|
16
16
|
/vsaf-plan <requirement> # scope + impact + approach
|
|
17
|
-
/vsaf-doc-prd #
|
|
18
|
-
/vsaf-doc-srs #
|
|
19
|
-
/vsaf-test <path/to/srs> #
|
|
17
|
+
/vsaf-doc-prd # write PRD from approved scope
|
|
18
|
+
/vsaf-doc-srs # write SRS from PRD
|
|
19
|
+
/vsaf-test <path/to/srs> # generate testcases from SRS
|
|
20
20
|
```
|
|
21
21
|
|
|
22
|
-
|
|
22
|
+
Please use `/vsaf-doc-prd` or `/vsaf-doc-srs` instead of this skill.
|
|
@@ -1,57 +1,57 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: vsaf-doc-prd
|
|
3
|
-
description:
|
|
3
|
+
description: Write PRD (Product Requirements Document) from /vsaf-plan output. Use after /vsaf-plan when scope and approach are clear.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# VSAF Doc PRD
|
|
7
7
|
|
|
8
|
-
##
|
|
9
|
-
|
|
8
|
+
## Goal
|
|
9
|
+
Convert plan output into a formal PRD: vision, goals, FRs, NFRs, epics, user stories, success metrics.
|
|
10
10
|
|
|
11
|
-
##
|
|
12
|
-
|
|
11
|
+
## Prerequisites
|
|
12
|
+
Must have run `/vsaf-plan` and have its output before running this skill.
|
|
13
13
|
|
|
14
|
-
##
|
|
14
|
+
## Steps
|
|
15
15
|
|
|
16
|
-
###
|
|
17
|
-
-
|
|
18
|
-
- **
|
|
19
|
-
- **
|
|
20
|
-
-
|
|
16
|
+
### Step 0 — Determine mode: Create or Edit
|
|
17
|
+
- Check if a PRD already exists in `docs/project/planning-artifacts/` for this feature
|
|
18
|
+
- **If none exists** → Mode: CREATE (create from scratch)
|
|
19
|
+
- **If one exists** → Mode: EDIT (edit based on feedback/changes)
|
|
20
|
+
- Ask user: "A PRD already exists. Do you want to create a new one from scratch or edit the existing one?"
|
|
21
21
|
|
|
22
|
-
###
|
|
22
|
+
### Step 1 — Generate or Edit PRD
|
|
23
23
|
|
|
24
24
|
#### Mode CREATE:
|
|
25
|
-
-
|
|
26
|
-
- John
|
|
27
|
-
- PRD
|
|
28
|
-
-
|
|
25
|
+
- Use skill `bmad-agent-pm` (John) to guide the PRD creation process from `/vsaf-plan` output
|
|
26
|
+
- John will call skill `bmad-create-prd` to generate a standard PRD
|
|
27
|
+
- PRD must include: vision, goals, FRs, NFRs, epics, user stories, success metrics, scope, out-of-scope, assumptions
|
|
28
|
+
- Save to `docs/project/planning-artifacts/prd-[feature].md`
|
|
29
29
|
|
|
30
30
|
#### Mode EDIT:
|
|
31
|
-
-
|
|
32
|
-
-
|
|
33
|
-
-
|
|
31
|
+
- Use skill `bmad-edit-prd` to edit the existing PRD
|
|
32
|
+
- Preserve existing structure and IDs — only add/modify/remove sections as needed
|
|
33
|
+
- If changes are significant: warn user that SRS and testcases need to be re-run
|
|
34
34
|
|
|
35
|
-
###
|
|
36
|
-
-
|
|
37
|
-
-
|
|
38
|
-
-
|
|
39
|
-
-
|
|
35
|
+
### Step 2 — Validate PRD (BMAD validate)
|
|
36
|
+
- Use skill `bmad-validate-prd` to validate the generated/edited PRD
|
|
37
|
+
- Check: Are FRs clear enough? Are NFRs measurable? Are acceptance criteria verifiable?
|
|
38
|
+
- If issues found: fix immediately in the PRD, do not wait until build
|
|
39
|
+
- Record validation result (PASS/FAIL + findings)
|
|
40
40
|
|
|
41
|
-
###
|
|
41
|
+
### Step 3 — Output to user
|
|
42
42
|
```
|
|
43
|
-
## PRD
|
|
43
|
+
## PRD Created/Updated
|
|
44
44
|
|
|
45
45
|
### File
|
|
46
46
|
- docs/project/planning-artifacts/prd-[feature].md
|
|
47
47
|
- Mode: [CREATE / EDIT]
|
|
48
|
-
- Validation: [PASS / FAIL —
|
|
48
|
+
- Validation: [PASS / FAIL — details if fail]
|
|
49
49
|
|
|
50
50
|
## Next step
|
|
51
|
-
|
|
51
|
+
Run /vsaf-doc-srs to write SRS from this PRD
|
|
52
52
|
```
|
|
53
53
|
|
|
54
|
-
##
|
|
55
|
-
-
|
|
56
|
-
-
|
|
57
|
-
- Commit docs
|
|
54
|
+
## Notes
|
|
55
|
+
- Do not start coding in this step
|
|
56
|
+
- If scope is too large (>3 modules): suggest splitting into multiple PRs
|
|
57
|
+
- Commit docs before moving to SRS: `git commit -m "docs: prd for <feature>"`
|