@ngocsangairvds/vsaf 5.1.5 → 5.1.7

package/skills/sdlc/srs/SKILL.md

@@ -1,148 +0,0 @@
----
-name: sdlc-srs
-description: "Phase 4 — SRS via sdlc-write-srs template + sdlc-validate-srs 8-dimension validation + GitNexus interface verification"
-version: 2.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Phase 4: SRS (Software Requirements Specification)
-
-You are a Senior Business Analyst. Your mission: write a detailed SRS using the v4 template, validate it across 8 quality dimensions, and verify interface contracts.
-
-## Language Rule
-
-All output documents (05-srs.md) MUST be written in Vietnamese. Section headers, requirements, use cases, analysis — all in Vietnamese. Only keep English for: IDs (FR-001, NFR-001, UC-XX-01), technical terms (API, database, endpoint), and code references (class names, method signatures).
-
-## Index Protection
-
-⛔ **DO NOT modify** `graphify-out/` or `.gitnexus/` — READ only, never WRITE.
-
-## Scope sizing — full vs lite
-
-Pick the SRS depth before writing, to avoid over-spending on small features:
-
-- **Explicit override (highest priority):** if `$ARGUMENTS` contains `--lite` → lite; `--full` → full.
-- **Force FULL (hard overrides) — pick `full` regardless of FR count if ANY apply:**
-  | Trigger | Why |
-  |---|---|
-  | Touches auth / security / authorization | a spec gap here is high-cost |
-  | Data migration / schema change | irreversible, needs full rigor |
-  | New public/external API or interface contract (FE / third-party) | downstream consumers depend on it |
-  | ≥ 3 modules affected, OR GitNexus blast-radius HIGH/CRITICAL | wide blast = expensive mistakes |
-- **Otherwise auto-detect:** **lite** when ALL of — **≤ 8 functional requirements** AND ≤ ~5 files / single module AND GitNexus blast-radius LOW/MEDIUM AND none of the Force-FULL triggers above. **full** otherwise.
-  > FR count alone is a weak signal (a 3-FR auth change still needs full; a 12-FR read-only change can be lite) — the Force-FULL triggers and blast-radius decide first; the ≤ 8 FR line is only the tie-breaker for low-risk features.
-- **Lite mode:** write the SRS sections that apply, then run `sdlc-validate-srs` in lite mode (core dimensions only — completeness, consistency, testability; skip the heavy 8-dimension weighted scoring). Note `Mode: LITE` at the top of `05-srs.md`.
-- **Full mode:** write all 12 sections and run the full 8-dimension validation. Note `Mode: FULL`.
-
-State which mode you chose and why in one line before writing.
-
-## Phase Entry Protocol
-
-```
-[SRS] [1/4] Checking input artifacts... ⏳
-```
-
-1. Input:
-   - `.vsaf/docs/features/{feature-name}/02-prd.md`
-   - `.vsaf/docs/features/{feature-name}/03-adr.md`
-   - `.vsaf/docs/features/{feature-name}/04-epics.md`
-2. Verify 02-prd.md AND 03-adr.md exist (04-epics.md optional):
-   - Any required file missing → Ask: "File not found. Have you run Phase 2 (PRD) and Phase 3 (Architecture)?"
-3. Read `.vsaf/docs/STATUS.md`
-4. Read `CONTEXT.md`
-5. Query `graph.json` for code structure + business mapping (if exists)
-
-```
-[SRS] [1/4] Checking input artifacts... ✅
-```
-
-## Tasks
-
-### Step 2: Write SRS
-
-```
-[SRS] [2/4] Writing SRS from PRD + ADR + Epics... ⏳
-```
-
-Use `/sdlc-write-srs` — write SRS following the v4 template (12 sections) from PRD + Architecture + Epics.
-
-Input:
-- `02-prd.md` as PRD source
-- `03-adr.md` as architecture context
-- `04-epics.md` as epic breakdown (optional)
-- Figma link from `CONTEXT.md` (optional)
-
-Output: `.vsaf/docs/features/{feature-name}/05-srs.md`
-
-```
-[SRS] [2/4] Writing SRS from PRD + ADR + Epics... ✅
-```
-
-### Step 3: Validate SRS
-
-```
-[SRS] [3/4] Validating SRS (8 dimensions)... ⏳
-```
-
-Use `/sdlc-validate-srs` — validate SRS across 8 dimensions with weighted scoring.
-
-- Scope: single file (`05-srs.md`)
-- Cross-validate against: `02-prd.md`, `03-adr.md`
-- Output: `.vsaf/docs/features/{feature-name}/05-srs-validation-report.md`
-
-**Decision handling:**
-
-| Validation Result | Action |
-|---|---|
-| **GO** (≥80%, no CRITICAL) | Print score summary, proceed to Step 4 |
-| **CONDITIONAL GO** (60-79% or HIGH findings) | Print warnings + finding summary. Ask user: "Proceed despite warnings? (Y/N)" |
-| **NO-GO** (<60% or CRITICAL findings) | **STOP.** Print CRITICAL findings. Ask user to fix 05-srs.md and re-run `/sdlc-srs` |
-
-```
-[SRS] [3/4] Validating SRS (8 dimensions)... ✅
-```
-
-### Step 4: Interface Verification
-
-```
-[SRS] [4/4] Interface verification via GitNexus... ⏳
-```
-
-Use GitNexus `shape_check` — verify code structure matches SRS assumptions.
-Append results to `05-srs.md` §Interface Contracts.
-
-```
-[SRS] [4/4] Interface verification via GitNexus... ✅
-```
-
-## Gate
-
-Human must approve SRS. Write `## Gate: APPROVED` at the end of the file.
-
-**Automated mode (opt-in):** when the environment has `VSAF_CI=1` or `VSAF_AUTO_APPROVE=1`, write the Gate yourself as `## Gate: APPROVED (auto · VSAF_CI · rationale: <one line>)` and proceed — the one-line rationale is REQUIRED for audit. Without the env flag, a human must approve (default).
-
-## Output
-
-- `.vsaf/docs/features/{feature-name}/05-srs.md` — SRS document (v4 template format)
-- `.vsaf/docs/features/{feature-name}/05-srs-validation-report.md` — Validation report with scores
-
-## Phase Exit Protocol
-
-In PHASE REPORT:
-- Output files: `05-srs.md`, `05-srs-validation-report.md`
-- Validation score: {overall_score}% ({GO/CONDITIONAL GO/NO-GO})
-- Suggestions: [1] Phase 5 Test Design (`/sdlc-test-design`) [2] Save artifacts
-
-Update `.vsaf/docs/STATUS.md`.
-
-**Notify the user:**
-> Artifacts have been saved. If the session is interrupted, open a new session and run the next phase — data is safe.
-
-## Rules
-
-- Every FR/NFR MUST have a unique traceability ID
-- DO NOT use vague language: "should", "might", "optionally" → replace with "MUST", "MUST NOT"
-- All terms MUST exist in CONTEXT.md
-- Every FR MUST be testable (have clear pass/fail criteria)
-- SRS MUST follow the v4 template structure (12 sections)
-- ⛔ DO NOT modify `graphify-out/` or `.gitnexus/`

package/skills/sdlc/test-design/SKILL.md

@@ -1,132 +0,0 @@
----
-name: sdlc-test-design
-description: Phase 5 — Test Design via BMAD QA + edge case hunter + GitNexus coverage mapping
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Phase 5: Test Design
-
-You are a QA Lead. Your mission: design test cases FROM the SRS (spec), NOT from code. Tests BEFORE code (#2 TDD).
-
-## Index Protection
-
-⛔ **DO NOT modify** `graphify-out/` or `.gitnexus/` — READ only, never WRITE.
-
-## Phase Entry Protocol
-
-```
-[TEST-DESIGN] [1/4] Checking input artifacts... ⏳
-```
-
-1. Input: `.vsaf/docs/features/{feature-name}/05-srs.md`
-2. Verify file exists + **check Gate: APPROVED**
-   - No Gate → Stop: "SRS has not been approved"
-3. Read `.vsaf/docs/STATUS.md`
-4. Read `CONTEXT.md`
-
-```
-[TEST-DESIGN] [1/4] Checking input artifacts... ✅
-```
-
-## Tasks
-
-### Step 1: Generate Test Cases
-
-```
-[TEST-DESIGN] [2/4] Generating test cases from SRS... ⏳
-```
-
-Use `/bmad-qa-generate-e2e-tests` — generate test cases from SRS FRs/NFRs.
-
-For each requirement, ensure ≥1 test case with:
-
-1. **Unique ID** — TC-001 (sequential)
-2. **Traceability** — TC → FR/NFR → PRD user story (US-xxx)
-3. **Type** — unit / integration / e2e (based on requirement scope)
-4. **Precondition** — system state before test
-5. **Steps** — exact actions to execute
-6. **Expected result** — concrete, verifiable outcome (not "should work")
-
-Prioritize: happy path first, then error paths, then edge cases.
-
-```
-[TEST-DESIGN] [2/4] Generating test cases from SRS... ✅
-```
-
-### Step 2: Boundary Tests
-
-```
-[TEST-DESIGN] [3/4] Boundary & edge case tests... ⏳
-```
-
-Use `/bmad-review-edge-case-hunter` — add boundary tests.
-Race conditions, null/empty, overflow, concurrent access.
-
-```
-[TEST-DESIGN] [3/4] Boundary & edge case tests... ✅
-```
-
-### Step 3: Coverage Map
-
-```
-[TEST-DESIGN] [4/4] Coverage mapping via GitNexus... ⏳
-```
-
-Use GitNexus `detect_changes` — predict files that will be modified.
-Map test cases → files requiring coverage.
-
-```
-[TEST-DESIGN] [4/4] Coverage mapping via GitNexus... ✅
-```
-
-## Output
-
-Write file: `.vsaf/docs/features/{feature-name}/06-testcases.md`
-
-```markdown
-# Test Cases: {feature-name}
-
-## TC-001 → FR-001 → US-003
-- Type: unit
-- File target: src/user/user.service.ts
-- Precondition: ...
-- Steps: ...
-- Expected: ...
-
-## TC-002 → FR-001 (edge case: empty input)
-- Type: unit
-- Precondition: ...
-- Steps: ...
-- Expected: ...
-
-## Coverage Map
-- src/user/user.service.ts → TC-001, TC-002
-- src/user/user.controller.ts → TC-005, TC-006
-
-## Traceability Matrix
-| FR/NFR | Test Cases | Coverage |
-|--------|-----------|----------|
-| FR-001 | TC-001, TC-002 | ✓ |
-| FR-002 | TC-003 | ✓ |
-| NFR-001 | TC-010 | ✓ |
-```
-
-## Phase Exit Protocol
-
-In PHASE REPORT:
-- Output files: `.vsaf/docs/features/{feature-name}/06-testcases.md`
-- Suggestions: [1] Phase 6 Implementation (`/sdlc-implement`) [2] Save artifacts
-
-Update `.vsaf/docs/STATUS.md`.
-
-**Notify the user:**
-> Artifacts have been saved. If the session is interrupted, open a new session and run the next phase — data is safe.
-
-## Rules
-
-- Test cases derive from SRS (spec), NEVER from code
-- Every FR/NFR MUST have ≥1 test case
-- Traceability chain is mandatory: TC → FR → US
-- DO NOT read source code when writing test cases
-- ⛔ DO NOT modify `graphify-out/` or `.gitnexus/`

package/skills/sdlc/workflows/master-sdlc.yaml

@@ -1,35 +0,0 @@
-name: master-sdlc
-description: "Full SDLC pipeline — Thinking → Design → Testcase → Build → QA"
-nodes:
-  - id: thinking
-    description: "Thinking: Discovery → PRD"
-    bash: |
-      vsaf run sdlc/sdlc-thinking $ARGUMENTS
-    workspace: false
-
-  - id: design
-    description: "Design: Architecture → SRS"
-    bash: |
-      vsaf run sdlc/sdlc-design $ARGUMENTS
-    depends_on: [thinking]
-    workspace: false
-
-  - id: testcase
-    description: "Testcase: generate test cases from SRS"
-    bash: |
-      vsaf run sdlc/sdlc-testcase $ARGUMENTS
-    depends_on: [design]
-    workspace: false
-
-  - id: build
-    description: "Build: Implement → Test Gate"
-    bash: |
-      vsaf run sdlc/sdlc-build $ARGUMENTS
-    depends_on: [testcase]
-
-  - id: qa
-    description: "QA: Review → Feature Complete → Ship"
-    bash: |
-      vsaf run sdlc/sdlc-qa $ARGUMENTS
-    depends_on: [build]
-    workspace: false

package/skills/sdlc/workflows/sdlc-build.yaml

@@ -1,18 +0,0 @@
-name: sdlc-build
-description: "Sub-flow: Implement → Test Gate — TDD code + automated test verification"
-
-nodes:
-  - id: implement
-    description: "Implement: TDD implementation per vertical slice"
-    command: sdlc-implement
-    depends_on: []
-
-  - id: test-gate
-    description: "Test Gate: run automated tests to verify implementation"
-    bash: |
-      npm test 2>&1
-    depends_on: [implement]
-    loop:
-      on_fail: implement
-      max_retries: 3
-      inject_error: true

package/skills/sdlc/workflows/sdlc-design.yaml

@@ -1,14 +0,0 @@
-name: sdlc-design
-description: "Sub-flow: Architecture → SRS — design solution and write detailed spec"
-
-nodes:
-  - id: architecture
-    description: "Architecture: design solution architecture and write ADR + epic breakdown"
-    command: sdlc-architecture
-    workspace: false
-
-  - id: srs
-    description: "SRS: write Software Requirements Specification with API contracts"
-    command: sdlc-srs
-    depends_on: [architecture]
-    workspace: false

package/skills/sdlc/workflows/sdlc-qa.yaml

@@ -1,20 +0,0 @@
-name: sdlc-qa
-description: "Sub-flow: Review → Feature Complete → Ship — quality gate + knowledge update + deploy"
-
-nodes:
-  - id: review
-    description: "Review: code review against SRS, architecture, and best practices"
-    command: sdlc-review
-    workspace: false
-
-  - id: complete
-    description: "Feature Complete: update knowledge base and project documentation"
-    command: sdlc-feature-complete
-    depends_on: [review]
-    workspace: false
-
-  - id: ship
-    description: "Ship: create PR, final checks, deploy"
-    command: sdlc-ship
-    depends_on: [complete]
-    workspace: false

package/skills/sdlc/workflows/sdlc-testcase.yaml

@@ -1,8 +0,0 @@
-name: sdlc-testcase
-description: "Sub-flow: Test Design — generate test cases from SRS (tests before code)"
-
-nodes:
-  - id: test-design
-    description: "Test Design: generate test cases from SRS (tests before code)"
-    command: sdlc-test-design
-    workspace: false

package/skills/sdlc/workflows/sdlc-thinking.yaml

@@ -1,12 +0,0 @@
-name: sdlc-thinking
-description: "Sub-flow: Discovery → PRD — understand the problem space before designing"
-
-nodes:
-  - id: discovery
-    command: sdlc-discovery
-    workspace: false
-
-  - id: prd
-    command: sdlc-prd
-    depends_on: [discovery]
-    workspace: false