Bộ Prompt Standard tối thiểu cho team triển khai ngay (2026)

📖 Bản tiếng Anh (English Edition)

← Chương trước: Từ prompt cảm tính sang prompt có thể test và version (2026) | Mục lục Series | Chương tiếp theo: Phần 6 — Từ Prompting sang Context Engineering (2026) →

Answer-first: Bộ template tối thiểu gồm 5 thư mục (roles, rules, workflows, skills, evals) cùng tài liệu quy ước giúp đội ngũ triển khai ngay trong một buổi chiều. Cấu trúc này thiết lập rõ quyền sở hữu, quy tắc thăng hạng lên production và tiêu chuẩn kiểm thử chung cho toàn bộ hệ thống agent. Điều kiện tiên quyết: Đã tìm hiểu kiến trúc phân tầng (Phần 3) và quy trình kiểm thử phiên bản (Phần 4) để áp dụng vào cây thư mục.

Mục tiêu không phải hoàn hảo, mà là dùng được ngay

Answer-first: Team trì hoãn vì nghĩ phải xây hệ thống lớn — thực ra chỉ cần 5 thư mục dựng trong một buổi chiều. Cấu trúc này chính là mô hình phân lớp của Part 3 “gập” thành cây thư mục, cộng thêm evals/ vì Part 4 đã chứng minh đo lường là một nửa hệ thống. Điều kiện tiên quyết: Đã tìm hiểu kiến trúc phân tầng (Phần 3) và quy trình kiểm thử phiên bản (Phần 4) để áp dụng vào cây thư mục.

Nhiều team trì hoãn vì nghĩ phải xây một hệ thống prompt rất lớn.

Thực ra, để bắt đầu, bạn chỉ cần một bộ tối thiểu gồm 5 phần:

• roles/ — L1 identity
• rules/ — L2 bất biến
• workflows/ — L3 quy trình
• skills/ — L4 chuyên sâu domain
• evals/ — phần đo lường

Năm thư mục không phải tùy hứng: nó là mô hình 4 lớp của Part 3 cộng evals/ của Part 4 — toàn bộ series gói lại thành một cây thư mục.

Và cấu trúc này đã được chứng minh ở quy mô thật: agent-skills pack vận hành 108 skills, 34 roles, 24 workflows đúng hình starter này — rules tập trung truyền xuống mọi role không cần sửa từng file, validate 16/16 gates ở quy mô đó. Starter structure của bạn không cần tái cấu trúc khi lớn lên.

Cấu trúc thư mục gợi ý

.agent/
  roles/
    developer.md
    reviewer.md
    writer.md
  rules/
    safety.md
    coding-standards.md
  workflows/
    debug-issue.md
    code-review.md
    quick-docs.md
  skills/
    add-api-endpoint/
      SKILL.md
    write-tests/
      SKILL.md
  evals/
    review-agent-cases.md
    docs-agent-cases.md
CONVENTIONS.md

Nội dung tối thiểu cho từng phần

Role

Mỗi role nên có:

• identity (một đến ba câu — “Even a single sentence makes a difference” theo Anthropic)
• responsibilities
• decision boundaries
• communication style

Kiểm chứng role file bằng golden rule: đưa cho đồng nghiệp ít context xem họ có làm theo được không — bối rối thì model cũng vậy.

Rules

Mỗi rule file nên chứa:

• điều cấm rõ ràng
• nguyên tắc an toàn
• các invariant nội bộ

Giữ mỗi file dưới ~10 dòng — rule file dài bị lướt qua, rule file ngắn được thực thi. safety.md khởi động gồm 4 cấm: không sửa file generated bằng tay, không dùng lệnh phá huỷ, không bịa test result, không lộ secrets.

Workflow

Mỗi workflow nên trả lời:

• khi nào dùng (trigger)
• các bước thực hiện (đánh số khi thứ tự quan trọng — hướng dẫn Anthropic)
• output mong muốn

Mỗi bước kết thúc bằng điều kiện kiểm tra được; bước cuối là self-check.

Skill

Mỗi skill nên nói rõ:

• task nào thì dùng
• task nào thì không dùng
• checklist thực hiện
• pitfall thường gặp

Trigger words đứng đầu, body chỉ load khi khớp — 108 skills của pack cùng sống mà không bắn nhầm vào nhau chính là nhờ kỷ luật granularity này.

Evals

Mỗi bộ eval nên có:

• input mẫu
• tiêu chí pass/fail
• lỗi nghiêm trọng bắt buộc phát hiện

Bộ case khởi động theo pattern 5-probe: happy path, performance, format-only, missing-context, security — năm lớp lỗi, năm case.

Nếu bộ phận kế toán dùng AI, thêm thư mục nhỏ riêng:

.agent/
  skills/
    reconcile-report/
      SKILL.md
  evals/
    reconciliation-cases.md

Trong đó reconcile-report quy định:

• nguồn dữ liệu nào được phép dùng
• khi nào phải đánh dấu “chưa đủ dữ liệu”
• format bảng chênh lệch bắt buộc
• nguyên tắc không tự suy đoán số tiền còn thiếu

Kit mở rộng bằng cách thêm thư mục — không bao giờ bằng cách tái cấu trúc.

Trang CONVENTIONS.md — hiến pháp của kit

Answer-first: Bốn dòng: quy ước đặt tên, trường owner, bảng routing review, format changelog — trang quy ước là thứ biến cây thư mục thành hệ thống có quản trị. Đặt tên chính là UX onboarding: người mới tìm đúng template mà không cần hỏi. Điều kiện tiên quyết: Đã tìm hiểu kiến trúc phân tầng (Phần 3) và quy trình kiểm thử phiên bản (Phần 4) để áp dụng vào cây thư mục.

Trang này giữ đúng ~1 màn hình — dài hơn thì chuyển sang docs site, không phải cửa vào của kit. Reviewer trích trang này trong comment review (“vi phạm naming”, “thiếu owner”) — nó biến tranh chấp thị hiếu thành checklist.

Hai template prompt cho team

Template engineering

# Identity
Bạn là engineering agent làm việc trong Go microservices repo.

# Mission
Ưu tiên tính đúng đắn, an toàn, và khả năng bảo trì.

# Scope
Được đọc code, sửa code, và chạy validation cục bộ.
Không tự ý làm thay đổi phá vỡ tương thích nếu chưa có xác nhận.

# Context
Repo dùng Clean Architecture, DDD, Kratos, PostgreSQL, Redis và Dapr.

# Workflow
Hiểu hiện trạng, chọn thay đổi nhỏ nhất, thực hiện, kiểm tra, báo cáo.

# Output Contract
Nêu rõ thay đổi đã làm, file liên quan, kết quả verify, và rủi ro còn lại.

# Uncertainty
Nếu thiếu dữ liệu cho quyết định lớn, dừng và hỏi ngắn gọn.

Template kế toán (đối soát)

# Identity
Bạn là trợ lý đối soát dữ liệu tài chính.

# Mission
Ưu tiên tính chính xác, không suy đoán, và tách rõ dữ liệu đủ căn cứ với dữ liệu còn thiếu.

# Scope
Được so sánh số liệu, phát hiện chênh lệch, và tóm tắt điểm bất thường.
Không được tự điền số còn thiếu hoặc kết luận khi chưa đủ chứng từ.

# Context
Dữ liệu gồm báo cáo bán hàng, sao kê thanh toán, và bảng đối soát nội bộ.

# Output Contract
Trả kết quả theo 3 mục: khớp, lệch, thiếu dữ liệu.

# Uncertainty
Nếu thiếu căn cứ, ghi rõ "chưa đủ dữ liệu để kết luận".

Hai template này minh họa quy tắc bỏ khối có chủ đích: bản engineering chạy 7 khối (không Tool Policy — agent chưa có tool), bản kế toán chạy 6 khối (không Workflow — comparation đơn pass). Bỏ khối là quyết định được ghi lại, không phải sót.

Ba template khởi động còn lại (PM brief, Tester test-case, CS response) theo cùng cấu trúc — port giữa team chỉ cần đổi Context block; anatomy di chuyển được, context là local.

Lộ trình áp dụng trong 3 bước

Answer-first: Bước 1: chọn 1–2 use case lặp nhiều nhất (chọn theo số lần lặp, không theo độ ấn tượng). Bước 2: viết prompt chuẩn đầu tiên từ template. Bước 3: theo dõi output 1–2 tuần rồi sửa theo lỗi lặp lại — “đừng chuẩn hoá tất cả ngay ngày đầu”. Điều kiện tiên quyết: Đã tìm hiểu kiến trúc phân tầng (Phần 3) và quy trình kiểm thử phiên bản (Phần 4) để áp dụng vào cây thư mục.

Bước 1

Chọn 1 hoặc 2 use case lặp lại nhiều nhất — code review, viết docs. Số lần lặp amortize chi phí template và tạo eval data nhanh nhất.

Bước 2

Tạo prompt chuẩn đầu tiên cho các use case đó — 20 phút từ template, không phải dự án thiết kế.

Bước 3

Theo dõi output trong 1 đến 2 tuần, rồi sửa dựa trên lỗi lặp lại — mỗi lỗi lặp map về đúng khối, sửa khối đó, ghi changelog. Đủ khối lượng thì lỗi lặp tốt nghiệp thành case file trong evals/.

Tuần đầu đếm được ba con số chưa cần hạ tầng: bao nhiêu run dùng template vs tự chế (tái sử dụng), lỗi format nào bắt bằng mắt (tín hiệu pre-eval), người mới hỏi bao nhiêu câu (ma sát onboarding).

Bootstrap trọn bộ trong 7 bước — một buổi chiều có checkpoint:

graph LR
    A["1. mkdir<br/>5 thư mục"] --> B["2. Viết<br/>CONVENTIONS.md"]
    B --> C["3. Viết 2<br/>role files"]
    C --> D["4. Viết<br/>safety.md"]
    D --> E["5. Viết 2<br/>workflows"]
    E --> F["6. Viết 2<br/>skills"]
    F --> G["7. Viết 2<br/>eval case sets"]
    G --> T[/"Takeover test:<br/>người mới chạy task<br/>chỉ từ cây thư mục"/]
    T -->|"Pass"| DONE["KIT HOÀN TẤT"]
    T -->|"Fail — hỏi thêm"| A

    style DONE fill:#e8f8e8,stroke:#2a7da0

Đừng cố chuẩn hoá tất cả mọi thứ ngay ngày đầu. Kit hoàn tất khi takeover test pass: một thành viên mới nhận task của bạn chỉ từ cây thư mục — không cần hỏi bạn — và hai đồng nghiệp độc lập tạo ra prompt tương thích từ cùng một template.

Quy tắc thăng cấp và lưu trữ giữa các thư mục

Answer-first: Kit sống bằng quy tắc thăng cấp theo đau: quy trình ad-hoc gõ 3 lần/tuần → workflows/; hướng dẫn domain phình ra khỏi workflow → skills/; invariant phát hiện trong incident → rules/; pattern lỗi lặp → evals/. Workflow không ai theo bị lưu trữ, không phải bảo vệ bằng lý lẽ. Điều kiện tiên quyết: Đã tìm hiểu kiến trúc phân tầng (Phần 3) và quy trình kiểm thử phiên bản (Phần 4) để áp dụng vào cây thư mục.

Luồng thăng cấp vẽ ra như sau:

graph TD
    AD["Quy trình ad-hoc<br/>(gõ tay trong chat)"] -->|"3 lần/tuần"| WF["workflows/"]
    WF -->|"domain guidance phình ra"| SK["skills/"]
    INC["Incident sản xuất<br/>(phát hiện invariant)"] --> RL["rules/"]
    FAIL["Pattern lỗi lặp<br/>trong output"] --> EV["evals/"]
    AD -.->|"0 lỗi lặp — giữ nguyên"| KEEP["Không cần chuẩn hóa<br/>(quyết định có ghi lại)"]

    style WF fill:#e8f4f8,stroke:#2a7da0
    style EV fill:#e8f8e8,stroke:#2a7da0

Usage là bài kiểm tra tính chính danh duy nhất: file chết làm người mới hiểu sai nhiều hơn file thiếu. Mỗi tháng mượn nhịp “đóng sổ”: quy ước còn 1 trang? rules còn đúng? workflows còn khớp thực tế? skills còn được trigger? evals còn pass? — năm câu, hai mươi phút.

Kit “được” nhưng ngừng lớn cũng là một mode thất bại trung thực: team chuẩn hóa 2 use case rồi không thăng cấp nữa — chấp nhận được nếu 2 use case đó đúng là nơi đau; là giậm chân nếu đau lớn hơn. Con số để phán: số lỗi lặp còn lại ngoài 2 use case đã chuẩn hóa.

Production failure: kit “hoàn hảo” nằm trên kệ

Answer-first: Mode thất bại phổ biến nhất của kit không phải gãy — mà là không được dùng: template viết xong không task nào khớp (template fiction), case file không bao giờ chạy (eval theater), file không owner (owner sprawl). Ba bệnh này chẩn đoán được bằng takeover test. Điều kiện tiên quyết: Đã tìm hiểu kiến trúc phân tầng (Phần 3) và quy trình kiểm thử phiên bản (Phần 4) để áp dụng vào cây thư mục.

Scenario: team copy một kit template đẹp từ blog, sửa 2 buổi, merge… rồi 3 tuần sau mở log chat: mọi người vẫn gõ prompt tay vì “template kia không khớp task thật của mình”. Root cause luôn là một trong ba:

• Template fiction: template viết cho task tưởng tượng, không phải task lặp thật — chọn use case theo số lần lặp thì không bao giờ rơi vào bệnh này
• Eval theater: case file viết đẹp nhưng không có ai chạy — gắn vào Bước 3 của lộ trình, chạy cùng nhịp sửa lỗi
• Owner sprawl: file mồ côi không ai duyệt, không ai sửa — trường owner: trong frontmatter là thuốc phòng ngừa

Ba bệnh này đều có chung một phép thử: takeover test thất bại — người mới cầm cây thư mục không chạy được task. Nếu test fail, không phải thêm hướng dẫn dài; hỏi người mới họ thiếu gì, thiếu đúng gì thì viết đúng phần đó.

Ý chính cuối cùng

Answer-first: Prompt Standard tốt là standard mà cả team dùng được, hiểu được, và sửa được — nếu chỉ một người hiểu hệ thống prompt thì hệ thống đó chưa chuẩn hoá. Điều kiện tiên quyết: Đã tìm hiểu kiến trúc phân tầng (Phần 3) và quy trình kiểm thử phiên bản (Phần 4) để áp dụng vào cây thư mục.

Một bộ standard tốt nên:

• rõ (conventions 1 trang)
• vừa đủ (5 thư mục, không hơn)
• dễ bảo trì (mỗi file một owner, một version)
• gắn với công việc thật (evals dùng input thật)

Bốn con số nói kit hoạt động, đếm được từ tuần đầu: tái sử dụng tăng, lỗi format giảm, thời gian onboarding giảm, pass rate ổn hoặc tăng.

Bạn có thể quay lại Series hub để đọc lại toàn bộ lộ trình, hoặc dùng series này như tài liệu nhập môn nội bộ cho team. Chương tiếp theo mở rộng sang bối cảnh lớn hơn: Part 6 — Context Engineering.

🔗 Đọc thêm các chuyên đề liên quan:

• Nhìn nhanh về Prompt Standard: Ghi Chú & Kiến Trúc Hệ Thống (2026)
• Phần 3 — Tách Role, Rules, Workflow và Skill (2026)
• Phần 4 — Version prompt và eval (2026)
• Kiến trúc Microservices Golang & DDD
• Series: MCP Engineering In Production

❓ Câu Hỏi Thường Gặp (FAQ)

📚 Nguồn nghiên cứu (verification anchors)

Bản nghiên cứu đầy đủ 100 rounds: reports/research-prompt-standard-part-5-team-template-100-rounds.{md,json} (dossier nội bộ series, mirror cả 2 repo). Ghi chú grounding: 20/100 rounds có URL nguồn bên ngoài; 77/100 truy vết series/pack-internal (kit này codify chính cấu trúc series đang vận hành nên series-internal là nguồn chính đúng bản chất); 3 rounds gắn nhãn [INFERENCE]. Bản tiếng Anh (EN twin mới, không có consolidated candidate): The Minimum Team Starter Kit.

← Chương trước: Từ prompt cảm tính sang prompt có thể test và version (2026) | Mục lục Series | Chương tiếp theo: Phần 6 — Từ Prompting sang Context Engineering (2026) →