Prompt seed AGENTS.md dùng khi chạy đồng thời nhiều AI coding agent trên một/nhiều codebase (EstreGenesis)

Trong một dự án, nếu chạy đồng thời nhiều AI coding agent như

• Claude Code
• Cursor
• GitHub Copilot
• Gemini (Antigravity)
• Cline
• Windsurf
• Continue

nhằm phân tán token để tối ưu chi phí, thì CLAUDE.md, .cursor/rules/, và GEMINI.md sẽ dần bắt đầu lệch nhau.
EstreGenesis là thư viện prompt seed bootstrap AI Native được tạo ra để giải quyết vấn đề đó.

https://github.com/SoliEstre/EstreGenesis

Chỉ cần lấy một file seed và gửi nó làm tin nhắn đầu tiên trong chat bằng cách

• sao chép nội dung rồi dán vào,
• cung cấp đường dẫn local,
• đính kèm file, hoặc
• mô tả trong chat để gián tiếp truyền vị trí file, v.v.

thì agent sẽ

• bootstrap dự án mới theo cấu trúc AGENTS.md nguồn chân lý duy nhất + file bridge mỏng cho từng công cụ, hoặc
• kiểm tra dự án hiện có với các file rule rời rạc rồi migrate sang cùng một cấu trúc.

Tùy độ sâu, bạn chỉ cần chọn một trong 3 tier (Master / Lite / Compact).

• Lite là mặc định.
• Nếu bạn theo phong cách đổ nhiều token (ưu tiên chất lượng bằng cách chỉ dùng các model cao cấp như Opus 4.7, GPT 5.5), hoặc muốn có harness vững hơn trên model thấp hơn (Sonnet, Haiku), thì hãy dùng tier Master.
• Ngược lại, nếu muốn giảm ảnh hưởng của seed xuống mức tối thiểu, hãy dùng tier Compact.

Được cung cấp theo cặp tiếng Anh/tiếng Hàn.
Hai bộ seed ở cả hai ngôn ngữ được quản lý đồng nhất tới cả phase, migration và hướng dẫn vận hành, nên nếu là đội song ngữ thì có thể triển khai cả cặp ngôn ngữ cùng lúc.

Có bốn mẫu cốt lõi:

1. AGENTS.md SSoT + bridge mỏng theo từng công cụ để ngăn hỗn loạn rule.
2. .agent/_coordination/ để tránh xung đột khi chỉnh sửa đồng thời.
3. .agent/_lessons/ để lỗi phải debug 3 giờ ở phiên này thành xử lý 30 giây ở phiên sau, ngăn lặp lại sự cố.
4. Với các quyết định quan trọng, ép vòng lặp Research → Report → Plan để dẫn dắt phát triển vững chắc dựa trên nghiên cứu.

Ngoài ra, trong v1.6.0 lần này còn bổ sung chính sách ước lượng agent-time vs human-time.
Vì hầu hết AI khi lập kế hoạch đều hay thổi phồng thời gian theo tiêu chuẩn lập trình viên con người lên 5~10×, nên ở bước chọn execution pace mode của bootstrap Phase 0, nếu xác định trước một trong các mức

• Cautious 2~4×
• Proactive 5~6×
• Burst 6~8×
• Sprint 9~10×

thì mọi ước lượng sẽ được báo tách thành thời gian làm việc của agent + thời gian review của con người + thời gian trôi qua thực tế.
Trong quá trình dự án, cũng có thể chuyển mode và hiệu chỉnh theo số đo thực tế bằng _lessons/.

Và một trong những chính sách tùy chọn quan trọng là mô hình vận hành tách riêng từng repo dự án liên kết (như FE/BE) và một repo riêng chỉ dành cho tài liệu phát triển để điều phối toàn bộ.

** Vì Antigravity hay GitHub Copilot không thể truy cập file ngoài thư mục làm việc, nên có thể đặt từng source repo bên dưới repo tài liệu, rồi thêm các thư mục đó vào .gitignore để tách phạm vi git.

Làm như vậy sẽ có một repo tài liệu thiên về .md, và kể cả khi source là public repo thì riêng tài liệu phát triển vẫn có thể để private để kiểm soát phạm vi công khai.

Đặc biệt, nếu tạo project trong Claude Project rồi kéo repo tài liệu chuyên dụng này vào phần file của project bằng kết nối GitHub để nối nó thành tri thức của project, thì bạn sẽ có một thiết lập cho phép không chỉ chat mà cả deep research dựa trên tài liệu dự án. (Mỗi lần push repo cần bấm nút cập nhật trong project và chờ đồng bộ.)
Trong khi tận dụng song song coding agent và agent có thể deep research, khi phát sinh nhu cầu deep research thì có thể yêu cầu prompt ủy thác deep research, chạy deep research trong Claude Project,
rồi đưa kết quả vào /archive/<ngày>_<chủ_đề> của repo tài liệu và giao cho agent trong IDE rà soát, tổng hợp; cách này có thể nâng tầm tiến độ phát triển của dự án lên mức rất cao.
Không chỉ vậy, còn có thể dùng chat của Claude Project để tham vấn về monetization và business (pháp lý, bằng sáng chế, v.v.), nên tôi muốn khuyến nghị mô hình này.

Repo này là nơi tôi hệ thống hóa thành seed các kinh nghiệm tích lũy được trong lúc vận hành đồng thời 3 agent Antigravity + Claude Code + GitHub Copilot trên dự án AI Native nghiêm túc thứ hai của mình, đồng thời liên tục cải thiện các lỗi lặp lại và điểm bất tiện.
Ngoài ra, tôi cũng đang gom các mẫu sử dụng hữu ích từ những dự án khác của mình để tiếp tục lăn quả cầu tuyết này.

Và kể cả không phải coding agent, nếu đưa nó cho các agent như Hermes thì chúng cũng hấp thụ và phản ánh tốt những phần phù hợp với mình, nên về thực chất có thể xem đây là một seed đa dụng.

Tham khảo thêm, giấy phép là Apache 2.0.

Rất hoan nghênh feedback, issue và đề xuất bridge cho các công cụ AI khác.

[kurthong]

Trước hết xin cảm ơn vì đã giới thiệu một dự án hay. Đây cũng là lĩnh vực tôi quan tâm.
Bạn đã hệ thống hóa pattern rất tốt. Trong lúc đọc bài, tôi tò mò về hai điểm nên để lại bình luận.
Thứ nhất - chi phí tích lũy của _lessons/. Nếu lessons tích lũy từ khoảng 100 lên hơn 500 mục, thì chi phí grep rồi đọc xuyên suốt các file sẽ tăng tỷ lệ thuận; trong các dự án AI Native, không biết từ ngưỡng nào chi phí khởi động cho mỗi task bắt đầu trở nên đáng kể, và nếu bạn có số liệu đo đạc thì tôi rất muốn tham khảo.
Vì phần tối ưu hóa chỉ mục RAG ở v1.3 rốt cuộc vẫn là metadata Markdown, nên tôi cảm thấy đó không phải là lời giải mang tính bản chất.

Thứ hai - điểm mà cùng một file bị nạp trùng lặp theo số lượng agent khi vận hành đa agent đồng thời. Thiết kế này dựa trên 3 agent, nhưng nếu trong từng session mỗi agent đều đọc toàn bộ AGENTS.md + rules.md + architecture.md + STATE.md + lessons, thì mục tiêu phân tán token có phải ngược lại đang bị nhân lên không? Tôi muốn hỏi không biết bạn đã xử lý điểm này như thế nào, hoặc dự định sẽ giải quyết ra sao.

[soliestre]

Câu trả lời ở trên là nội dung tôi đã chỉ thị trực tiếp bằng prompt khi tôi tự tay làm seed harness engineering, và là phần tôi trả lời ngay trong phạm vi những gì tôi nhớ chắc chắn.
Chi tiết cụ thể về cách xử lý việc tích lũy lessons là phần tác nhân đã tự xem xét trong quá trình build seed, rồi tự thêm chi tiết và phản ánh vào cấu hình; (đó là phần đã được tiến hành sẵn trong dự án dùng để làm việc trước khi chưng cất thành seed.)
Thay vì để tôi trực tiếp trả lời, có vẻ đúng hơn là hỏi tác nhân đã tổng hợp seed, vì nó nắm rõ cấu hình thực tế hơn, nên khi về nhà tôi đã hỏi ý kiến của nó về phần Hỏi-Đáp ở trên.

Câu trả lời được nó tóm tắt lại như sau:

1. grep theo tag — thu hẹp tìm kiếm bằng các tag liên quan đến ngữ cảnh công việc, chứ không đọc xuyên suốt toàn bộ lessons.
2. Chỉ mục _lessons/README.md — dùng tiêu đề, tag và tóm tắt 1 dòng để lọc lần đầu trước khi grep.
3. Nâng cấp pattern — những lessons lặp lại sẽ được ổn định hóa vào docs/troubleshooting/, và được kiểm soát tự nhiên bằng ngưỡng trần thư mục đánh chỉ mục 50+ mục.

Q2 cũng cùng ngữ cảnh đó:

• vận hành đồng thời không phải để tiết kiệm token mà mục tiêu chính là tránh xung đột và ngăn rule drift.

Là như vậy đấy.

Nếu mục tiêu là phân tán token, thì cách tôi nêu làm ví dụ ở trên mới đúng là pattern chính xác.

[soliestre]

Hiện tôi đã rà lại các dự án mình đang làm thì thấy số lượng lessons tối đa là 16.
Và vì phần tác động cùng Severity được gắn nhãn chung, nên có vẻ vẫn chịu được mức tích lũy nhất định,
nhưng nếu tích lũy vượt quá mức đó thì có lẽ vẫn cần nghĩ trước một kế hoạch xử lý.

Trường hợp của tôi thì không chạy riêng các bài test cho seed,
mà thay vì chỉ thử trên các dự án ở mức demo, tôi áp dụng trực tiếp vào những dự án đang được triển khai nghiêm túc và vừa dùng vừa tinh chỉnh, nên không có dữ liệu đo lường riêng.
Phần tối ưu hóa chỉ mục RAG hiện tại được áp dụng ở mức hiện nay vì mục tiêu là repo tài liệu phát triển thiên về Markdown.
(* Đây là phần được áp dụng nhằm tối ưu khi liên kết repo tài liệu phát triển của Claude Project.)

Về điểm thứ hai, trên thực tế tôi không hẳn khuyến nghị vận hành đồng thời theo thời gian thực.
Giả định cơ bản là sẽ dùng mô hình hiệu quả nhất tùy theo mục đích,
ngoài ra chỉ trong trường hợp làm các phần rõ ràng khác nhau thì mới có thể dùng đồng thời.
Ví dụ, có thể để Claude đảm nhiệm vai trò PM để lập kế hoạch phân chia công việc trước,
sau đó cho Antigravity và Codex chạy đồng thời FE/BE tương ứng,
rồi PM tổng hợp kết quả và tiếp tục lập kế hoạch vòng tiếp theo.

Ngoài ra, ở thời điểm hiện tại tôi không ở trong tình huống phải tiết kiệm token, nên trong master seed tôi đang cho chạy toàn bộ bằng các model cấp cao,
vì vậy việc phân tán token được tiếp cận theo hướng chọn gói có hiệu quả chi phí tốt trên từng nền tảng agent, đồng thời đăng ký thêm các nền tảng khác cũng với các gói hiệu quả chi phí để mở rộng theo chiều ngang.
Nếu mục tiêu là tiết kiệm token một cách tuyệt đối thì ở thời điểm này tôi không nghiêng về việc khuyến nghị sử dụng seed này.

[soliestre]

Tham khảo thêm, giới hạn dung lượng tệp của Claude Project (kiến thức dự án) vào khoảng 10MB, nên repo nhất định phải chủ yếu là văn bản.
Tất nhiên, vì có thể loại trừ một số tệp trong UI của Claude Project, nên nếu được tách theo thư mục hoặc số lượng tệp ít thì vẫn có thể ổn.