@ngocsangairvds/vsaf 5.1.5 → 5.1.7

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

@@ -1,198 +0,0 @@
----
-name: sdlc-hotfix-analyze
-description: "Hotfix Phase 1 — Analyze bug report via GitNexus impact + context, identify root cause and blast radius"
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Hotfix Phase 1: Analyze Bug Report
-
-You are a Senior Bug Analyst. Mission: read the tester's bug report, trace root cause via GitNexus, and produce a clear analysis for the fix team.
-
-## Language Rule
-
-Output documents (01-analysis.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-ANALYZE] [step/6] description... ⏳
-[HOTFIX-ANALYZE] [step/6] description... ✅
-```
-
-## Index Protection
-
-⛔ Do NOT modify `graphify-out/` or `.gitnexus/` — READ only.
-
-## Phase Entry Protocol
-
-```
-[HOTFIX-ANALYZE] [1/6] Reading bug report... ⏳
-```
-
-1. Input: `$ARGUMENTS` — path to bug report file from tester
-2. Read the bug report file
-3. Read `CONTEXT.md` for domain context
-4. Read `.vsaf/docs/STATUS.md`
-5. Extract a short `{bug-id}` from the report filename or title (e.g., `fix-null-rating`, `fix-auth-timeout`)
-
-```
-[HOTFIX-ANALYZE] [1/6] Reading bug report... ✅
-```
-
-## Tasks
-
-### Step 2: Grill Session — Clarify Bug Context
-
-```
-[HOTFIX-ANALYZE] [2/6] Grill session — interviewing user about bug... ⏳
-```
-
-Use `/grill-me` to interview the user about the bug. Walk down each branch of the problem tree:
-- What exactly was observed? Under what conditions?
-- Can it be reproduced consistently? What are the exact steps?
-- When did it start? What changed recently?
-- What is the expected behavior vs actual behavior?
-- Which users/environments are affected?
-- Any workarounds discovered?
-
-Continue grilling until you have a complete understanding. Then extract:
-- **Symptoms** — what the tester/user observed
-- **Reproduction steps** — exact steps to trigger the bug
-- **Expected vs actual behavior**
-- **Affected area** — which feature/module/endpoint
-
-```
-[HOTFIX-ANALYZE] [2/6] Grill session complete ✅
-```
-
-### Step 3: Root Cause via GitNexus
-
-```
-[HOTFIX-ANALYZE] [3/6] Mapping code structure via GitNexus... ⏳
-```
-
-1. Use GitNexus `context` — understand the affected module's structure and dependencies
-2. Use GitNexus `impact` — trace which files and symbols are in the blast radius
-3. Use GitNexus `route_map` — map the call chain from entry point to suspected buggy code
-4. Collect:
-   - **Affected files** — files that contain or touch the suspected area
-   - **Call chain** — entry point → intermediate → suspected defect
-   - **Blast radius** — what else could break if this area is changed
-
-```
-[HOTFIX-ANALYZE] [3/6] Mapping code structure via GitNexus... ✅
-```
-
-### Step 4: Deep Thinking — Root Cause Reasoning
-
-```
-[HOTFIX-ANALYZE] [4/6] Deep thinking — reasoning about root cause... ⏳
-```
-
-**Two approaches available — choose based on complexity:**
-
-**Option A: Full approach** — Use `/superpowers:systematic-debugging` for complex, multi-layered bugs where you need structured hypothesis testing with instrumentation.
-
-**Option B: Lean approach (mattpocock)** — Use `/diagnose` for focused bugs where the feedback loop is clear. `/diagnose` provides a disciplined 6-phase loop: build feedback loop → reproduce → hypothesise → instrument → fix → regression-test. Also use `/zoom-out` if the affected code area is unfamiliar.
-
-Regardless of approach:
-
-1. **Read the actual source code** — do NOT rely only on GitNexus metadata. Open and read every file in the call chain identified in Step 3.
-2. **Form hypotheses** — based on symptoms + code reading, list 2-3 possible root causes
-3. **Evaluate each hypothesis:**
-   - Does it explain ALL symptoms from the bug report?
-   - Does it match the reproduction steps?
-   - Is it consistent with the code structure from GitNexus?
-4. **Eliminate** — rule out hypotheses that don't explain all symptoms
-5. **Conclude** — select the most likely root cause with specific file:line reference
-6. **Propose fix strategy** — minimal approach to fix the confirmed root cause
-
-If no hypothesis explains all symptoms → the bug report may be incomplete. List what information is missing.
-
-```
-[HOTFIX-ANALYZE] [4/6] Deep thinking — reasoning about root cause... ✅
-```
-
-### Step 5: Grill Fix Strategy
-
-```
-[HOTFIX-ANALYZE] [5/6] Grill session — stress-testing fix strategy... ⏳
-```
-
-Use `/grill-me` again to stress-test the proposed fix strategy with the user:
-- Does the fix address the root cause, not just the symptom?
-- Are there edge cases the fix could miss?
-- Could the fix introduce regressions in related areas?
-- Is the fix scope appropriate for a hotfix (minimal)?
-
-```
-[HOTFIX-ANALYZE] [5/6] Fix strategy validated ✅
-```
-
-### Step 6: Write Analysis
-
-```
-[HOTFIX-ANALYZE] [6/6] Writing analysis document... ⏳
-```
-
-Create directory `.vsaf/docs/hotfixes/{bug-id}/` if it doesn't exist.
-
-Write file: `.vsaf/docs/hotfixes/{bug-id}/01-analysis.md`
-
-```markdown
-# Bug Analysis: {bug-id}
-
-## Tester Report
-{summary of bug report}
-
-## Symptoms
-{symptoms observed}
-
-## Reproduction Steps
-{reproduction steps}
-
-## Hypotheses
-| # | Hypothesis | Explains all symptoms? | Verdict |
-|---|-----------|----------------------|---------|
-| 1 | {hypothesis} | {yes/no + why} | Eliminated / Selected |
-
-## Root Cause
-{confirmed root cause — specific code defect with file:line references}
-
-## Affected Files
-| File | Role | Severity |
-|------|------|----------|
-| {file} | {role in the bug} | Direct / Indirect |
-
-## Blast Radius
-{what else could break}
-
-## Fix Strategy
-{minimal fix approach — what to change and why}
-```
-
-```
-[HOTFIX-ANALYZE] [6/6] Writing analysis document... ✅
-```
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Bug: {bug-id}
-- Status: ANALYSIS COMPLETED
-- Root cause: {one-line summary}
-- Affected files: {count} files
-- Output: `.vsaf/docs/hotfixes/{bug-id}/01-analysis.md`
-- Next step: `/sdlc-hotfix-prd`
-
-Update `.vsaf/docs/STATUS.md`.
-
-## Rules
-
-- ⛔ Do NOT modify code — analysis only
-- ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`
-- GitNexus impact analysis is MANDATORY — never skip it
-- Root cause must reference specific file:line, not vague descriptions
-- `/grill-me` is MANDATORY — used in Step 2 (clarify bug) and Step 5 (validate fix strategy)

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

@@ -1,272 +0,0 @@
----
-name: sdlc-hotfix-implement
-description: "Hotfix Phase 3 — TDD implementation: RED → GREEN → REFACTOR, minimal fix, SonarQube-in-loop"
-version: 1.0.0
-author: "@ngocsangairvds/vsaf"
----
-
-# Hotfix Phase 3: Implementation (TDD)
-
-You are a Senior Software Engineer performing a surgical fix. Mission: implement the fix using strict TDD — write failing test first, make it pass with minimal code, refactor. No subagents, no parallel epics — hotfixes are focused single-area changes.
-
-## Progress Protocol
-
-Print progress at each step:
-```
-[HOTFIX-IMPL] [step/6] description... ⏳
-[HOTFIX-IMPL] [step/6] description... ✅
-```
-
-## Index Protection
-
-⛔ Do NOT modify `graphify-out/` or `.gitnexus/` — READ only.
-
-## Phase Entry Protocol
-
-```
-[HOTFIX-IMPL] [1/6] Checking input artifacts... ⏳
-```
-
-1. Input:
-   - `.vsaf/docs/hotfixes/{bug-id}/02-prd.md`
-   - `.vsaf/docs/hotfixes/{bug-id}/01-analysis.md`
-2. Verify BOTH files exist:
-   - Missing → Stop: "Run previous phases first."
-3. Check `02-prd.md` has `## Gate: APPROVED`
-   - No Gate → Stop: "PRD not approved. Get approval first."
-4. Extract from PRD: FRs, acceptance criteria, scope boundary
-5. Extract from analysis: root cause (file:line), affected files, fix strategy
-6. Read `CONTEXT.md`
-
-```
-[HOTFIX-IMPL] [1/6] Checking input artifacts... ✅
-```
-
-## Tasks
-
-### Step 2: Branch Setup
-
-```
-[HOTFIX-IMPL] [2/6] Creating hotfix branch... ⏳
-```
-
-```bash
-git checkout -b hotfix/{bug-id}
-```
-
-If branch already exists → switch to it.
-
-```
-[HOTFIX-IMPL] [2/6] Creating hotfix branch... ✅
-```
-
-### Step 3: TDD Cycle — `/tdd` Methodology
-
-```
-[HOTFIX-IMPL] [3/6] TDD cycle — RED → GREEN → REFACTOR... ⏳
-```
-
-Use `/tdd` methodology — behavior-based, vertical slice:
-
-**For each FR in the PRD:**
-
-1. **RED — Write failing test FIRST**
-   - Test the BEHAVIOR described in the acceptance criteria
-   - Test the PUBLIC INTERFACE, not internals
-   - Include the regression test: reproduce the original bug → MUST FAIL before fix
-   - Run test → confirm it FAILS (red)
-   - ⚠️ If test passes without code changes → the test is wrong or the bug is already fixed
-
-2. **GREEN — Write MINIMAL code to pass**
-   - Change ONLY what is needed to make the test pass
-   - Stay within the scope boundary from PRD
-   - Apply SonarQube rules while writing (see below)
-   - Run test → confirm it PASSES (green)
-
-3. **REFACTOR — Clean without changing behavior**
-   - Remove duplication introduced by the fix
-   - Improve naming if needed
-   - Run ALL tests → still green
-
-**Repeat for each FR.** Typically 1-3 cycles for a hotfix.
-
-```
-[HOTFIX-IMPL] [3/6] TDD cycle complete ✅
-```
-
-### Step 4: SonarQube Self-Check
-
-```
-[HOTFIX-IMPL] [4/6] SonarQube quality check... ⏳
-```
-
-Apply DURING Step 3 (not after). After the fix is complete, final sweep.
-
-> **Standard (single source of truth):** **`.claude/skills/_shared/sdlc/sonar-viettel/quality-gate.md`** — full gate, 357-rule parameters, and the importable `sonar-viettel-profile.xml` / `sonar-viettel-gate.json`. Phase 4 (`/sdlc-hotfix-review`) re-checks the same file. A hotfix applies the gate's **New Code** conditions on changed files.
-
-| Metric | Threshold |
-|--------|-----------|
-| Issues / Blocker / Critical / Major | = 0 |
-| Code Smells (new) | = 0 — stricter than the gate's ≤20 **by design**: a surgical 1–3 line fix has no excuse to add a smell, and `/sdlc-hotfix-review` rejects any new smell |
-| Vulnerabilities | = 0 |
-| Security Hotspots Reviewed | = 100% |
-| Duplicated Lines (new) | ≤ 45% |
-| Maintainability / Reliability / Security Rating | ≥ A |
-
-**Honour the `sonar-viettel` parametrised rules in the changed code** — S107 (params), S3776 (complexity), S1192 (literals), S2068/S2077 (secrets/injection), S100/S101/S115 (naming). **Thresholds are authoritative in the profile XML** — derive them via the snippet in the shared `quality-gate.md`, do not hard-code numbers.
-
-- If project has SonarQube → import the profile + gate from the shared folder, then run `sonar-scanner` incremental
-- If not → Claude self-reviews changed files against the shared `quality-gate.md`
-
-```
-[HOTFIX-IMPL] [4/6] SonarQube quality check... ✅
-```
-
-### Step 5: Build & Test Verification
-
-```
-[HOTFIX-IMPL] [5/6] Build & test verification... ⏳
-```
-
-**MANDATORY — hard gate:**
-
-1. **Compile**: Build entire project → 0 errors
-   - Java: `mvn compile` / `gradle build`
-   - Node: `npm run build` / `tsc --noEmit`
-   - Angular: `ng build`
-   - Go: `go build ./...`
-   - FAIL → fix immediately
-
-2. **Full test suite**: Run ALL tests (not just new ones)
-   - `npm test` / `mvn test` / equivalent
-   - ALL tests MUST pass — no regressions
-   - FAIL → use `/diagnose` to find the issue
-
-3. **Regression test confirmation**: The specific test from Step 3 RED phase → now PASSES
-
-⚠️ DO NOT exit if build fails or tests fail. This is a hard gate.
-
-```
-[HOTFIX-IMPL] [5/6] Build & test verification... ✅
-```
-
-### Step 6: Impact Verification
-
-```
-[HOTFIX-IMPL] [6/6] Impact verification via GitNexus... ⏳
-```
-
-Use GitNexus `impact` — verify the fix did not break anything outside blast radius.
-
-If unexpected impact detected → evaluate:
-- Within scope boundary → OK, note in impl log
-- Outside scope boundary → STOP, escalate to user
-
-```
-[HOTFIX-IMPL] [6/6] Impact verification... ✅
-```
-
-## Verification Gate
-
-⛔ **NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE.**
-
-Before printing Phase Exit, you MUST pass ALL checks below. For each check: **run the command → read the full output → verify the claim matches the output.** Do NOT trust memory, do NOT trust previous runs, do NOT say "should pass."
-
-| # | Check | Command to Run | Evidence Required | ❌ NOT Acceptable |
-|---|-------|---------------|-------------------|-------------------|
-| 1 | Build compiles | `mvn compile` / `npm run build` / equivalent | `BUILD SUCCESS` or `0 errors` in output | "It compiled earlier" |
-| 2 | All tests pass | `npm test` / `mvn test` / equivalent | `X passed, 0 failed` in output | "Tests should still pass" |
-| 3 | Regression test passes | Run specific test by name | Test name + PASS in output | "I wrote the test so it passes" |
-| 4 | No new SonarQube issues | Check output from Step 4 | 0 blockers, 0 critical, 0 vulns | "Code looks clean" |
-| 5 | GitNexus impact clean | Check output from Step 6 | Blast radius matches analysis | "Fix is minimal so it's fine" |
-| 6 | Scope boundary held | `git diff --stat` | Changed files ⊆ files listed in analysis | "I only changed what was needed" |
-
-**Red flags — if you catch yourself thinking any of these, STOP and run the command:**
-- "It should work" → Run it and prove it
-- "I'm confident" → Confidence ≠ evidence
-- "I already checked" → Check again with fresh output
-- "It's a small change so it's safe" → Small changes break big systems
-- "The test passed during TDD" → TDD was minutes ago; verify NOW
-
-**Procedure:**
-1. Run checks 1-6 sequentially
-2. For each: paste the **actual command output** (or key lines) into `03-impl-log.md` under a `## Verification Evidence` section
-3. If ANY check fails → fix → re-run ALL checks (not just the failed one)
-4. Only after ALL 6 checks show fresh passing evidence → proceed to Phase Exit
-
-## Output
-
-Write file: `.vsaf/docs/hotfixes/{bug-id}/03-impl-log.md`
-
-```markdown
-# Implementation Log: {bug-id}
-
-## Branch
-`hotfix/{bug-id}`
-
-## TDD Cycles
-
-### FR-001: {title}
-- RED: {test file}:{test name} — FAILED ✓
-- GREEN: {changed files} — PASSED ✓
-- REFACTOR: {what was cleaned}
-
-### FR-002: {title} (if applicable)
-...
-
-## Files Changed
-| File | Change type | Lines |
-|------|-------------|-------|
-| {file} | Modified / Added | +{n} -{m} |
-
-## Test Results
-- New tests: {count}
-- Regression test: {test name} — PASS
-- Full suite: {total} tests, all PASS
-
-## SonarQube
-- Issues: 0
-- Vulnerabilities: 0
-- Duplication: {n}%
-
-## Build
-- Compile: PASS
-- Full test suite: PASS
-
-## Verification Evidence
-
-| # | Check | Result | Evidence |
-|---|-------|--------|----------|
-| 1 | Build compiles | ✅ PASS | `{actual build output line}` |
-| 2 | All tests pass | ✅ PASS | `{X} passed, 0 failed` |
-| 3 | Regression test | ✅ PASS | `{test name} — PASSED` |
-| 4 | SonarQube clean | ✅ PASS | 0 blocker, 0 critical, 0 vuln |
-| 5 | Impact clean | ✅ PASS | Blast radius = {files}, matches analysis |
-| 6 | Scope held | ✅ PASS | `git diff --stat`: {n} files changed, all within scope |
-```
-
-## Phase Exit Protocol
-
-Print PHASE REPORT:
-- Bug: {bug-id}
-- Status: IMPLEMENTATION COMPLETED
-- Branch: `hotfix/{bug-id}`
-- Tests: {new} new, {total} total — all PASS
-- Files changed: {count}
-- Output: `.vsaf/docs/hotfixes/{bug-id}/03-impl-log.md`
-- Next step: `/sdlc-hotfix-ship`
-
-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 write code without a failing test first (TDD)
-- ⛔ Do NOT modify `graphify-out/` or `.gitnexus/`
-- ⛔ Do NOT exceed scope boundary defined in PRD
-- ⛔ Do NOT use subagent-driven development — hotfixes are sequential, focused
-- Code MUST compile — hard gate, no exceptions
-- Full test suite MUST pass — no regressions allowed
-- If fix fails 3 times → STOP, escalate to user
-- If scope drift detected → STOP, go back to PRD

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