@ngocsangairvds/vsaf 5.1.4 → 5.1.6

package/skills/sdlc/hotfix-prd/SKILL.md

@@ -1,161 +0,0 @@
----
-name: sdlc-hotfix-prd
-description: "Hotfix Phase 2 — Lightweight PRD from analysis: fix requirements, acceptance criteria, scope"
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Hotfix Phase 2: PRD (Fix Requirements)
-
-You are a Principal Product Owner focused on a surgical fix. Mission: define exactly what needs to change, acceptance criteria, and "done" definition — no discovery needed (grill already happened in analyze phase).
-
-## Language Rule
-
-Output documents (02-prd.md) MUST be written in Vietnamese. Only keep English for: IDs, technical terms, code references.
-
-## Progress Protocol
-
-Print progress at each step:
-```
-[HOTFIX-PRD] [step/4] description... ⏳
-[HOTFIX-PRD] [step/4] description... ✅
-```
-
-## Index Protection
-
-⛔ Do NOT modify `graphify-out/` or `.gitnexus/` — READ only.
-
-## Phase Entry Protocol
-
-```
-[HOTFIX-PRD] [1/4] Checking input artifacts... ⏳
-```
-
-1. Input: `.vsaf/docs/hotfixes/{bug-id}/01-analysis.md`
-2. Verify file exists:
-   - Does not exist → Stop: "Analysis not found. Run `/sdlc-hotfix-analyze` first."
-3. Read the analysis file — extract:
-   - Root cause (file:line)
-   - Blast radius
-   - Fix strategy (proposed in analyze phase)
-   - Affected files
-4. Read `.vsaf/docs/STATUS.md`
-5. Read `CONTEXT.md`
-
-```
-[HOTFIX-PRD] [1/4] Checking input artifacts... ✅
-```
-
-## Tasks
-
-### Step 2: Define Fix Requirements
-
-```
-[HOTFIX-PRD] [2/4] Defining fix requirements from analysis... ⏳
-```
-
-Based on the analysis (NOT a new grill session — that already happened), define:
-
-1. **Fix Goal** — one sentence: what the fix achieves
-2. **Functional Requirements** — FR-001, FR-002... (typically 1-3 for a hotfix)
-   - Each FR traces to the root cause or blast radius item
-3. **Acceptance Criteria** — Given/When/Then for each FR
-   - MUST include a regression test criterion: "Given the fix is applied, When {original reproduction steps}, Then {expected behavior}"
-4. **Scope Boundary** — explicitly state what is OUT of scope (no refactoring, no enhancements)
-5. **Non-Functional Requirements** — only if relevant (performance regression, security)
-
-```
-[HOTFIX-PRD] [2/4] Defining fix requirements... ✅
-```
-
-### Step 3: Validate + Risk Check
-
-```
-[HOTFIX-PRD] [3/4] Validating PRD... ⏳
-```
-
-Use `/bmad-validate-prd` — validate:
-- Every FR is testable
-- Acceptance criteria are unambiguous
-- Scope is minimal (hotfix, not enhancement)
-- Fix addresses root cause, not just symptom
-
-If FAIL → fix inline, re-validate.
-
-Use GitNexus `impact` — confirm blast radius from analysis is still accurate.
-
-```
-[HOTFIX-PRD] [3/4] Validating PRD... ✅
-```
-
-### Step 4: Write PRD
-
-```
-[HOTFIX-PRD] [4/4] Writing hotfix PRD... ⏳
-```
-
-Write file: `.vsaf/docs/hotfixes/{bug-id}/02-prd.md`
-
-```markdown
-# Hotfix PRD: {bug-id}
-
-## Fix Goal
-{one sentence}
-
-## Source
-- Analysis: `01-analysis.md`
-- Root cause: {file:line — summary}
-
-## Functional Requirements
-
-### FR-001: {title}
-{description}
-
-**Acceptance Criteria:**
-- Given {context}, When {action}, Then {expected result}
-
-### FR-002: {title} (if needed)
-...
-
-## Non-Functional Requirements
-{NFR-001 if applicable, otherwise "N/A — no NFR impact for this fix"}
-
-## Scope Boundary
-**In scope:** {what will change}
-**Out of scope:** {what will NOT change — no refactoring, no enhancements}
-
-## Blast Radius (confirmed)
-{from GitNexus impact — files that may be affected}
-
-## Gate: {PENDING / APPROVED by {name} on {date}}
-```
-
-```
-[HOTFIX-PRD] [4/4] Writing hotfix PRD... ✅
-```
-
-## Gate
-
-Human must approve the PRD. Write `## Gate: APPROVED` at the end of the file.
-Do NOT proceed to implementation without the Gate marker.
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Bug: {bug-id}
-- Status: PRD COMPLETED
-- FRs: {count} functional requirements
-- Output: `.vsaf/docs/hotfixes/{bug-id}/02-prd.md`
-- Next step: `/sdlc-hotfix-implement`
-
-Update `.vsaf/docs/STATUS.md`.
-
-> Artifacts saved. If the session is interrupted, open a new session and run the next phase — data is safe.
-
-## Rules
-
-- ⛔ Do NOT start a new grill session — analysis already has grill results
-- ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`
-- ⛔ Do NOT add enhancements — hotfix scope only
-- Scope MUST be minimal — fix root cause, add regression test, nothing more
-- Every FR MUST be directly traceable to the root cause or blast radius

package/skills/sdlc/hotfix-review/SKILL.md

@@ -1,153 +0,0 @@
----
-name: sdlc-hotfix-review
-description: "Hotfix Phase 4 — Quick review — verify minimal fix, impact check, test quality, SonarQube on changed files"
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Hotfix Phase 4: Quick Review
-
-You are a Tech Lead doing a focused hotfix review. Mission: verify the fix is minimal, the test is real, and nothing else broke.
-
-## Language Rule
-
-Output documents (02-review.md) MUST be written in Vietnamese. Only keep English for: IDs, technical terms, code references. The template below shows structure only — write actual content in Vietnamese.
-
-## Progress Protocol
-
-Print progress at each step:
-```
-[HOTFIX-REVIEW] [step/4] description... ⏳
-[HOTFIX-REVIEW] [step/4] description... ✅
-```
-
-## Index Protection
-
-⛔ Do NOT modify `graphify-out/` or `.gitnexus/` — READ only.
-
-## Phase Entry Protocol
-
-```
-[HOTFIX-REVIEW] [1/4] Loading context... ⏳
-```
-
-1. Read `.vsaf/docs/hotfixes/{bug-id}/01-analysis.md` — understand what was supposed to change
-2. Read `CONTEXT.md`
-3. Identify all files changed in the GREEN phase (use git diff or read the phase report)
-
-```
-[HOTFIX-REVIEW] [1/4] Loading context... ✅
-```
-
-## Tasks
-
-### Step 2: Minimality Verification
-
-```
-[HOTFIX-REVIEW] [2/4] Verifying fix is minimal... ⏳
-```
-
-Check:
-- [ ] Only files identified in the analysis were changed
-- [ ] No unnecessary refactoring included
-- [ ] No formatting-only changes on untouched code
-- [ ] No unrelated fixes bundled in
-- [ ] Diff size is proportional to the bug (a 1-line bug should not need 50 lines of changes)
-
-If any check fails → flag as CHANGES_REQUESTED with specific reason.
-
-```
-[HOTFIX-REVIEW] [2/4] Verifying fix is minimal... ✅
-```
-
-### Step 3: Test Quality Check
-
-```
-[HOTFIX-REVIEW] [3/4] Verifying test quality... ⏳
-```
-
-Read the reproduction test and verify:
-- [ ] Test targets the specific bug (not a generic happy-path test)
-- [ ] Test would FAIL without the fix (it's not trivially always-passing)
-- [ ] Test exercises the exact code path from the root cause analysis
-- [ ] Test has a descriptive name referencing the bug
-- [ ] Test follows project conventions
-
-```
-[HOTFIX-REVIEW] [3/4] Verifying test quality... ✅
-```
-
-### Step 4: Impact Check + SonarQube
-
-```
-[HOTFIX-REVIEW] [4/4] Impact check + quality gate... ⏳
-```
-
-1. Use GitNexus `detect_changes` + `impact` — confirm blast radius matches the analysis
-2. If blast radius is LARGER than analysis predicted → flag for human review
-3. SonarQube rules on changed files only:
-
-| Metric | Threshold |
-|--------|-----------|
-| Issues (Blocker) | 0 |
-| Issues (Critical) | 0 |
-| Security Hotspots | 0 |
-| New code smells | 0 |
-
-> **Standard (single source of truth):** **`.claude/skills/_shared/sdlc/sonar-viettel/quality-gate.md`** — full gate + 357-rule parameters + importable `sonar-viettel-profile.xml` / `sonar-viettel-gate.json`. Same file Phase 3 (`/sdlc-hotfix-implement`) coded against. If SonarQube is present, scan changed files against the `sonar-viettel` profile + gate; otherwise re-check manually. `New code smells = 0` is intentionally stricter than the gate's ≤20 for surgical fixes.
-
-```
-[HOTFIX-REVIEW] [4/4] Impact check + quality gate... ✅
-```
-
-## Gate
-
-Write `## Gate: APPROVED` or `## Gate: CHANGES_REQUESTED` with reasons.
-
-If CHANGES_REQUESTED:
-- List specific issues with triage: MUST FIX / SHOULD FIX / NOTED
-- Do NOT proceed to ship until all MUST FIX items are resolved
-
-## Output
-
-Write file: `.vsaf/docs/hotfixes/{bug-id}/02-review.md`
-
-```markdown
-# Hotfix Review: {bug-id}
-
-## Minimality Check
-{minimality check results}
-
-## Test Quality Check
-{test quality check results}
-
-## Blast Radius
-{blast radius confirmation — matches/exceeds analysis}
-
-## SonarQube
-{quality gate results on changed files}
-
-## Conclusion
-{overall assessment}
-
-## Gate: {APPROVED / CHANGES_REQUESTED}
-{reasons if changes requested}
-```
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Bug: {bug-id}
-- Status: REVIEW COMPLETED
-- Gate: {APPROVED / CHANGES_REQUESTED}
-- Output: `.vsaf/docs/hotfixes/{bug-id}/02-review.md`
-- Next step: `/sdlc-ship` (if approved)
-
-Update `.vsaf/docs/STATUS.md`.
-
-## Rules
-
-- ⛔ Do NOT modify code — review only
-- ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`
-- A hotfix review is FAST but NOT sloppy — every check matters
-- If the fix touches more files than the analysis predicted, escalate to human

package/skills/sdlc/hotfix-ship/SKILL.md

@@ -1,221 +0,0 @@
----
-name: sdlc-hotfix-ship
-description: "Hotfix Phase 4 — Ship: commit, PR on hotfix branch, ship report"
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Hotfix Phase 4: Ship
-
-You are DevOps Engineer. Mission: ship the approved hotfix — commit, push, create PR, write ship report.
-
-## Progress Protocol
-
-Print progress at each step:
-```
-[HOTFIX-SHIP] [step/5] description... ⏳
-[HOTFIX-SHIP] [step/5] description... ✅
-```
-
-## Phase Entry Protocol
-
-```
-[HOTFIX-SHIP] [1/5] Checking prerequisites... ⏳
-```
-
-1. Input: `.vsaf/docs/hotfixes/{bug-id}/` directory
-2. Verify these files exist:
-   - `01-analysis.md` — root cause analysis
-   - `02-prd.md` — fix requirements (MUST have `## Gate: APPROVED`)
-   - `03-impl-log.md` — implementation log
-3. Check `02-prd.md` has `## Gate: APPROVED`
-   - No Gate → Stop: "PRD not approved. Get approval before shipping."
-4. Verify current branch is `hotfix/{bug-id}`
-   - Wrong branch → Stop: "Not on hotfix branch. Switch to `hotfix/{bug-id}`."
-5. Read `CONTEXT.md`
-
-```
-[HOTFIX-SHIP] [1/5] Checking prerequisites... ✅
-```
-
-## Tasks
-
-### Step 2: .gitignore Enforcement
-
-```
-[HOTFIX-SHIP] [2/5] Checking .gitignore... ⏳
-```
-
-**MANDATORY** — verify before committing:
-
-1. Check `.gitignore` contains:
-   ```
-   graphify-out/
-   .gitnexus/
-   ```
-2. If MISSING → add automatically and notify user
-3. Verify with `git status` — `graphify-out/` and `.gitnexus/` do NOT appear
-4. If they appear → `git rm --cached -r graphify-out/ .gitnexus/`
-
-⚠️ **ABSOLUTELY DO NOT commit `graphify-out/` or `.gitnexus/`**
-
-```
-[HOTFIX-SHIP] [2/5] Checking .gitignore... ✅
-```
-
-### Step 3: Final Test Gate
-
-```
-[HOTFIX-SHIP] [3/5] Final test verification... ⏳
-```
-
-Run full test suite one last time before shipping:
-```bash
-npm test  # or mvn test / gradle test / equivalent
-```
-
-- ALL tests MUST pass
-- If FAIL → Stop: "Tests failing. Fix before shipping."
-
-```
-[HOTFIX-SHIP] [3/5] Final test verification... ✅
-```
-
-### Step 4: Commit + Push + PR
-
-```
-[HOTFIX-SHIP] [4/5] Commit + push + create PR... ⏳
-```
-
-**Commit scope — ONLY commit:**
-- Source code changes (the fix)
-- `.vsaf/docs/hotfixes/{bug-id}/` (all artifacts)
-- `.gitignore` (if updated)
-
-**DO NOT commit:**
-- `graphify-out/`
-- `.gitnexus/`
-
-**Commit message format:**
-```
-fix({area}): {short description}
-
-Root cause: {one line from 01-analysis.md}
-Closes: #{issue-number} (if applicable)
-```
-
-**Push + PR:**
-```bash
-git push -u origin hotfix/{bug-id}
-gh pr create --title "fix({area}): {short description}" --body "{PR body}"
-```
-
-**PR body template:**
-```markdown
-## Bug Fix: {bug-id}
-
-### Root Cause
-{from 01-analysis.md — one paragraph}
-
-### Fix
-{from 03-impl-log.md — what was changed and why}
-
-### Tests
-- Regression test: `{test file}:{test name}`
-- Full suite: {total} tests, all PASS
-
-### Affected Files
-{list from 03-impl-log.md}
-
-### Scope
-- ✅ Fix only — no refactoring, no enhancements
-- ✅ Regression test added
-- ✅ Full test suite passing
-
----
-> **Post-pull:** Run `npx gitnexus analyze` and `/graphify` to re-index locally.
-```
-
-```
-[HOTFIX-SHIP] [4/5] Commit + push + create PR... ✅
-```
-
-### Step 5: Ship Report
-
-```
-[HOTFIX-SHIP] [5/5] Writing ship report... ⏳
-```
-
-Write file: `.vsaf/docs/hotfixes/{bug-id}/04-ship.md`
-
-```markdown
-# Ship Report: {bug-id}
-
-## PR
-- {repo}: PR #{number} — {url}
-
-## Branch
-`hotfix/{bug-id}` → `main`
-
-## Commit Scope
-- Source code: {N} files (minimal fix)
-- .vsaf/docs/: {M} files (hotfix artifacts)
-- Excluded: graphify-out/, .gitnexus/ (local index)
-
-## Final Status
-- Build: PASS
-- Tests: all GREEN (including regression test)
-- PRD Gate: APPROVED
-
-## Bug Fix Summary
-- Root cause: {from 01-analysis.md}
-- Regression test: {test file}:{test name}
-- Fix: {minimal diff description}
-
-## Artifacts
-- `01-analysis.md` — root cause analysis
-- `02-prd.md` — fix requirements (approved)
-- `03-impl-log.md` — TDD implementation log
-- `04-ship.md` — this file
-
-## Post-pull Setup
-After pulling the code, run:
-- `npx gitnexus analyze` — re-index code
-- `/graphify` — rebuild knowledge graph
-```
-
-```
-[HOTFIX-SHIP] [5/5] Writing ship report... ✅
-```
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-```
-═══════════════════════════════════════════
-  HOTFIX SHIPPED: {bug-id}
-═══════════════════════════════════════════
-  Flow: Analyze → PRD → Implement → Ship
-  
-  PR: #{number} — {url}
-  Branch: hotfix/{bug-id}
-  Commit: source code + .vsaf/docs/ only
-  Excluded: graphify-out/, .gitnexus/
-  
-  Artifacts: .vsaf/docs/hotfixes/{bug-id}/ (4 files)
-  
-  Hotfix DONE.
-═══════════════════════════════════════════
-```
-
-Update `.vsaf/docs/STATUS.md` → move to "Completed Hotfixes".
-
-## Rules
-
-- ⛔ Do NOT review code — that happened during TDD (self-review via SonarQube)
-- ⛔ Do NOT commit `graphify-out/` or `.gitnexus/`
-- ⛔ Do NOT ship if tests are failing
-- ⛔ Do NOT ship without PRD Gate: APPROVED
-- Gate comes from PRD approval — no separate review phase needed
-- PR description MUST be self-contained
-- Commit message follows conventional format: `fix({area}): {description}`