@ngocsangairvds/vsaf 3.2.16 → 4.0.1

package/tools/skills/bmad-validate-prd/data/prd-purpose.md

@@ -1,197 +0,0 @@
-# BMAD PRD Purpose
-
-**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw BMad Method.**
-
----
-
-## What is a BMAD PRD?
-
-A dual-audience document serving:
-1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
-2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
-
-Each successive document becomes more AI-tailored and granular.
-
----
-
-## Core Philosophy: Information Density
-
-**High Signal-to-Noise Ratio**
-
-Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
-
-**Anti-Patterns (Eliminate These):**
-- ❌ "The system will allow users to..." → ✅ "Users can..."
-- ❌ "It is important to note that..." → ✅ State the fact directly
-- ❌ "In order to..." → ✅ "To..."
-- ❌ Conversational filler and padding → ✅ Direct, concise statements
-
-**Goal:** Maximum information per word. Zero fluff.
-
----
-
-## The Traceability Chain
-
-**PRD starts the chain:**
-```
-Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
-```
-
-**In the PRD, establish:**
-- Vision → Success Criteria alignment
-- Success Criteria → User Journey coverage
-- User Journey → Functional Requirement mapping
-- All requirements traceable to user needs
-
-**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
-
----
-
-## What Makes Great Functional Requirements?
-
-### FRs are Capabilities, Not Implementation
-
-**Good FR:** "Users can reset their password via email link"
-**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
-
-**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
-**Bad FR:** "Fast loading time" (subjective, unmeasurable)
-
-### SMART Quality Criteria
-
-**Specific:** Clear, precisely defined capability
-**Measurable:** Quantifiable with test criteria
-**Attainable:** Realistic within constraints
-**Relevant:** Aligns with business objectives
-**Traceable:** Links to source (executive summary or user journey)
-
-### FR Anti-Patterns
-
-**Subjective Adjectives:**
-- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
-- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
-
-**Implementation Leakage:**
-- ❌ Technology names, specific libraries, implementation details
-- ✅ Focus on capability and measurable outcomes
-
-**Vague Quantifiers:**
-- ❌ "multiple users", "several options", "various formats"
-- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
-
-**Missing Test Criteria:**
-- ❌ "The system shall provide notifications"
-- ✅ "The system shall send email notifications within 30 seconds of trigger event"
-
----
-
-## What Makes Great Non-Functional Requirements?
-
-### NFRs Must Be Measurable
-
-**Template:**
-```
-"The system shall [metric] [condition] [measurement method]"
-```
-
-**Examples:**
-- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
-- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
-- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
-
-### NFR Anti-Patterns
-
-**Unmeasurable Claims:**
-- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
-- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
-
-**Missing Context:**
-- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
-
----
-
-## Domain-Specific Requirements
-
-**Auto-Detect and Enforce Based on Project Context**
-
-Certain industries have mandatory requirements that must be present:
-
-- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
-- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
-- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
-- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
-
-**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
-
----
-
-## Document Structure (Markdown, Human-Readable)
-
-### Required Sections
-1. **Executive Summary** - Vision, differentiator, target users
-2. **Success Criteria** - Measurable outcomes (SMART)
-3. **Product Scope** - MVP, Growth, Vision phases
-4. **User Journeys** - Comprehensive coverage
-5. **Domain Requirements** - Industry-specific compliance (if applicable)
-6. **Innovation Analysis** - Competitive differentiation (if applicable)
-7. **Project-Type Requirements** - Platform-specific needs
-8. **Functional Requirements** - Capability contract (FRs)
-9. **Non-Functional Requirements** - Quality attributes (NFRs)
-
-### Formatting for Dual Consumption
-
-**For Humans:**
-- Clear, professional language
-- Logical flow from vision to requirements
-- Easy for stakeholders to review and approve
-
-**For LLMs:**
-- ## Level 2 headers for all main sections (enables extraction)
-- Consistent structure and patterns
-- Precise, testable language
-- High information density
-
----
-
-## Downstream Impact
-
-**How the PRD Feeds Next Artifacts:**
-
-**UX Design:**
-- User journeys → interaction flows
-- FRs → design requirements
-- Success criteria → UX metrics
-
-**Architecture:**
-- FRs → system capabilities
-- NFRs → architecture decisions
-- Domain requirements → compliance architecture
-- Project-type requirements → platform choices
-
-**Epics & Stories (created after architecture):**
-- FRs → user stories (1 FR could map to 1-3 stories potentially)
-- Acceptance criteria → story acceptance tests
-- Priority → sprint sequencing
-- Traceability → stories map back to vision
-
-**Development AI Agents:**
-- Precise requirements → implementation clarity
-- Test criteria → automated test generation
-- Domain requirements → compliance enforcement
-- Measurable NFRs → performance targets
-
----
-
-## Summary: What Makes a Great BMAD PRD?
-
-✅ **High Information Density** - Every sentence carries weight, zero fluff
-✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
-✅ **Clear Traceability** - Each requirement links to user need and business objective
-✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
-✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
-✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
-✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
-
----
-
-**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.

package/tools/skills/gitnexus/gitnexus-cli/SKILL.md

@@ -1,82 +0,0 @@
----
-name: gitnexus-cli
-description: "Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \"Index this repo\", \"Reanalyze the codebase\", \"Generate a wiki\""
----
-
-# GitNexus CLI Commands
-
-All commands work via `npx` — no global install required.
-
-## Commands
-
-### analyze — Build or refresh the index
-
-```bash
-npx gitnexus analyze
-```
-
-Run from the project root. This parses all source files, builds the knowledge graph, writes it to `.gitnexus/`, and generates CLAUDE.md / AGENTS.md context files.
-
-| Flag           | Effect                                                           |
-| -------------- | ---------------------------------------------------------------- |
-| `--force`      | Force full re-index even if up to date                           |
-| `--embeddings` | Enable embedding generation for semantic search (off by default) |
-
-**When to run:** First time in a project, after major code changes, or when `gitnexus://repo/{name}/context` reports the index is stale. In Claude Code, a PostToolUse hook runs `analyze` automatically after `git commit` and `git merge`, preserving embeddings if previously generated.
-
-### status — Check index freshness
-
-```bash
-npx gitnexus status
-```
-
-Shows whether the current repo has a GitNexus index, when it was last updated, and symbol/relationship counts. Use this to check if re-indexing is needed.
-
-### clean — Delete the index
-
-```bash
-npx gitnexus clean
-```
-
-Deletes the `.gitnexus/` directory and unregisters the repo from the global registry. Use before re-indexing if the index is corrupt or after removing GitNexus from a project.
-
-| Flag      | Effect                                            |
-| --------- | ------------------------------------------------- |
-| `--force` | Skip confirmation prompt                          |
-| `--all`   | Clean all indexed repos, not just the current one |
-
-### wiki — Generate documentation from the graph
-
-```bash
-npx gitnexus wiki
-```
-
-Generates repository documentation from the knowledge graph using an LLM. Requires an API key (saved to `~/.gitnexus/config.json` on first use).
-
-| Flag                | Effect                                    |
-| ------------------- | ----------------------------------------- |
-| `--force`           | Force full regeneration                   |
-| `--model <model>`   | LLM model (default: minimax/minimax-m2.5) |
-| `--base-url <url>`  | LLM API base URL                          |
-| `--api-key <key>`   | LLM API key                               |
-| `--concurrency <n>` | Parallel LLM calls (default: 3)           |
-| `--gist`            | Publish wiki as a public GitHub Gist      |
-
-### list — Show all indexed repos
-
-```bash
-npx gitnexus list
-```
-
-Lists all repositories registered in `~/.gitnexus/registry.json`. The MCP `list_repos` tool provides the same information.
-
-## After Indexing
-
-1. **Read `gitnexus://repo/{name}/context`** to verify the index loaded
-2. Use the other GitNexus skills (`exploring`, `debugging`, `impact-analysis`, `refactoring`) for your task
-
-## Troubleshooting
-
-- **"Not inside a git repository"**: Run from a directory inside a git repo
-- **Index is stale after re-analyzing**: Restart Claude Code to reload the MCP server
-- **Embeddings slow**: Omit `--embeddings` (it's off by default) or set `OPENAI_API_KEY` for faster API-based embedding

package/tools/skills/gitnexus/gitnexus-debugging/SKILL.md

@@ -1,89 +0,0 @@
----
-name: gitnexus-debugging
-description: "Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: \"Why is X failing?\", \"Where does this error come from?\", \"Trace this bug\""
----
-
-# Debugging with GitNexus
-
-## When to Use
-
-- "Why is this function failing?"
-- "Trace where this error comes from"
-- "Who calls this method?"
-- "This endpoint returns 500"
-- Investigating bugs, errors, or unexpected behavior
-
-## Workflow
-
-```
-1. gitnexus_query({query: "<error or symptom>"})            → Find related execution flows
-2. gitnexus_context({name: "<suspect>"})                    → See callers/callees/processes
-3. READ gitnexus://repo/{name}/process/{name}                → Trace execution flow
-4. gitnexus_cypher({query: "MATCH path..."})                 → Custom traces if needed
-```
-
-> If "Index is stale" → run `npx gitnexus analyze` in terminal.
-
-## Checklist
-
-```
-- [ ] Understand the symptom (error message, unexpected behavior)
-- [ ] gitnexus_query for error text or related code
-- [ ] Identify the suspect function from returned processes
-- [ ] gitnexus_context to see callers and callees
-- [ ] Trace execution flow via process resource if applicable
-- [ ] gitnexus_cypher for custom call chain traces if needed
-- [ ] Read source files to confirm root cause
-```
-
-## Debugging Patterns
-
-| Symptom              | GitNexus Approach                                          |
-| -------------------- | ---------------------------------------------------------- |
-| Error message        | `gitnexus_query` for error text → `context` on throw sites |
-| Wrong return value   | `context` on the function → trace callees for data flow    |
-| Intermittent failure | `context` → look for external calls, async deps            |
-| Performance issue    | `context` → find symbols with many callers (hot paths)     |
-| Recent regression    | `detect_changes` to see what your changes affect           |
-
-## Tools
-
-**gitnexus_query** — find code related to error:
-
-```
-gitnexus_query({query: "payment validation error"})
-→ Processes: CheckoutFlow, ErrorHandling
-→ Symbols: validatePayment, handlePaymentError, PaymentException
-```
-
-**gitnexus_context** — full context for a suspect:
-
-```
-gitnexus_context({name: "validatePayment"})
-→ Incoming calls: processCheckout, webhookHandler
-→ Outgoing calls: verifyCard, fetchRates (external API!)
-→ Processes: CheckoutFlow (step 3/7)
-```
-
-**gitnexus_cypher** — custom call chain traces:
-
-```cypher
-MATCH path = (a)-[:CodeRelation {type: 'CALLS'}*1..2]->(b:Function {name: "validatePayment"})
-RETURN [n IN nodes(path) | n.name] AS chain
-```
-
-## Example: "Payment endpoint returns 500 intermittently"
-
-```
-1. gitnexus_query({query: "payment error handling"})
-   → Processes: CheckoutFlow, ErrorHandling
-   → Symbols: validatePayment, handlePaymentError
-
-2. gitnexus_context({name: "validatePayment"})
-   → Outgoing calls: verifyCard, fetchRates (external API!)
-
-3. READ gitnexus://repo/my-app/process/CheckoutFlow
-   → Step 3: validatePayment → calls fetchRates (external)
-
-4. Root cause: fetchRates calls external API without proper timeout
-```

package/tools/skills/gitnexus/gitnexus-exploring/SKILL.md

@@ -1,78 +0,0 @@
----
-name: gitnexus-exploring
-description: "Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of the codebase. Examples: \"How does X work?\", \"What calls this function?\", \"Show me the auth flow\""
----
-
-# Exploring Codebases with GitNexus
-
-## When to Use
-
-- "How does authentication work?"
-- "What's the project structure?"
-- "Show me the main components"
-- "Where is the database logic?"
-- Understanding code you haven't seen before
-
-## Workflow
-
-```
-1. READ gitnexus://repos                          → Discover indexed repos
-2. READ gitnexus://repo/{name}/context             → Codebase overview, check staleness
-3. gitnexus_query({query: "<what you want to understand>"})  → Find related execution flows
-4. gitnexus_context({name: "<symbol>"})            → Deep dive on specific symbol
-5. READ gitnexus://repo/{name}/process/{name}      → Trace full execution flow
-```
-
-> If step 2 says "Index is stale" → run `npx gitnexus analyze` in terminal.
-
-## Checklist
-
-```
-- [ ] READ gitnexus://repo/{name}/context
-- [ ] gitnexus_query for the concept you want to understand
-- [ ] Review returned processes (execution flows)
-- [ ] gitnexus_context on key symbols for callers/callees
-- [ ] READ process resource for full execution traces
-- [ ] Read source files for implementation details
-```
-
-## Resources
-
-| Resource                                | What you get                                            |
-| --------------------------------------- | ------------------------------------------------------- |
-| `gitnexus://repo/{name}/context`        | Stats, staleness warning (~150 tokens)                  |
-| `gitnexus://repo/{name}/clusters`       | All functional areas with cohesion scores (~300 tokens) |
-| `gitnexus://repo/{name}/cluster/{name}` | Area members with file paths (~500 tokens)              |
-| `gitnexus://repo/{name}/process/{name}` | Step-by-step execution trace (~200 tokens)              |
-
-## Tools
-
-**gitnexus_query** — find execution flows related to a concept:
-
-```
-gitnexus_query({query: "payment processing"})
-→ Processes: CheckoutFlow, RefundFlow, WebhookHandler
-→ Symbols grouped by flow with file locations
-```
-
-**gitnexus_context** — 360-degree view of a symbol:
-
-```
-gitnexus_context({name: "validateUser"})
-→ Incoming calls: loginHandler, apiMiddleware
-→ Outgoing calls: checkToken, getUserById
-→ Processes: LoginFlow (step 2/5), TokenRefresh (step 1/3)
-```
-
-## Example: "How does payment processing work?"
-
-```
-1. READ gitnexus://repo/my-app/context       → 918 symbols, 45 processes
-2. gitnexus_query({query: "payment processing"})
-   → CheckoutFlow: processPayment → validateCard → chargeStripe
-   → RefundFlow: initiateRefund → calculateRefund → processRefund
-3. gitnexus_context({name: "processPayment"})
-   → Incoming: checkoutHandler, webhookHandler
-   → Outgoing: validateCard, chargeStripe, saveTransaction
-4. Read src/payments/processor.ts for implementation details
-```

package/tools/skills/gitnexus/gitnexus-guide/SKILL.md

@@ -1,64 +0,0 @@
----
-name: gitnexus-guide
-description: "Use when the user asks about GitNexus itself — available tools, how to query the knowledge graph, MCP resources, graph schema, or workflow reference. Examples: \"What GitNexus tools are available?\", \"How do I use GitNexus?\""
----
-
-# GitNexus Guide
-
-Quick reference for all GitNexus MCP tools, resources, and the knowledge graph schema.
-
-## Always Start Here
-
-For any task involving code understanding, debugging, impact analysis, or refactoring:
-
-1. **Read `gitnexus://repo/{name}/context`** — codebase overview + check index freshness
-2. **Match your task to a skill below** and **read that skill file**
-3. **Follow the skill's workflow and checklist**
-
-> If step 1 warns the index is stale, run `npx gitnexus analyze` in the terminal first.
-
-## Skills
-
-| Task                                         | Skill to read       |
-| -------------------------------------------- | ------------------- |
-| Understand architecture / "How does X work?" | `gitnexus-exploring`         |
-| Blast radius / "What breaks if I change X?"  | `gitnexus-impact-analysis`   |
-| Trace bugs / "Why is X failing?"             | `gitnexus-debugging`         |
-| Rename / extract / split / refactor          | `gitnexus-refactoring`       |
-| Tools, resources, schema reference           | `gitnexus-guide` (this file) |
-| Index, status, clean, wiki CLI commands      | `gitnexus-cli`               |
-
-## Tools Reference
-
-| Tool             | What it gives you                                                        |
-| ---------------- | ------------------------------------------------------------------------ |
-| `query`          | Process-grouped code intelligence — execution flows related to a concept |
-| `context`        | 360-degree symbol view — categorized refs, processes it participates in  |
-| `impact`         | Symbol blast radius — what breaks at depth 1/2/3 with confidence         |
-| `detect_changes` | Git-diff impact — what do your current changes affect                    |
-| `rename`         | Multi-file coordinated rename with confidence-tagged edits               |
-| `cypher`         | Raw graph queries (read `gitnexus://repo/{name}/schema` first)           |
-| `list_repos`     | Discover indexed repos                                                   |
-
-## Resources Reference
-
-Lightweight reads (~100-500 tokens) for navigation:
-
-| Resource                                       | Content                                   |
-| ---------------------------------------------- | ----------------------------------------- |
-| `gitnexus://repo/{name}/context`               | Stats, staleness check                    |
-| `gitnexus://repo/{name}/clusters`              | All functional areas with cohesion scores |
-| `gitnexus://repo/{name}/cluster/{clusterName}` | Area members                              |
-| `gitnexus://repo/{name}/processes`             | All execution flows                       |
-| `gitnexus://repo/{name}/process/{processName}` | Step-by-step trace                        |
-| `gitnexus://repo/{name}/schema`                | Graph schema for Cypher                   |
-
-## Graph Schema
-
-**Nodes:** File, Function, Class, Interface, Method, Community, Process
-**Edges (via CodeRelation.type):** CALLS, IMPORTS, EXTENDS, IMPLEMENTS, DEFINES, MEMBER_OF, STEP_IN_PROCESS
-
-```cypher
-MATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: "myFunc"})
-RETURN caller.name, caller.filePath
-```

package/tools/skills/gitnexus/gitnexus-impact-analysis/SKILL.md

@@ -1,97 +0,0 @@
----
-name: gitnexus-impact-analysis
-description: "Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: \"Is it safe to change X?\", \"What depends on this?\", \"What will break?\""
----
-
-# Impact Analysis with GitNexus
-
-## When to Use
-
-- "Is it safe to change this function?"
-- "What will break if I modify X?"
-- "Show me the blast radius"
-- "Who uses this code?"
-- Before making non-trivial code changes
-- Before committing — to understand what your changes affect
-
-## Workflow
-
-```
-1. gitnexus_impact({target: "X", direction: "upstream"})  → What depends on this
-2. READ gitnexus://repo/{name}/processes                   → Check affected execution flows
-3. gitnexus_detect_changes()                               → Map current git changes to affected flows
-4. Assess risk and report to user
-```
-
-> If "Index is stale" → run `npx gitnexus analyze` in terminal.
-
-## Checklist
-
-```
-- [ ] gitnexus_impact({target, direction: "upstream"}) to find dependents
-- [ ] Review d=1 items first (these WILL BREAK)
-- [ ] Check high-confidence (>0.8) dependencies
-- [ ] READ processes to check affected execution flows
-- [ ] gitnexus_detect_changes() for pre-commit check
-- [ ] Assess risk level and report to user
-```
-
-## Understanding Output
-
-| Depth | Risk Level       | Meaning                  |
-| ----- | ---------------- | ------------------------ |
-| d=1   | **WILL BREAK**   | Direct callers/importers |
-| d=2   | LIKELY AFFECTED  | Indirect dependencies    |
-| d=3   | MAY NEED TESTING | Transitive effects       |
-
-## Risk Assessment
-
-| Affected                       | Risk     |
-| ------------------------------ | -------- |
-| <5 symbols, few processes      | LOW      |
-| 5-15 symbols, 2-5 processes    | MEDIUM   |
-| >15 symbols or many processes  | HIGH     |
-| Critical path (auth, payments) | CRITICAL |
-
-## Tools
-
-**gitnexus_impact** — the primary tool for symbol blast radius:
-
-```
-gitnexus_impact({
-  target: "validateUser",
-  direction: "upstream",
-  minConfidence: 0.8,
-  maxDepth: 3
-})
-
-→ d=1 (WILL BREAK):
-  - loginHandler (src/auth/login.ts:42) [CALLS, 100%]
-  - apiMiddleware (src/api/middleware.ts:15) [CALLS, 100%]
-
-→ d=2 (LIKELY AFFECTED):
-  - authRouter (src/routes/auth.ts:22) [CALLS, 95%]
-```
-
-**gitnexus_detect_changes** — git-diff based impact analysis:
-
-```
-gitnexus_detect_changes({scope: "staged"})
-
-→ Changed: 5 symbols in 3 files
-→ Affected: LoginFlow, TokenRefresh, APIMiddlewarePipeline
-→ Risk: MEDIUM
-```
-
-## Example: "What breaks if I change validateUser?"
-
-```
-1. gitnexus_impact({target: "validateUser", direction: "upstream"})
-   → d=1: loginHandler, apiMiddleware (WILL BREAK)
-   → d=2: authRouter, sessionManager (LIKELY AFFECTED)
-
-2. READ gitnexus://repo/my-app/processes
-   → LoginFlow and TokenRefresh touch validateUser
-
-3. Risk: 2 direct callers, 2 processes = MEDIUM
-```