@ngocsangairvds/vsaf 5.1.5 → 5.1.6

package/workflows/sdlc/sdlc-review.yaml

@@ -0,0 +1,36 @@
+name: sdlc-review
+description: 'Phase workflow: Review step-level execution'
+nodes:
+  - id: review-prereq
+    description: Review 1/5 — prerequisites
+    model: gpt-5.5
+    workspace: false
+    command: sdlc-review-prereq
+  - id: review-verification
+    description: Review 2/5 — system verification
+    model: gpt-5.5
+    depends_on:
+      - review-prereq
+    workspace: false
+    command: sdlc-review-verification
+  - id: review-code
+    description: Review 3/5 — code review + quality gate
+    model: gpt-5.5
+    depends_on:
+      - review-verification
+    workspace: false
+    command: sdlc-review-code
+  - id: review-impact
+    description: Review 4/5 — impact assessment
+    model: gpt-5.5
+    depends_on:
+      - review-code
+    workspace: false
+    command: sdlc-review-impact
+  - id: review-debate
+    description: Review 5/5 — debate + gate
+    model: gemini-3.5-flash
+    depends_on:
+      - review-impact
+    workspace: false
+    command: sdlc-review-debate

package/workflows/sdlc/sdlc-ship.yaml

@@ -0,0 +1,36 @@
+name: sdlc-ship
+description: 'Phase workflow: Ship step-level execution'
+nodes:
+  - id: ship-prereq
+    description: Ship 1/5 — prerequisites
+    model: gpt-5.5
+    workspace: false
+    command: sdlc-ship-prereq
+  - id: ship-gitignore
+    description: Ship 2/5 — .gitignore enforcement
+    model: gpt-5.5
+    depends_on:
+      - ship-prereq
+    workspace: false
+    command: sdlc-ship-gitignore
+  - id: ship-commit
+    description: Ship 3/5 — merge strategy + commit
+    model: gpt-5.5
+    depends_on:
+      - ship-gitignore
+    workspace: false
+    command: sdlc-ship-commit
+  - id: ship-pr
+    description: Ship 4/5 — push + PR
+    model: gpt-5.5
+    depends_on:
+      - ship-commit
+    workspace: false
+    command: sdlc-ship-pr
+  - id: ship-report
+    description: Ship 5/5 — ship report
+    model: gemini-3.5-flash
+    depends_on:
+      - ship-pr
+    workspace: false
+    command: sdlc-ship-report

package/workflows/sdlc/sdlc-srs.yaml

@@ -0,0 +1,29 @@
+name: sdlc-srs
+description: 'Phase workflow: SRS step-level execution'
+nodes:
+  - id: srs-prereq
+    description: SRS 1/4 — input artifacts
+    model: gpt-5.5
+    workspace: false
+    command: sdlc-srs-prereq
+  - id: srs-write
+    description: SRS 2/4 — write SRS
+    model: gemini-3.5-flash
+    depends_on:
+      - srs-prereq
+    workspace: false
+    command: sdlc-srs-write
+  - id: srs-validate
+    description: SRS 3/4 — validate SRS
+    model: gemini-3.5-flash
+    depends_on:
+      - srs-write
+    workspace: false
+    command: sdlc-srs-validate
+  - id: srs-interface
+    description: SRS 4/4 — interface verification + gate
+    model: gemini-3.5-flash
+    depends_on:
+      - srs-validate
+    workspace: false
+    command: sdlc-srs-interface

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

@@ -0,0 +1,29 @@
+name: sdlc-test-design
+description: 'Phase workflow: Test Design step-level execution'
+nodes:
+  - id: test-design-prereq
+    description: Test Design 1/4 — input artifacts
+    model: gpt-5.5
+    workspace: false
+    command: sdlc-test-design-prereq
+  - id: test-design-cases
+    description: Test Design 2/4 — generate test cases
+    model: gpt-5.5
+    depends_on:
+      - test-design-prereq
+    workspace: false
+    command: sdlc-test-design-cases
+  - id: test-design-boundary
+    description: Test Design 3/4 — boundary tests
+    model: gpt-5.5
+    depends_on:
+      - test-design-cases
+    workspace: false
+    command: sdlc-test-design-boundary
+  - id: test-design-coverage
+    description: Test Design 4/4 — coverage map + output
+    model: gemini-3.5-flash
+    depends_on:
+      - test-design-boundary
+    workspace: false
+    command: sdlc-test-design-coverage

package/workflows/sdlc/sdlc-testcase.yaml

@@ -0,0 +1,25 @@
+name: sdlc-testcase
+description: 'Sub-flow: step-level Test Design'
+nodes:
+  - id: test-design-prereq
+    description: Test Design 1/4 — input artifacts
+    workspace: false
+    command: sdlc-test-design-prereq
+  - id: test-design-cases
+    description: Test Design 2/4 — generate test cases
+    depends_on:
+      - test-design-prereq
+    workspace: false
+    command: sdlc-test-design-cases
+  - id: test-design-boundary
+    description: Test Design 3/4 — boundary tests
+    depends_on:
+      - test-design-cases
+    workspace: false
+    command: sdlc-test-design-boundary
+  - id: test-design-coverage
+    description: Test Design 4/4 — coverage map + output
+    depends_on:
+      - test-design-boundary
+    workspace: false
+    command: sdlc-test-design-coverage

package/workflows/sdlc/sdlc-thinking.yaml

@@ -0,0 +1,67 @@
+name: sdlc-thinking
+description: 'Sub-flow: step-level Discovery → PRD'
+nodes:
+  - id: discovery-prereq
+    description: Discovery 1/6 — prerequisites
+    workspace: false
+    command: sdlc-discovery-prereq
+  - id: discovery-system
+    description: Discovery 2/6 — existing system
+    depends_on:
+      - discovery-prereq
+    workspace: false
+    command: sdlc-discovery-system
+  - id: discovery-grill
+    description: Discovery 3/6 — grill session
+    depends_on:
+      - discovery-system
+    workspace: false
+    command: sdlc-discovery-grill
+  - id: discovery-brainstorm
+    description: Discovery 4/6 — dual brainstorming
+    depends_on:
+      - discovery-grill
+    workspace: false
+    command: sdlc-discovery-brainstorm
+  - id: discovery-domain
+    description: Discovery 5/6 — domain research + code scan
+    depends_on:
+      - discovery-brainstorm
+    workspace: false
+    command: sdlc-discovery-domain
+  - id: discovery-prfaq
+    description: Discovery 6/6 — PRFAQ + discovery output
+    depends_on:
+      - discovery-domain
+    workspace: false
+    command: sdlc-discovery-prfaq
+  - id: prd-prereq
+    description: PRD 1/5 — prerequisites
+    workspace: false
+    command: sdlc-prd-prereq
+    depends_on:
+      - discovery-prfaq
+  - id: prd-elicitation
+    description: PRD 2/5 — elicitation
+    depends_on:
+      - prd-prereq
+    workspace: false
+    command: sdlc-prd-elicitation
+  - id: prd-create
+    description: PRD 3/5 — create PRD
+    depends_on:
+      - prd-elicitation
+    workspace: false
+    command: sdlc-prd-create
+  - id: prd-validate
+    description: PRD 4/5 — validate + adversarial review
+    depends_on:
+      - prd-create
+    workspace: false
+    command: sdlc-prd-validate
+  - id: prd-blast-radius
+    description: PRD 5/5 — blast radius + gate
+    depends_on:
+      - prd-validate
+    workspace: false
+    command: sdlc-prd-blast-radius

package/skills/sdlc/architecture/SKILL.md

@@ -1,218 +0,0 @@
----
-name: sdlc-architecture
-description: Phase 3 — Architecture + Epics via GitNexus analysis + grill session + BMAD architecture + conflict mapping
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Phase 3: Architecture + Epics
-
-You are a Solution Architect. Mission: understand constraints before designing, split into vertical slices, create conflict map to prevent stepping on each other's work.
-
-**IMPORTANT:** This phase MUST ask architecture questions BEFORE designing. Do NOT design before understanding constraints from the user.
-
-## Progress Protocol
-
-Print progress at each step in this format:
-```
-[ARCHITECTURE] [step/6] description... ⏳
-[ARCHITECTURE] [step/6] description... ✅
-```
-
-## Index Protection
-
-⛔ Do NOT modify `graphify-out/` or `.gitnexus/` in this phase.
-
-## Phase Entry Protocol
-
-```
-[ARCHITECTURE] [1/6] Checking prerequisites... ⏳
-```
-
-1. Input: `.vsaf/docs/features/{feature-name}/02-prd.md`
-2. Check if file exists + **check for Gate: APPROVED**
-   - No Gate → Stop: "PRD has not been approved"
-3. Read `.vsaf/docs/STATUS.md`
-4. Read `CONTEXT.md`
-5. Query `graph.json` for code structure + business mapping
-
-```
-[ARCHITECTURE] [1/6] Checking prerequisites... ✅
-```
-
-## Tasks
-
-### Step 2: Current State Analysis
-
-```
-[ARCHITECTURE] [2/6] Analyzing current state via GitNexus... ⏳
-```
-
-Use GitNexus `context` — 360° view of all affected symbols (from PRD §Blast Radius).
-Use GitNexus `api_impact` — API route pre-change analysis (if project has API).
-Record results internally to prepare questions for Step 3.
-
-```
-[ARCHITECTURE] [2/6] Analyzing current state via GitNexus... ✅
-```
-
-### Step 3: GRILL Session — ASK architecture questions BEFORE designing
-
-```
-[ARCHITECTURE] [3/6] Grill session — asking architecture questions... ⏳
-```
-
-Use `/bmad-advanced-elicitation` — grill architecture-specific questions BASED ON current state analysis from Step 2.
-
-**STRICT RULES:**
-- ⛔ Do NOT make architecture decisions before asking
-- ⛔ Do NOT say "I recommend using pattern X"
-- ✅ ONLY ask questions
-- ✅ Questions MUST cover the following areas:
-
-**Mandatory questions:**
-1. **Tech constraints** — "Are there any limitations on tech stack, library versions, or infrastructure?"
-2. **Integration points** — "What external services/systems does this feature need to interact with? What protocol?"
-3. **Performance requirements** — "What is the expected load? Latency budget? Throughput target?"
-4. **Deployment model** — "Deploy within the existing service or separate? Blue-green, canary, or rolling?"
-5. **Data model concerns** — "Is acceptable downtime for schema migration OK? Data volume estimate?"
-
-**WAIT** for the user to respond BEFORE continuing to Step 4.
-
-```
-[ARCHITECTURE] [3/6] Grill session — asking architecture questions... ✅
-```
-
-### Step 4: Architecture Decision
-
-```
-[ARCHITECTURE] [4/6] Designing architecture based on grill answers... ⏳
-```
-
-Use `/bmad-create-architecture` — design architecture based on grill answers from Step 3.
-
-Ensure the output covers:
-
-1. **Component diagram** — identify bounded contexts and their interfaces
-2. **Deep Module validation** — each component: small public interface, complex logic inside
-3. **Data model** — entity relationships, schema changes, migration strategy
-4. **Integration points** — APIs, message queues, external services
-5. **Trade-offs** — explicitly state: "Based on answer '{user answer}' → chose '{approach}' because '{reasoning}'"
-
-Write to `03-adr.md` §Current State + §Grill Session + §Decision.
-
-```
-[ARCHITECTURE] [4/6] Designing architecture based on grill answers... ✅
-```
-
-### Step 5: Epic Breakdown
-
-```
-[ARCHITECTURE] [5/6] Splitting epics + conflict map... ⏳
-```
-
-Use `/bmad-create-epics-and-stories` — split PRD into vertical slices (DB→API→UI per epic, NOT horizontal layers):
-
-1. Group related FRs into epics — each epic deliverable independently
-2. Each story MUST be a vertical slice with clear acceptance criteria
-3. Create Conflict Map — which file belongs to which epic
-
-Write to `04-epics.md`:
-
-```markdown
-## Epic 1: {name} [Owner: {ai/person}] [Branch: feat/{feature}/epic-1]
-- Scope: {folders/files belonging to this epic}
-- Stories: ...
-
-## Epic 2: {name} [Owner: {ai/person}] [Branch: feat/{feature}/epic-2]
-- Scope: {folders/files belonging to this epic}
-- Stories: ...
-
-## Conflict Map
-- src/user/user.service.ts → Epic 1 ONLY
-- src/shared/dto/ → SHARED (adding NEW files OK, do not modify existing files)
-- If multi-repo:
-  - user-service/ → Epic 1 ONLY
-  - payment-service/ → Epic 2 ONLY
-```
-
-```
-[ARCHITECTURE] [5/6] Splitting epics + conflict map... ✅
-```
-
-### Step 6: Readiness Check
-
-```
-[ARCHITECTURE] [6/6] Checking implementation readiness... ⏳
-```
-
-Use `/bmad-check-implementation-readiness` — validate architecture is clear enough to implement:
-
-1. **PRD coverage** — every FR traceable to at least one epic/story?
-2. **Architecture completeness** — all integration points, data models, error handling defined?
-3. **Story clarity** — can a developer pick up any story and start coding without ambiguity?
-4. **Conflict map** — any file claimed by multiple epics without resolution?
-
-Write to `03-adr.md` §Readiness. If FAIL → record what's missing, fix ADR or PRD.
-
-```
-[ARCHITECTURE] [6/6] Checking implementation readiness... ✅
-```
-
-## Gate
-
-Readiness = PASS to proceed to Phase 4.
-If FAIL → record reasoning, go back to fix ADR or PRD.
-
-## Output
-
-- `.vsaf/docs/features/{feature-name}/03-adr.md`
-- `.vsaf/docs/features/{feature-name}/04-epics.md`
-
-### 03-adr.md template:
-
-```markdown
-# ADR: {feature-name}
-
-## Current State
-{from GitNexus context + api_impact}
-
-## Grill Session
-{questions and answers from bmad-advanced-elicitation}
-
-## Decision
-{from bmad-create-architecture, based on grill answers}
-{clearly state: "Based on answer X → chose approach Y because Z"}
-
-## Readiness
-{from bmad-check-implementation-readiness}
-```
-
-## Artifact Auto-Save
-
-After writing the file, print the message:
-
-> Artifacts saved. If the session is interrupted, open a new session and run the next phase — data is safe.
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Feature: {feature-name}
-- Status: COMPLETED
-- Completed: current state analysis, grill session, architecture decision, epic breakdown, readiness check
-- Output files: `03-adr.md`, `04-epics.md`
-- Suggested next steps:
-  [1] Phase 4 SRS → `/sdlc-srs`
-  [2] Save artifacts
-
-Update `.vsaf/docs/STATUS.md`.
-
-## Rules
-
-- ⛔ Do NOT design architecture before asking — Grill session MUST happen before architecture decision
-- ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`
-- Every story MUST be a vertical slice (DB→API→UI), NOT a horizontal layer
-- Conflict Map MUST be clear: which file belongs to which epic, what rules apply for shared files
-- ADR is append-only: after approval do not edit, only create a new ADR to supersede
-- If multi-repo: clearly specify which repo belongs to which epic
-- Architecture decisions MUST reference specific answers from the grill session

package/skills/sdlc/discovery/SKILL.md

@@ -1,197 +0,0 @@
----
-name: sdlc-discovery
-description: Phase 1 — Discovery via system understanding + grill session + brainstorming + domain research + PRFAQ
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Phase 1: Discovery
-
-You are a Principal Product Owner. Mission: deeply understand the problem space before writing any spec.
-
-**IMPORTANT:** This phase MUST ask questions FIRST. Do NOT offer suggestions before understanding context from the user.
-
-## Progress Protocol
-
-Print progress at each step in this format:
-```
-[DISCOVERY] [step/6] description... ⏳
-[DISCOVERY] [step/6] description... ✅
-```
-
-## Index Protection
-
-⛔ Do NOT modify `graphify-out/` or `.gitnexus/` in this phase.
-
-## Phase Entry Protocol
-
-```
-[DISCOVERY] [1/6] Checking prerequisites... ⏳
-```
-
-1. Receive feature request: `$ARGUMENTS`
-2. Check if `graphify-out/graph.json` exists:
-   - Does not exist → Ask: "Graph not found. Have you run onboarding?"
-3. Read `.vsaf/docs/STATUS.md` → confirm feature does not already exist or identify current phase
-4. Read `CONTEXT.md`
-5. Query `graph.json` for related business domain context
-
-```
-[DISCOVERY] [1/6] Checking prerequisites... ✅
-```
-
-## Tasks
-
-### Step 2: Understand Existing System FIRST
-
-```
-[DISCOVERY] [2/6] Analyzing current system via GitNexus... ⏳
-```
-
-BEFORE asking any questions, MUST understand the current system:
-
-1. Use GitNexus MCP tools:
-   - `query` — find code/patterns related to the feature request
-   - `route_map` — understand current API routes and flow
-   - `context` — 360° view of related symbols
-2. Read `graphify-out/graph.json` — understand relationships between concepts/modules
-
-Record analysis results internally (do NOT output to user at this step).
-
-```
-[DISCOVERY] [2/6] Analyzing current system via GitNexus... ✅
-```
-
-### Step 3: GRILL Session — ASK questions, do NOT suggest
-
-```
-[DISCOVERY] [3/6] Grill session — asking detailed questions... ⏳
-```
-
-Use `/bmad-advanced-elicitation` — grill questions BASED ON system understanding from Step 2.
-
-**STRICT RULES:**
-- ⛔ Do NOT offer suggestions or recommendations
-- ⛔ Do NOT say "I think we should do X"
-- ✅ ONLY ask questions
-- ✅ Questions MUST be specific, based on actual code/architecture analyzed
-- ✅ Correct example: "The current system has UserService handling auth. Do you want the new feature to interact with the existing auth flow or be separate?"
-- ✅ Correct example: "Route `/api/orders` currently returns 5 fields. What additional fields does the new feature need?"
-- ⛔ Wrong example: "I suggest using event-driven architecture for this feature"
-
-**WAIT** for the user to respond BEFORE continuing to Step 4.
-
-```
-[DISCOVERY] [3/6] Grill session — asking detailed questions... ✅
-```
-
-### Step 4: Dual Brainstorming
-
-```
-[DISCOVERY] [4/6] Dual brainstorming based on grill answers... ⏳
-```
-
-Two complementary brainstorming approaches:
-
-**4a — Structured brainstorm**
-
-Based on grill answers + system analysis, propose:
-- 2-3 viable approaches with trade-offs
-- Risk/constraint evaluation per approach
-- Recommended option with reasoning
-
-**4b — Creative brainstorm (BMAD)**
-
-Use `/bmad-brainstorming` to explore alternatives and uncover hidden risks:
-- Facilitator-led, diverse creative techniques
-- Goal: ≥20 ideas/alternatives before reorganizing
-- Surfaces edge cases the structured approach may miss
-
-Record both results in `01-discovery.md` — §Problem Statement (4a) + §Alternatives (4b).
-
-```
-[DISCOVERY] [4/6] Dual brainstorming based on grill answers... ✅
-```
-
-### Step 5: Domain Research + Existing Code Scan
-
-```
-[DISCOVERY] [5/6] Domain research + existing code scan... ⏳
-```
-
-Use `/bmad-domain-research` — deep-dive domain knowledge.
-Use GitNexus `query` — find related code/patterns already available in the codebase.
-Record results in `01-discovery.md` §Domain Research + §Existing Code.
-
-```
-[DISCOVERY] [5/6] Domain research + existing code scan... ✅
-```
-
-### Step 6: PRFAQ (if large feature)
-
-```
-[DISCOVERY] [6/6] PRFAQ (if needed)... ⏳
-```
-
-Use `/bmad-prfaq` — Working Backwards to force clarity.
-Record results in `01-discovery.md` §PRFAQ.
-If the feature is small, record "PRFAQ: Skipped — feature scope does not require it."
-
-```
-[DISCOVERY] [6/6] PRFAQ (if needed)... ✅
-```
-
-## Output
-
-Create directory `.vsaf/docs/features/{feature-name}/` if it does not exist.
-Write file: `.vsaf/docs/features/{feature-name}/01-discovery.md`
-
-```markdown
-# Discovery: {feature-name}
-
-## Grill Session
-{questions and answers from bmad-advanced-elicitation}
-
-## Problem Statement
-{from bmad-brainstorming, based on grill answers}
-
-## Domain Research
-{from bmad-domain-research}
-
-## Existing Code
-{from GitNexus query + context + route_map}
-
-## PRFAQ
-{from bmad-prfaq, if applicable}
-
-## Decision: Proceed / Pivot / Kill
-{recommendation on whether to continue, with reasoning}
-```
-
-## Artifact Auto-Save
-
-After writing the file, print the message:
-
-> Artifacts saved. If the session is interrupted, open a new session and run the next phase — data is safe.
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Feature: {feature-name}
-- Status: COMPLETED
-- Completed: system analysis, grill session, brainstorming, domain research, existing code scan, PRFAQ
-- Output files: `.vsaf/docs/features/{feature-name}/01-discovery.md`
-- Suggested next steps:
-  [1] Continue to Phase 2 PRD → `/sdlc-prd`
-  [2] Save artifacts
-
-Update `.vsaf/docs/STATUS.md`.
-
-## Rules
-
-- ⛔ Do NOT offer suggestions before asking — Grill session MUST happen before brainstorming
-- ⛔ Do NOT read detailed source code — only use GitNexus tools for high-level scanning
-- ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`
-- Every discovery must have a clear Decision: Proceed, Pivot, or Kill
-- If Decision = Kill → record reasoning, stop the flow
-- Questions in the grill session MUST be based on actual system understanding, NOT generic