Berat Çimen

---
name: create-plan
description: Tạo một bản kế hoạch ngắn gọn, súc tích. Sử dụng khi người dùng yêu cầu rõ ràng việc lập kế hoạch liên quan đến một tác vụ lập trình.
metadata:
  short-description: Tạo một kế hoạch
---

# Tạo Kế hoạch (Create Plan)

## Mục tiêu

Biến câu lệnh (prompt) của người dùng thành **một bản kế hoạch duy nhất, có thể hành động ngay** được gửi trong tin nhắn phản hồi cuối cùng của trợ lý.

## Quy trình làm việc tối giản

Trong suốt toàn bộ quy trình làm việc, hãy vận hành ở chế độ chỉ đọc (read-only mode). Không ghi mới hoặc cập nhật bất kỳ tệp tin nào.

1. **Quét nhanh ngữ cảnh**
   - Đọc tệp `README.md` và bất kỳ tài liệu rõ ràng nào khác (`docs/`, `CONTRIBUTING.md`, `ARCHITECTURE.md`).
   - Đọc lướt qua các tệp có liên quan (những tệp có khả năng cao nhất sẽ được chỉnh sửa).
   - Xác định các ràng buộc (ngôn ngữ lập trình, frameworks, các lệnh CI/test, hình thái triển khai).

2. **Chỉ hỏi thêm nếu thực sự bị chặn không thể tiếp tục**
   - Hỏi **tối đa 1–2 câu hỏi**.
   - Chỉ đặt câu hỏi nếu bạn không thể lập kế hoạch một cách có trách nhiệm khi thiếu câu trả lời đó; ưu tiên câu hỏi dạng trắc nghiệm nhiều lựa chọn.
   - Nếu chưa chắc chắn nhưng không đến mức bị chặn đứng, hãy đưa ra một giả định hợp lý và tiếp tục tiến hành.

3. **Tạo kế hoạch theo mẫu dưới đây**
   - Bắt đầu bằng **1 đoạn văn ngắn** mô tả mục đích và hướng tiếp cận.
   - Nêu rõ ngắn gọn những gì **nằm trong phạm vi (in scope)** và những gì **nằm ngoài phạm vi (not in scope)**.
   - Sau đó cung cấp một **danh sách kiểm tra (checklist) nhỏ** gồm các hạng mục hành động (mặc định từ 6–10 mục).
      - Mỗi mục trong danh sách kiểm tra phải là một hành động cụ thể và, khi hữu ích, hãy nêu rõ tên tệp/câu lệnh.
      - **Đảm bảo các mục có tính nguyên tử và được sắp xếp theo đúng trình tự**: khám phá → thay đổi → kiểm thử → triển khai (rollout).
      - **Bắt đầu bằng động từ**: “Thêm…”, “Tái cấu trúc…”, “Xác minh…”, “Triển khai…”.
   - Bao gồm ít nhất một mục dành cho **kiểm thử/xác thực (tests/validation)** và một mục cho **trường hợp biên/rủi ro (edge cases/risk)** khi có áp dụng.
   - Nếu vẫn còn những điểm chưa rõ, hãy đưa thêm một phần nhỏ **Các câu hỏi bỏ ngỏ (Open questions)** (tối đa 3 câu).

4. **Không mở đầu bản kế hoạch bằng những lời giải thích siêu ngôn ngữ (meta explanations); chỉ xuất duy nhất bản kế hoạch theo đúng mẫu**

## Mẫu kế hoạch (tuân thủ chính xác)

```markdown
# Plan

<1–3 câu: chúng ta đang làm gì, tại sao lại làm, và hướng tiếp cận tổng quan ở cấp độ cao.>

## Scope
- In:
- Out:

## Action items
[ ] <Bước 1>
[ ] <Bước 2>
[ ] <Bước 3>
[ ] <Bước 4>
[ ] <Bước 5>
[ ] <Bước 6>

## Open questions
- <Câu hỏi 1>
- <Câu hỏi 2>
- <Câu hỏi 3>
```

## Hướng dẫn viết các mục trong danh sách kiểm tra
Các mục danh sách kiểm tra tốt:
- Chỉ rõ tới các tệp/mô-đun có khả năng liên quan: `src/...`, `app/...`, `services/...`
- Nêu rõ cách xác thực cụ thể: “Chạy `npm test`”, “Thêm unit tests cho X”
- Bao gồm phương án triển khai an toàn khi có liên quan: cờ tính năng (feature flag), kế hoạch di chuyển dữ liệu (migration plan), ghi chú hoàn tác (rollback note)

Tránh:
- Các bước mơ hồ chung chung (“xử lý phần backend”, “làm phần xác thực auth”)
- Chia thành quá nhiều bước siêu nhỏ vụn vặt
- Viết các đoạn mã nguồn cụ thể (hãy giữ cho bản kế hoạch độc lập với chi tiết triển khai mã)