@ngocsangairvds/vsaf 5.1.5 → 5.1.7

package/skills/sdlc/prd/SKILL.md

@@ -1,182 +0,0 @@
----
-name: sdlc-prd
-description: Phase 2 — PRD via BMAD elicitation + create + validate + adversarial review + GitNexus impact
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Phase 2: PRD (Product Requirements Document)
-
-You are a Principal Product Owner. Mission: write a clear PRD that is validated and has blast radius assessment.
-
-## Language Rule
-
-All output documents (02-prd.md) MUST be written in Vietnamese. Section headers, user stories, requirements, analysis — all in Vietnamese. Only keep English for: IDs (FR-001, NFR-001, US-001), technical terms (API, database, endpoint), and code references.
-
-## Progress Protocol
-
-Print progress at each step in this format:
-```
-[PRD] [step/5] description... ⏳
-[PRD] [step/5] description... ✅
-```
-
-## Index Protection
-
-⛔ Do NOT modify `graphify-out/` or `.gitnexus/` in this phase.
-
-## Phase Entry Protocol
-
-```
-[PRD] [1/5] Checking prerequisites... ⏳
-```
-
-1. Input: `.vsaf/docs/features/{feature-name}/01-discovery.md`
-2. Check if file exists:
-   - Does not exist → Ask: "File not found. Have you run Phase 1 Discovery?"
-3. Read `.vsaf/docs/STATUS.md`
-4. Read `CONTEXT.md`
-5. Query `graph.json` for business domain context
-
-```
-[PRD] [1/5] Checking prerequisites... ✅
-```
-
-## Tasks
-
-### Step 2: Elicitation (Grill Session)
-
-```
-[PRD] [2/5] Grill session — elicitation probing edge cases... ⏳
-```
-
-Use `/bmad-advanced-elicitation` — grill 40-100 questions probing edge cases.
-Record results in `02-prd.md` §Grill Log.
-
-```
-[PRD] [2/5] Grill session — elicitation probing edge cases... ✅
-```
-
-### Step 3: Create PRD
-
-```
-[PRD] [3/5] Creating PRD from grill results... ⏳
-```
-
-Use `/bmad-create-prd` — create structured PRD from grill results (Step 2).
-
-Ensure the output covers:
-
-1. **Goals** — business goals + success metrics
-2. **User Stories** — each MUST have acceptance criteria (Given/When/Then)
-3. **Functional Requirements** — unique ID per requirement (FR-001, FR-002...)
-4. **Non-Functional Requirements** — unique ID (NFR-001, NFR-002...) — performance, security, scalability
-5. **Success Metrics** — measurable KPIs tied to goals
-
-Write to `02-prd.md` §Requirements.
-
-```
-[PRD] [3/5] Creating PRD from grill results... ✅
-```
-
-### Step 4: Validate + Adversarial Review
-
-```
-[PRD] [4/5] Validate + adversarial review... ⏳
-```
-
-**4a — Validate PRD:**
-
-Use `/bmad-validate-prd` — validate the PRD against BMAD standards:
-- Completeness — all user stories covered by FRs? All FRs traceable to a user story?
-- Clarity — any ambiguous requirements? Can each FR be implemented without guessing?
-- Testability — can each FR be verified with a test case?
-- Consistency — any FRs that contradict each other?
-
-Write to `02-prd.md` §Validation. If FAIL → fix inline, re-validate.
-
-**4b — Adversarial review:**
-
-Use `/bmad-review-adversarial-general` — cynical review to find gaps.
-Write to `02-prd.md` §Adversarial.
-
-```
-[PRD] [4/5] Validate + adversarial review... ✅
-```
-
-### Step 5: Blast Radius
-
-```
-[PRD] [5/5] Assessing blast radius via GitNexus... ⏳
-```
-
-Use GitNexus `impact` — assess scope of feature impact.
-Write to `02-prd.md` §Blast Radius.
-
-```
-[PRD] [5/5] Assessing blast radius via GitNexus... ✅
-```
-
-## Gate
-
-Human must approve the PRD. Write `## Gate: APPROVED` at the end of the file.
-Do NOT proceed to Phase 3 without the Gate marker.
-
-**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
-
-Write file: `.vsaf/docs/features/{feature-name}/02-prd.md`
-
-```markdown
-# PRD: {feature-name}
-
-## Grill Log
-{elicitation Q&A}
-
-## Requirements
-### User Stories
-{with acceptance criteria}
-### Functional Requirements
-{FR-001, FR-002...}
-### Non-Functional Requirements
-{NFR-001, NFR-002...}
-
-## Validation
-{validate-prd result}
-
-## Adversarial
-{adversarial findings}
-
-## Blast Radius
-{GitNexus impact result}
-
-## Gate: {PENDING / APPROVED by {name} on {date}}
-```
-
-## 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: elicitation, create PRD, validate, adversarial review, blast radius
-- Output files: `.vsaf/docs/features/{feature-name}/02-prd.md`
-- Suggested next steps:
-  [1] Phase 3 Architecture → `/sdlc-architecture`
-  [2] Save artifacts
-
-Update `.vsaf/docs/STATUS.md`.
-
-## Rules
-
-- ⛔ Do NOT skip elicitation — Shared Understanding is mandatory
-- ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`
-- Every user story MUST have acceptance criteria
-- Every FR/NFR MUST have a unique ID
-- Do NOT proceed if blast radius = HIGH without human approval

package/skills/sdlc/review/SKILL.md

@@ -1,210 +0,0 @@
----
-name: sdlc-review
-description: Phase 7 — Review via Superpowers verification + BMAD code review + SonarQube re-check + GitNexus impact + debate
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Phase 7: Review
-
-You are Tech Lead + QA Lead. Mission: verify code against SRS, adversarial review, impact assessment.
-
-## Progress Protocol
-
-Print progress at each step in this format:
-```
-[REVIEW] [step/5] description... ⏳
-[REVIEW] [step/5] description... ✅
-```
-
-## Index Protection
-
-⛔ DO NOT modify `graphify-out/` or `.gitnexus/` in this phase.
-
-## Artifact Auto-save
-
-All artifacts are automatically saved to `.vsaf/docs/features/{feature-name}/` to ensure session continuity. If the session is interrupted, you can resume from the last artifact.
-
-## Phase Entry Protocol
-
-```
-[REVIEW] [1/5] Checking prerequisites... ⏳
-```
-
-1. Input:
-   - `.vsaf/docs/features/{feature-name}/05-srs.md`
-   - Code diff on feature branch
-2. Check that SRS file exists
-3. Check that feature branch exists
-4. Read `.vsaf/docs/STATUS.md`
-5. Read `CONTEXT.md`
-6. Query `graph.json` for impact verification
-
-```
-[REVIEW] [1/5] Checking prerequisites... ✅
-```
-
-## Tasks
-
-### Step 2: System Verification
-
-```
-[REVIEW] [2/5] System verification — build, tests, scope... ⏳
-```
-
-Use `/superpowers:verification-before-completion`:
-- Build passes
-- All tests GREEN
-- No uncommitted files
-- Scope matches SRS
-Write to `08-review.md` §Verification.
-
-```
-[REVIEW] [2/5] System verification... ✅
-```
-
-### Step 3: Code Review
-
-```
-[REVIEW] [3/5] Adversarial code review... ⏳
-```
-
-Use `/bmad-code-review` — adversarial code review on the feature branch diff with parallel review layers (Blind Hunter, Edge Case Hunter, Acceptance Auditor).
-
-Ensure the review covers:
-
-1. **Security scan** — SQL injection, XSS, command injection, hardcoded secrets, insecure deserialization
-2. **Data integrity** — null dereference, resource leaks, race conditions, missing transactions
-3. **SOLID violations** — god classes, leaky abstractions, interface segregation
-4. **Naming consistency** — verify against CONTEXT.md terminology
-5. **SRS compliance** — every FR/NFR implemented? Any extra scope not in SRS?
-
-Classify each finding: MUST FIX / SHOULD FIX / NOTED.
-Write to `08-review.md` §Code Review.
-
-#### Quality Gate Re-check (SonarQube)
-
-**IMPORTANT:** SonarQube rules were already applied in Phase 6 (Implementation). The Review phase only RE-CHECKS — confirming that code still meets standards after all changes.
-
-Verify that code meets the `sonar-viettel` Quality Gate.
-
-> **Standard (single source of truth):** **`.claude/skills/_shared/sdlc/sonar-viettel/quality-gate.md`** — the full New Code + Overall Code tables, the 357-rule parameters, and the importable `sonar-viettel-profile.xml` / `sonar-viettel-gate.json`. This is the **same** file Phase 6 (`/sdlc-implement`) coded against — review only confirms compliance, do not change the numbers.
-
-**Hard fails to confirm (summary — see the shared doc for the full gate):**
-- New Code: Issues / Blocker / Critical / Major / Vulnerabilities = **0**; Code Smells **≤ 20**; Security Hotspots Reviewed = **100%**; Duplicated **≤ 45%**; Maintainability / Reliability / Security Rating **≥ A**.
-- Overall Code: Bugs = **0**; Code Smells **≤ 50**; same Blocker/Critical/Major/Vuln/Duplication/rating rules.
-
-**How to execute (auto-detect — check whether `sonar-scanner` is on PATH):**
-- SonarQube present → ensure it uses the `sonar-viettel` Profile + Gate (import from the shared folder if missing), run `sonar-scanner`, and check the report
-- SonarQube absent → print `Sonar not found → self-checklist mode` and perform a manual re-check against the shared `quality-gate.md` (a fully supported path — SonarQube is OPTIONAL):
-  - Scan for security vulnerabilities (SQL injection, XSS, command injection, hardcoded secrets)
-  - Scan for bugs (null dereference, resource leaks, concurrency issues)
-  - Scan for code smells (long methods, deep nesting, duplicated blocks)
-  - Verify naming conventions, SOLID principles, duplicated blocks
-- Write results to `08-review.md` §Quality Gate
-
-**Quality Gate FAIL** → classify each issue as MUST FIX / SHOULD FIX / NOTED per the triage rules below.
-
-```
-[REVIEW] [3/5] Adversarial code review + Quality Gate re-check... ✅
-```
-
-### Step 4: Impact Assessment
-
-```
-[REVIEW] [4/5] Impact assessment via GitNexus... ⏳
-```
-
-Use GitNexus `detect_changes` + `impact`:
-- Confirm only expected files changed
-- Blast radius confidence scoring
-Write to `08-review.md` §Impact.
-
-```
-[REVIEW] [4/5] Impact assessment... ✅
-```
-
-### Step 5: Debate (complex features only)
-
-```
-[REVIEW] [5/5] Multi-agent debate (if needed)... ⏳
-```
-
-Use `/bmad-party-mode` — multi-agent debate:
-- Security vs Performance vs Maintainability
-Write to `08-review.md` §Debate.
-
-```
-[REVIEW] [5/5] Multi-agent debate... ✅
-```
-
-## Gate
-
-MUST FIX = 0, Human approve.
-
-**Automated mode (opt-in):** when `VSAF_CI=1` or `VSAF_AUTO_APPROVE=1` is set AND MUST FIX = 0, write `## Gate: APPROVED (auto · VSAF_CI · rationale: <one line>)` and proceed. If MUST FIX > 0, NEVER auto-approve — return to Phase 6 (Implement) regardless of the flag. Without the env flag, a human must approve (default).
-
-Triage:
-- **MUST FIX**: Security, data loss, SRS FR/NFR not satisfied, crash → Blocks ship
-- **SHOULD FIX**: Performance, maintainability → Fix if time allows
-- **NOTED**: Style, minor naming → Log only
-
-If MUST FIX > 0 → return to Phase 6 (Implementation) with specific issues.
-
-## Output
-
-Write file: `.vsaf/docs/features/{feature-name}/08-review.md`
-
-```markdown
-# Review: {feature-name}
-
-## Verification
-- Build: PASS/FAIL
-- Tests: {X}/{Y} passed
-- Uncommitted files: none
-- Scope: matches SRS ✓
-
-## Code Review
-### MUST FIX
-- (none)
-### SHOULD FIX
-- {issue description}
-### NOTED
-- {minor items}
-
-## Quality Gate (Re-check)
-- SonarQube: {available / manual re-check}
-- New Code: {PASS/FAIL} — Issues={N}, Blocker={N}, Critical={N}, Major={N}, Smells={N}, Vulns={N}, Duplication={N}%
-- Overall: {PASS/FAIL} — Bugs={N}, Blocker={N}, Critical={N}, Major={N}, Smells={N}, Vulns={N}, Duplication={N}%
-- Compile: PASS/FAIL
-- Runtime: PASS/FAIL
-
-## Impact
-- Files changed: {N}
-- Blast radius: {low/medium/high}
-- Confidence: {%}
-
-## Debate (if applicable)
-{party-mode findings}
-
-## Gate: {PENDING / APPROVED by {name} on {date}}
-```
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Results: MUST FIX = {N}, SHOULD FIX = {N}, NOTED = {N}
-- Output files: `08-review.md`
-- Suggestion: [1] `/sdlc-feature-complete` (if APPROVED) [2] Return to Phase 6 (if MUST FIX > 0)
-
-Update `.vsaf/docs/STATUS.md`.
-
-## Rules
-
-- Review against SRS (spec), NOT against code implementation
-- Max 2 review rounds — if still failing → escalate to human
-- MUST FIX items MUST be resolved before feature-complete
-- **Quality Gate FAIL = MUST FIX** — Blocker, Critical, Vulnerability all block ship
-- **Code does not compile = MUST FIX** — hard gate, no exceptions
-- If there is no SonarQube, Claude performs a manual quality gate re-check
-- **SonarQube only RE-CHECKS** — rules were applied in Phase 6, review only confirms compliance

package/skills/sdlc/ship/SKILL.md

@@ -1,194 +0,0 @@
----
-name: sdlc-ship
-description: Phase 9 — Ship via commit (source + .vsaf/docs only) + PR generation
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Phase 9: Ship
-
-You are DevOps Engineer. Mission: ship approved code + updated knowledge — commit, create PR, write ship report.
-
-## Progress Protocol
-
-Print progress at each step in this format:
-```
-[SHIP] [step/5] description... ⏳
-[SHIP] [step/5] description... ✅
-```
-
-## Phase Entry Protocol
-
-```
-[SHIP] [1/5] Checking prerequisites... ⏳
-```
-
-1. Input: `.vsaf/docs/features/{feature-name}/08-review.md`
-2. Check that the file exists + **check for Gate: APPROVED**
-   - No Gate → Stop: "Review has not been approved"
-3. Check `.vsaf/docs/STATUS.md` — feature must be in "Knowledge Updated" status
-   - If not → Stop: "Feature has not passed feature-complete. Run `/sdlc-feature-complete` first."
-4. Read `CONTEXT.md`
-
-```
-[SHIP] [1/5] Checking prerequisites... ✅
-```
-
-## Tasks
-
-### Step 2: .gitignore Enforcement
-
-```
-[SHIP] [2/5] Checking .gitignore — ensuring index files are not committed... ⏳
-```
-
-**MANDATORY** — MUST verify before committing:
-
-1. Check that `.gitignore` contains:
-   ```
-   graphify-out/
-   .gitnexus/
-   ```
-2. If MISSING → **AUTOMATICALLY add to `.gitignore`** and notify user
-3. Verify with `git status` — `graphify-out/` and `.gitnexus/` DO NOT appear in staged/unstaged files
-4. If they still appear → `git rm --cached -r graphify-out/ .gitnexus/` before committing
-
-⚠️ **ABSOLUTELY DO NOT commit `graphify-out/` or `.gitnexus/`** — these are local indexes, each machine builds its own.
-
-```
-[SHIP] [2/5] Checking .gitignore... ✅
-```
-
-### Step 3: Merge Strategy + Commit
-
-```
-[SHIP] [3/5] Commit source code + .vsaf/docs/... ⏳
-```
-
-Use `/superpowers:finishing-a-development-branch`:
-- Decide merge strategy (merge commit / squash / rebase)
-- Resolve conflicts if any
-- Verify final build passes
-
-**Commit scope — ONLY commit:**
-- Source code changes (implementation / fix)
-- `.vsaf/docs/` folder (artifacts, CONTEXT.md, KNOWLEDGE.md, STATUS.md)
-- `.gitignore` (if updated)
-
-**DO NOT commit:**
-- `graphify-out/` — local graph index
-- `.gitnexus/` — local code index
-
-```
-[SHIP] [3/5] Commit source code + .vsaf/docs/... ✅
-```
-
-### Step 4: Push + PR
-
-```
-[SHIP] [4/5] Push branch + create PR... ⏳
-```
-
-Generate PR description from review artifacts:
-- Read the review file from `{artifact-dir}` — summary, impact, test results
-- Create a structured PR description
-- Open PR (or suggest command if multi-repo)
-
-**Branch naming:** `feat/{feature-name}`
-
-**Single repo:**
-```bash
-git push -u origin {branch}
-gh pr create --title "{title}" --body "{description}"
-```
-
-**Multi-repo:**
-```
-For each repo with code changes:
-  cd {repo} && git push -u origin {branch}
-  gh pr create --title "{title}" --body "{description}"
-```
-
-**Add note to PR description:**
-```
-> **Note for reviewer:** After pulling the code, run `npx gitnexus analyze` and `/graphify` to re-index locally.
-```
-
-```
-[SHIP] [4/5] Push branch + create PR... ✅
-```
-
-### Step 5: Ship Report
-
-```
-[SHIP] [5/5] Writing ship report... ⏳
-```
-
-Write file: `.vsaf/docs/features/{feature-name}/09-ship.md`
-
-```
-[SHIP] [5/5] Writing ship report... ✅
-```
-
-## Output
-
-```markdown
-# Ship Report: {feature-name}
-
-## PR
-- {repo}: PR #{number} — {url}
-
-## Merge Strategy
-{merge commit / squash / rebase}
-
-## Commit Scope
-- Source code: {N} files
-- .vsaf/docs/: {M} files (artifacts + knowledge)
-- Excluded: graphify-out/, .gitnexus/ (local index)
-
-## Final Status
-- Build: PASS
-- Tests: all GREEN
-- Review: APPROVED
-- Knowledge: UPDATED (feature-complete done)
-
-## Traceability
-US-001 → FR-001 → TC-001 → impl ✓
-US-002 → FR-002 → TC-003 → impl ✓
-
-## Post-pull Setup
-After pulling the code, run:
-- `npx gitnexus analyze` — re-index code
-- `/graphify` — rebuild knowledge graph
-```
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-```
-═══════════════════════════════════════════
-  SHIP COMPLETE: {feature-name}
-═══════════════════════════════════════════
-  Phase: 9 (Ship — final phase)
-  
-  PR: #{number} — {url}
-  Commit: source code + .vsaf/docs/ only
-  Excluded: graphify-out/, .gitnexus/
-  
-  Phases completed: 1→2→3→4→5→6→7→8→9
-  Artifacts: .vsaf/docs/features/{feature-name}/ (9 files)
-  
-  Feature DONE.
-═══════════════════════════════════════════
-```
-
-Update `.vsaf/docs/STATUS.md` → move to "Completed Features".
-
-## Rules
-
-- DO NOT review code — that is the review phase's job
-- Only ship code that is APPROVED + knowledge UPDATED (feature-complete done)
-- PR description MUST be self-contained (reading the PR alone should be enough to understand the feature without reading artifacts)
-- **ABSOLUTELY DO NOT commit `graphify-out/` or `.gitnexus/`** — verify .gitignore first
-- **ONLY commit source code + `.vsaf/docs/`**
-- Add re-index note to PR description for team members