@ngocsangairvds/vsaf 3.0.0

package/.claude/skills/openspec-explore/SKILL.md

@@ -0,0 +1,288 @@
+---
+name: openspec-explore
+description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.3.0"
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│      ┌────────┐         ┌────────┐      │
+│      │ State  │────────▶│ State  │      │
+│      │   A    │         │   B    │      │
+│      └────────┘         └────────┘      │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+    | Insight Type               | Where to Capture               |
+    |----------------------------|--------------------------------|
+    | New requirement discovered | `specs/<capability>/spec.md` |
+    | Requirement changed        | `specs/<capability>/spec.md` |
+    | Design decision made       | `design.md`                  |
+    | Scope changed              | `proposal.md`                |
+    | New work identified        | `tasks.md`                   |
+    | Assumption invalidated     | Relevant artifact              |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Handling Different Entry Points
+
+**User brings a vague idea:**
+```
+User: I'm thinking about adding real-time collaboration
+
+You: Real-time collab is a big space. Let me think about this...
+
+      COLLABORATION SPECTRUM
+      ════════════════════════════════════════════
+
+      Awareness          Coordination         Sync
+          │                   │                 │
+          ▼                   ▼                 ▼
+      ┌────────┐         ┌────────┐        ┌────────┐
+      │Presence│         │Cursors │        │  CRDT  │
+      │  "3    │         │ Multi  │        │Conflict│
+      │online" │         │ select │        │  free  │
+      └────────┘         └────────┘        └────────┘
+          │                   │                 │
+       trivial            moderate           complex
+
+      Where's your head at?
+```
+
+**User brings a specific problem:**
+```
+User: The auth system is a mess
+
+You: [reads codebase]
+
+     ┌─────────────────────────────────────────────┐
+     │              CURRENT AUTH FLOW              │
+     └─────────────────────────────────────────────┘
+                        │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  Session  │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   Perms   │
+                  └───────────┘
+
+     I see three tangles. Which one's burning?
+```
+
+**User is stuck mid-implementation:**
+```
+User: /opsx:explore add-auth-system
+      The OAuth integration is more complex than expected
+
+You: [reads change artifacts]
+
+     You're on task 4: "Implement OAuth flow"
+
+     Let me trace what's involved...
+
+     [draws diagram, explores options, suggests paths]
+
+     Want to update the design to reflect this?
+     Or add a spike task to investigate?
+```
+
+**User wants to compare options:**
+```
+User: Should we use Postgres or SQLite?
+
+You: Generic answer is boring. What's the context?
+
+User: A CLI tool that tracks local dev environments
+
+You: That changes everything.
+
+     ┌─────────────────────────────────────────────────┐
+     │          CLI TOOL DATA STORAGE                  │
+     └─────────────────────────────────────────────────┘
+
+     Key constraints:
+     • No daemon running
+     • Must work offline
+     • Single user
+
+                  SQLite          Postgres
+     Deployment   embedded ✓      needs server ✗
+     Offline      yes ✓           no ✗
+     Single file  yes ✓           no ✗
+
+     SQLite. Not even close.
+
+     Unless... is there a sync component?
+```
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When it feels like things are crystallizing, you might summarize:
+
+```
+## What We Figured Out
+
+**The problem**: [crystallized understanding]
+
+**The approach**: [if one emerged]
+
+**Open questions**: [if any remain]
+
+**Next steps** (if ready):
+- Create a change proposal
+- Keep exploring: just keep talking
+```
+
+But this summary is optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own

package/.claude/skills/openspec-propose/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: openspec-propose
+description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.3.0"
+---
+
+Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next

package/.claude/skills/vsaf-build/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: vsaf-build
+description: Implement code theo tài liệu spec đã có. Dùng sau /vsaf-doc, khi PRD và spec đã được approve. Tự động đọc memory trước khi code.
+---
+
+# VSAF Build
+
+## Mục tiêu
+Implement code đúng theo spec, từng task một, với TDD — đảm bảo mỗi commit có tests pass.
+
+## Điều kiện tiên quyết
+- Đã chạy `/vsaf-doc` và có file spec trong `openspec/`
+- User đã approve plan
+
+## Các bước thực hiện
+
+### Bước 1 — Đọc memory tự động trước khi code (bắt buộc)
+Thực hiện AUTO-READ từ `.claude/skills/vsaf-memory-protocol.md` với keyword là tên module/feature sắp implement.
+
+### Bước 2 — Đọc spec
+- Đọc file spec trong `openspec/` liên quan đến feature hiện tại
+- Xác nhận task list và verification steps với user trước khi bắt đầu
+
+### Bước 3 — Implement từng task (TDD)
+Với mỗi task trong spec:
+1. **RED**: Viết test trước, chạy test → phải fail
+2. **GREEN**: Viết code tối thiểu để test pass
+3. **REFACTOR**: Clean up code, giữ test vẫn pass
+4. Chạy `mcp__gitnexus__detect_changes` để verify chỉ đúng files thay đổi
+5. Chạy `/opsx:verify` để check task đúng spec
+6. Commit: `git commit -m "feat: <task description>"`
+
+### Bước 4 — ECC (tự động)
+- ECC hooks chạy tự động — không cần gọi thủ công
+- Nếu bị block: đọc message, không dùng `--no-verify` để bypass
+
+### Bước 5 — Xử lý khi fail
+- Fail 1-2 lần: thử approach khác
+- Fail 3 lần cùng 1 task: DỪNG, báo user, quay lại `/vsaf-plan`
+
+### Bước 6 — Output sau mỗi task
+```
+✓ Task [N]: [tên task]
+  - Files changed: [danh sách]
+  - Tests: [X passed]
+  - Commit: [hash]
+```
+
+## Lưu ý
+- 1 commit = 1 task, không gộp nhiều tasks vào 1 commit
+- Không sửa file ngoài scope của task hiện tại
+- Sau khi hoàn thành tất cả tasks: chạy `/vsaf-test` để viết tài liệu test

package/.claude/skills/vsaf-doc/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: vsaf-doc
+description: Viết tài liệu plan cho feature đã được phân tích. Dùng sau /vsaf-plan, khi đã có scope và approach rõ ràng, cần chuyển thành tài liệu có cấu trúc với task list atomic.
+---
+
+# VSAF Doc
+
+## Mục tiêu
+Chuyển kết quả plan thành tài liệu chính thức: PRD, spec proposal, và task list có verification step.
+
+## Điều kiện tiên quyết
+Phải đã chạy `/vsaf-plan` và có output trước khi chạy skill này.
+
+## Các bước thực hiện
+
+### Bước 0 — Đọc memory tự động
+Thực hiện AUTO-READ từ `.claude/skills/vsaf-memory-protocol.md` với keyword từ feature hiện tại.
+
+### Bước 1 — Sinh PRD (BMAD pm)
+- Dùng skill `bmad-agent-pm` để tạo PRD từ kết quả plan
+- PRD phải bao gồm: FRs, NFRs, Epics, User Stories
+- Lưu vào `docs/` theo cấu trúc project
+
+### Bước 2 — Tạo spec proposal (OpenSpec)
+- Dùng skill `opsx:propose` với tên feature
+- OpenSpec sẽ tạo task list atomic (mỗi task 2-5 phút)
+- Mỗi task PHẢI có verification step rõ ràng
+- Lưu vào `openspec/`
+
+### Bước 3 — Fast-forward docs (OpenSpec)
+- Dùng skill `opsx:explore` để sync tất cả docs liên quan
+- Đảm bảo không có inconsistency giữa PRD và spec
+
+### Bước 4 — Chi tiết hoá task list (Superpowers)
+- Dùng skill `superpowers:writing-plans` để review và làm rõ task list
+- Kiểm tra: mỗi task có đủ context để implement không?
+- Kiểm tra: verification step có đo lường được không?
+
+### Bước 5 — Lưu architecture decision (MemPalace)
+- Gọi `mcp__mempalace__mempalace_add_drawer` để lưu decision quan trọng
+- Nội dung: approach được chọn, lý do, alternatives đã bỏ qua
+
+### Bước 6 — Output cho user
+Thông báo các file đã tạo:
+
+```
+## Tài liệu đã tạo
+
+### PRD
+- docs/[feature]-prd.md
+
+### Spec
+- openspec/[feature]-spec.md
+  - [X] tasks, mỗi task có verification step
+
+### Architecture Decision
+- Đã lưu vào MemPalace
+
+## Next step
+Chạy /vsaf-build để bắt đầu implement
+```
+
+## Lưu ý
+- Không bắt đầu code trong bước này
+- Nếu task list quá dài (>10 tasks): đề nghị split thành nhiều PRs
+- Commit docs trước khi chuyển sang build: `git commit -m "spec: <feature>"`

package/.claude/skills/vsaf-memory-protocol.md

@@ -0,0 +1,51 @@
+# VSAF Memory Protocol
+
+Đây là protocol chung được tất cả vsaf skills sử dụng.
+Thực hiện tự động — không cần user nhắc.
+
+---
+
+## AUTO-READ (thực hiện ở đầu mỗi skill)
+
+Thực hiện tuần tự, không bỏ qua:
+
+1. **claude-mem** — kiểm tra session context đã sẵn sàng:
+   - Nếu có `$ARGUMENTS`: search claude-mem với keyword từ arguments
+   - Dùng `mcp__plugin_claude-mem_mcp-search__search` nếu có thể
+
+2. **MemPalace — search theo topic**:
+   - Gọi `mcp__mempalace__mempalace_search` với keyword chính từ task/feature
+   - Gọi `mcp__mempalace__mempalace_search` với tên module/domain liên quan
+   - Gọi `mcp__mempalace__mempalace_search` với "pattern" hoặc "decision" nếu cần context rộng hơn
+
+3. **Áp dụng kết quả**:
+   - Nếu tìm thấy relevant memories: tóm tắt ngắn gọn trước khi bắt đầu ("Từ memory: team đã dùng pattern X, tránh Y")
+   - Nếu không tìm thấy: tiếp tục bình thường, không báo lỗi
+
+---
+
+## AUTO-WRITE (thực hiện ở cuối vsaf-ship và vsaf-doc)
+
+Thực hiện tuần tự sau khi task hoàn tất:
+
+1. **Diary** — ghi tóm tắt session:
+   - Gọi `mcp__mempalace__mempalace_diary_write`
+   - Nội dung: feature gì, approach nào, kết quả ra sao
+
+2. **Decisions** — lưu từng quyết định quan trọng:
+   - Với mỗi decision không hiển nhiên (pattern mới, workaround, trade-off):
+   - Gọi `mcp__mempalace__mempalace_add_drawer`
+   - Format: "Quyết định: [X]. Lý do: [Y]. Alternatives bỏ qua: [Z]"
+
+3. **Reasoning chain** — capture knowledge graph:
+   - Gọi `mcp__mempalace__mempalace_kg_add` để lưu relationships giữa các concepts
+   - Ưu tiên: gotchas phát hiện khi implement, dependencies ẩn, edge cases thực tế
+
+---
+
+## Nguyên tắc
+
+- **Đọc trước, không đoán** — dù đã biết domain, vẫn phải check memory trước
+- **Ghi decisions, không ghi code** — code ở trong repo, memory lưu lý do và context
+- **Không báo user** khi memory trống — tiếp tục bình thường
+- **Không chờ user confirm** để đọc/ghi memory — làm tự động

package/.claude/skills/vsaf-onboard/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: vsaf-onboard
+description: Hiểu toàn bộ context dự án mới. Dùng khi lần đầu tiếp nhận project, cần nắm kiến trúc, decisions cũ, và codebase trước khi làm bất cứ điều gì.
+---
+
+# VSAF Onboard
+
+## Mục tiêu
+Xây dựng full mental model về dự án trước khi chạm vào bất kỳ code nào.
+
+## Các bước thực hiện
+
+### Bước 0 — Đọc memory tự động
+Thực hiện AUTO-READ từ `.claude/skills/vsaf-memory-protocol.md` với keyword "architecture".
+
+### Bước 1 — Kiến trúc tổng thể (Graphify)
+- Đọc file `graphify-out/GRAPH_REPORT.md` nếu đã tồn tại
+- Nếu chưa có: thông báo user chạy `/graphify .` để build graph trước
+- Tóm tắt: các module chính, dependencies, entry points
+
+### Bước 2 — Code intelligence (GitNexus)
+- Dùng `mcp__gitnexus__context` để lấy codebase overview
+- Dùng `mcp__gitnexus__group_list` để xem các functional clusters
+- Tóm tắt: execution flows quan trọng, symbols có nhiều dependencies nhất
+
+### Bước 3 — Decisions cũ (MemPalace)
+- Gọi `mcp__mempalace__mempalace_search` với query "architecture"
+- Gọi `mcp__mempalace__mempalace_search` với query "decision"
+- Gọi `mcp__mempalace__mempalace_search` với query "pattern"
+- Tóm tắt: các quyết định kiến trúc quan trọng team đã đưa ra
+
+### Bước 4 — Output cho user
+Trình bày tóm tắt theo format:
+
+```
+## Project Overview
+[Mô tả ngắn về dự án]
+
+## Kiến trúc
+[Các layer/module chính và quan hệ]
+
+## Patterns đang dùng
+[Tech stack, design patterns, conventions]
+
+## Decisions quan trọng
+[Những gì team đã quyết định và lý do]
+
+## Cần chú ý
+[Risk areas, legacy code, known issues]
+```
+
+## Lưu ý
+- KHÔNG sửa bất kỳ file nào trong bước này
+- Nếu bộ nhớ MemPalace trống: thông báo user chạy `mempalace mine` để populate
+- Sau khi hoàn thành: gợi ý user dùng `/vsaf-plan <feature>` để bắt đầu task

package/.claude/skills/vsaf-plan/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: vsaf-plan
+description: Lên plan cho 1 feature/task mới. Dùng khi nhận được yêu cầu cần phân tích scope, impact, và chiến lược tiếp cận. Ví dụ: /vsaf-plan tạo module quản lý user
+---
+
+# VSAF Plan
+
+## Mục tiêu
+Hiểu đầy đủ yêu cầu, phân tích impact, và xác định chiến lược implement trước khi viết bất kỳ dòng code nào.
+
+## Input
+`$ARGUMENTS` — mô tả feature/task cần làm (ví dụ: "tạo module quản lý dashboard")
+
+## Các bước thực hiện
+
+### Bước 1 — Đọc memory tự động (bắt buộc)
+Thực hiện AUTO-READ từ `.claude/skills/vsaf-memory-protocol.md` với keyword từ `$ARGUMENTS`.
+
+### Bước 2 — Clarify scope (BMAD analyst)
+- Dùng skill `bmad-agent-analyst` để phân tích yêu cầu
+- Xác định: FRs, NFRs, edge cases, assumptions, out-of-scope
+- DỪNG và hỏi user nếu còn điểm chưa rõ
+
+### Bước 3 — Impact analysis (GitNexus)
+- Dùng `mcp__gitnexus__impact` với target là module/symbol liên quan
+- Dùng `mcp__gitnexus__query` để tìm code liên quan
+- Báo cáo blast radius: bao nhiêu module bị ảnh hưởng, risk level
+
+### Bước 4 — Trace dependencies (Graphify)
+- Nếu cần trace path giữa 2 services: dùng `/graphify path ServiceA ServiceB`
+- Xác định: integration points, shared dependencies
+
+### Bước 5 — Architecture decision (BMAD architect)
+- Dùng skill `bmad-agent-architect` để đề xuất architecture approach
+- So sánh alternatives, chọn approach phù hợp nhất
+
+### Bước 6 — Brainstorm (Superpowers)
+- Dùng skill `superpowers:brainstorming` để explore alternatives
+- Đặt câu hỏi Socratic: "What if...", "What could go wrong..."
+
+### Bước 7 — Output cho user
+Trình bày kết quả theo format:
+
+```
+## Feature: [tên feature]
+
+## Scope
+- In: [những gì sẽ làm]
+- Out: [những gì không làm]
+
+## Impact Analysis
+- Modules bị ảnh hưởng: [danh sách]
+- Risk level: [LOW/MEDIUM/HIGH]
+- Breaking changes: [có/không, chi tiết]
+
+## Approach được chọn
+[Mô tả architecture approach]
+
+## Alternatives đã xem xét
+[Tại sao không chọn]
+
+## Next step
+Chạy /vsaf-doc để viết tài liệu plan
+```
+
+## Lưu ý
+- Nếu Impact > 3 modules: cảnh báo user, đề nghị split thành nhiều PRs
+- Nếu risk level HIGH/CRITICAL: DỪNG, báo user trước khi tiếp tục