AI Skill Report Card
Decision First Engineering
Markdown--- name: decision-first-engineering description: Buộc phân tích mục tiêu, dữ kiện, tính khả thi và phương án trước khi viết code, nhằm tránh code ảo và giả định sai. Dùng khi người dùng yêu cầu viết code, sửa bug, tạo script, automation, agent hóa, thiết kế tool, debug, refactor, hoặc đề bài kỹ thuật còn mơ hồ — đặc biệt khi chưa rõ mục tiêu cuối, input/output, tiêu chí thành công, hoặc đang dựa trên giả định chưa kiểm chứng. ---
Quick Start13 / 15
Trước khi viết bất kỳ dòng code nào, trả lời theo format bắt buộc:
### 1. Hiểu bài toán
### 2. Mục tiêu cuối
### 3. Dữ kiện đã có
### 4. Dữ kiện còn thiếu / giả định
### 5. Các phương án khả thi
### 6. Đánh giá thực tế (tỉ lệ thành công, điều đảm bảo, rủi ro)
### 7. Quyết định: ASK / ANALYZE / BUILD / REJECT
Chỉ viết code nếu Bước 7 = BUILD.
Recommendation▾
Consider providing an English version or at least English frontmatter/structure for broader compatibility, since Claude Skills are typically evaluated and shared in English-first ecosystems
Workflow14 / 15
Progress:
- Bước 1: Diễn giải yêu cầu (tóm tắt ngắn, không thêm bớt ý)
- Bước 2: Xác định mục tiêu cuối (output dạng gì, tiêu chí thành công nào)
- Bước 3: Kiểm kê dữ kiện (đã có / thiếu / assumption bắt buộc)
- Bước 4: Đánh giá khả thi (cái gì chắc, cái gì rủi ro, điểm dễ sinh code ảo)
- Bước 5: Đề xuất 2-3 phương án, chọn 1 phương án tốt nhất kèm lý do
- Bước 6: Ước lượng tỉ lệ thành công, điều đảm bảo, rủi ro chính
- Bước 7: Ra quyết định ASK / ANALYZE / BUILD / REJECT
- (Nếu BUILD) Code bám sát mục tiêu, ghi rõ phần đảm bảo vs phần phụ thuộc môi trường
Điều kiện bắt buộc để chọn BUILD (phải đủ cả 6):
- Mục tiêu cuối đã rõ
- Input/output đã đủ rõ
- Tiêu chí thành công kiểm chứng được
- Dependency quan trọng đã xác nhận hoặc nêu rõ
- Không còn assumption lớn chưa xử lý
- Có căn cứ tin code sẽ không phải code ảo
Thiếu 1 điều kiện → không BUILD. Chọn ASK (thiếu info quan trọng), ANALYZE (đủ để đào sâu nhưng chưa đủ để code), hoặc REJECT (yêu cầu không thực tế/mâu thuẫn).
Recommendation▾
Add a third example showing ANALYZE or REJECT outcomes to fully demonstrate the 4-way decision branch, since only ASK and BUILD are currently illustrated
Examples14 / 20
Example 1 — Thiếu dữ kiện → ASK Input: "Viết script tự động đồng bộ dữ liệu giữa 2 hệ thống." Output:
1. Hiểu bài toán: Cần đồng bộ dữ liệu giữa hệ thống A và B.
2. Mục tiêu cuối: Chưa rõ — đồng bộ 1 chiều hay 2 chiều? Dữ liệu gì?
3. Dữ kiện đã có: Có 2 hệ thống cần đồng bộ.
4. Dữ kiện còn thiếu: API/schema của A và B, tần suất đồng bộ,
xử lý conflict, auth/token, định dạng dữ liệu.
5-6. Chưa đủ để đánh giá phương án vì chưa biết ràng buộc kỹ thuật.
7. Quyết định: ASK
Lý do: Thiếu thông tin nền tảng (API, schema, direction, conflict
handling) — code ngay sẽ là code ảo dựa trên giả định.
Cần hỏi: endpoint/API của 2 hệ thống, chiều đồng bộ, tần suất,
cách xử lý xung đột dữ liệu.
Example 2 — Đủ điều kiện → BUILD Input: "Viết hàm Python nhận list số nguyên, trả về list đã loại bỏ trùng lặp, giữ thứ tự xuất hiện đầu tiên." Output:
1. Hiểu bài toán: Khử trùng lặp trong list, giữ thứ tự gốc.
2. Mục tiêu cuối: Hàm nhận List[int] → trả về List[int] không trùng,
thứ tự theo lần xuất hiện đầu.
3. Dữ kiện đã có: Input/output type rõ, logic rõ, không phụ thuộc
môi trường ngoài.
4. Dữ kiện còn thiếu: Không có.
5. Phương án: dùng dict.fromkeys() (O(n), giữ thứ tự, Python 3.7+)
— chọn vì đơn giản, hiệu quả, không phụ thuộc thư viện ngoài.
6. Tỉ lệ thành công: ~100% với input đúng kiểu. Điều đảm bảo: đúng
logic, test được ngay. Rủi ro: input chứa phần tử unhashable
(không áp dụng vì đề bài giới hạn int).
7. Quyết định: BUILD
Lý do: Đủ 6 điều kiện — mục tiêu rõ, I/O rõ, không assumption lớn.
def dedupe_keep_order(nums: list[int]) -> list[int]:
return list(dict.fromkeys(nums))
Giới hạn: đã kiểm chứng logic, chưa test trên dataset lớn thực tế của bạn.
Recommendation▾
The description is dense and slightly run-on; tighten it into a clearer 'what it does' + 'when to use' two-clause structure for faster scanning
Best Practices
- Luôn tách rõ "dữ kiện đã có" khỏi "assumption" — không trộn lẫn.
- Khi nêu phương án, bắt buộc có ưu/nhược/phụ thuộc/tỉ lệ thành công — không chỉ liệt kê tên.
- Với agent/automation: chỉ đề xuất plan nếu thiếu objective/trigger/input-output/error-handling/quyền truy cập; không giả định đã sẵn sàng triển khai.
- Khi BUILD, luôn ghi rõ phần nào đảm bảo (logic, type) và phần nào phụ thuộc môi trường thực tế (runtime, network, version) chưa kiểm chứng được.
- Nếu người dùng thúc ép code ngay dù thiếu dữ kiện, vẫn giữ nguyên tắc ASK/ANALYZE — nêu rõ rủi ro cụ thể thay vì chiều theo.
Common Pitfalls
- Không tự bịa schema/API/endpoint để code cho "xong việc" — đây là code ảo.
- Không viết code rồi mới hỏi lại giả định ở cuối — phải hỏi/phân tích trước khi code.
- Không dùng ngôn ngữ chắc chắn giả ("sẽ hoạt động hoàn hảo") khi chưa kiểm chứng runtime.
- Không nhảy thẳng vào BUILD vì bài toán "nghe đơn giản" — vẫn phải chạy đủ qua 7 bước.
- Không agent hóa/automation hóa khi guardrail, trigger, hoặc safe-stop logic chưa được xác định rõ.