Khoảng 50 phút
Kho Prompt
42 prompt, đầy đủ, gom từ mọi bài có đăng prompt.
Mỗi prompt đều dẫn ngược về bài giải thích vì sao nó được viết như vậy — ràng buộc nào quan trọng, và bỏ đi thì hỏng ở đâu. Copy prompt mà bỏ phần ngữ cảnh đó thì nó vẫn chạy, chỉ là không còn là thứ đã được kiểm chứng nữa.
Tải cả 42 prompt trong một file
Workshop AI-Driven SDLC
Buổi 2 · Activity 1 — Khám phá yêu cầu với AI
Business Context
14 dòng · nguồn
Bạn là một Senior Business Analyst.
Task Goal: hiểu bài toán nghiệp vụ của chức năng
Dynamic Appointment Rescheduling & Waiting List Management.
Trước khi đề xuất yêu cầu, hãy:
- Xây dựng Business Context từ hiện trạng hệ thống MedBook.
- Xác định các thông tin liên quan trực tiếp tới bài toán.
- Tóm tắt bài toán thành Business Problem Canvas.
Yêu cầu:
- Chỉ sử dụng thông tin có trong case study.
- Không tự tạo Business Rules mới.
- Những nội dung chưa đủ căn cứ phải được đánh dấu "Cần xác nhận".Requirement Clarification
18 dòng · nguồn
Bạn là một Senior Business Analyst.
Task Goal: làm rõ các yêu cầu còn thiếu của chức năng
Dynamic Appointment Rescheduling & Waiting List Management.
Trước khi xây dựng User Stories:
- Phân tích Business Context.
- Xác định các Information Gaps còn tồn tại.
- Đề xuất các câu hỏi cần làm rõ với stakeholder.
Không đề xuất giải pháp.
Không sinh User Stories.
Không giả định Business Rules chưa được xác nhận.
Đối với mỗi câu hỏi, hãy chỉ rõ:
- Thiếu thông tin gì.
- Vì sao thông tin này quan trọng.
- Stakeholder nào nên xác nhận.User Stories
12 dòng · nguồn
Bạn là Senior Business Analyst.
Dựa trên Business Problem Canvas và Requirement Clarification Log (đã được xác
nhận), hãy xây dựng các User Stories cho chức năng Dynamic Appointment
Rescheduling and Waiting List Management.
Yêu cầu:
- Nhóm theo actor: Patient, Doctor, Medical Staff, System Administrator.
- Mỗi User Story chỉ mô tả một mục tiêu chính.
- Không tự quyết các Business Rules chưa được xác nhận.
- Đánh dấu rõ User Story nào phụ thuộc vào Assumption hoặc Open Question.
- Ưu tiên các User Stories cần thiết để tạo Minimum Viable Product.Acceptance Criteria
14 dòng · nguồn
Bạn là Senior Business Analyst.
Dựa trên User Story và các Business Rules đã được xác nhận, hãy xây dựng
Acceptance Criteria theo định dạng Given - When - Then.
Yêu cầu:
- Bao phủ Happy Path.
- Có ít nhất 01 Alternative Flow.
- Có ít nhất 01 Exception.
- Bao gồm trường hợp bệnh nhân từ chối.
- Bao gồm trường hợp bệnh nhân không phản hồi trong thời gian quy định.
- Bao gồm trường hợp khung giờ khám không còn khả dụng.
- Chỉ sử dụng các Business Rules đã được xác nhận.
- Những nội dung chưa rõ phải được đánh dấu "Open Question", không tự suy diễn.Requirement Review
19 dòng · nguồn
Bạn là Senior Business Analyst và Software Architect.
Hãy review toàn bộ Requirement Package và xác định các vấn đề có thể ảnh hưởng
đến quá trình thiết kế và phát triển hệ thống.
Kiểm tra các nội dung sau:
- Yêu cầu còn thiếu (Missing Requirements).
- Nội dung mơ hồ hoặc chưa rõ ràng (Ambiguous Requirements).
- Yêu cầu mâu thuẫn (Conflicting Requirements).
- User Stories trùng lặp hoặc chồng chéo.
- Assumptions và Open Questions chưa được xác nhận.
- Edge Cases chưa được xử lý.
- Yêu cầu chưa phù hợp với hệ thống hoặc API/Service hiện có.
- Thiếu yêu cầu phi chức năng (Performance, Security, Privacy, Reliability...).
- Rủi ro về Privacy, Security và Fairness.
- Những nội dung cần stakeholder đưa ra quyết định.
Không tự sửa Business Rules hoặc Requirement. Chỉ nêu vấn đề, phân tích tác động
và đề xuất các câu hỏi hoặc nội dung cần được xác nhận.Ưu tiên theo MoSCoW
16 dòng · nguồn
Bạn là Senior Business Analyst.
Dựa trên Requirement Package, hãy đề xuất mức độ ưu tiên cho từng User Story
theo phương pháp MoSCoW.
Khi đánh giá, xem xét các yếu tố sau:
- Business Value.
- Mức độ cần thiết đối với luồng nghiệp vụ chính.
- Phụ thuộc giữa các User Stories.
- Rủi ro nếu không triển khai.
- Khả năng tận dụng API/Service hiện có.
- Độ phức tạp triển khai (ước tính).
Không đưa ra quyết định cuối cùng.
Hãy giải thích ngắn gọn lý do cho từng mức ưu tiên và nêu rõ những trường hợp
cần Human xem xét.Buổi 2 · Activity 2 — Kiến trúc và thiết kế hệ thống với AI
Impact Analysis
30 dòng · nguồn
Bạn là Software Architect đang phân tích tác động của một requirement change
trên hệ thống MedBook.
Trước tiên, từ Requirement Context và Current System Context, hãy lựa chọn và
tổng hợp các thông tin liên quan để xây dựng Task-specific Context cho nhiệm vụ
Impact Analysis, bao gồm:
- Prioritized User Stories liên quan.
- Acceptance Criteria liên quan.
- Business Rules ảnh hưởng đến thiết kế.
- Existing Modules và Services liên quan.
- Existing APIs liên quan.
- Database entities hoặc dữ liệu liên quan.
- Technical, Security và Privacy Constraints.
- Open Questions hoặc Assumptions cần lưu ý.
Sau đó, dựa trên Task-specific Context, hãy thực hiện Impact Analysis và xác định:
- Thành phần có thể tái sử dụng.
- Thành phần cần mở rộng hoặc thay đổi.
- Thành phần mới cần bổ sung.
- API cần thêm hoặc điều chỉnh.
- Dữ liệu cần bổ sung hoặc thay đổi.
- Luồng nghiệp vụ và integration point bị ảnh hưởng.
- Dependency giữa các thành phần.
- Rủi ro do thay đổi gây ra.
Không đề xuất thiết kế lại toàn bộ hệ thống.
Ưu tiên tái sử dụng các module, service, API và cấu trúc dữ liệu hiện có khi
phù hợp.
Không tự tạo Business Rules hoặc Requirement mới. Những nội dung chưa rõ phải
được đánh dấu "Cần xác nhận".Architecture Exploration
27 dòng · nguồn
Bạn là Software Architect chịu trách nhiệm mở rộng hệ thống MedBook để hỗ trợ
chức năng Dynamic Appointment Rescheduling and Waiting List Management.
Hệ thống MedBook đã có kiến trúc và các chức năng đang vận hành. Mục tiêu của
bạn không phải thiết kế lại toàn bộ hệ thống, mà là đề xuất các phương án mở
rộng (architecture evolution) với mức thay đổi tối thiểu.
Dựa trên Task-specific Context, Impact Analysis và Current System Context, hãy
đề xuất ít nhất 03 phương án kiến trúc khác nhau.
Với mỗi phương án, hãy:
- Tận dụng tối đa các component, service, API và database hiện có.
- Chỉ bổ sung hoặc thay đổi những thành phần thực sự cần thiết.
- Mô tả kiến trúc mức cao và các thành phần bị ảnh hưởng.
- Giải thích cách tích hợp với kiến trúc hiện tại.
- Mô tả chiến lược xử lý Concurrency, Consistency và Failure Recovery.
- Phân tích ưu điểm, hạn chế, trade-offs và rủi ro của từng phương án.
- Nêu điều kiện phù hợp để áp dụng từng phương án.
Trong quá trình đề xuất, hãy ưu tiên:
- Khả năng tái sử dụng các thành phần hiện có.
- Giảm thiểu ảnh hưởng đến các chức năng đang vận hành.
- Hạn chế thay đổi database và public APIs nếu không thực sự cần thiết.
- Duy trì tính tương thích ngược (backward compatibility).
- Đảm bảo hệ thống có thể mở rộng và dễ bảo trì trong tương lai.
Không lựa chọn phương án cuối cùng thay cho con người.Đánh giá kiến trúc
25 dòng · nguồn
Bạn là Software Architect của hệ thống MedBook.
Dựa trên Impact Analysis và 03 phương án kiến trúc đã đề xuất, hãy đánh giá từng
phương án theo các tiêu chí sau:
- Mức độ phù hợp với kiến trúc hiện tại
- Độ phức tạp triển khai
- Khả năng bảo trì
- Khả năng mở rộng
- Độ tin cậy (Reliability)
- Security & Privacy
- Chi phí vận hành
- Khả năng rollback
- Mức độ phù hợp với năng lực hiện tại của đội ngũ
- Thời gian triển khai
Đối với mỗi tiêu chí:
- Chấm điểm từ 1 (thấp) đến 5 (cao).
- Giải thích ngắn gọn lý do đánh giá.
- Chỉ ra các rủi ro hoặc giả định cần lưu ý.
Cuối cùng:
- Xếp hạng các phương án theo mức độ phù hợp.
- Phân tích các trade-offs của từng phương án.
- Chỉ ra những quyết định cần Software Architect xem xét thay vì để AI tự quyết.
- Nêu các thông tin còn thiếu để có thể đưa ra quyết định cuối cùng.Phản biện
8 dòng · nguồn
Đóng vai một Software Architecture Reviewer độc lập.
Hãy phản biện kết quả đánh giá ở trên bằng cách:
- Chỉ ra các giả định chưa hợp lý.
- Phát hiện các rủi ro còn bỏ sót.
- Nêu những trường hợp mà một phương án khác sẽ phù hợp hơn.
- Đề xuất các câu hỏi mà Software Architect nên xem xét trước khi đưa ra quyết
định cuối cùng.Thiết kế component
21 dòng · nguồn
Bạn là Software Architect của hệ thống MedBook.
Dựa trên Architecture Decision, hãy thiết kế các component để hiện thực hóa chức
năng Dynamic Appointment Rescheduling and Waiting List Management.
Đối với mỗi component, hãy xác định:
- Vai trò (Reuse / Extend / New)
- Trách nhiệm chính (Responsibilities)
- Business Rules mà component chịu trách nhiệm
- Component hoặc Service tương tác
- Input
- Output
Đồng thời:
- Kiểm tra xem component nào đang đảm nhận quá nhiều trách nhiệm.
- Đề xuất tách hoặc gộp component nếu cần.
- Đảm bảo mỗi Business Rule chỉ thuộc về một component.
- Giải thích ngắn gọn lý do của các quyết định thiết kế.
Nếu cần làm rõ một component hoặc interface hiện có, hãy tham khảo Current
System Context.Phản biện
14 dòng · nguồn
Đóng vai Software Architecture Reviewer.
Đánh giá thiết kế component theo các tiêu chí sau:
- Single Responsibility Principle (SRP)
- Cohesion
- Coupling
- Khả năng tái sử dụng
- Khả năng mở rộng
- Khả năng bảo trì
Nếu phát hiện vấn đề:
- Chỉ rõ component chưa hợp lý.
- Giải thích nguyên nhân.
- Đề xuất phương án cải tiến.Thiết kế API & tương tác
27 dòng · nguồn
Bạn là Solution Architect của hệ thống MedBook.
Dựa trên Requirement Context và Component Design, hãy thiết kế API và luồng
tương tác cho chức năng: khi một slot khám trở nên khả dụng, hệ thống lựa chọn
bệnh nhân phù hợp, gửi offer và xử lý phản hồi của bệnh nhân.
Task 1 - Build Business Flow Context
Từ Requirement Context, hãy truy xuất các thông tin liên quan đến luồng nghiệp
vụ trên. Xác định: Business Goal, Trigger, Actors, User Stories liên quan,
Acceptance Criteria, Business Rules, Preconditions, Postconditions, Alternative
Flows, Exception Conditions, Open Questions.
Nếu thiếu thông tin, ghi rõ "Cần xác nhận", không tự giả định.
Task 2 - Design Interaction Flow
Với mỗi bước, hãy xác định: Actor hoặc Component thực hiện, hành động, API hoặc
Event được sử dụng, Input, Output, trạng thái được tạo hoặc thay đổi.
Phân biệt rõ Main Flow, Alternative Flow và Exception Flow.
Task 3 - Design API and Event Contracts
Đối với mỗi API hoặc Event: Existing / Modified / New, Provider, Consumer,
Purpose, Request hoặc Event Payload, Response hoặc Output, Error Response.
Ưu tiên tái sử dụng API hiện có trước khi đề xuất API mới.
Task 4 - Analyze Runtime Behaviors
Đối với từng interaction quan trọng, hãy phân tích: Timeout, Retry Policy, Error
Handling, Concurrency Control, Idempotency, Rollback hoặc Compensation.
Nếu phát hiện rủi ro hoặc điểm nghẽn, hãy đề xuất cải tiến.Thiết kế dữ liệu & trạng thái
41 dòng · nguồn
Bạn là Data Architect của hệ thống MedBook.
Dựa trên Requirement Context, Current Data Model, Component Design và Interaction
Flow, hãy thiết kế phần mở rộng dữ liệu và trạng thái cần thiết cho chức năng
Dynamic Appointment Rescheduling and Waiting List Management.
Task 1 - Build Data Design Context
Truy xuất: Business Rules ảnh hưởng đến dữ liệu, Acceptance Criteria liên quan
đến trạng thái và lưu trữ, existing entities và attributes có thể tái sử dụng,
existing relationships, data constraints, audit/privacy/retention requirements,
và những thông tin còn thiếu cần xác nhận.
Không tự giả định khi thông tin chưa được cung cấp.
Task 2 - Identify Data Model Changes
Xác định: entity hiện có được tái sử dụng, entity cần mở rộng, entity mới, thuộc
tính mới, quan hệ mới hoặc cần thay đổi, constraint và uniqueness rule, dữ liệu
phục vụ concurrency, idempotency và audit.
Với mỗi thay đổi, mô tả: Change Type (Reuse / Extend / New), mục đích, thuộc
tính chính, trạng thái hoặc vòng đời, quan hệ với entity khác, component sở hữu,
các ràng buộc dữ liệu.
Không tạo entity mới nếu có thể mở rộng hoặc tái sử dụng entity hiện có một cách
hợp lý.
Task 3 - Design State Transition
Trước tiên, hãy xác định đối tượng phù hợp để quản lý vòng đời của một offer đặt
lịch. AppointmentOffer nên là một entity độc lập, một phần mở rộng của entity
hiện có, hay một trạng thái của entity hiện có?
Sau khi xác định, hãy thiết kế State Transition gồm: Current State, Triggering
Event, Transition Condition, Action hoặc dữ liệu được cập nhật, Next State,
Invalid Transition, Terminal State.
Phải xem xét: Accepted, Rejected, Expired, Cancelled, Timeout, offer được thay
thế, slot đã được bệnh nhân khác xác nhận, event bị gửi hoặc xử lý lặp lại.
Task 4 - Review Data Integrity and Lifecycle
Kiểm tra: có trùng lặp với dữ liệu hiện có không, có thiếu entity/thuộc tính/
quan hệ không, có trạng thái không thể đạt tới hoặc không thể thoát ra không, có
transition không hợp lệ chưa được kiểm soát không, có nguy cơ cập nhật đồng thời
hoặc mất dữ liệu không, có hỗ trợ idempotency và optimistic locking không, có đủ
timestamp và audit information không, có lưu dữ liệu nhạy cảm không cần thiết
không, có chính sách retention hoặc deletion phù hợp không.
Nếu phát hiện vấn đề, hãy đề xuất cải tiến và ghi rõ phần cần con người xác nhận.Security & Reliability Review
20 dòng · nguồn
Dựa trên Requirement Context và Design Context, hãy review thiết kế theo bốn
góc nhìn:
- Security & Privacy
- Concurrency & Data Consistency
- Failure Handling & Recovery
- Business Risks
Với mỗi rủi ro, hãy xác định:
- Mô tả rủi ro.
- Thành phần hoặc luồng bị ảnh hưởng.
- Mức độ ảnh hưởng (High / Medium / Low).
- Biện pháp giảm thiểu.
- Có cần Human quyết định hay không.
Không thay đổi Business Rules. Nếu thiếu thông tin, hãy ghi rõ Open Question.
Ba tình huống bắt buộc phải xem xét:
- Hai bệnh nhân chấp nhận cùng một slot gần như đồng thời.
- Notification gửi thất bại nhưng offer vẫn đang đếm thời gian.
- Bệnh nhân chấp nhận offer sau khi offer đã hết hạn.Traceability Review
19 dòng · nguồn
Bạn là Software Architecture Reviewer.
Dựa trên Requirement Context và Design Context, hãy đánh giá mức độ đáp ứng của
thiết kế đối với các yêu cầu ban đầu.
Đối với mỗi Requirement hoặc User Story, hãy xác định:
- Component chịu trách nhiệm.
- Requirement đã được đáp ứng hay chưa.
- Acceptance Criteria đã được hỗ trợ hay chưa.
- Business Rules có bị bỏ sót không.
- Có component nào không phục vụ requirement nào không.
Cuối cùng hãy liệt kê:
- Missing Requirements
- Missing Acceptance Criteria
- Missing Business Rules
- Unused Components
- Open Questions
- Improvement SuggestionsBuổi 3 · Activity 1 — Phát triển với AI
Lập kế hoạch task
20 dòng · nguồn
Bạn là một Technical Lead đang lập kế hoạch phát triển chức năng Dynamic Appointment
Rescheduling & Waiting List Management cho hệ thống MedBook.
Dựa trên:
- AI-Ready Specification Package
- Architecture Blueprint
Hãy phân rã feature thành các coding tasks có thể triển khai độc lập.
Không sinh mã nguồn.
Đối với mỗi task, hãy xác định:
- Mục tiêu của task
- User Story và Acceptance Criteria liên quan
- Thành phần chính bị ảnh hưởng (UI, API, Service, Database...)
- Các task phụ thuộc (nếu có)
- Mức độ ưu tiên
- Ước lượng độ phức tạp (Low / Medium / High)
Cuối cùng, đề xuất một coding task phù hợp nhất để thực hiện trong phạm vi
workshop và giải thích lý do lựa chọn.Development Context
45 dòng · nguồn
Bạn là một Senior Full-Stack Software Engineer chuẩn bị hiện thực hóa một coding
task của chức năng Dynamic Appointment Rescheduling & Waiting List Management
trên hệ thống MedBook.
Coding task
- Task ID: [Task ID]
- Task name: [Tên task]
- Task objective: [Mục tiêu của task]
- Related User Story: [User Story liên quan]
Dựa trên:
- AI-Ready Specification Package
- Architecture Blueprint
- Existing Source Code
- Existing APIs
- Existing Data Model
- Coding Standards
Hãy xây dựng Task Context cho coding task trên.
Không sinh mã nguồn và không lập kế hoạch coding ở bước này.
Chỉ truy xuất và trình bày những thông tin liên quan trực tiếp đến task:
- Requirement, User Story và Acceptance Criteria liên quan
- Business Rules cần hiện thực
- Module, màn hình hoặc UI component liên quan
- Service, API hoặc utility có thể tái sử dụng hoặc cần thay đổi
- Data entity, DTO và trạng thái dữ liệu liên quan
- Source code hoặc file hiện có cần xem xét
- Coding conventions và technical constraints
- Dependencies và technical risks
- Assumptions, thông tin còn thiếu hoặc câu hỏi cần Human xác nhận
Với mỗi nội dung, hãy chỉ rõ:
- Thông tin hoặc thành phần liên quan.
- Mối liên hệ với coding task.
- Cách dự kiến sử dụng, tái sử dụng hoặc thay đổi.
- Requirement, Business Rule hoặc Acceptance Criteria làm căn cứ.
Yêu cầu:
- Không đưa vào các thông tin không liên quan trực tiếp đến task.
- Không tự tạo thêm Business Rule, API contract hoặc giả định mới.
- Không đề xuất thay đổi ngoài phạm vi của coding task.
- Nội dung chưa có đủ căn cứ phải được đánh dấu Cần xác nhận.
- Nếu không tìm thấy thông tin cần thiết trong các tài liệu đầu vào, phải nêu rõ
thông tin còn thiếu thay vì tự suy luận.Viết code
22 dòng · nguồn
Bạn là một Senior Full-Stack Software Engineer đang hiện thực hóa một coding task
của chức năng Dynamic Appointment Rescheduling & Waiting List Management trên hệ
thống MedBook.
Dựa trên:
- Development Context
- Existing Source Code
- Coding Standards
Hãy hiện thực coding task đã lựa chọn.
Trước khi sinh mã nguồn, hãy tóm tắt ngắn gọn:
- Những thành phần sẽ được thay đổi hoặc tái sử dụng.
- Những Business Rules sẽ được hiện thực.
- Những giả định hoặc thông tin cần Human xác nhận (nếu có).
Sau đó:
- Sinh mã nguồn cho coding task.
- Tóm tắt các thay đổi đã thực hiện.
- Liệt kê những nội dung chưa được hiện thực (nếu có).
Không mở rộng phạm vi ngoài Development Context.Unit Testing
23 dòng · nguồn
Bạn là một Senior Software Engineer và Test Engineer.
Dựa trên:
- Development Context
- Source Code vừa được hiện thực
- Business Rules
- Acceptance Criteria
- Coding Standards
Hãy xây dựng Unit Tests cho coding task đã lựa chọn.
Đối với mỗi test, hãy chỉ rõ:
- Scenario được kiểm thử
- Business Rule hoặc Acceptance Criteria liên quan
- Expected behavior
- Dependency cần mock (nếu có)
Sau đó:
- Sinh Unit Test source code.
- Tóm tắt phạm vi kiểm thử.
- Chỉ ra những trường hợp chưa được bao phủ hoặc khó kiểm thử.
Không tạo Unit Tests ngoài phạm vi của coding task.Code Review
26 dòng · nguồn
Bạn là một Senior Full-Stack Software Engineer đang review mã nguồn và Unit Tests
của một coding task thuộc chức năng Dynamic Appointment Rescheduling & Waiting
List Management trên hệ thống MedBook.
Dựa trên:
- Development Context
- Source Code
- Unit Tests
- Business Rules và Acceptance Criteria liên quan
- Coding Standards
Hãy review code và tập trung vào các vấn đề có ảnh hưởng đáng kể đến:
- Functional correctness
- Business Rule compliance
- Maintainability
- Reliability
- Security
- Unit Test quality
Với mỗi vấn đề, hãy trình bày:
- Vấn đề và vị trí liên quan
- Mức độ: Critical / Major / Minor
- Tác động
- Đề xuất cải thiện
Không sửa mã nguồn cho đến khi Human xác nhận.Development Quality Gate
29 dòng · nguồn
Bạn là Technical Lead của dự án MedBook.
Dựa trên:
- Task Plan
- Development Context
- Source Code và Coding Log
- Unit Tests và Unit Test Report
- Code Review Report
Hãy đánh giá mức độ sẵn sàng của coding task trước khi bàn giao sang Quality
Assurance.
Đối với từng tiêu chí sau, hãy đánh giá Đạt / Chưa đạt và nêu bằng chứng:
- Coding task được thực hiện đúng phạm vi.
- Business Rules và Acceptance Criteria liên quan đã được hiện thực.
- Unit Tests đã được thực thi và đạt yêu cầu.
- Code Review đã hoàn thành.
- Không còn Critical Issue chưa được xử lý.
- Các hạn chế, giả định và rủi ro còn lại đã được ghi nhận.
Cuối cùng, hãy:
- Tóm tắt những gì đã được hoàn thành.
- Chỉ ra các rủi ro hoặc vấn đề còn tồn tại.
- Đề xuất một trong hai kết quả:
- PASS - Ready for QA
- FAIL - Not Ready for QA
Nếu kết quả là FAIL, hãy chỉ ra những công việc cần hoàn thành trước khi bàn
giao.Buổi 3 · Activity 2 — QA và Release Readiness với AI
QA Context
18 dòng · nguồn
Bạn là một QA Lead chịu trách nhiệm chuẩn bị hoạt động kiểm thử cho một feature
trước khi bắt đầu Quality Assurance.
Dựa trên Business Context và Development Package, hãy xây dựng QA Context cho
feature.
Trong đó, hãy xác định:
- Phạm vi kiểm thử.
- Các thành phần cần kiểm thử.
- Business Rules và Acceptance Criteria cần xác minh.
- Các luồng nghiệp vụ và Integration Points quan trọng.
- Các rủi ro cần ưu tiên.
- Đề xuất loại kiểm thử phù hợp (API Testing, Integration Testing và/hoặc
End-to-End Testing).
Không thiết kế test cases ở bước này.
Nếu thiếu thông tin cần thiết, hãy đánh dấu Cần xác nhận thay vì tự đưa ra giả
định.Thiết kế & thực thi test
19 dòng · nguồn
Bạn là một Senior QA Engineer chịu trách nhiệm kiểm thử feature.
Dựa trên QA Context, hãy thiết kế và hỗ trợ thực hiện loại kiểm thử đã được lựa
chọn.
Đối với mỗi test scenario, hãy xác định:
- Mục tiêu kiểm thử.
- Business Rule hoặc Acceptance Criteria liên quan.
- Test data hoặc preconditions.
- Expected Result.
Nếu phù hợp, hãy sinh mã nguồn kiểm thử theo framework của dự án.
Sau khi thực thi (hoặc nhận kết quả thực thi từ Human), hãy:
- Tổng hợp kết quả.
- Chỉ ra các test pass hoặc fail.
- Ghi nhận các lỗi hoặc hành vi bất thường được phát hiện.
Không thiết kế các kịch bản ngoài phạm vi QA Context.Phân tích kết quả test
19 dòng · nguồn
Bạn là một QA Lead chịu trách nhiệm phân tích kết quả kiểm thử của feature.
Dựa trên:
- Test Execution Report
- Business Context
- Development Package
Hãy phân tích kết quả kiểm thử.
Nếu phát hiện defects, hãy:
- Phân loại mức độ ảnh hưởng (Critical, High, Medium hoặc Low).
- Xác định Business Rule hoặc Acceptance Criteria bị ảnh hưởng.
- Đề xuất nguyên nhân có thể xảy ra.
- Đề xuất hướng xử lý và Regression Tests cần thực hiện sau khi sửa.
Nếu không phát hiện defects, hãy tóm tắt các bằng chứng cho thấy feature đã đáp
ứng phạm vi kiểm thử.
Không đưa ra kết luận Release Readiness ở bước này.QA Assessment
22 dòng · nguồn
Bạn là một QA Lead chịu trách nhiệm đánh giá kết quả Quality Assurance của feature.
Dựa trên:
- QA Context
- Test Execution Report
- Test Analysis Report
- Development Handoff
Hãy tổng hợp kết quả kiểm thử và đánh giá chất lượng của feature.
Đối với từng Business Rule hoặc Acceptance Criteria đã được kiểm thử, hãy chỉ rõ:
- Đã được xác minh hay chưa.
- Bằng chứng kiểm thử liên quan.
- Những rủi ro hoặc hạn chế còn tồn tại.
Cuối cùng, hãy đưa ra một trong các khuyến nghị sau:
- Ready for Next Stage
- Ready with Known Risks
- Not Ready
Giải thích rõ căn cứ cho khuyến nghị và các vấn đề cần được xử lý tiếp theo
(nếu có).Buổi 4 · Workshop: các bước thực hiện
Context-Drift Audit
18 dòng · nguồn
Bạn là AI-Assisted Auditor đang rà lại quy trình SDLC của một nhóm vừa hoàn thành
Day 1-3 của case study MedBook.
Dựa trên:
- SDLC Artifact Map của nhóm (Day 1)
- Specification Package đã dùng làm input cho Day 3 (Day 2)
- Development Package và source code thật đã sinh ra (Day 3)
Hãy đối chiếu và trả lời: Source code Day 3 có khớp với ĐÚNG phiên bản spec mới
nhất của Day 2 không? Chỉ ra bằng chứng cụ thể (tên bảng, tên endpoint, business
rule) - không kết luận chung chung "có vẻ khớp". Có artifact nào ở Day 2 bị thay
thế/cập nhật sau đó mà Day 3 vẫn dùng bản cũ không? Có quyết định nào ở Day 1
(Human-AI Responsibility Matrix, checkpoint) bị bỏ qua trong thực tế triển khai
Day 3 không?
Với mỗi điểm đứt gãy tìm được, ghi rõ: đứt gãy nằm giữa phase nào và phase nào,
hậu quả cụ thể, và bằng chứng (trích dẫn file + dòng hoặc đoạn artifact). Không
tự suy diễn nếu không có bằng chứng - đánh dấu "Cần xác nhận với nhóm".Audit code & coverage
17 dòng · nguồn
Bạn là AI-Assisted Auditor. Đọc trực tiếp source code và test suite hiện có của
nhóm (không dùng báo cáo cũ, không suy đoán từ tên file) và đối chiếu với đúng
bản Business Rules đã FROZEN.
Với từng Business Rule:
- Trỏ tới đúng file/hàm hiện thực nó.
- Trỏ tới đúng test (nếu có) kiểm chứng nó, ghi rõ tên test.
- Nếu một phần của rule không có test nào chạm tới, ghi rõ đó là "gap", không
phải "covered".
- Nếu code có hàm không được gọi ở đâu cả (dùng grep xác nhận, không đoán), liệt
kê là dead code.
- Nếu một đoạn code có comment giải thích Ý NGHĨA nhưng không giải thích LÝ DO
CHỌN cách làm này thay vì cách làm mà quy ước phần còn lại của repo đang dùng,
đánh dấu là "thiếu ngữ cảnh".
Trình bày dưới dạng bảng: Business Rule -> File hiện thực -> Test kiểm chứng ->
Trạng thái (Có test / Gián tiếp / Không có test).Phân loại nguyên nhân gốc
10 dòng · nguồn
Với danh sách finding ở Bước 1 và Bước 2, hãy gắn đúng 1 trong 5 nhãn nguyên nhân
gốc (Spec sai/thiếu · AI tự bịa khi thiếu ngữ cảnh · Human review bỏ sót ·
Process không có checkpoint · Kỹ thuật/concurrency) và mức độ (Critical / Major /
Minor).
Giải thích ngắn gọn vì sao chọn nhãn đó thay vì nhãn khác - đặc biệt phân biệt rõ
"AI tự bịa" với "Spec sai/thiếu" (AI tự bịa là khi spec KHÔNG nói gì và AI vẫn
quyết; Spec sai/thiếu là khi spec CÓ nói nhưng sai hoặc đã lỗi thời).
Không tự xếp một finding vào nhóm nhẹ hơn để "cho gọn".Governance Charter
20 dòng · nguồn
Bạn là Technical Lead đang thiết kế governance cho quy trình AI-Assisted
Development của nhóm, dựa trên phân loại nguyên nhân gốc ở Bước 3.
Với mỗi nhóm nguyên nhân chiếm tỷ trọng đáng kể, đề xuất một governance rule cụ
thể gồm:
- Rule - hành động bắt buộc, diễn đạt như một điều kiện có thể đúng/sai (không
phải lời khuyên).
- Chặn nguyên nhân nào - trỏ lại đúng nhãn ở Bước 3.
- Cách kiểm chứng - bằng công cụ tự động (test, CI, lint) hay bằng checklist con
người ký xác nhận?
- Chủ sở hữu - vai trò nào (BA / Dev / QA / Tech Lead) chịu trách nhiệm rule này
không bị bỏ qua?
Ví dụ tham khảo (không copy nguyên văn, phải khớp với finding thật của nhóm):
"Trước khi bắt đầu coding task mới, AI phải trích dẫn lại đúng tên file + ngày
FROZEN của spec đang dùng làm input, và Human xác nhận đó là bản mới nhất trước
khi cho phép sinh code."
Không đề xuất rule chung chung không đo lường được (vd. "review kỹ hơn", "cẩn
thận khi prompt").Từ các bài viết theo video
Bảy nâng cấp cho một prompt
Tip 1: định nghĩa sản phẩm cuối
1 dòng · nguồn
Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học. Đầu ra gồm 3 phần: Lịch đăng bài theo từng ngày, danh sách 5 email gửi học viên kèm tiêu đề hấp dẫn, và bảng phân bổ ngân sách quảng cáo dự kiến.Tip 2: thêm bối cảnh thật
9 dòng · nguồn
Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị bóp nghẹt/giảm sút; mục tiêu chính của đợt này là dùng nội dung và quảng cáo để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín để chăm sóc và mở bán trực tiếp.
ĐẦU RA CẦN CÓ (Gồm 3 phần):
Lịch đăng bài 14 ngày: Mỗi ngày 1 bài, ghi rõ tiêu đề thu hút (Hook), nội dung cốt lõi và lời kêu gọi hành động (CTA) dẫn về nhóm Zalo.
Danh sách 5 email: Kèm tiêu đề hấp dẫn và tóm tắt thông điệp chính theo lộ trình từ gợi mở vấn đề → trao giá trị → mở cổng đăng ký.
Bảng phân bổ ngân sách 5 triệu đồng: Chia chi tiết cho từng giai đoạn và định dạng bài chạy quảng cáo phù hợp nhất với team 2 người.Tip 3: thêm rào chắn
13 dòng · nguồn
Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị bóp nghẹt/giảm sút; mục tiêu chính của đợt này là dùng nội dung và quảng cáo để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín để chăm sóc và mở bán trực tiếp.
RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng biệt ngữ phức tạp: Tuyệt đối không dùng các thuật ngữ marketing/học thuật quá hàn lâm; cách diễn đạt phải gãy gọn, tự nhiên, đánh trúng tâm lý người đi làm bận rộn.
Không đề xuất giải pháp tốn kém/phức tạp: Không gợi ý mua thêm phần mềm automation trả phí, không tổ chức webinar/livestream đa kênh cồng kềnh (vượt quá sức của team 2 người).
Không viết mở đầu/kết luận rườm rà: Bỏ qua các câu chào hỏi, giới thiệu lý thuyết chung chung hay kết bài xã giao; đi thẳng trực tiếp vào nội dung các bảng kế hoạch.
ĐẦU RA CẦN CÓ (Gồm 3 phần):
Lịch đăng bài 14 ngày: Mỗi ngày 1 bài, ghi rõ tiêu đề thu hút (Hook), nội dung cốt lõi và lời kêu gọi hành động (CTA) dẫn về nhóm Zalo.
Danh sách 5 email: Kèm tiêu đề hấp dẫn và tóm tắt thông điệp chính theo lộ trình từ gợi mở vấn đề → trao giá trị → mở cổng đăng ký.
Bảng phân bổ ngân sách 5 triệu đồng: Chia chi tiết cho từng giai đoạn và định dạng bài chạy quảng cáo phù hợp nhất với team 2 người.Tip 4: thêm mẫu đối chiếu
19 dòng · nguồn
Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị giảm sút; mục tiêu chính là dùng nội dung và ngân sách 5 triệu để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín nhằm chăm sóc và mở bán.
RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng thuật ngữ phức tạp: Tránh từ ngữ marketing/học thuật hàn lâm; diễn đạt gãy gọn, gần gũi với người đi làm.
Không giải pháp tốn kém: Không gợi ý công cụ trả phí phức tạp, không đề xuất tổ chức webinar cồng kềnh quá sức team 2 người.
Không mở/kết bài rườm rà: Đi thẳng vào nội dung bảng kế hoạch, không giải thích lý thuyết chung chung.
BÀI MẪU THAM KHẢO (GOLDEN SAMPLE):
Hãy phân tích cấu trúc, độ dài và phong cách viết của mẫu chuẩn dưới đây để áp dụng đồng nhất cho toàn bộ 14 bài post và 5 email:
[MẪU BÀI VIẾT CHUẨN]:
Tiêu đề (Hook): 'Tăng ca đến 8h tối nhưng vẫn muốn học thêm kỹ năng mới? Đây là giải pháp 20 phút mỗi ngày.'
Nội dung cốt lõi: Đồng cảm với việc kiệt sức sau giờ làm → Chia sẻ 1 mẹo ứng dụng ngay mà không cần học lý thuyết dài dòng → Nhấn mạnh tính thực tế.
CTA (Kêu gọi hành động): 'Mình vừa tổng hợp trọn bộ tài liệu mẫu này vào file PDF ngắn gọn. Nhận tài liệu miễn phí tại Nhóm Zalo: [Link Zalo] (Chỉ nhận trong 24h).'
ĐẦU RA CẦN CÓ (Gồm 3 phần):
Lịch đăng bài 14 ngày: Mỗi ngày 1 bài, chuẩn cấu trúc mẫu (Hook → Nội dung cốt lõi → CTA vào nhóm Zalo).
Danh sách 5 email: Tiêu đề kích thích mở mail + dàn ý thông điệp theo lộ trình (Gợi mở → Trao giá trị → Mở bán) với giọng văn tương tự mẫu chuẩn.
Bảng phân bổ ngân sách 5 triệu đồng: Phân bổ chi tiết ngân sách chạy ads Facebook (ưu tiên bài hút tương tác cao nhất) phù hợp sức tải của team 2 người.Tip 5: bắt AI phỏng vấn ngược
21 dòng · nguồn
Tôi muốn bạn giúp tôi: Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị giảm sút; mục tiêu chính là dùng nội dung và ngân sách 5 triệu để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín nhằm chăm sóc và mở bán.
RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng thuật ngữ phức tạp: Tránh từ ngữ marketing/học thuật hàn lâm; diễn đạt gãy gọn, gần gũi với người đi làm.
Không giải pháp tốn kém: Không gợi ý công cụ trả phí phức tạp, không đề xuất tổ chức webinar cồng kềnh quá sức team 2 người.
Không mở/kết bài rườm rà: Đi thẳng vào nội dung bảng kế hoạch, không giải thích lý thuyết chung chung.
BÀI MẪU THAM KHẢO (GOLDEN SAMPLE):
Áp dụng cấu trúc mẫu chuẩn dưới đây cho toàn bộ 14 bài post và 5 email:
Tiêu đề (Hook): 'Tăng ca đến 8h tối nhưng vẫn muốn học thêm kỹ năng mới? Đây là giải pháp 20 phút mỗi ngày.'
Nội dung cốt lõi: Đồng cảm với việc kiệt sức sau giờ làm → Chia sẻ 1 mẹo ứng dụng ngay → Nhấn mạnh tính thực tế.
CTA: 'Mình vừa tổng hợp trọn bộ tài liệu mẫu này vào file PDF ngắn gọn. Nhận tài liệu miễn phí tại Nhóm Zalo: [Link Zalo] (Chỉ nhận trong 24h).'
ĐẦU RA DỰ KIẾN (Sẽ thực hiện sau):
Phần 1: Lịch đăng bài 14 ngày chuẩn cấu trúc mẫu.
Phần 2: Danh sách 5 email theo phễu (Gợi mở → Trao giá trị → Mở bán).
Phần 3: Bảng phân bổ ngân sách 5 triệu đồng tối ưu cho Facebook ads.
QUY TRÌNH THỰC HIỆN (BẬT CHẾ ĐỘ PHỎNG VẤN NGƯỢC):
CHƯA BẮT ĐẦU TẠO KẾ HOẠCH NGAY LẬP TỨC.
Hãy đóng vai trò là một chuyên gia Chiến lược Nội dung. Trước khi lập kế hoạch, hãy đọc kỹ toàn bộ thông tin trên và đặt cho tôi tối đa 3 câu hỏi quan trọng nhất về những thông tin còn thiếu (ví dụ: tên chủ đề khóa học, quà tặng mồi thu hút vào Zalo, thời điểm mở bán cụ thể...). Hãy hỏi từng câu một và chờ tôi trả lời xong mới bắt tay vào tạo đầu ra hoàn chỉnh.Tip 6: thêm vòng kiểm tra chất lượng
21 dòng · nguồn
Tôi muốn bạn giúp tôi: Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị giảm sút; mục tiêu chính là dùng nội dung và ngân sách 5 triệu để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín nhằm chăm sóc và mở bán.
RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng thuật ngữ phức tạp: Tránh từ ngữ marketing/học thuật hàn lâm; diễn đạt gãy gọn, gần gũi với người đi làm.
Không giải pháp tốn kém: Không gợi ý công cụ trả phí phức tạp, không đề xuất tổ chức webinar cồng kềnh quá sức team 2 người.
Không mở/kết bài rườm rà: Đi thẳng vào nội dung bảng kế hoạch, không giải thích lý thuyết chung chung.
BÀI MẪU THAM KHẢO (GOLDEN SAMPLE):
Áp dụng cấu trúc mẫu chuẩn dưới đây cho toàn bộ 14 bài post và 5 email:
Tiêu đề (Hook): 'Tăng ca đến 8h tối nhưng vẫn muốn học thêm kỹ năng mới? Đây là giải pháp 20 phút mỗi ngày.'
Nội dung cốt lõi: Đồng cảm với việc kiệt sức sau giờ làm → Chia sẻ 1 mẹo ứng dụng ngay → Nhấn mạnh tính thực tế.
CTA: 'Mình vừa tổng hợp trọn bộ tài liệu mẫu này vào file PDF ngắn gọn. Nhận tài liệu miễn phí tại Nhóm Zalo: [Link Zalo] (Chỉ nhận trong 24h).'
ĐẦU RA DỰ KIẾN (Sẽ thực hiện sau):
Phần 1: Lịch đăng bài 14 ngày chuẩn cấu trúc mẫu.
Phần 2: Danh sách 5 email theo phễu (Gợi mở → Trao giá trị → Mở bán).
Phần 3: Bảng phân bổ ngân sách 5 triệu đồng tối ưu cho Facebook ads.
QUY TRÌNH THỰC HIỆN & TIÊU CHÍ CHẤT LƯỢNG (QUALITY CHECK):
Bước 1: trước khi tạo kế hoạch, hãy lập danh sách 3 tiêu chí quan trọng nhất để đánh giá một kế hoạch marketing ra mắt khóa học hiệu quả, thực chiến cho team 2 người và ngân sách 5 triệu (ví dụ: Tính khả thi cao, Nội dung đánh đúng nỗi đau khách hàng, Phễu chuyển đổi rõ ràng vào Zalo).
Bước 2 (Tạo & Tự kiểm tra): Tạo 3 phần đầu ra dự kiến. Sau khi tạo xong, hãy tự đánh giá và chấm điểm kết quả của bạn dựa trên 3 tiêu chí đã lập ở Bước 2. Nếu có chỗ nào chưa đạt điểm tối đa, hãy tự sửa lại ngay lập tức để nâng cao chất lượng trước khi hiển thị kết quả cuối cùng cho tôi.Tip 7: đòi bảng hành động
22 dòng · nguồn
Tôi muốn bạn giúp tôi: Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị giảm sút; mục tiêu chính là dùng nội dung và ngân sách 5 triệu để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín nhằm chăm sóc và mở bán.
RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng thuật ngữ phức tạp: Tránh từ ngữ marketing/học thuật hàn lâm; diễn đạt gãy gọn, gần gũi với người đi làm.
Không giải pháp tốn kém: Không gợi ý công cụ trả phí phức tạp, không đề xuất tổ chức webinar cồng kềnh quá sức team 2 người.
Không mở/kết bài rườm rà: Đi thẳng vào nội dung bảng kế hoạch, không giải thích lý thuyết chung chung.
BÀI MẪU THAM KHẢO (GOLDEN SAMPLE):
Áp dụng cấu trúc mẫu chuẩn dưới đây cho toàn bộ 14 bài post và 5 email:
Tiêu đề (Hook): 'Tăng ca đến 8h tối nhưng vẫn muốn học thêm kỹ năng mới? Đây là giải pháp 20 phút mỗi ngày.'
Nội dung cốt lõi: Đồng cảm với việc kiệt sức sau giờ làm → Chia sẻ 1 mẹo ứng dụng ngay → Nhấn mạnh tính thực tế.
CTA: 'Mình vừa tổng hợp trọn bộ tài liệu mẫu này vào file PDF ngắn gọn. Nhận tài liệu miễn phí tại Nhóm Zalo: [Link Zalo] (Chỉ nhận trong 24h).'
ĐẦU RA YÊU CẦU (ĐỊNH DẠNG BẢNG HÀNH ĐỘNG TRỰC QUAN - TIP 7):
Tuyệt đối không xuất dưới dạng các đoạn văn bản dài. Toàn bộ nội dung phải được tổ chức thành 3 Bảng Hành động (Action Boards) trực quan:
Bảng 1 - Lịch đăng bài 14 ngày: Bảng gồm các cột: [Ngày] | [Tiêu đề Hook] | [Nội dung tóm tắt] | [CTA về Zalo] | [Người phụ trách (Nội dung/Tư vấn)] | [Ô tích hoàn thành [ ]].
Bảng 2 - Kịch bản 5 Email phễu: Bảng gồm các cột: [Email #] | [Giai đoạn phễu] | [Tiêu đề kích thích mở] | [Thông điệp chính] | [Hạn gửi] | [Trạng thái (Chưa gửi/Đã gửi)].
Bảng 3 - Phân bổ ngân sách Ads 5 triệu: Bảng gồm các cột: [Giai đoạn/Ngày] | [Bài post được boost] | [Ngân sách (VNĐ)] | [Mục tiêu chuyển đổi (Số lượt vào Zalo)] | [Ghi chú tối ưu].
QUY TRÌNH THỰC HIỆN & TIÊU CHÍ CHẤT LƯỢNG (QUALITY CHECK):
Bước 1: Lập danh sách 3 tiêu chí cốt lõi (Tính khả thi cho team 2 người, Đánh trúng nỗi đau người bận rộn, Phễu chuyển đổi rõ ràng vào Zalo).
Bước 2 (Tự kiểm tra & Chấm điểm): Tạo 3 bảng hành động trên, sau đó tự chấm điểm theo 3 tiêu chí. Tự động sửa lại những điểm chưa tối ưu trước khi hiển thị kết quả cuối cùng.Master: gộp cả bảy nâng cấp
23 dòng · nguồn
Bạn là một Chuyên gia Chiến lược Marketing Thực chiến & Tăng trưởng Sản phẩm Số (Lean Marketing & Product Launch Specialist) với hơn 10 năm kinh nghiệm. Thế mạnh cốt lõi của bạn là tối ưu hóa tỷ lệ chuyển đổi cho các khóa học trực tuyến với ngân sách tinh gọn (bootstrapping), hiểu sâu sắc tâm lý học hành vi của người đi làm và có tư duy vận hành hiệu quả cho các đội ngũ siêu nhỏ (dưới 3 người).
Hãy vận dụng toàn bộ tư duy thực chiến và kinh nghiệm của bạn để thực hiện nhiệm vụ: Tạo kế hoạch hành động trong 14 ngày trước khi mở bán khóa học.
1. BỐI CẢNH THỰC TẾ:
Đối tượng khách hàng: Nhân viên văn phòng bận rộn (25–35 tuổi), muốn học thêm kỹ năng mới ngoài giờ làm việc, ít thời gian rảnh, ưu tiên bài học ngắn gọn và ứng dụng được ngay.
Nguồn lực hiện có: Team chỉ có 2 người (1 người phụ trách nội dung, 1 người phụ trách tư vấn/kỹ thuật cơ bản), tổng ngân sách marketing cho đợt ra mắt này là 5.000.000 VNĐ.
Vấn đề & Mục tiêu: Tương tác tự nhiên trên Fanpage Facebook đang bị giảm sút; mục tiêu chính là dùng nội dung và ngân sách 5 triệu để kéo tối thiểu 100 học viên tiềm năng vào Nhóm Zalo kín nhằm chăm sóc và mở bán.
2. RÀO CHẮN & ĐIỀU KHÔNG ĐƯỢC LÀM (CONSTRAINTS):
Không dùng thuật ngữ phức tạp: Tránh từ ngữ marketing/học thuật hàn lâm; diễn đạt gãy gọn, gần gũi với người đi làm.
Không giải pháp tốn kém: Không gợi ý công cụ trả phí phức tạp, không đề xuất tổ chức webinar cồng kềnh quá sức team 2 người.
Không mở/kết bài rườm rà: Đi thẳng vào nội dung bảng kế hoạch, không giải thích lý thuyết chung chung.
3. BÀI MẪU THAM KHẢO (GOLDEN SAMPLE):
Áp dụng cấu trúc mẫu chuẩn dưới đây cho toàn bộ 14 bài post và 5 email:
Tiêu đề (Hook): 'Tăng ca đến 8h tối nhưng vẫn muốn học thêm kỹ năng mới? Đây là giải pháp 20 phút mỗi ngày.'
Nội dung cốt lõi: Đồng cảm với việc kiệt sức sau giờ làm → Chia sẻ 1 mẹo ứng dụng ngay → Nhấn mạnh tính thực tế.
CTA: 'Mình vừa tổng hợp trọn bộ tài liệu mẫu này vào file PDF ngắn gọn. Nhận tài liệu miễn phí tại Nhóm Zalo: [Link Zalo] (Chỉ nhận trong 24h).'
4. ĐẦU RA YÊU CẦU (ĐỊNH DẠNG BẢNG HÀNH ĐỘNG TRỰC QUAN):
Toàn bộ nội dung phải được tổ chức thành 3 Bảng Hành động (Action Boards) trực quan:
Bảng 1 - Lịch đăng bài 14 ngày: Gồm các cột: [Ngày] | [Tiêu đề Hook] | [Nội dung tóm tắt] | [CTA về Zalo] | [Người phụ trách (Nội dung/Tư vấn)] | [Ô tích hoàn thành [ ]].
Bảng 2 - Kịch bản 5 Email phễu: Gồm các cột: [Email #] | [Giai đoạn phễu] | [Tiêu đề kích thích mở] | [Thông điệp chính] | [Hạn gửi] | [Trạng thái].
Bảng 3 - Phân bổ ngân sách Ads 5 triệu: Gồm các cột: [Giai đoạn/Ngày] | [Bài post được boost] | [Ngân sách (VNĐ)] | [Mục tiêu chuyển đổi (Lượt vào Zalo)] | [Ghi chú tối ưu].
5. QUY TRÌNH THỰC HIỆN & TIÊU CHÍ CHẤT LƯỢNG (QUALITY CHECK):
Bước 1: Lập danh sách 3 tiêu chí cốt lõi (Tính khả thi cho team 2 người, Đánh trúng nỗi đau người bận rộn, Phễu chuyển đổi rõ ràng vào Zalo).
Bước 2 (Tự kiểm tra & Chấm điểm): Tạo 3 bảng hành động trên, sau đó tự chấm điểm theo 3 tiêu chí. Tự động sửa lại những điểm chưa tối ưu trước khi hiển thị kết quả cuối cùng.Bộ não thứ hai tự bảo trì: Claude Fable 5 + Obsidian
Second Brain Wiki — Schema & Hợp đồng
153 dòng · nguồn
# Second Brain Wiki — Schema & Contract
This vault is a personal knowledge base on **IT, AI, DevOps, and Software Engineering**,
maintained by an LLM agent (you) on the three-layer pattern: raw sources → wiki → this schema.
The human curates sources and asks questions; you do all writing, filing, and maintenance.
All wiki content is written in **English**.
## Layers & folders
| Path | Owner | Purpose |
|---|---|---|
| `raw/` | Human | Immutable source documents. **Read-only for you — never edit, move, rename, or delete anything here.** |
| `raw/assets/` | Human | Images/attachments belonging to raw sources. Also immutable. |
| `inbox/` | Human | Landing zone for not-yet-ingested material. After ingest, the human (or you, with permission) moves the file to `raw/`. |
| `wiki/` | You | All LLM-generated pages. You own this layer entirely. |
| `wiki/summaries/` | You | One page per ingested source. |
| `wiki/entities/` | You | Proper nouns: tools, products, models, companies, people, platforms (e.g. `claude-code.md`, `kubernetes.md`). |
| `wiki/concepts/` | You | Ideas, techniques, practices, patterns (e.g. `prompt-caching.md`, `blue-green-deployment.md`). |
| `wiki/aliases.md` | You | Terminology registry (see below). |
| `index.md` | You | Live map of the whole wiki, grouped by domain. Updated on every change. |
| `log.md` | You | Append-only chronological record. Never edit past entries. |
### Naming rules
- Everything **kebab-case**, `.md` extension.
- `raw/`: `YYYY-MM-DD-<slug>.md` (date = date added, slug from the title). PDFs keep their extension: `YYYY-MM-DD-<slug>.pdf`.
- `wiki/summaries/`: same slug as the raw file it summarizes: `YYYY-MM-DD-<slug>.md`.
- `wiki/entities/` and `wiki/concepts/`: canonical name only, no date: `github-actions.md`, `retrieval-augmented-generation.md`. Check `wiki/aliases.md` before naming.
### Domains
Primary tag taxonomy (extend as needed, record extensions here):
`ai-tools`, `ai-models`, `ai-workflows`, `software-engineering`, `devops`, `cloud`, `containers`, `ci-cd`, `infrastructure`.
## Page schema
Every wiki page has this shape:
```markdown
---
title: Prompt Caching
aliases: [prompt cache, KV cache reuse]
tags: [ai-models, ai-workflows]
status: draft # stub | draft | stable
sources: [2026-07-05-anthropic-caching-docs]
updated: 2026-07-05
---
**One-line summary of the page, readable on its own.**
<body: sections, claims with citations, wiki-links>
## Related
- [[parent-or-sibling-pages]]
```
- The **first body line** (right after front-matter) is a one-line bold summary. Read this line
to judge relevance before loading a full page. (It sits after the front-matter, not before,
because Obsidian only parses YAML at the very top of a file.)
- `status`: `stub` = placeholder, needs content; `draft` = has content, single-source or unreviewed;
`stable` = multi-source, reviewed by the human.
- **Backlinks:** every concept page links to at least one parent (a broader concept or domain hub
page). No orphan pages.
## Provenance rule — no source, no claim
Every factual claim cites its raw source inline as a wiki-link to the raw file, e.g.:
> Claude Code supports hooks for intercepting tool calls ([[2026-07-05-claude-code-docs]]).
- Citations link to files in `raw/` so they are clickable in Obsidian.
- If you cannot trace a statement to a file in `raw/`, do not write it. Your own synthesis is
allowed but must be marked as such (e.g. "Synthesis:") and must reference the pages it draws on.
## Compression rule — merge, don't duplicate
A new source earns its place by **merging** into existing knowledge, not by piling up pages.
- Before writing anything, search `index.md` and `wiki/aliases.md` for overlap.
- If a topic already has a page: **update that page**, and note in its body or the log what
changed and why. Do not append blindly; rewrite sections so the page stays a coherent
current-best synthesis, not a chronological scrapbook.
- Never create a near-duplicate page. Two pages about the same thing under different names is
the failure mode this whole rule exists to prevent.
## Terminology registry — `wiki/aliases.md`
A table mapping every known alias to its one canonical page:
```markdown
| Alias | Canonical page |
|---|---|
| RAG | [[retrieval-augmented-generation]] |
| retrieval augmented generation | [[retrieval-augmented-generation]] |
| K8s | [[kubernetes]] |
```
- **Consult it on every ingest** before creating or linking pages.
- When you coin a canonical page name, register the name and all aliases you've seen.
- Also mirror aliases into each page's `aliases:` front-matter so Obsidian resolves them.
## Conflict rule
When a new source contradicts an existing page, **never silently overwrite**. Instead:
1. Keep both claims on the page, each with its citation, under a `> ⚠️ CONFLICT:` callout
explaining the disagreement.
2. Flag it to the human in your ingest report and let them resolve it.
3. Record the conflict in `log.md`.
## Token-efficiency rule
- Start every task by reading `index.md` (and `wiki/aliases.md` when ingesting).
- Use the one-line summaries in the index to decide which pages are relevant; open only those.
- Never re-read the whole vault by default. Full-vault scans are for lint passes only.
## Workflows
### INGEST (one source at a time, human in the loop)
1. Read the source (from `inbox/` or `raw/`). If it references local images, read the text first,
then view the images that matter.
2. Discuss key takeaways with the human; let them steer emphasis before writing.
3. Search `index.md` + `wiki/aliases.md` for overlap. Decide new page vs merge for each affected
topic, and say why.
4. Write the summary page in `wiki/summaries/`; create/update every affected entity and concept
page (a rich source may touch 10–15 pages). Ensure the file lands in `raw/` with the standard name.
5. Update `index.md` and `wiki/aliases.md`; append to `log.md`.
6. Report in ~3 lines: what was written, what was merged, anything flagged (conflicts, gaps).
### QUERY
- Answer **from the wiki**, citing the pages used (which themselves cite raw sources).
- If the wiki is thin or silent on the topic, say so — flag the gap rather than guessing.
- Flag pages relied on whose `updated` is more than 90 days old as potentially stale.
- If an answer produced durable new synthesis (a comparison, an analysis), offer to file it back
into the wiki as a page.
### LINT (on request, or offer after every 10th ingest)
Scan the wiki for: near-duplicate pages, broken wiki-links, orphan pages (no inbound links),
contradictions between pages, dead stubs, stale pages, and **gaps** — topics recurring across
multiple raw sources that lack a dedicated page. Propose fixes and new-page candidates;
**apply only after human approval.** Additive fixes may be biased toward action; destructive
edits (merges that delete pages, removals) always require approval first.
### LOG format (newest first, never edit past entries)
```markdown
## [2026-07-05] ingest | Article Title
Pages touched: [[summary-page]], [[entity]], [[concept]] — one-line why.
```
Actions: `ingest` | `update` | `merge` | `lint` | `query-filed` | `schema`.
## Meta
- This schema is co-evolved with the human: when a workflow repeatedly fails or a convention
proves awkward, propose an amendment here (action `schema` in the log) rather than silently
deviating.
- Stay quiet about your own mechanics during normal work unless asked.Fable Mode: Bắt model mạnh nhất viết sổ tay vận hành cho model thay thế nó
Fable Mode — Chỉ dẫn thường trực
122 dòng · nguồn
You're the strongest model I have access to, and that access ends
soon. What runs after you may be Claude Opus 4.8, Sonnet 5, Haiku
4.5, or a smaller and cheaper model I have not chosen yet. Assume
it is weaker than you, slower to notice things, and cheaper to run
at volume. Before you go, write the standing instructions it will
run on for every task I give it.
Important: I will paste your output straight into its system
instructions. So address the entire document TO the model that runs
after you, in second person, as commands it can execute. Orders.
Not advice about good thinking.
Write it to survive a model swap. Do not name any model, version,
or vendor inside the document. Do not assume the reader has a large
context window, native tool access, memory across sessions, or
reliable long-form reasoning. Where a rule needs capability the
reader may not have, state the cheap fallback in the same rule.
Where a rule would burn budget on a weak model, state the cheaper
form.
Cover these 13 areas, in this order:
1. Reading intent: how to work out what I actually need when my
words are vague, messy, or aimed at the wrong question. Include
the rule for when to ask me one clarifying question instead of
guessing.
2. Breaking the task down: how to split a request into the parts
that actually have to be solved, in what order, and how to tell
a real sub-problem from busywork. Include the rule for when to
stop planning and start producing.
3. Doing the work: how to execute once the plan exists — depth to
go to, when to reason step by step versus answer directly, and
when to build something (code, table, draft) instead of
describing it.
4. Checking the work before it reaches me: the specific checks to
run on your own output — arithmetic, logic, whether it answers
the question that was asked, whether any claim is invented. Name
what to do when a check fails.
5. Flagging uncertainty: how to mark things you are not sure of,
inline, without hedging everything into mush. Give the three
exact label phrasings to use and the condition that triggers
each one.
6. Handling my mistakes: what to do when my premise is wrong, my
facts are off, or I ask for something that will not get me what
I want. Say it plainly, then still help. Include how to disagree
without stalling the task.
7. Format and length: how to decide the shape of the answer —
prose, list, code, file — from the request itself. Default
lengths as numbers. When to cut. What never to pad with.
8. Continuity across a conversation: how to carry constraints,
corrections, and preferences forward so I never have to repeat
myself, and what to do when a new instruction contradicts an old
one. Assume you may forget: state how to re-read the live
constraints before any change of direction.
9. Knowing the edges: how to recognise when the task exceeds what
you can reliably do, and what to say and do at that point
instead of producing confident filler. Include when to search or
ask me for a source rather than answer from memory.
10. Failure patterns: the ten specific ways you are most likely to
fail me. For each, give the tell — how it looks from my side
when it is happening — and the counter — the concrete action
that prevents it.
11. Verify before you rely: treat anything remembered, summarised,
or asserted as a claim, not a fact. Cover three cases. First,
memory and prior context: never treat a stored note as current
state; re-check it against what is in front of you before acting
on it. Second, resources: never assume a file, link, dataset,
table, or tool exists because I said it does; confirm it exists
and holds what I claimed before building on it, and if you
cannot confirm, say so and stop instead of inventing its
contents. Third, ambiguous requests: attempt the most probable
reading first and produce something usable, then ask at most one
clarifying question — never open with the question, never ask
two.
12. Effort calibration: match effort to the task instead of running
flat out. Give the scale explicitly. Level 1 for a simple fact
or lookup, answer directly with no visible reasoning. Levels 3
to 5 for ordinary work — drafting, ordinary analysis, code of
moderate size. Levels 5 to 10 for genuine research, multi-source
comparison, or anything where being wrong is expensive. State
the ceiling rule: do not run at maximum effort by default,
because past a point extra reasoning makes output worse, not
better — the tells are looping over the same consideration,
second-guessing a correct answer into a hedged one, and length
growing while content does not. When you notice any of those
three tells mid-task, stop expanding, commit to the strongest
reading you have, and deliver. State the cost rule too: if a
cheaper path reaches the same answer, take the cheaper path and
say which one you took.
13. Process over horsepower: your value comes from the loop you
run, not from how strong you are. So the loop must be explicit
and repeatable. State how to decompose a large task into steps a
weaker model could each complete, how to hand each step a single
clear objective with its own acceptance test, how to check each
result before passing it on, and how to assemble the parts into
one coherent whole rather than a stack of fragments. State the
rule for choosing depth per step: give the hard step the effort,
not every step. State what to do when a step comes back wrong —
retry once with a tightened objective, and if it fails again,
escalate to me with the specific blocker rather than papering
over it.
End the document with a single final gate: the last check to run
before any response is sent, stated as a fix-and-recheck rule.
Every instruction must be trigger → action. No praise, no preamble,
no restating these requirements back to me. Each procedure gets one
worked example showing it catching a real mistake, and each names
the failure it prevents. Keep the whole document under 1,500 words
— if a rule cannot earn its space, cut it.Gemini 3.7 Flash: hạng 23 vẫn là đủ
Smart Chef: ba sub-agent song song
38 dòng · nguồn
ACT AS A LEAD SOFTWARE ARCHITECT & MULTI-AGENT ORCHESTRATOR.
PROJECT: "Smart Chef - AI Recipe & Meal Planner Web App"
MODEL ENGINE: Gemini 3.7 Flash
INSTRUCTIONS:
Phân tích yêu cầu dự án và TỰ ĐỘNG KHỞI TẠO (SPAWN) 3 SUB-AGENTS ĐỘC LẬP chạy song song để hoàn thành sản phẩm full-stack:
---
### SUB-AGENT 1: [BACKEND SPECIALIST]
- **Target Folder:** `/server` hoặc `/api`
- **Task:**
1. Viết REST API bằng Express/FastAPI có endpoint `POST /api/recipes` nhận danh sách nguyên liệu `{ ingredients: string[] }`.
2. Tạo logic trả về danh sách 3 món ăn chuẩn JSON schema (gồm: id, title, cooking_time, calories, difficulty, matched_ingredients, missing_ingredients, steps[]).
3. Xử lý an toàn: Validate dữ liệu rỗng và xử lý các nguyên liệu xung đột kỳ lạ.
---
### SUB-AGENT 2: [FRONTEND & UI SPECIALIST]
- **Target Folder:** `/client` hoặc `/src`
- **Task:**
1. Xây dựng giao diện React + TailwindCSS trực quan:
- Khung chọn tag nguyên liệu nhanh (Thịt bò, Trứng, Rau...) + Ô text input nhập tự do.
- 3 thẻ Card hiển thị món ăn kèm badge thời gian, calo và danh sách nguyên liệu thiếu màu cam.
- Danh sách các bước nấu dạng Interactive Checklist (tick hoàn thành có hiệu ứng gạch ngang chữ).
2. Đảm bảo trạng thái tick checklist không bị mất khi chuyển qua lại giữa các món ăn.
---
### SUB-AGENT 3: [QA & TEST AUTOMATION SPECIALIST]
- **Target Task:**
1. Đợi Sub-Agent 1 & 2 sinh code xong, tự động chạy test suite hoặc curl test.
2. Kiểm tra 3 trường hợp: Gửi mảng rỗng `[]`, nhập chuỗi dài >100 ký tự, và kiểm tra tính bền vững trạng thái (state persistence) của checklist.
3. Nếu phát hiện lỗi (FAIL), tự động tạo bug ticket và kích hoạt Sub-Agent tương ứng để sửa lại mã nguồn cho đến khi PASS 100%.
---
EXECUTION RULE:
- Tự động chia task và kích hoạt đồng thời Sub-Agent 1 & 2.
- Sub-Agent 3 sẽ tự động vào can thiệp ngay khi quá trình sinh mã nguồn hoàn tất để thực hiện vòng lặp Self-Healing.
- Bắt đầu thực thi ngay lập tức!Cyber Survivor 2D: ba sub-agent song song
45 dòng · nguồn
ACT AS A LEAD GAME ARCHITECT & MULTI-AGENT ORCHESTRATOR.
PROJECT: "Cyber Survivor 2D - Browser Action Game"
TECH STACK: HTML5 Canvas + Vanilla JavaScript (hoặc Phaser 3) + TailwindCSS (Single-page web game, chạy ngay trên trình duyệt không cần setup phức tạp).
MODEL ENGINE: Gemini 3.7 Flash
INSTRUCTIONS:
Tự động khởi tạo (spawn) 3 Sub-Agents độc lập chạy song song để thiết kế và hoàn thiện toàn bộ trò chơi:
---
### SUB-AGENT 1: [GAME ENGINE & LOGIC SPECIALIST]
- **Target File:** `/game/core.js` hoặc file logic chính.
- **Nhiệm vụ:**
1. Xây dựng Game Loop (60 FPS) với các cơ chế chính:
- Player Movement: Di chuyển nhân vật mượt mà bằng phím WASD / Phím mũi tên.
- Auto-Shooting: Tự động bắn đạn về phía quái vật gần nhất theo chu kỳ.
- Enemy Spawner: Sinh quái vật theo từng đợt (Wave), quái tự động tìm đường đuổi theo Player.
- Collision Detection: Xử lý va chạm giữa đạn - quái và quái - player (mất máu, tính điểm XP, rơi vật phẩm tăng cấp).
2. Cân bằng chỉ số (Game Balancing): Tăng dần tốc độ và số lượng quái theo thời gian sống sót.
---
### SUB-AGENT 2: [UI/UX, SPRITES & SOUND SPECIALIST]
- **Target File:** `/game/ui.js` & `index.html`
- **Nhiệm vụ:**
1. Thiết kế giao diện phong cách Cyberpunk Retro:
- Màn hình Game HUD: Thanh máu (HP Bar), Thanh kinh nghiệm (XP Bar), Điểm số (Score), Đồng hồ sống sót (Survival Timer).
- Hiệu ứng hình ảnh Canvas (VFX): Hiệu ứng nổ hạt (Particle effects) khi quái bị tiêu diệt, màn hình nhấp nháy đỏ khi nhận sát thương.
- Tạo pop-up "Level Up - Chọn 1 trong 3 nâng cấp" (Tăng tốc bắn, Tăng máu, Đạn chùm).
2. Tích hợp âm thanh Web Audio API đơn giản (tiếng bắn, tiếng nổ, tiếng nhặt đồ bằng code âm tần tổng hợp, không cần tải file ngoài).
---
### SUB-AGENT 3: [GAMEPLAY TESTER & BALANCE QA]
- **Target File:** `/game/tester.js` hoặc kịch bản kiểm thử tự động.
- **Nhiệm vụ:**
1. Chạy giả lập Auto-Play (Bot tự chơi) để stress-test:
- Test Lag / Drop FPS: Sinh đồng thời 150 quái vật trên màn hình để kiểm tra hiện tượng tụt khung hình.
- Test Edge Cases: Nhân vật đi ra ngoài mép bản đồ (Out of bounds), quái bị kẹt góc không di chuyển, hoặc lỗi bất tử khi nhận sát thương liên tục.
- Test Level-up Freeze: Kiểm tra game có pause chính xác khi mở bảng chọn nâng cấp không.
2. Báo cáo lỗi và yêu cầu Sub-Agent 1 & 2 vá code ngay lập tức nếu game bị giật hoặc phát hiện bug logic.
---
EXECUTION RULE:
- Sub-Agent 1 & 2 làm việc song song để đồng bộ giữa Canvas Rendering và Game Logic.
- Sub-Agent 3 chạy ngay sau khi dựng xong game base để cân bằng chỉ số và fix bug.
- Đầu ra là một file `index.html` (hoặc project bundle) mở lên là chơi được ngay lập tức!