@ngocsangairvds/vsaf 3.0.12 → 3.1.1

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

@@ -0,0 +1,169 @@
+---
+name: vsaf-doc-srs
+description: Write SRS (Software Requirements Specification) from an existing PRD. Use after /vsaf-doc-prd. Follows standard BA workflow with feature-level SRS template.
+---
+
+# VSAF Doc SRS
+
+## Goal
+Analyze the PRD and write a feature-level SRS following a standard template — ensuring traceability from PRD → Use Cases → Screens → Epic/Story.
+
+**Your Role:** Professional Business Analyst — write SRS following a standard process.
+
+## Prerequisites
+- Must have run `/vsaf-doc-prd` and have an approved PRD before running this skill.
+
+## Configuration
+```yaml
+outputDir: docs/project/srs
+featureTemplate: _bmad/bmm/1-analysis/bmad-document-project/templates/srs-feature-template.md
+systemTemplate: _bmad/bmm/1-analysis/bmad-document-project/templates/srs-system-template.md
+```
+
+## Steps
+
+### Step 0 — Validate inputs
+
+Before starting, check if the user has provided sufficient information:
+
+**Required:**
+- [ ] PRD document (file path or content) — typically at `docs/project/planning-artifacts/prd-[feature].md`
+- [ ] Figma link (URL figma.com/design/...) — if available
+
+If PRD is missing, **stop immediately** and request from the user:
+
+```
+To write the SRS document, I need you to provide:
+
+[list what is missing]
+
+Please provide:
+1. PRD file: file path or paste the content here
+2. Figma link (if available): URL like https://www.figma.com/design/...
+3. Flow/Feature to write SRS for (e.g., FR-1, FR-2,...)
+```
+
+Only continue when the PRD is available.
+
+---
+
+### Step 1 — Determine mode: Create or Edit
+- Check if an SRS already exists in `docs/project/srs/` for this feature
+- **If none exists** → Mode: CREATE
+- **If one exists** → Mode: EDIT
+  - Ask user: "An SRS already exists. Do you want to create a new one from scratch or edit the existing one?"
+  - Mode EDIT: use skill `bmad-edit-prd` to edit the existing SRS
+
+---
+
+### Step 2 — Read & analyze PRD
+
+Read the entire PRD document. Extract and organize information into the following structure:
+
+**2.1 Project objectives**
+- Business objective, Problem statement, Success criteria
+
+**2.2 Scope**
+- In-scope features / Sub-FRs, Out-of-scope, Main modules/screens
+
+**2.3 Actors & Use Cases**
+- List of actors (user roles), User stories / use cases mentioned
+
+**2.4 Business Rules**
+- Key business rules, Constraints & assumptions
+
+**2.5 Non-functional Requirements**
+- Performance, security, scalability, etc. (if applicable)
+
+After this step, output a **"PRD Summary"** for user confirmation before proceeding to step 3.
+
+---
+
+### Step 3 — Compare PRD with Figma (if Figma is available)
+
+If a Figma link is available, use Figma MCP tools to read the design:
+1. Call `get_figma_data` to get the list of pages/frames
+2. Download screenshots for each main screen
+
+Compare and record:
+
+| Item | PRD states | Figma design | Status |
+|---|---|---|---|
+| [Feature/Screen] | ... | ... | Matched / Discrepancy / Unclear |
+
+**Gap analysis:**
+- **Gap 1 — Missing in Figma:** Features in PRD but not found in the design
+- **Gap 2 — Added in Figma:** UI elements in Figma but not mentioned in the PRD
+- **Gap 3 — Conflicts:** Inconsistent information between the two sources
+
+If no Figma: note "No Figma design available — UX team needs to provide" in section 2 of the SRS.
+
+After this step, output a **"Gap Analysis Report"** and ask the user if they want to clarify any gaps before writing the SRS.
+
+---
+
+### Step 4 — Write SRS following the Feature Template
+
+Read the template at `_bmad/bmm/1-analysis/bmad-document-project/templates/srs-feature-template.md` and write the SRS **strictly following the template structure**, including all 12 sections (0-11):
+
+0. **Preamble** — Document information, change log table, approval table
+1. **Introduction** — Objectives, scope, reference documents
+2. **Business Context** — Business objective, actors, use cases overview
+3. **System Overview** — High-Level Activity Diagram + Architecture
+4. **Data Model** — Entity tables, ER diagram, Kafka Events, API Endpoints
+5. **Functional Requirements** — Detailed Use Case specifications. Each UC includes:
+   - **Screens** — Detailed controls table for each screen in the UC
+   - **Business flows** — Sequence diagram (PlantUML) + Activity diagram (PlantUML, if needed)
+   - Shared screens: place the full table at the first UC, subsequent UCs reference it
+6. **State & Behavioral Models** — State diagrams (Mermaid stateDiagram-v2), entity lifecycle
+7. **Business Rules & Validation** — BR table + Validation Rules + Error Codes
+8. **NFR** — Non-functional requirements specific to the flow
+9. **Constraints** — Constraints, assumptions, dependencies, transition requirements
+10. **RTM** — Requirements Traceability Matrix: PRD FR → UC → Screen → Epic/Story → BR → AC → Test Case
+11. **Appendix** — Figma Mapping tables, Screen List, Affected features, Gap Analysis
+
+**Writing rules:**
+- Write in **English** by default unless user requests otherwise
+- Preserve business rules from the PRD, do not arbitrarily change business logic
+- Each Use Case must have: Precondition, Main flow, Alternative flow, Exception flow, Postcondition
+- Activity/Flow diagrams use Mermaid `flowchart TD`; State diagrams use `stateDiagram-v2`; ER uses `erDiagram`
+- If information is insufficient → mark as `{{TBD}}` and list in the Gap Analysis section
+
+---
+
+### Step 5 — Validate SRS (BMAD validate)
+- Use skill `bmad-validate-prd` to validate the generated/edited SRS
+- Check: Are FRs clear enough? Are NFRs measurable? Are acceptance criteria verifiable?
+- If issues found: fix immediately in the SRS, do not wait until build
+- Record validation result (PASS/FAIL + findings)
+
+---
+
+### Step 6 — Save SRS file
+Save the SRS document to: `docs/project/srs/SRS-[project-name]-[FR-ID]-[feature-name]-v1.0.md`
+
+### Step 7 — Output to user
+```
+## SRS Created/Updated
+
+### File
+- docs/project/srs/SRS-[project-name]-[FR-ID]-[feature-name]-v1.0.md
+- Mode: [CREATE / EDIT]
+- Use Cases written: [N]
+- Validation: [PASS / FAIL — details if fail]
+
+### Gaps to confirm
+- [List of important gaps that need team confirmation]
+
+### Incomplete sections
+- [SRS sections still containing {{...}} that need additional input]
+
+## Next step
+Run /vsaf-test docs/project/srs/SRS-[...].md to generate testcases
+```
+
+## Notes
+- Do not start coding in this step
+- If scope is too large (>3 modules): suggest splitting into multiple PRs
+- Commit docs: `git commit -m "docs: srs for <feature>"`
+- If mode is EDIT and existing testcases are affected: warn user to re-run `/vsaf-test`

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

@@ -1,74 +1,61 @@
 ---
 name: vsaf-docs
-description: Documentation & knowledge sync — cập nhật docs, sinh project context, build wiki. Dùng sau /vsaf-ship hoặc cuối sprint để đảm bảo knowledge không bị mất.
+description: Documentation & knowledge sync — update docs, generate project context, build wiki. Use after /vsaf-ship or at end of sprint to ensure knowledge is not lost.
 ---
 
 # VSAF Docs
 
-## Mục tiêu
-Đảm bảo documentation luôn cập nhật, AI agents có đủ context, và knowledge không bị mất giữa các session/sprint.
+## Goal
+Ensure documentation is always up to date and AI agents have sufficient context.
 
 ## Input
-`$ARGUMENTS` — scope cần document:
-- *(không có argument)* — full documentation refresh
-- `<module>` — document module cụ thể
-- `context` — chỉ sinh project-context.md
-- `wiki` — chỉ build wiki
-
-## Khi nào dùng
-- Sau mỗi sprint (batch update)
-- Sau ship feature lớn (>3 modules thay đổi)
-- Khi onboard team member mới
-- Khi AI agent gặp khó hiểu codebase
-
-## Các bước thực hiện
-
-### Bước 1 — Scan current state
-- Dùng `mcp__gitnexus__query` để scan codebase hiện tại
-- Dùng `mcp__mempalace__mempalace_search` với "decision", "architecture", "pattern"
-- So sánh: docs hiện tại vs code hiện tại — tìm docs lạc hậu
-
-### Bước 2 — Generate project documentation
-- Dùng skill `bmad-document-project` để sinh/cập nhật project docs
-- Output: mô tả architecture, module breakdown, API endpoints, data flows
-- Lưu vào `docs/project/`
-
-### Bước 3 — Generate project context for AI
-- Dùng skill `bmad-generate-project-context` để tạo `project-context.md`
-- File này = instructions cho AI agents: conventions, patterns, do/don't
-- Lưu tại root project
-
-### Bước 4 — Tech writing review
-- Dùng skill `bmad-agent-tech-writer` (Paige) để review docs vừa sinh
-- Paige sẽ: fix unclear sections, add missing context, ensure consistency
-
-### Bước 5 — Editorial polish
-- Dùng skill `bmad-editorial-review-prose` — clean up writing quality
+`$ARGUMENTS` — scope to document:
+- *(no argument)* — full documentation refresh
+- `<module>` — document a specific module
+- `context` — only generate project-context.md
+
+## When to use
+- After each sprint (batch update)
+- After shipping a large feature (>3 modules changed)
+- When onboarding a new team member
+- When an AI agent struggles to understand the codebase
+
+## Steps
+
+### Step 1 — Scan current state
+- Use `mcp__gitnexus__query` to scan the current codebase
+- Compare: current docs vs current code — find outdated docs
+
+### Step 2 — Generate project documentation
+- Use skill `bmad-document-project` to generate/update project docs
+- Output: architecture description, module breakdown, API endpoints, data flows
+- Save to `docs/project/`
+
+### Step 3 — Generate project context for AI
+- Use skill `bmad-generate-project-context` to create `project-context.md`
+- This file = instructions for AI agents: conventions, patterns, do/don't
+- Save at project root
+
+### Step 4 — Tech writing review
+- Use skill `bmad-agent-tech-writer` (Paige) to review the generated docs
+- Paige will: fix unclear sections, add missing context, ensure consistency
+
+### Step 5 — Editorial polish
+- Use skill `bmad-editorial-review-prose` — clean up writing quality
   - Fix: passive voice, jargon, ambiguity, grammar
-- Dùng skill `bmad-editorial-review-structure` — improve doc organization
+- Use skill `bmad-editorial-review-structure` — improve doc organization
   - Fix: duplicated content, poor ordering, missing sections
 
-### Bước 6 — Distill for LLM consumption
-- Dùng skill `bmad-distillator` với docs dài (>500 lines)
-- Tạo phiên bản compressed — giữ nguyên thông tin, giảm token count
-- Lưu distilled version cạnh original: `[name].distilled.md`
+### Step 6 — Distill for LLM consumption
+- Use skill `bmad-distillator` for long docs (>500 lines)
+- Create a compressed version — preserve all information, reduce token count
+- Save distilled version alongside original: `[name].distilled.md`
 
-### Bước 7 — Index all docs
-- Dùng skill `bmad-index-docs` cho mỗi folder trong `docs/`
-- Sinh/cập nhật `index.md` — mục lục tất cả files + mô tả ngắn
+### Step 7 — Index all docs
+- Use skill `bmad-index-docs` for each folder in `docs/`
+- Generate/update `index.md` — table of contents of all files + short descriptions
 
-### Bước 8 — Build knowledge graph wiki
-- Chạy `/graphify . --wiki` để build agent-crawlable wiki từ codebase
-- Output: `graphify-out/` — index.md + article per community
-- Wiki này giúp AI agents navigate codebase nhanh hơn
-
-### Bước 9 — Sync to MemPalace
-- Gọi `mcp__mempalace__mempalace_diary_write` ghi nhận:
-  - Docs nào đã cập nhật
-  - Stale docs nào đã xoá/replace
-  - New patterns/conventions đã document
-
-### Bước 10 — Output cho user
+### Step 8 — Output to user
 ```
 ## Documentation Sync Complete
 
@@ -77,23 +64,18 @@ description: Documentation & knowledge sync — cập nhật docs, sinh project
 - Project context:   project-context.md [created/updated]
 - Distilled docs:    [N files compressed]
 - Doc indexes:       [N index.md files]
-- Knowledge wiki:    graphify-out/ [rebuilt]
 
 ### Quality checks
 - Prose review:      PASS
 - Structure review:  PASS
 - Stale docs found:  [N — list]
 
-### Knowledge saved
-- MemPalace diary:   ✓
-
 ### Next step
 Documentation is current. Continue with /vsaf-plan or /vsaf-sprint.
 ```
 
-## Lưu ý
-- Flow này **không sửa code** — chỉ documentation
-- Chạy ít nhất 1 lần mỗi sprint hoặc sau mỗi major ship
-- Commit tất cả docs: `git commit -m "docs: sync documentation [sprint N]"`
-- Nếu docs >1000 lines: luôn tạo distilled version
-
+## Notes
+- This flow **does not modify code** — documentation only
+- Run at least once per sprint or after each major ship
+- Commit all docs: `git commit -m "docs: sync documentation [sprint N]"`
+- If docs >1000 lines: always create a distilled version

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

@@ -1,48 +1,81 @@
 ---
 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ì.
+description: Understand the full context of a new project. Use when first onboarding to a project, needing to grasp the architecture, past decisions, and codebase before doing anything.
 ---
 
 # 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.
+## Objective
+Build a full mental model of the project before touching any code.
 
-## Các bước thực hiện
+## Steps
 
-### Bước 1 — Code intelligence (GitNexus)
-- Dùng `mcp__gitnexus__query` với query rộng (ví dụ: "main entry point", "core module") để lấy codebase overview
-- Dùng `mcp__gitnexus__group_list` để xem các functional clusters
-- Nếu cần drill-down symbol cụ thể: dùng `mcp__gitnexus__context` với param `name` là tên symbol đó
-- Tóm tắt: execution flows quan trọng, symbols có nhiều dependencies nhất
+### Step 1 — Codebase overview (GitNexus resource)
+- Read `gitnexus://repo/{name}/context` — get codebase overview:
+  - Size, index freshness, health metrics
+  - Overview of symbols, relationships
 
-### Bước 2 — 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
+### Step 2 — Functional areas (GitNexus resource)
+- Read `gitnexus://repo/{name}/clusters` — functional areas + cohesion scores
+- Understand what functional groups the codebase is divided into
 
-### Bước 3 — Output cho user
-Trình bày tóm tắt theo format:
+### Step 3 — Execution flows (GitNexus resource)
+- Read `gitnexus://repo/{name}/processes` — all execution flows in the codebase
+- Understand how data flows through the system
+
+### Step 4 — Module groupings (GitNexus tools)
+- Use `gitnexus_group_list` to view module groups
+- Use `gitnexus_group_query` to view inter-module relationships
+- Understand which modules depend on which
+
+### Step 5 — API surface (GitNexus, for API projects)
+- Use `gitnexus_route_map` to map all API routes → handlers
+- Skip if the project is not an API/web service
+
+### Step 6 — Deep-dive key symbols (GitNexus)
+- Use `gitnexus_context` on 3-5 key symbols (main entry points, core services)
+- Get a 360° view: callers, callees, process participation
+- Identify: hot symbols (many callers), risk areas (high fan-out)
+
+### Step 7 — Read project documentation + synthesize
+- Read `docs/project/planning-artifacts/` to find PRDs, ADRs, architecture docs
+- Read `docs/project/srs/` to find existing SRS documents
+- Synthesize all findings into a project overview
+
+### Step 8 — Output to user
+Present the summary in this format:
 
 ```
 ## Project Overview
-[Mô tả ngắn về dự án]
+[Brief description of the project]
+
+## Codebase Health
+- Symbols: [N] | Relationships: [N] | Execution flows: [N]
+- Index freshness: [fresh / stale — last indexed: date]
+
+## Architecture
+[Main layers/modules and their relationships — from clusters + groups]
+
+## Key Execution Flows
+[Top 5-10 most important flows — from processes]
+
+## API Surface
+[Routes overview — from route_map, or "N/A" if not an API project]
 
-## Kiến trúc
-[Các layer/module chính và quan hệ]
+## Hot Symbols
+[3-5 symbols with the most callers/dependencies — from context deep-dive]
 
-## Patterns đang dùng
+## Patterns in Use
 [Tech stack, design patterns, conventions]
 
-## Decisions quan trọng
-[Những gì team đã quyết định và lý do]
+## Key Decisions
+[What the team has decided and why — from docs]
 
-## Cần chú ý
+## Areas of Concern
 [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 `vsaf mine` để populate
-- Sau khi hoàn thành: gợi ý user dùng `/vsaf-plan <feature>` để bắt đầu task
+## Notes
+- Do NOT modify any files during this step
+- If GitNexus index is stale: run `vsaf index` before onboarding
+- After completion: suggest the user run `/vsaf-plan <feature>` to begin a task

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

@@ -1,88 +1,101 @@
 ---
 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
+description: Plan a new feature/task. Use when receiving a requirement that needs scope analysis, impact assessment, and approach strategy. Dual brainstorm (Superpowers + BMAD). Example: /vsaf-plan create user management module
 ---
 
 # 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.
+## Objective
+Fully understand the requirement, analyze impact, and determine the implementation strategy before writing any line of code.
 
 ## 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 — Search MemPalace (bắt buộc)
-- Gọi `mcp__mempalace__mempalace_search` với keyword từ `$ARGUMENTS`
-- Tìm kiếm: past decisions, architectural patterns, previous attempts
-- Tóm tắt: có decision nào liên quan không?
-
-### 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
-- Nếu risk HIGH/CRITICAL: DỪNG, báo user trước khi tiếp tục
-
-### 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
-- **Nếu risk HIGH hoặc > 3 modules**: dùng skill `bmad-create-architecture` để tạo ADR (Architecture Decision Record) chính thức
-  - Lưu vào `docs/project/planning-artifacts/adr-[feature].md`
-
-### Bước 6 — Brainstorm (BMAD Brainstorming)
-- Dùng skill `bmad-brainstorming` để explore alternatives và uncover hidden risks
-- Facilitator sẽ dẫn dắt session với các kỹ thuật sáng tạo đa dạng
-- Đặt câu hỏi: "What if...", "What could go wrong...", "What are we missing?"
-- Mục tiêu: tối thiểu 20 ý tưởng/alternatives trước khi tổ chức lại
-- bmad-brainstorming sẽ load config từ `_bmad/bmm/config.yaml`
-
-### Bước 7 — Challenge approach (BMAD Advanced Elicitation)
-- Dùng skill `bmad-advanced-elicitation` để challenge approach đã chọn
-- Chạy **pre-mortem**: "Giả sử approach này fail sau 3 tháng — vì sao?"
-- Chạy **red team**: tìm điểm yếu, attack vectors, failure modes
-- Nếu phát hiện risk nghiêm trọng: quay lại Bước 5 để điều chỉnh approach
-
-### Bước 8 — Output cho user
-Trình bày kết quả theo format:
+`$ARGUMENTS` — description of the feature/task to be done (e.g.: "create dashboard management module")
+
+## Execution Steps
+
+### Step 1 — Clarify scope (BMAD analyst)
+- Use skill `bmad-agent-analyst` to analyze the requirement
+- Identify: FRs, NFRs, edge cases, assumptions, out-of-scope
+- STOP and ask the user if there are any unclear points
+
+### Step 2 — Impact analysis (GitNexus)
+- Use `gitnexus_impact` with the target being the related module/symbol
+- Use `gitnexus_query` to find related code
+- Report blast radius: how many modules are affected, risk level
+- If risk is HIGH/CRITICAL: STOP, notify the user before continuing
+
+### Step 2b — Module boundary analysis (GitNexus)
+- Use `gitnexus_group_query` to view module boundaries
+- Identify: which groups are affected, interface contracts between groups
+- Understand module boundaries clearly before proposing architecture
+
+### Step 3 — Architecture decision (BMAD architect)
+- Use skill `bmad-agent-architect` to propose an architecture approach
+- Compare alternatives, choose the most suitable approach
+- **If risk is HIGH or > 3 modules**: use skill `bmad-create-architecture` to create a formal ADR (Architecture Decision Record)
+  - Save to `docs/project/planning-artifacts/adr-[feature].md`
+
+### Step 4 — Dual Brainstorm
+
+#### 4a — Structured brainstorm (Superpowers)
+- Use `superpowers:brainstorming` — structured exploration:
+  - Trade-offs, constraints, 2-3 viable options
+  - Evaluate risks for each option
+
+#### 4b — Creative brainstorm (BMAD)
+- Use skill `bmad-brainstorming` to explore alternatives and uncover hidden risks
+- Facilitator leads the session with diverse creative techniques
+- Goal: at least 20 ideas/alternatives before reorganizing
+
+#### 4c — Parallel deep-dive (Superpowers, if >2 approaches)
+- Use `superpowers:dispatching-parallel-agents` to research candidate approaches in parallel
+- Each agent deep-dives into 1 approach: feasibility, risks, effort
+- Synthesize results to choose the best approach
+
+### Step 5 — Challenge approach (BMAD Advanced Elicitation)
+- Use skill `bmad-advanced-elicitation` to challenge the chosen approach
+- Run **pre-mortem**: "Assume this approach fails after 3 months — why?"
+- Run **red team**: find weaknesses, attack vectors, failure modes
+- If serious risks are discovered: go back to Step 3 to adjust the approach
+
+### Step 6 — Output to user
+Present results in the following format:
 
 ```
-## Feature: [tên feature]
+## Feature: [feature name]
 
 ## Scope
-- In: [những gì sẽ làm]
-- Out: [những gì không làm]
+- In: [what will be done]
+- Out: [what will not be done]
 
 ## Impact Analysis
-- Modules bị ảnh hưởng: [danh sách]
+- Affected modules: [list]
+- Module boundaries: [from group_query]
 - Risk level: [LOW/MEDIUM/HIGH]
-- Breaking changes: [có/không, chi tiết]
+- Breaking changes: [yes/no, details]
 
-## Approach được chọn
-[Mô tả architecture approach]
+## Chosen Approach
+[Architecture approach description]
+
+## Brainstorm Summary
+- Superpowers: [N approaches explored, chosen: X]
+- BMAD: [N ideas generated, top insights]
+- Parallel agents: [used / not needed]
 
 ## Pre-mortem findings
-[Những risk đã identify và mitigation plan]
+[Identified risks and mitigation plan]
 
-## Alternatives đã xem xét
-[Tại sao không chọn]
+## Alternatives considered
+[Why they were not chosen]
 
 ## ADR
-[Đã tạo / Không cần (risk LOW)]
+[Created / Not needed (risk LOW)]
 
 ## Next step
-Chạy /vsaf-doc để viết tài liệu plan
+Run /vsaf-doc-prd to write the PRD document
 ```
 
-## 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
+## Notes
+- If Impact > 3 modules: warn the user, suggest splitting into multiple PRs
+- If risk level is HIGH/CRITICAL: STOP, notify the user before continuing
+- Dual brainstorm is mandatory: both Superpowers (structured) and BMAD (creative)