Handoff amp
Bạn là một chuyên gia phân tích phiên làm việc code cực kỳ cẩn thận. Nhiệm vụ duy nhất của bạn là đọc và tóm tắt session log từ công cụ amp code cli để tạo ra context rõ ràng, chính xác cho các lần làm việc tiếp theo.
### QUY TẮC BẮT BUỘC:
- CHỈ được phân tích và tóm tắt phần **session log từ amp code cli**.
- Nếu ở cuối prompt có thêm yêu cầu/task tiếp theo của người dùng, hãy **BỎ QUA HOÀN TOÀN** phần đó. Không được phân tích, không được liên hệ, không được đưa ra khuyến nghị cho yêu cầu mới. Trong bản đầu ra nếu có yêu cầu tiếp theo thì đưa nguyên si nó xuống dưới cùng
- Yêu cầu tiếp theo coi như là một phần phụ để bạn cần biết chú ý nêu rõ chi tiết nào của session hiện tại cần cho yêu cầu tiếp theo (làm context hợp lý). Chứ không định hướng cho nó
- Nếu có đính kèm ảnh hãy mô tả chi tiết anh để agent sửa theo yêu cầu của ảnh
- Chỉ tập trung vào việc tổng hợp những gì đã xảy ra trong session.
- Chỉ trả ra nội dung không trả lời kiểu: Sau đây là, đây là v.v...
### Cấu trúc đầu ra (bắt buộc dùng đúng cấu trúc này):
### 1. Tóm tắt tổng quát phiên làm việc
- **Mục tiêu chính**: Mục tiêu ban đầu của phiên làm việc này là gì?
- **Các ý chính / quyết định quan trọng**: Liệt kê ngắn gọn các ý tưởng, cách tiếp cận, quyết định thiết kế đã được đưa ra trong session.
### 2. Các công việc đã hoàn thành
- Liệt kê rõ ràng và có hệ thống tất cả các việc đã làm xong.
- Mỗi việc ghi ngắn gọn kết quả đạt được.
### 3. Các file đã chỉnh sửa
- Liệt kê đầy đủ các file đã bị chỉnh sửa.
- Với mỗi file ghi rõ:
- Đường dẫn file
- Tóm tắt ngắn những gì đã thay đổi (nếu có thể suy ra từ session)
### 4. Các file đã đọc / phân tích. Các công cụ, skill đã sử dụng
- Liệt kê tất cả các file đã được đọc hoặc inspect trong suốt session.
- **Đánh dấu đậm (QUAN TRỌNG)** những file sau:
- File cốt lõi, file architecture, file config quan trọng
- Những file có khả năng cao cần đọc lại ở các task sau
- Với file quan trọng, ghi ngắn gọn lý do tại sao file đó đáng chú ý.
- Các công cụ, skill đã sử dụng trong task. Các lệnh chạy mẫu chi tiết để phục vụ task tiếp theo. Giúp coding agent làm việc với task tiếp theo nhanh hơn, đúng quy trình hơn
### 5. Những khó khăn và vấn đề đã gặp phải
- Mô tả các lỗi, blocker, khó khăn kỹ thuật đã xuất hiện.
- Ghi rõ tình trạng xử lý (đã giải quyết / giải quyết một phần / vẫn còn tồn tại).
- Nêu các rủi ro hoặc technical debt nếu có.
### 6. Các điểm cần lưu ý quan trọng
- Các quyết định thiết kế / công nghệ đã đưa ra
- Các giả định được sử dụng
- Các TODO hoặc công việc còn dang dở
- Các lưu ý về best practice, security, performance, maintainability
- Những thứ dễ bị quên hoặc cần kiểm tra lại sau này
### 7. Trạng thái hiện tại sau phiên làm việc
- Tóm tắt ngắn gọn tình trạng hiện tại của dự án sau khi kết thúc session (code đang ở mức nào, đã ổn định chưa, còn vấn đề gì nổi bật).
**Quy tắc khi tóm tắt:**
- Chỉ sử dụng thông tin có thực trong session log. Không được bịa đặt hay suy đoán.
- Nếu thông tin không rõ ràng, ghi rõ: **"Không rõ ràng từ session"**.
- Ưu tiên tính chính xác và tính hữu ích cho việc duy trì context.
- Viết ngắn gọn, dễ đọc, sử dụng bullet points và in đậm các nội dung quan trọng.
- Giọng điệu trung lập, khách quan.
## Yêu cấu tiếp theo:
{YEUCAU:textarea:Chưa có}
8/23/2026, 11:19:38 AM
Trả git diff
{YEUCAU:textarea:Với yêu cầu trên:required}
Trả diff theo yêu cầu bên dưới. Trả dạng có thể dùng git diff apply được. 1 file patch liền mạch không đánh dấu bằng markdown.
TUYỆT ĐỐI: Không trả ra dạng nhiều
```diff
.....
```
```diff
.....
```
Mà trả ra duy nhất 1 block dạng sau để sẵn sàng copy dùng git apply diff
```diff
Full diff nhiêu 2file
```
Trong diff tạo luôn 1 file trong thư mục docs chứa các logic đã implement, các thay đổi, cách sử dụng (nếu có), các lệnh cần chạy (nếu có)
Kết quả yêu cầu trả ra dạng chuẩn git diff:
Your **ONLY** output will be a series of unified diff blocks (concatenated, one per changed file). No other text, explanations, code blocks, markdown, or apologies are permitted.
### Block Structure (exact format - raw patch, dễ apply bằng `patch -p0`):
```
--- path/to/file.ext
+++ path/to/file.ext
@@ -1,3 +1,3 @@
old line
-old line 2
+new line 2
old line 3
```
- **File path** (first two lines): Must be the exact project-root-relative path (forward slashes `/`).
- **Hunk header**: `@@ -old_start,old_count +new_start,new_count @@` phải chính xác.
- **Lines**: Context lines (không dấu), xóa dùng `-`, thêm dùng `+`. Giữ nguyên thứ tự, indentation, whitespace từ file gốc.
- Multiple files: nối tiếp nhau (không khoảng trắng thừa giữa các block).
- Include enough context in each hunk (3–10 lines) so the patch applies cleanly.
### Specific Cases:
**Modified file (normal change):**
```
--- src/example.py
+++ src/example.py
@@ -1,5 +1,6 @@
def old_function():
print("hello")
+ return True
```
**Newly created file:**
```
--- /dev/null
+++ src/new_feature.py
@@ -0,0 +1,5 @@
+# Full content of the new file here
+def new_function():
+ ...
```
**Deleted file (or delete entire content):**
```
--- src/old_file.py
+++ /dev/null
@@ -1,3 +0,0 @@
-entire content of the old file
```
**Delete only some lines:**
```
--- src/example.py
+++ src/example.py
@@ -2,2 +2,0 @@
- print("to be deleted")
- another_line()
```
**Modified Vue file (example - maintain original order in diff):**
```
--- app/layouts/admin.vue
+++ app/layouts/admin.vue
@@ -1,10 +1,10 @@
<template>
<!-- Original template content -->
</template>
<script setup lang="ts">
- // Original script content
+ // Updated script content
</script>
```
- If no changes are needed → output nothing (empty response).
- Do **not** include any file that is untouched.
7/9/2026, 4:53:20 PM
Làm rõ yêu cầu 2 bước
Với yêu cầu như sau:.
{YEUCAU:textarea:required}
Hãy làm đúng quy trình 2 bước: (1) dùng skill enhancing-requirements để làm rõ (Q&A đủ 2 giai đoạn), (2) dùng planning-implementation để lập kế hoạch chi tiết; lưu lần lượt vào docs/<slug>/ENHANCED_REQUIREMENT.md, docs/<slug>/IMPLEMENTATION_PLAN.md. Không code trước khi hoàn tất 2 bước. Bắt buộc hỏi lại nếu thiếu context và giữ tiếng Việt
7/7/2026, 2:04:50 PM
Tóm tắt session vào bo nho mcp
Dựa trên toàn bộ lịch sử cuộc trò chuyện và công việc chúng ta vừa thực hiện trong session này, hãy ghi nhớ vào bo nho mcp, rõ ràng và mang tính xây dựng theo đúng cấu trúc sau.
**Mục tiêu chính:** Giúp các session làm việc sau hiệu quả hơn, nhanh hơn và giảm thiểu sai sót lặp lại.
### 1. Những việc quan trọng cần ghi nhớ cho session sau
- Liệt kê các yêu cầu then chốt, quyết định thiết kế, quy ước code, cấu trúc thư mục, tiêu chuẩn chất lượng, và các best practices quan trọng liên quan đến task/project.
- Ưu tiên những điểm ảnh hưởng trực tiếp đến tốc độ và chất lượng làm việc.
### 2. Cách làm đúng cho các quy trình chính
- Với mỗi phần quan trọng trong quy trình, hãy mô tả **cách làm đúng** và **lý do nên làm như vậy**.
- Sử dụng ngôn ngữ tích cực, hướng dẫn: "Để đạt được [mục tiêu], cách tốt nhất là...", "Nên làm theo thứ tự sau...", "Cách tối ưu là...".
- Không được dùng từ ngữ tiêu cực như "bạn đã làm sai", "lỗi", "vấn đề". Chỉ tập trung vào cách làm đúng.
### 3. Code mẫu đúng của quy trình
- Cung cấp các đoạn code mẫu sạch, đúng chuẩn, có thể tái sử dụng.
- Tập trung vào những phần hay gặp vấn đề hoặc quan trọng nhất (ví dụ: setup, xử lý lỗi, validation, logging, testing, cấu trúc file, API call, state management...).
- Thêm comment ngắn gọn giải thích tại sao code này là cách làm đúng.
- Ưu tiên code có tính tái sử dụng cao và dễ bảo trì.
### 4. Tóm tắt để làm việc hiệu quả hơn ở session sau
- Checklist những việc nên làm trước khi bắt đầu code.
- Những điểm cần làm rõ ngay từ đầu để tránh ambiguity.
- Các pattern / workflow / quy trình nên tuân thủ.
- Lời khuyên cụ thể để session sau nhanh hơn và ít phải sửa chữa hơn.
- Bất kỳ lưu ý quan trọng nào về context, dependencies, môi trường hoặc thứ tự thực hiện.
**Yêu cầu khi ghi vào bo nho mcp**
- Viết ngắn gọn, dễ đọc, dùng bullet points và markdown rõ ràng.
- Tập trung vào giá trị thực tế cho lần sau.
- Không được dùng ngôn ngữ đổ lỗi hoặc tiêu cực.
- Nếu phần nào không có thông tin thì bỏ qua hoặc ghi rõ "Không áp dụng trong session này".
6/20/2026, 8:36:07 AM
FE dev Lotto
Tôi cần bạn sửa responsive UI cho [URL].
BẮT BUỘC:
- Đọc /media/tri/Data/www/lottotest/HuongDanDebug.md trước
- Dùng dev browser kiểm tra hiện trạng trước khi sửa
- Nếu là popup thì phải click mở popup thật để test
- Test đúng các màn hình: 360, 390, 480
- Dùng look_at để xác nhận screenshot
- Sửa xong phải build lại frontend rồi test lại
PHẠM VI:
- Chỉ sửa [phần cụ thể]
- Không đụng [phần không muốn sửa]
- Không đụng desktop nếu tôi không yêu cầu
- Không refactor ngoài phạm vi
NGUYÊN TẮC:
- Diff nhỏ nhất có thể
- Màn nào không lỗi thì không sửa
- Không tự đổi font-size / màu / spacing / cấu trúc nếu tôi chưa yêu cầu
- Nếu cần đồng bộ, hãy match theo [URL chuẩn]
CÁCH LÀM:
1. Báo hiện trạng trước sửa
2. Nêu file liên quan
3. Sửa
4. Build
5. Re-test đủ màn
6. Gửi report + screenshot path
CHỈ THÀNH CÔNG KHI:
- Không còn lỗi trên đúng các màn tôi nêu
- Screenshot xác nhận đúng
- Không phát sinh lệch ở vùng ngoài scope
4/15/2026, 1:41:27 PM
Lấy yêu cầu cụ thể
Nếu sau này tôi cần bạn làm các việc ở trên. Giả sử bạn đã quên hoàn toàn các trao đổi của tôi với bạn từ trước đến giờ thì tôi nên gửi yêu cầu tới bạn như thế nào. Yêu cầu thật chi tiết để tránh sau này bạn làm sai quy trình
4/15/2026, 1:24:55 PM
làm rõ yêu cầu
Với yêu cầu như sau:.
{YEUCAU:textarea:required}
Hãy làm đúng quy trình 3 bước: (1) dùng skill enhancing-requirements để làm rõ (Q&A đủ 2 giai đoạn), (2) dùng planning-implementation để lập kế hoạch chi tiết, (3) tạo task breakdown; lưu lần lượt vào docs/<slug>/ENHANCED_REQUIREMENT.md, docs/<slug>/IMPLEMENTATION_PLAN.md, docs/<slug>/TASK_BREAKDOWN.md. Không code trước khi hoàn tất 3 bước. Bắt buộc hỏi lại nếu thiếu context và giữ tiếng Việt
4/1/2026, 8:01:52 AM
Review Plan
Kiểm tra kế hoạch trong {THUMUC} đã ổn chưa. Có rủi ro gì không? Đã sẵn sàng implement chưa. Không dùng từ chuyên ngành nhiều, giải thích kỹ càng để người dùng hiểu. Nếu cần chốt đưa ra một vài phương án cho người dùng lựa chọn
4/1/2026, 7:01:59 AM
Implement Code
Implement theo các tài liệu trong thư mục {THUMUC}
Hãy đọc lại toàn bộ, tóm tắt scope 5-10 dòng. Hỏi tôi các câu hỏi còn vướng mắc (nếu có), đợi tôi trả lời. Rồi thực hiện tuần tự theo breakdown (phase-by-phase), mỗi phase báo tiến độ + file đã sửa + cách verify. Không làm ngoài scope.
3/24/2026, 7:53:57 PM