strategic-self-questioning

name: strategic-self-questioning description: | Kích hoạt chế độ tự đặt câu hỏi chiến lược (Strategic Self-Questioning) — xây dựng kế hoạch, xác nhận giả định, dự đoán rủi ro trước khi thực hiện. Trigger khi: thiết kế hệ thống, migration, refactor lớn, lập kế hoạch dự án, phân tích yêu cầu, debug phức tạp, quyết định kiến trúc, deploy production, task mơ hồ/nhiều bước/rủi ro cao. Trigger phrases: "suy nghĩ kỹ", "phân tích trước", "lập kế hoạch", "đánh giá rủi ro", "cần cẩn thận", "hãy cẩn thận".

Goal

Dừng lại và suy nghĩ có hệ thống trước khi hành động — hỏi đúng câu hỏi để tránh làm sai rồi phải sửa.

Instructions

Bước 0: Chọn chế độ phân tích

Đánh giá task theo 3 câu tự vấn:

1. Nếu làm sai, user mất bao lâu để sửa? (>30 phút → cần cẩn thận)
2. Có điểm nào không chắc chắn? (có → cần clarify)
3. Ảnh hưởng production/data thật? (có → risk assessment bắt buộc)

• Nếu cả 3 đều "không/nhẹ" → Quick Mode (Bước 1Q)
• Nếu bất kỳ câu nào "có/nặng" → Full Mode (Bước 1F → 5F)
• Nếu user nói "just do it" / "cứ làm đi" → Nêu 1-2 risk quan trọng nhất → thực hiện

Quick Mode

Bước 1Q: Phân tích nhanh — 3 câu hỏi

Trả lời ngắn gọn:

1. Mục tiêu chính xác là gì? (1 câu)
2. Giả định nào có thể sai? (liệt kê nhanh)
3. Nếu sai thì hậu quả gì? (đánh giá nhanh)

• Nếu tất cả rõ ràng → Thực hiện luôn
• Nếu có điểm mờ → Hỏi user HOẶC chuyển sang Full Mode

Full Mode

Bước 1F: Clarification — Làm rõ yêu cầu

Tự hỏi và trả lời:

• End goal (business outcome, không phải task): là gì?
• Đầu ra user mong đợi: format, structure, nơi đặt, ai dùng?
• Ràng buộc: thời gian, tech stack, resources, conventions hiện có?
• Context: phần của dự án lớn hơn? Liên quan đến hệ thống đang chạy?

Phân biệt rõ "điều user NÓI" vs "điều user THỰC SỰ CẦN".

• Nếu thiếu context → hỏi user trước khi giả định.
• Nếu suy luận được → nêu giả định và xác nhận nhanh.

Bước 2F: Assumption Validation — Xác nhận giả định

Liệt kê mọi giả định đang đưa ra, phân loại:

Tự hỏi: "Nếu giả định sai → phải làm lại bao nhiêu?" → Ưu tiên xác nhận giả định có cost-of-wrong cao.

Bước 3F: Action Planning — Lập kế hoạch

Tạo kế hoạch theo format:

Phase 1: [Tên] — [Mục tiêu]
  ├─ Bước 1.1: [Action cụ thể] → Checkpoint: [Kiểm tra gì]
  ├─ Bước 1.2: [Action cụ thể] → Checkpoint: [Kiểm tra gì]
  └─ Gate: [Điều kiện để qua Phase 2]

Phase 2: [Tên] — [Mục tiêu]
  ├─ ...

Tự hỏi:

• Dependencies: bước nào phải xong trước?
• Parallelization: bước nào chạy song song được?
• Checkpoints: kiểm tra output ở đâu trước khi đi tiếp?

Bước 4F: Risk Assessment — Đánh giá rủi ro

Liệt kê 3-5 risk quan trọng nhất (KHÔNG liệt kê mọi thứ):

Ưu tiên: Impact cao + Likelihood cao trước. Mỗi risk PHẢI có mitigation cụ thể. Nếu không nghĩ ra → flag cho user.

Bước 5F: Success Criteria — Tiêu chí thành công

Định nghĩa "XONG" cụ thể:

Must-have (không có thì chưa xong):
  - [ ] [Criterion cụ thể + cách verify]
  - [ ] [Criterion cụ thể + cách verify]

Nice-to-have (có thì tốt):
  - [ ] [Criterion]

Bước 6F: ✅ VERIFY — Tự kiểm tra trước khi output

Đọc lại toàn bộ phân tích và tự hỏi:

• "Mỗi risk có mitigation cụ thể chưa?" → Nếu thiếu → bổ sung
• "Plan có đủ thông tin để AI khác thực hiện không?" → Nếu thiếu → bổ sung
• "Có giả định nguy hiểm nào chưa được flag?" → Nếu có → thêm vào Bước 2F
• "Output có quá dài cho mức độ phức tạp của task?" → Nếu có → rút gọn

Nếu pass tất cả → output kết quả và bắt đầu thực hiện.

Examples

Ví dụ 1: Quick Mode — Task rõ ràng, risk vừa

Context: User yêu cầu thay đổi database schema Input: "Thêm cột status vào bảng users trong database"

Thought process:

• Task cụ thể, 1 bước → Quick Mode
• Nhưng ALTER TABLE có risk nếu bảng lớn → cần xác nhận

Output:

Quick Analysis:
1. Mục tiêu: ALTER TABLE thêm cột `status` vào bảng `users`
2. Giả định cần kiểm tra: Kiểu dữ liệu? Default value? Bảng có đang bị lock? Cần index?
3. Rủi ro: Nếu bảng lớn (hàng triệu rows), ALTER có thể lock table → downtime

→ Hỏi user: "Bảng users hiện có bao nhiêu records? Cần default value cho status không?"

Ví dụ 2: Full Mode — Task mơ hồ, risk cao

Context: User yêu cầu migration lớn Input: "Migrate từ REST sang GraphQL"

Thought process:

• Task rất lớn, nhiều bước, ảnh hưởng production → Full Mode
• Nhiều giả định nguy hiểm cần xác nhận

Output:

Bước 1F — Clarification:
- End goal: Chuyển API sang GraphQL để giảm over-fetching
- Cần clarify: Migrate toàn bộ hay từng phần?

Bước 2F — Assumptions:
| Giả định                         | Loại          | Action            |
|----------------------------------|---------------|-------------------|
| Migrate toàn bộ cùng lúc        | Cần xác nhận  | Hỏi scope         |
| Có client đang dùng REST API cũ | Nguy hiểm     | BẮT BUỘC hỏi     |
| Schema GraphQL chưa có design   | Cần xác nhận  | Ảnh hưởng approach|

Bước 3F — Plan:
Phase 1: Assessment — Đánh giá hiện trạng
  ├─ 1.1: Inventory REST endpoints → Checkpoint: Danh sách đầy đủ
  ├─ 1.2: Identify dependent clients → Checkpoint: Client list confirmed
  └─ Gate: Scope confirmed bởi user

Bước 4F — Risks:
| Risk                                | Impact | Likelihood | Mitigation                     |
|-------------------------------------|--------|------------|--------------------------------|
| Client cũ bị break                  | High   | Med        | Versioning, backward compatible|
| Schema design sai, phải redesign    | High   | Med        | Prototype + review trước       |

Bước 5F — Success Criteria:
Must-have:
  - [ ] REST endpoints có GraphQL equivalent (verify: mapping table)
  - [ ] Client cũ vẫn hoạt động (verify: integration test)

Ví dụ 3: User nói "cứ làm đi" — Rút gọn tối đa

Context: User muốn deploy nhanh, không kiên nhẫn phân tích Input: "Deploy lên production đi, không cần phân tích"

Output:

⚠️ 2 risk quan trọng nhất:
1. Chưa test staging → crash production (mitigation: smoke test 5 phút)
2. Chưa backup → rollback khó (mitigation: snapshot DB trước)

→ Tiến hành deploy.

Constraints

Cân bằng (ưu tiên #1 — PHẢI tuân thủ)

• 🚫 KHÔNG ĐƯỢC over-analyze task đơn giản — "đổi màu button" dùng Quick Mode, KHÔNG viết 500 từ
• 🚫 KHÔNG ĐƯỢC hỏi quá 4 câu mỗi lượt — gộp câu hỏi liên quan thành nhóm
• 🚫 KHÔNG ĐƯỢC analysis paralysis — đặt time-box, plan đủ tốt rồi bắt tay làm
• ✅ LUÔN LUÔN chọn đúng chế độ (Quick/Full) TRƯỚC KHI phân tích

Chất lượng (ưu tiên #2)

• 🚫 KHÔNG ĐƯỢC nêu risk chung chung ("có thể có bug") — nêu risk CỤ THỂ: gì, ở đâu, impact gì
• 🚫 KHÔNG ĐƯỢC copy-paste template mà không adapt cho context hiện tại
• ✅ LUÔN LUÔN phân biệt "điều user nói" vs "điều user thực sự cần"
• ✅ LUÔN LUÔN có mitigation cho mỗi risk được nêu

Linh hoạt (ưu tiên #3 — nếu quên thì không chết ai)

• ⚠️ Plan đủ tốt + bắt đầu sớm TỐT HƠN plan hoàn hảo + bắt đầu muộn
• ⚠️ User tỏ ra muốn nhanh → rút gọn analysis, flag risk rồi làm
• ⚠️ Sau mỗi task, ngẫm lại: giả định nào sai? Risk nào không lường trước?