deep-questions

Mục tiêu: tạo file deep-questions.md ở root project, gồm 10–14 câu hỏi GOLIVE-readiness được tuỳ biến theo codebase, mỗi câu hỏi có câu trả lời do 1 sub-agent điều tra trực tiếp trong code, kèm risk verdict.

Triết lý: câu hỏi tốt > câu hỏi nhiều. Mỗi câu hỏi phải có thể chứng minh đúng/sai bằng code, không phải checklist trừu tượng.

Nguyên tắc

• Project-aware: Phải scan project trước để biết stack/domain, KHÔNG hỏi câu hỏi generic kiểu "có dùng HTTPS không"
• Fan-out song song: Tất cả sub-agent spawn trong 1 message duy nhất — không tuần tự
• Mỗi câu hỏi → 1 sub-agent: Tránh hỏi nhồi nhét. 1 agent = 1 câu hỏi = 1 file evidence list
• Bằng chứng từ code: Sub-agent phải trích dẫn path/to/file.ext:line cho mọi claim
• Verdict bắt buộc: Mỗi câu trả lời kết thúc bằng 1 trong 4 mức: ✅ READY · ⚠️ RISKY · 🚨 BLOCKER · ❓ INSUFFICIENT_EVIDENCE
• Không tạo file phụ: Chỉ ghi deep-questions.md. Không update README, không mở PR

Phase 1: Project recon (1 message, song song)

Đọc song song để hiểu stack & domain:

• Read: README.md, CLAUDE.md, AGENTS.md, discovery.md (nếu có)
• Glob manifest: Cargo.toml, package.json, go.mod, pyproject.toml, *.csproj
• Glob deploy: Dockerfile*, .github/workflows/*, .gitea/workflows/*, k8s/**, helm/**, *.service
• Glob config: .env.example, config/*, settings*.json, *.toml
• Bash: git log --oneline -10, git remote -v

Sau Phase 1 phải xác định:

• Loại sản phẩm: CLI tool / web service / library / desktop app / batch job
• Có state không (DB, file, cache)
• Có expose network không (HTTP/gRPC/WebSocket)
• Có user-facing không (auth, PII)
• Có dependencies bên ngoài quan trọng nào

Phase 2: Sinh câu hỏi (tuỳ chọn, không cố định)

Chọn 10–14 câu từ ngân hàng dưới đây, bỏ câu không liên quan với loại project. Có thể thêm câu mới đặc thù domain.

Ngân hàng câu hỏi GOLIVE (phân theo trục rủi ro):

A. Failure modes & resilience

1. Khi dependency quan trọng nhất (DB / API thượng nguồn / disk) chết, code ứng xử thế nào? Có circuit breaker, timeout, retry với backoff không?
2. Có path nào panic/crash toàn process thay vì trả lỗi cục bộ không? Liệt kê unwrap()/panic!/os.Exit(1) ở hot path.
3. Process có graceful shutdown không? Khi nhận SIGTERM, in-flight requests có được xử lý xong không?

B. Data integrity & rollback

4. Có thao tác ghi nào không idempotent? Nếu retry sau crash, có double-write/double-charge không?
5. Migration DB hoặc schema thay đổi có reversible script không? Rollback thực tế đã test bao giờ chưa?
6. Backup story của state quan trọng (DB/file): tần suất, vị trí, đã từng restore thử chưa?

C. Security

7. Có secret nào hardcode trong code/repo/CI không? Grep api_key|password|token|secret cộng heuristic.
8. Endpoint nào không require auth? Có endpoint debug/admin nào lộ ra prod không?
9. Input từ user/external có được validate ở boundary không? SQL injection / command injection / path traversal có thể không?
10. Logging có in PII / token / password ra log không?

D. Performance & capacity

11. Bottleneck nghi ngờ nhất là gì (DB query N+1, sync IO trong async, lock contention)? Có ai đo chưa?
12. Tại load nào hệ thống fail? Đã có load test chưa? Số liệu cụ thể?
13. Có resource leak tiềm ẩn không (goroutine/task không close, FD không close, connection pool unbounded)?

E. Observability

14. Khi user report "nó hỏng", trong bao lâu có thể xác định nguyên nhân? Có structured logs, request ID, distributed trace không?
15. Alert nào sẽ trigger khi service down / latency tăng / error rate tăng? Đã test alert chưa?
16. Health check endpoint có thực sự kiểm tra dependency không hay chỉ trả 200 OK?

F. Concurrency & correctness

17. Có race condition nào có thể xảy ra? Liệt kê shared mutable state và cơ chế bảo vệ.
18. Có deadlock tiềm ẩn không (lock order không nhất quán, lock chéo qua await)?

G. Tech debt & known unknowns

19. TODO/FIXME/HACK ở vị trí critical path? Liệt kê và đánh giá blocker.
20. Test coverage cho top-3 critical flow là bao nhiêu? Có flow nào ZERO test không?
21. Dependency có version nào EOL / có CVE đã biết không?

H. Operational

22. Có runbook cho oncall không? Khi alert kêu, người trực biết phải làm gì không?
23. Deploy có thể rollback trong <5 phút không? Quy trình rollback đã document chưa?
24. Config khác giữa dev/staging/prod ở đâu? Có per-env override không hay phải sửa code?

Quy tắc chọn:

• CLI tool: bỏ B6, C8, D11–13 phần lớn, E14–16; tập trung A1–3, C7, F17, G19–21
• Web service: cover gần như toàn bộ
• Library: tập trung A2, F17–18, G19–21, bỏ phần ops
• Desktop app: tập trung A1–3, C7–10, G19–21

Số lượng câu cuối: 10–14. Không cần đủ tất cả, ưu tiên câu có khả năng tìm thấy bằng chứng trong code.

Phase 3: Fan-out sub-agent (1 message duy nhất, parallel)

Spawn Agent (subagent_type=Explore) cho mỗi câu hỏi. Tất cả trong cùng 1 message — đây là điểm mấu chốt về tốc độ.

Brief template (gửi y nguyên cho mỗi agent, chỉ thay câu hỏi):

Câu hỏi GOLIVE-readiness: <câu hỏi đầy đủ>

Nhiệm vụ: Điều tra codebase tại <project_root> để trả lời câu hỏi trên bằng bằng chứng cụ thể. KHÔNG đoán, KHÔNG suy diễn từ tên file. Phải mở file và đọc.

Cách làm:

1. Xác định nơi vấn đề có thể tồn tại (Glob/Grep targeted)
2. Đọc file liên quan, trích đoạn code nhỏ làm bằng chứng
3. Nếu không tìm thấy gì → đó cũng là 1 phát hiện (verdict ❓)

Format trả lời (Markdown, tiếng Việt có dấu, dưới 400 từ):

### Phát hiện chính
<2-4 bullet, mỗi bullet kèm `path/file.ext:line`>

### Bằng chứng
<code block ngắn, chỉ đoạn cốt lõi, có file:line>

### Verdict
✅ READY | ⚠️ RISKY | 🚨 BLOCKER | ❓ INSUFFICIENT_EVIDENCE

### Hành động đề xuất (nếu RISKY/BLOCKER)
<1-3 bullet hành động cụ thể>

Giới hạn: Đọc tối đa 12 file. Không sửa code, không tạo file. Báo cáo dưới 400 từ.

Quan trọng: Tự kiểm tra trước khi gửi — số lượng agent gọi trong 1 message phải bằng số câu hỏi đã chọn. Nếu chia nhiều message là sai pattern.

Phase 4: Tổng hợp & ghi deep-questions.md

Sau khi tất cả agent trả về, gộp output theo template:

# <PROJECT_NAME> — Deep GOLIVE Questions

> Generated by deep-questions skill on YYYY-MM-DD
> <N> câu hỏi · <X> blocker · <Y> risky · <Z> ready

## Tóm tắt rủi ro

| # | Câu hỏi | Verdict |
|---|---------|---------|
| 1 | <câu hỏi rút gọn> | 🚨 BLOCKER |
| 2 | ... | ⚠️ RISKY |
| ... | | |

## Blocker (phải xử lý trước GOLIVE)

<liệt kê các câu verdict 🚨 với hành động đề xuất>

## Risky (nên xử lý, có thể go-live với mitigation)

<liệt kê ⚠️>

---

## Chi tiết từng câu hỏi

### Q1. <câu hỏi đầy đủ>

<paste nguyên report của sub-agent: phát hiện + bằng chứng + verdict + action>

### Q2. ...

...

Quy tắc viết:

• Bảng tóm tắt phải xếp blocker lên đầu
• Mỗi Q giữ nguyên file:line từ sub-agent — không paraphrase
• Nếu sub-agent trả về ❓ → ghi rõ "không đủ bằng chứng, cần điều tra thêm"
• Cuối file: 1 câu kết luận go/no-go dựa trên số blocker

Phase 5: Báo cáo cho user

Sau khi Write deep-questions.md:

1. wc -l deep-questions.md
2. Tóm tắt: tổng số câu hỏi, breakdown verdict (X blocker / Y risky / Z ready / W insufficient)
3. Liệt kê top-3 blocker theo thứ tự quan trọng
4. Verdict tổng: GO / NO-GO / GO WITH MITIGATION

KHÔNG commit, KHÔNG push, KHÔNG sửa code khác.

Anti-patterns

Test thực tế

Skill này được phát triển trong repo claurst (Rust CLI agent, multi-provider, có MCP, plugin, session storage). Chạy skill trên claurst phải sinh ra deep-questions.md với:

• 10–14 câu hỏi tuỳ biến cho CLI tool có state local + network calls
• Ít nhất 1 blocker hoặc risky về panic-on-hot-path / hardcoded fallback
• Mỗi câu có bằng chứng từ src-rust/crates/*/src/*.rs:line