@ngocsangairvds/vsaf 5.1.4 → 5.1.6

package/skills/sdlc/implement/subagents/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: sdlc-implement-subagents
+description: "Implement 2/8 — subagent setup"
+version: 1.0.0
+author: "@ngocsangairvds/vsaf"
+---
+
+# Implement 2/8 — subagent setup
+
+@include(step.md)

package/skills/sdlc/implement/subagents/step.md

@@ -0,0 +1,38 @@
+## Subagent-Driven Development Protocol
+
+```
+[IMPLEMENT] [2/8] Initializing subagent-driven development... ⏳
+```
+
+**MANDATORY** — Check and activate `/superpowers:subagent-driven-development`:
+1. If not already in subagent mode → **switch immediately**
+2. Analyze `04-epics.md` → identify Conflict Map
+3. Dispatch each epic/story as a separate subagent running in parallel
+4. Each subagent follows the Conflict Map — only modify files assigned to its epic
+
+```
+[IMPLEMENT] [2/8] Initializing subagent-driven development... ✅
+```
+
+## SonarQube Quality Gate — Apply DURING Coding
+
+⚠️ **DO NOT wait for review phase.** Each subagent MUST self-check the `sonar-viettel` gate WHILE writing code.
+
+> **Standard (single source of truth):** **`.claude/skills/_shared/sdlc/sonar-viettel/quality-gate.md`** — full New Code + Overall Code tables, the 357-rule parameters, and the importable `sonar-viettel-profile.xml` / `sonar-viettel-gate.json`. **Read it.** Phase 7 (`/sdlc-review`) re-checks the **same** file — anything that passes here must pass there. Do NOT invent stricter or looser values.
+
+**Hard fails to self-check (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.
+- Honour the parametrised rules — S107 (params), S3776 (complexity), S110 (inheritance), S1479 (switch), S1192 (literals), S2068/S2077 (secrets/injection), S100/S101/S115 (naming). **Thresholds live authoritatively in the profile XML** — derive them via the snippet in the shared `quality-gate.md`, do not memorise numbers.
+
+**How to apply during coding:**
+- **After each function** → self-review: security vulnerabilities? code smells? duplication?
+- **After each class** → check SOLID violations, naming conventions, interface segregation
+- **Before each commit** → scan changed files for: SQL injection, XSS, command injection, hardcoded secrets, null dereference, resource leaks, concurrency issues, duplicated blocks
+- **Auto-detect SonarQube:** check whether `sonar-scanner` is on PATH.
+  - Present → import the profile + gate from the shared folder, then run `sonar-scanner` incremental.
+  - Absent → print `Sonar not found → self-checklist mode` and self-review against the shared `quality-gate.md`. This is a fully supported path, not a fallback to apologise for — SonarQube is OPTIONAL.
+
+**Goal:** Review phase should only need to RE-CHECK, not find bugs for the first time.
+
+## Tasks

package/skills/sdlc/implement/tdd/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: sdlc-implement-tdd
+description: "Implement 4/8 — TDD cycle"
+version: 1.0.0
+author: "@ngocsangairvds/vsaf"
+---
+
+# Implement 4/8 — TDD cycle
+
+@include(step.md)

package/skills/sdlc/implement/tdd/step.md

@@ -0,0 +1,24 @@
+### Step 4: TDD Cycle (per subagent)
+
+```
+[IMPLEMENT] [4/8] TDD cycle — RED → GREEN → REFACTOR... ⏳
+```
+
+Use `/superpowers:test-driven-development`:
+
+For each test case in `06-testcases.md`:
+1. **RED**: Write test → run → MUST FAIL
+2. **GREEN**: Write minimal code → run → MUST PASS
+   - ⚠️ **While writing GREEN code** → apply SonarQube rules immediately:
+     - Do not create security vulnerabilities
+     - No code smells (long method, deep nesting)
+     - No duplicated code
+     - Null-safe, proper error handling
+3. **REFACTOR**: Clean code, do not change behavior
+   - Refactor MUST improve SonarQube metrics, not degrade them
+
+Use `/superpowers:executing-plans` — execute plan in order.
+
+```
+[IMPLEMENT] [4/8] TDD cycle — RED → GREEN → REFACTOR... ✅
+```

package/skills/sdlc/init/SKILL.md

@@ -23,6 +23,13 @@ Icon: `⏳` running, `✅` done, `❌` error.
 
 > ⛔ DO NOT modify `graphify-out/` or `.gitnexus/` — only READ and DO NOT write to these directories.
 
+## Artifact Write Boundary
+
+- Create generated knowledge, documentation, SDLC artifacts, reports, and agent-readable markdown only at the project root beside `.vsaf` or inside the root `.vsaf/` directory.
+- Do NOT create `docs/`, `.vsaf/`, `CONTEXT.md`, `AGENTS.md`, knowledge files, reports, or generated artifacts inside service/subproject folders.
+- For service-specific notes, write under root `.vsaf/docs/` using the service name in the path or filename.
+- Write inside a service/subproject folder only when the user explicitly authorizes that path, or when the task is a source-code/test change for that service.
+
 ## Input
 
 - Project path: `$ARGUMENTS` (or current directory)

package/skills/sdlc/onboard-code/SKILL.md

@@ -21,6 +21,13 @@ Icon: `⏳` running, `✅` done, `❌` error.
 
 > ⛔ DO NOT modify `graphify-out/` or `.gitnexus/` — only GitNexus tools are allowed to write to `.gitnexus/`.
 
+## Artifact Write Boundary
+
+- Create generated knowledge, documentation, SDLC artifacts, reports, and agent-readable markdown only at the project root beside `.vsaf` or inside the root `.vsaf/` directory.
+- Do NOT create `docs/`, `.vsaf/`, `CONTEXT.md`, `AGENTS.md`, knowledge files, reports, or generated artifacts inside service/subproject folders.
+- For service-specific notes, write under root `.vsaf/docs/` using the service name in the path or filename.
+- Write inside a service/subproject folder only when the user explicitly authorizes that path, or when the task is a source-code/test change for that service.
+
 ## Clear Responsibility Assignment
 
 | Tool | Scope | Notes |

package/skills/sdlc/onboard-docs/SKILL.md

@@ -22,6 +22,13 @@ Icon: `⏳` running, `✅` done, `❌` error.
 > ⛔ DO NOT modify `graphify-out/` or `.gitnexus/` DIRECTLY — only graphify is allowed to write to `graphify-out/`.
 > **Exception:** Phase 3 supplements nodes/edges directly into `graph.json` after graphify has built it — this is the only permitted direct modification.
 
+## Artifact Write Boundary
+
+- Create generated knowledge, documentation, SDLC artifacts, reports, and agent-readable markdown only at the project root beside `.vsaf` or inside the root `.vsaf/` directory.
+- Do NOT create `docs/`, `.vsaf/`, `CONTEXT.md`, `AGENTS.md`, knowledge files, reports, or generated artifacts inside service/subproject folders.
+- For service-specific notes, write under root `.vsaf/docs/` using the service name in the path or filename.
+- Write inside a service/subproject folder only when the user explicitly authorizes that path, or when the task is a source-code/test change for that service.
+
 ## Input
 
 - Project path: `$ARGUMENTS` (or current directory)

package/skills/sdlc/pack.yaml

@@ -2,6 +2,7 @@ name: sdlc
 version: 1.2.0
 description: Distributed Agentic SDLC — multi-machine, multi-repo, graph-based knowledge
 author: "@ngocsangairvds/vsaf"
+workflows: ../../workflows/sdlc
 
 skills:
   # Setup
@@ -13,24 +14,91 @@ skills:
   - onboard-code
 
   # Phase 1-9 — Main flow
-  - discovery
-  - prd
-  - architecture
-  - srs
   - write-srs
   - validate-srs
-  - test-design
-  - implement
-  - review
-  - feature-complete
-  - ship
 
-  # Hotfix flow
-  - hotfix-analyze
-  - hotfix-prd
-  - hotfix-implement
-  - hotfix-ship
-  - hotfix-review
+  # Hotfix step skills — generated from hotfix phase SKILL.md files
+  - hotfix/analyze/entry
+  - hotfix/analyze/grill
+  - hotfix/analyze/gitnexus
+  - hotfix/analyze/reasoning
+  - hotfix/analyze/fix-strategy
+  - hotfix/analyze/write
+  - hotfix/analyze/exit
+  - hotfix/prd/entry
+  - hotfix/prd/requirements
+  - hotfix/prd/validate
+  - hotfix/prd/write
+  - hotfix/prd/gate
+  - hotfix/implement/entry
+  - hotfix/implement/branch
+  - hotfix/implement/tdd
+  - hotfix/implement/sonar
+  - hotfix/implement/verify
+  - hotfix/implement/impact
+  - hotfix/implement/gate
+  - hotfix/review/entry
+  - hotfix/review/minimality
+  - hotfix/review/test-quality
+  - hotfix/review/impact
+  - hotfix/review/gate
+  - hotfix/ship/entry
+  - hotfix/ship/gitignore
+  - hotfix/ship/test-gate
+  - hotfix/ship/commit-pr
+  - hotfix/ship/report
+  - hotfix/ship/exit
+
+
+# Phase step skills — generated from phase SKILL.md files
+  - discovery/prereq
+  - discovery/system
+  - discovery/grill
+  - discovery/brainstorm
+  - discovery/domain
+  - discovery/prfaq
+  - prd/prereq
+  - prd/elicitation
+  - prd/create
+  - prd/validate
+  - prd/blast-radius
+  - architecture/prereq
+  - architecture/current-state
+  - architecture/grill
+  - architecture/decision
+  - architecture/epics
+  - architecture/readiness
+  - srs/prereq
+  - srs/write
+  - srs/validate
+  - srs/interface
+  - test-design/prereq
+  - test-design/cases
+  - test-design/boundary
+  - test-design/coverage
+  - implement/prereq
+  - implement/subagents
+  - implement/plan
+  - implement/checkpoint
+  - implement/tdd
+  - implement/debug
+  - implement/impact
+  - implement/build-run
+  - review/prereq
+  - review/verification
+  - review/code
+  - review/impact
+  - review/debate
+  - complete/prereq
+  - complete/context
+  - complete/knowledge
+  - complete/reindex
+  - complete/status
+  - ship/prereq
+  - ship/gitignore
+  - ship/commit
+  - ship/pr
+  - ship/report
 
   # Diagnostics
   - sdlc-health
@@ -62,4 +130,3 @@ bundled:
   - zoom-out
   - tdd
   - improve-codebase-architecture
-

package/skills/sdlc/prd/blast-radius/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: sdlc-prd-blast-radius
+description: "PRD 5/5 — blast radius + output"
+version: 1.0.0
+author: "@ngocsangairvds/vsaf"
+---
+
+# PRD 5/5 — blast radius + output
+
+@include(step.md)

package/skills/sdlc/prd/blast-radius/step.md

@@ -0,0 +1,76 @@
+### 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/prd/create/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: sdlc-prd-create
+description: "PRD 3/5 — create PRD"
+version: 1.0.0
+author: "@ngocsangairvds/vsaf"
+---
+
+# PRD 3/5 — create PRD
+
+@include(step.md)

package/skills/sdlc/prd/create/step.md

@@ -0,0 +1,21 @@
+### 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... ✅
+```

package/skills/sdlc/prd/elicitation/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: sdlc-prd-elicitation
+description: "PRD 2/5 — elicitation"
+version: 1.0.0
+author: "@ngocsangairvds/vsaf"
+---
+
+# PRD 2/5 — elicitation
+
+@include(step.md)

package/skills/sdlc/prd/elicitation/step.md

@@ -0,0 +1,12 @@
+### 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... ✅
+```

package/skills/sdlc/prd/prereq/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: sdlc-prd-prereq
+description: "PRD 1/5 — prerequisites"
+version: 1.0.0
+author: "@ngocsangairvds/vsaf"
+---
+
+# PRD 1/5 — prerequisites
+
+@include(step.md)

package/skills/sdlc/prd/prereq/step.md

@@ -0,0 +1,16 @@
+## 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... ✅
+```

package/skills/sdlc/prd/validate/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: sdlc-prd-validate
+description: "PRD 4/5 — validate + adversarial review"
+version: 1.0.0
+author: "@ngocsangairvds/vsaf"
+---
+
+# PRD 4/5 — validate + adversarial review
+
+@include(step.md)

package/skills/sdlc/prd/validate/step.md

@@ -0,0 +1,24 @@
+### 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... ✅
+```

package/skills/sdlc/review/code/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: sdlc-review-code
+description: "Review 3/5 — code review + quality gate"
+version: 1.0.0
+author: "@ngocsangairvds/vsaf"
+---
+
+# Review 3/5 — code review + quality gate
+
+@include(step.md)

package/skills/sdlc/review/code/step.md

@@ -0,0 +1,45 @@
+### 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... ✅
+```

package/skills/sdlc/review/debate/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: sdlc-review-debate
+description: "Review 5/5 — debate + output"
+version: 1.0.0
+author: "@ngocsangairvds/vsaf"
+---
+
+# Review 5/5 — debate + output
+
+@include(step.md)

package/skills/sdlc/review/debate/step.md

@@ -0,0 +1,84 @@
+### 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/review/impact/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: sdlc-review-impact
+description: "Review 4/5 — impact assessment"
+version: 1.0.0
+author: "@ngocsangairvds/vsaf"
+---
+
+# Review 4/5 — impact assessment
+
+@include(step.md)

package/skills/sdlc/review/impact/step.md

@@ -0,0 +1,14 @@
+### 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... ✅
+```

package/skills/sdlc/review/prereq/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: sdlc-review-prereq
+description: "Review 1/5 — prerequisites"
+version: 1.0.0
+author: "@ngocsangairvds/vsaf"
+---
+
+# Review 1/5 — prerequisites
+
+@include(step.md)