Mổ xẻ pstack: bộ skill của Lauren Tan biến coding agent thành một quy trình kỹ thuật

Tóm tắt nhanh: pstack là bộ skill, playbook và subagent mà Lauren Tan (poteto) mở mã nguồn trong repo cursor/plugins. Lõi của nó là /poteto-mode, một skill điều phối chọn playbook cho từng loại việc, yêu cầu agent chép nguyên các bước vào todo list và nêu tên nguyên tắc đã dùng. Điểm đáng học nhất không nằm ở số lượng skill, mà ở ba quyết định thiết kế: hầu hết skill chỉ chạy khi được gọi, review đối kháng dùng nhiều họ model khác nhau, và kết luận xác minh để cho merge phải đến từ một agent không viết phần code đó.

pstack do Lauren Tan viết. Lauren là thành viên nhóm React Compiler và viết các skill này trong thời gian làm ở Cursor (README ghi "the same skills i use every day to ship high quality code at Cursor"). Repo nằm ở cursor/plugins/pstack, giấy phép MIT.

Bài này dựa trên mã nguồn ở commit 9580c23 (pstack bản 0.15.32, commit lúc 10:27 ngày 24/10/2026 theo giờ Đông Dương (UTC+7)), các bài Lauren đăng trên X và phản hồi của cộng đồng. Những gì bài viết về hành vi của pstack là theo tài liệu và mã nguồn. Phần lớn pstack là chỉ dẫn bằng Markdown gửi cho model, nên khi bài viết "yêu cầu agent", hãy hiểu là skill yêu cầu, không phải plugin cưỡng chế.

pstack là gì

pstack là một plugin cho coding agent, gồm năm loại thành phần:

Thành phần	Có gì	Vai trò
Skill điều phối	`/poteto-mode`	Đọc yêu cầu, chọn playbook, áp nguyên tắc
Playbook	23 file Markdown trong `skills/poteto-mode/playbooks/`, phần lớn dưới 25 dòng	Các bước cho từng loại việc: sửa bug, tính năng, refactor, mở PR, chạy tự động qua đêm
Skill theo yêu cầu	`/how`, `/why`, `/architect`, `/arena`, `/interrogate`, `/swarm`, `/reflect` và các skill khác	Điều tra, thiết kế, review, xác minh
Nguyên tắc	24 skill `principle-*`	Mỗi nguyên tắc là một file riêng, agent đọc khi cần
Subagent	`poteto-agent`, `comment-sicko`	Người làm việc được giao, và một reviewer chuyên săn comment thừa

Lauren giải thích lý do làm pstack ngay đầu README: "throughput without quality is not a goal i aspire to. if you want to go fast, go deep first." Khi công bố bản mã nguồn mở ngày 25/5/2026 trên X, Lauren viết thêm một câu tóm gọn triết lý của cả bộ: "The bottleneck with agents is verification." (bài đăng)

Cài đặt

Theo README:

Trong Cursor: gõ /add-plugin pstack.
Trong Claude Code: chạy /plugin marketplace add cursor/plugins, rồi /plugin install pstack@cursor-plugins. Lệnh sẽ có tiền tố, ví dụ /pstack:poteto-mode. Với marketplace bên thứ ba, Claude Code mặc định tắt tự cập nhật. Bạn bật nó lên, hoặc cập nhật tay bằng claude plugin update pstack@cursor-plugins.

Sau khi cài, chạy /setup-pstack một lần để chọn ngân sách suy luận và model cho từng vai. Lauren tóm cách dùng trong một bài ngày 15/10/2026: chạy /setup-pstack, thêm /poteto-mode trước prompt nào cần làm kỹ, hỏi /poteto-help khi không biết dùng skill nào (bài đăng).

Một số bước trong playbook gọi tới skill không đóng gói sẵn: deslop, control-ui và control-cli nằm trong plugin cursor-team-kit. README khuyên cài thêm plugin này nếu bạn muốn đủ bộ.

Kiến trúc: một skill điều phối, nhiều playbook nhỏ

Phần đáng mổ xẻ nhất là cách pstack điều phối việc mà không nạp mọi thứ vào context ngay từ đầu.

Sáu bước của một task trong /poteto-mode: bạn gọi skill, skill tra bảng tác vụ và mở một playbook, agent chép các bước vào todo list, mỗi vòng giao cho subagent mới, một agent khác xác minh, câu trả lời nêu tên nguyên tắc — Một task đi qua /poteto-mode. Các mục dưới đây giải thích từng bước.

Hầu hết skill chỉ chạy khi được gọi. Trong 58 skill chính, 57 skill đặt disable-model-invocation: true. Ngoại lệ là setup-pstack. Model không tự nạp những skill này chỉ vì mô tả của chúng khớp với câu hỏi. Bạn gõ /poteto-mode, rồi poteto-mode gọi tiếp các skill khác theo tên. Lauren viết trên X rằng nhờ vậy cài pstack không tốn token cho tới khi bạn gọi nó (bài đăng). Lưu ý thêm: /setup-pstack ghi một file luật model mà agent nạp vào mỗi phiên mới.

File điều phối gọn về số dòng. skills/poteto-mode/SKILL.md dài 149 dòng, nhưng nhiều dòng rất dài, tổng cộng khoảng 20 KB. Nó chứa bảng tác vụ, mục lục một dòng cho 24 nguyên tắc, luật tự chủ, cách giao việc cho subagent, văn phong trả lời và danh sách playbook. Nó không chứa nội dung playbook. Mỗi playbook chỉ là một dòng trong file này, và agent chỉ mở file playbook khi việc khớp.

Todo list là hợp đồng. Đây là câu mình thấy hay nhất trong cả repo:

"Open a todolist whose first items are the matched playbook's steps, copied in verbatim [...] A step you choose not to do stays in the list with a one-line skip: <reason>."

Skill yêu cầu agent không tóm tắt hay "hiểu tinh thần" playbook, mà chép nguyên các bước. Bước nào bỏ qua vẫn nằm trong danh sách, kèm lý do một dòng. Người đọc lại phiên làm việc nhìn vào là biết agent đã bỏ bước nào và vì sao.

Nêu tên nguyên tắc kèm quyết định nó làm thay đổi. poteto-mode yêu cầu agent, trong câu trả lời, gọi tên từng nguyên tắc đã định hình một quyết định và quyết định cụ thể bị thay đổi. Agent chỉ được trích nguyên tắc nào đã đọc trọn file trong phiên đó. Luật này nhằm chặn kiểu trích dẫn cho có: nhắc tên "prove it works" mà không làm gì khác đi.

Mặc định dùng subagent mới. Mỗi vòng sửa, mỗi lần thử lại hay việc tiếp theo được giao cho một subagent mới, kèm toàn bộ phạm vi đã gom lại: brief gốc, mọi chỉ thị sau đó, báo cáo và nhánh của agent trước. Lý do được ghi thẳng: "Interrupt-chained resumes silently drop directives". Chỉ khi việc mới thật sự cần trạng thái nằm trong agent cũ (thay đổi chưa commit, một dev server đang chạy) mới dùng lại agent đó.

Agent chính chịu trách nhiệm cho mọi việc của subagent. "Review the diff and write your own summary, don't pass through what it said." Agent điều phối không được chuyển tiếp nguyên văn báo cáo của subagent, mà phải tự đọc diff.

Một playbook trông thế nào

Playbook sửa bug dài 15 dòng. Nó yêu cầu agent tự tái hiện lỗi trên đúng bề mặt (giao diện, CLI) trước khi hỏi người dùng, tìm nguyên nhân bằng cách loại trừ giả thuyết, giao phần sửa cho subagent, xác minh lại trên cùng bề mặt, rồi xếp commit sao cho bản tái hiện lỗi nằm trước bản sửa trong lịch sử git. Câu chốt: "Belt-and-suspenders that "might help" is a hypothesis, not a fix. It does not ship."

Không phải playbook nào cũng ngắn. multi-phase-plan.md dài 155 dòng và orchestrate.md dài 112 dòng.

24 nguyên tắc là bộ từ vựng để lái agent

Mỗi nguyên tắc là một skill riêng, dài 9 đến 34 dòng. Hướng dẫn chính thức (08-principles.md) giải thích cách dùng: bạn không gọi nguyên tắc, bạn dùng tên của nó để lái. Một cụm như "apply prove it works. run the real import flow and show me the written records." chuyển hướng agent chính xác hơn một đoạn chỉ dẫn dài, vì agent đã đọc luật đầy đủ đằng sau cái tên đó.

24 nguyên tắc chia thành năm nhóm: cốt lõi (bao nhiêu thì đủ, khi nào nghĩ lại thiết kế), kiến trúc (trạng thái, kiểm tra đầu vào, tương thích nằm ở đâu), xác minh (thế nào là bằng chứng), giao việc (context và quyền tự chủ) và một nguyên tắc về chính cách học. Năm nguyên tắc mình thấy khác biệt nhất:

Nguyên tắc	Ý chính	Câu đáng nhớ
Build the Lever	Viết script, codemod hay generator làm hoặc chứng minh công việc, để người review chạy lại được	Một script tất định biến "trust me" thành "run this"
Attack the Premise	Hai bản sửa dựa trên cùng một giả định đã fail thì nghi giả định, không nghi bản sửa	"Do not start the next fix before the premise is written down and tested."
Explain the Number	Gọi tên thứ giới hạn một con số đo được trước khi tin nó	Hỏi "why not double?": không nói được vì sao con số không tốt gấp đôi thì bạn chưa biết mình đo cái gì
Fix Root Causes	Sửa quyết định sai đầu tiên, không vá chỗ triệu chứng lộ ra	"If a workaround needs a paragraph-long comment to justify it, the code is wrong."
Encode Lessons in Structure	Chỉ dẫn lặp lại thì biến thành lint, check hoặc script	"If the fix is structural, only use the structural fix. The instruction is the symptom."

Nguyên tắc cuối là thứ chạy xuyên suốt repo. Skill /correct đào lịch sử commit, revert và bình luận review để tìm các lớp lỗi lặp lại, rồi sửa theo thứ tự cố định: kiến trúc trước, kiểu dữ liệu và lint sau, rồi test, tài liệu cuối cùng. Lý do tài liệu đứng cuối được viết rất thẳng: "Nothing fails when an agent skips them." Mỗi check mới phải được chứng minh là bắt được một lỗi có thật trong quá khứ.

Lauren kể trên X rằng nhiều nguyên tắc ra đời từ việc sửa sai agent suốt từ đầu năm 2026, và "Attack the Premise" lấy cảm hứng từ @VictorTaelin (bài đăng). Lịch sử commit cho thấy các nguyên tắc ngày càng ngắn và trừu tượng hơn: commit e5136d8 viết lại bốn nguyên tắc "as reasoning, not rules", để agent tự suy ra cách làm trong những trường hợp văn bản không nhắc tới.

Review đối kháng dựa vào nhiều họ model

Nhiều bộ skill review dùng persona: một agent đóng vai "chuyên gia bảo mật", một agent đóng vai "kiến trúc sư". Với review code, pstack chọn hướng khác. Dòng đầu của /interrogate ghi: "The adversarial signal comes from model diversity, not assigned personas." Đây là lựa chọn thiết kế của tác giả, repo không kèm thử nghiệm so sánh với cách dùng persona. pstack cũng không bỏ hẳn góc nhìn chia vai: /reflect vẫn chia ba góc nhìn, và comment-sicko là một persona rõ ràng.

Ý dùng nhiều họ model lặp lại ở nhiều skill:

Skill	Cách chạy	Gộp kết quả
`/interrogate`	Mỗi model đã cấu hình là một reviewer đối kháng (mặc định Opus và Grok)	Agent chính chia phát hiện thành nên làm, cân nhắc, ghi nhận, bác bỏ. Phát hiện mà hai model tìm ra độc lập là tín hiệu mạnh nhất
`/arena`	N ứng viên cùng một prompt, mỗi ứng viên một chỗ làm riêng (worktree khi được), thêm một giám khảo chéo, ưu tiên họ model khác với agent chính	Chọn một bản làm nền, ghép tay một hai phần tốt từ bản thua. Các bản lệch nhau quá nhiều thì đề bài chưa rõ, viết lại đề chứ không lấy trung bình
`/swarm`	Chia việc hoặc cho N worker chạy đua	Mỗi worker trả `PASS`, `ISSUES` hoặc `BLOCKED` kèm bằng chứng. "A gap does not count as a pass."
`/why`	Một điều tra viên cho mỗi nguồn bằng chứng tìm thấy lúc chạy (git, ticket, chat, log, lỗi)	Tách rõ điều đã tìm thấy, điều suy ra, các giả thuyết cạnh tranh và điều chưa biết
`/reflect`	Ba góc nhìn trên transcript của phiên: phán đoán, công cụ, góc ngược	Chờ người dùng duyệt rồi mới sửa skill

Cùng một diff đi tới reviewer Opus và reviewer Grok, agent chính lọc kết quả thành nên làm, cân nhắc, ghi nhận và bác bỏ; phát hiện cả hai cùng thấy là tín hiệu mạnh nhất — /interrogate với hai họ model mặc định. Số reviewer theo số model bạn cấu hình.

Agent chính cũng không phải người cộng điểm. File lead-judgment.md của /interrogate cảnh báo hiện tượng "nitpick gravity": reviewer không tìm ra lỗi nghiêm trọng sẽ thổi phồng lỗi vặt cho đủ báo cáo. Agent chính phải lọc những phát hiện kiểu "giả định chứ chưa xảy ra" hay "tôi sẽ làm khác".

Mặc định, pstack giao code cho Grok 4.7 và giao phán đoán, văn bản cho Opus 5.5. Lịch sử commit cho thấy bộ mặc định này đổi liên tục theo model mới, nên /setup-pstack ghi lựa chọn của bạn vào một file luật riêng để bạn không bị cuốn theo.

Xác minh là nút cổ chai, nên phần lớn code thật nằm ở đây

Các file Markdown trong pstack/skills/ cộng lại khoảng 432 KB. Code chạy thật tập trung ở những chỗ cần xác minh:

Thành phần	Làm gì	Loại
`statechart`	Nhận mô hình TLA+, vẽ ra statechart Mermaid, mỗi bug là một đường đi được đánh số	Khoảng 5.100 dòng JavaScript, kèm một file test khai báo 150 ca test
`watch-pr`	Theo dõi PR và chuỗi PR, trả kết quả có kiểu (`READY`, `WAITING`, `BLOCKER`...) với mã thoát riêng	TypeScript chạy bằng Bun, có test
`orch`	Sổ sách cho playbook điều phối nhiều ngày: đơn vị việc, hộp thư, cổng duyệt	TypeScript, chỉ ghi chép, không tự sinh agent
`check-plan.mjs`	Lint file kế hoạch nhiều PR, bắt buộc mỗi phần có mục xác minh	JavaScript, có test
`create-verification-skill`	Sinh một skill `verify-<app>` riêng cho dự án: khởi động, kiểm tra sức khoẻ, thao tác, thu bằng chứng, dọn dẹp, script phụ trợ, kèm một bản đồ tính năng trong `features/`	Prompt sinh ra skill và script

Ngày 30/7/2026, Lauren viết rằng /create-verification-skill và /maintain-verification-skill là hai skill nên dùng hoặc chép về (bài đăng). Skill sinh ra phải tự chạy trọn một lần trước khi được tính là xong: "A generated skill that was never executed is a draft, not a deliverable." Sau bước dọn dẹp, bằng chứng vẫn phải còn ở chỗ đã ghi.

/create-formal-verification-skill vào mã nguồn ngày 17/10/2026 (commit 4382e68, đã có trong bản 0.15.26). Lauren giới thiệu nó trên X kèm bản 0.15.27, gọi là bản beta, và cho biết đã tìm ra vài bug khi mô hình hoá code bằng TLA+ (bài đăng). Hướng dẫn chọn rất thực dụng: chỉ nên dùng khi code có đồng thời, thử lại, máy trạng thái hoặc parser, tức là chỗ bug đắt và test hiếm khi chạm tới. Skill cũng tự nói giới hạn: "A pass covers the model or the bound, not the whole system."

Luật xác minh khi ship nằm trong playbook shipping.md: "Only a verdict from an agent that did not write the code counts, because an author checks what it meant to build." Theo playbook này, CI xanh và bot review chấp thuận không phải là kết luận, vì chúng không chạy thay đổi như người dùng. Đây là tiêu chuẩn riêng của pstack: CI của bạn có thể có test đầu cuối, nhưng pstack vẫn đòi một agent độc lập tự chạy. Để biết một kết luận cũ còn dùng được không, playbook so git patch-id ở SHA đã duyệt với head hiện tại. Có một ngoại lệ hẹp khi thay đổi chỉ nằm ở test, tài liệu hoặc cấu hình lint và bản build tương đương, nhưng phần vừa đổi vẫn cần kiểm tra và review mới.

Lauren dùng pstack thế nào: hai phần đầu của bộ hướng dẫn trên X

Mã nguồn cho biết pstack có gì. Hai bài hướng dẫn Lauren đăng trên X cho biết tác giả ghép chúng lại thế nào trong công việc hằng ngày: phần một ngày 31/8/2026 và phần hai ngày 9/9/2026. Ở cả hai bài, Lauren kể đang dùng pstack để giữ chất lượng codebase của Grok Bot, một app desktop mà nhiều người cùng đóng góp mỗi ngày, và pstack cũng cài được dưới dạng plugin cho Grok Bot.

Nếu bạn muốn xem thay vì đọc, series video Mổ xẻ: Lauren Tan làm việc với coding agent có năm tập ngắn mổ xẻ buổi chia sẻ của Lauren: agent tự kiểm tra, skill và eval, tin agent ở máy mình trước, ràng buộc cứng, và token là khoản đầu tư. Nhiều ý trong series đi cùng mạch với các phần bên dưới, nhất là tập đầu về xác minh.

Phần một: skill xác minh là hạ tầng

Lauren coi skill xác minh là "critical infrastructure" chứ không chỉ là một skill, tức là thứ cần bảo trì và có người trực như hạ tầng. Ba ý chính:

Một CLI nhỏ thay vì Markdown. Đây là nguyên tắc "Build the Lever" áp vào xác minh. Thay vì để agent viết script dùng một lần để bấm nút, skill xác minh đi kèm một CLI có các lệnh như doctor, snapshot, screenshot, wait-settle, feature-flag. Lauren liệt kê các tính chất của một CLI hợp với agent: dễ ghép lệnh, lệnh có tác dụng phá huỷ thì có --dry-run, chia lệnh con để lộ dần chức năng, thông báo lỗi nói rõ agent nên làm gì thay thế, --help đầy đủ, và trả kết quả dạng máy đọc được như JSON.
Bản đồ tính năng (Feature Map). Đây là thư mục Markdown liệt kê mọi tính năng của app, cách tới nó từ góc nhìn người dùng và cách điều khiển nó bằng CLI. Trong mã nguồn, /create-verification-skill sinh thư mục features/ với đúng bốn mục cho mỗi tính năng: Sub-features, How to get to it (user POV), Driving it with <harness> và Gotchas. Lauren gọi nó là "materialized memory": codebase mới là bộ nhớ thật, còn bản đồ tính năng là một dạng nén để tiết kiệm token. Để bản đồ không lỗi thời, Lauren khuyên chạy /maintain-verification-skill ít nhất mỗi ngày một lần. Lauren cho biết thêm là agent thường tự cập nhật bản đồ trong chính PR sửa app, còn tác vụ tự động chỉ bắt phần bị sót (trả lời). Lauren cũng công bố một repo ví dụ cho một app giả tên Atlas.
Cloud agent thay vì worktree. Lauren khuyên không chạy song song bằng worktree trên máy mình, vì tốn dung lượng và tài nguyên, và chỉ chịu được khoảng mười agent tuỳ máy. Cloud agent của Cursor có máy riêng để cài phụ thuộc, chạy app và quay video. Đây cũng là lý do điểm "gắn chặt với Cursor" ở phần sau quan trọng: đường cài cho Claude Code chuyển các worker cloud thành worktree, đúng thứ Lauren khuyên tránh.

Từ nền đó, Lauren ghép skill xác minh với /swarm để chạy nhiều agent cùng đo một thay đổi hiệu năng cho đủ cỡ mẫu, và đặt nó vào tác vụ tự động để tự tái hiện các báo lỗi người dùng gửi vào Slack.

Phần hai: giám sát một agent giỏi hơn mình

Phần hai bàn chuyện quyết định xây gì, và Lauren gọi nó là "the art of supervising someone smarter than you". Lauren nêu hai kiểu thất bại hay gặp: agent không hiểu đúng ý vì yêu cầu thiếu, và agent thiếu context để làm đúng. Cách xử lý:

Bắt agent nói lại bằng lời của nó. Thay vì nêu giả thuyết của mình, Lauren yêu cầu agent đọc thread Slack rồi "restate in your own words and in plain english" vấn đề gốc. Cách này ép agent nén cuộc trò chuyện thành một phát biểu rõ ràng, giúp bắt hiểu lầm sớm, và tránh dắt agent theo giả định sai của người hỏi.
Xây mô hình trong đầu bằng /teach và /recall. /teach chạy /how và /why rồi gộp thành một lời giải thích dễ hiểu. /recall dựng lại context từ lịch sử chat để agent mới không phải bắt đầu từ đầu. Lauren nhận xét phần nghiên cứu này giúp cả agent, vì model vẫn hay khẳng định chắc nịch mà không đọc code.
Lên kế hoạch bằng code. README của pstack có mục "why are there no planning skills?" với câu "the best spec is code". Thực tế Lauren vẫn lập kế hoạch, nhưng qua README viết trước (dùng /technical-writing, chia tài liệu theo bốn kiểu của Diátaxis), qua playbook prototype.md dựng các bản thử dùng một lần đặt sau một nút chuyển, và qua /architect. /architect dựng nền bằng /how và /why, cho nhiều model phác giao diện và kiểu dữ liệu qua /arena, rồi viết code theo bản phác. Nếu kiểu dữ liệu phải dùng lối thoát như any hay ép kiểu, đó là bằng chứng kiến trúc sai và agent bỏ bản phác để làm lại.
Không review đối kháng kế hoạch trừu tượng. Lauren viết rằng khi review một kế hoạch còn trên giấy, agent "start hallucinating theoretical risks". Câu hỏi mở nên được trả lời bằng prototype. Mã nguồn khớp với điều này: /architect chỉ gợi ý chạy /interrogate trên bản phác đã có kiểu dữ liệu và chữ ký hàm, không chạy trên một tài liệu ý tưởng. Khi thật sự cần kế hoạch, playbook multi-phase-plan.md chia việc thành các PR nhỏ, mỗi phần có mục xác minh, và script check-plan.mjs kiểm cấu trúc. Lauren cho biết thường xoá kế hoạch sau khi xong việc.

Phần hai mở đầu bằng một ảnh chụp ghi 2.462 PR lên production trong tháng 8/2026. Đây vẫn là số Lauren tự báo.

Repo lớn lên thế nào trong năm tháng

Thư mục pstack/ có 162 commit. Ngày trong bảng lấy theo ngày tác giả của commit, giữ múi giờ ghi trong commit. 156 commit ghi tác giả là Lauren, và tháng 10 nhiều nhất với 72 commit. Vài mốc đáng chú ý:

Ngày	Mốc
22/5/2026	Commit đầu `24bd6eb`: `poteto-mode`, 18 nguyên tắc, `how`, `why`, `architect`, `arena`, `interrogate`, `reflect`
6/6/2026	Cấu hình model theo vai qua `/setup-pstack`
12/7/2026	`create-verification-skill` và `maintain-verification-skill`
14/7/2026	Commit `3fe2823` "parity sweep with the private skill tree"
1 và 2/8/2026	Playbook chạy tự động, Shipping, Orchestrate, cùng hai script `watch-pr` và `orch`
7/9/2026	Đợt sửa văn phong: thêm "Attack the Premise", thay 239 dấu chấm phẩy và đo lại số token
16/10/2026	Đường cài chính thức cho Claude Code, sinh từ cây skill gốc
17 đến 23/10/2026	Xác minh hình thức, `statechart` với TLA+

Hai điều mình rút ra từ lịch sử này. Một là tác giả liên tục cắt bớt: nhiều commit chỉ để giảm token hoặc bỏ chỉ dẫn mà model mới "không cần". Hai là một số thay đổi được đồng bộ từ một bộ skill nội bộ, theo tên các commit như 3fe2823. Mình không biết ở thời điểm hiện tại bản công khai khác bản nội bộ bao nhiêu.

Cộng đồng nói gì, và những điều cần biết trước khi cài

pstack được chú ý nhiều và có nhiều bản port. Taylor Otwell viết "pstack is the new solid" (bài đăng). Matt Pocock ghi chép từ buổi nói chuyện của Lauren ba ý: khoá chặt quyền của agent, đầu tư hạ tầng xác minh, giữ một bản đồ tính năng để agent định hướng (bài đăng). Ngày 19/8/2026, Lauren kể đã ship 1.000 PR trong tháng trước và đang trên đà gấp đôi (bài đăng). Phần một của bộ hướng dẫn pstack ghi con số 2.000 PR mỗi tháng, phần hai ghi 2.462 PR trong tháng 8. Đó là số Lauren tự báo, không có mẫu số như kích thước PR hay tỷ lệ revert, và mình không kiểm được.

Trong khi đó, các phản hồi thực tế xoay quanh ba điểm. Bạn nên biết trước khi cài:

Tốn token. Ray Fernando kể đã vượt hai tỷ token trong một ngày khi dùng pstack cho mọi việc, rồi chuyển sang chỉ dùng cho việc khó (bài đăng). Chính Lauren khuyên không dùng /poteto-mode cho mọi thứ (bài đăng), và tài liệu cài đặt ghi: "pstack spends extra tokens on subagents and review panels. That's the price of the rigor."
Quá tay cho việc nhỏ. Có người dùng gọi nó là "overkill" cho phần lớn việc hằng ngày (bài đăng), có người chỉ cài một phần (bài đăng).
Gắn chặt với Cursor. Skill gọi thẳng các tính năng riêng của Cursor: cloud agent, Automations, Bugbot, luật .mdc. Bản cho Claude Code là một lớp ánh xạ, không phải viết lại. Theo docs/harness/claude-code.md, vai Opus vẫn được ánh xạ sang Opus, còn vai dùng model không phải Claude như Grok thì bỏ trường model và chạy trên model của phiên. Nghĩa là trong Claude Code, cặp Opus và Grok mặc định không còn nguyên, và nếu phiên của bạn cũng chạy Opus thì hai reviewer sẽ cùng một họ model. Cũng theo file đó, subagent readonly: true được ánh xạ sang subagent Explore, vốn vẫn gọi được Bash, nên việc không sửa file chỉ còn là lời dặn trong brief cộng một lần kiểm git status. Worker environment: "cloud" thì chuyển thành worktree, tức là chạy trên chính máy của bạn thay vì một máy cloud riêng.

Một chi tiết kỹ thuật mình kiểm được: workflow CI duy nhất của repo chạy node --test pstack/skills/*/scripts/test/*.test.mjs. Mẫu đường dẫn này chỉ khớp thư mục test của statechart. Bộ test Bun của watch-pr, orch và check-plan không được workflow này chạy. Mình không biết chúng có được chạy ở nơi khác hay không.

Vì bản chính thức ban đầu chỉ chạy trên Cursor, cộng đồng tự port sang nơi khác. Số sao tính tới ngày 24/10/2026, cột cuối là mô tả do mỗi repo tự ghi:

Repo	Sao	Dành cho
michael-denyer/pstack-claude	3.347	Claude Code, Codex, Copilot, Pi, OpenCode và vài harness khác
backnotprop/pstack	2.655	Claude, Codex, Pi
ericlitman/open-pstack	519	Claude Code và Codex, bám theo bản gốc
chhoumann/t3-pstack	226	T3 Code, chia hội đồng review cho Claude, GPT và Grok
ScriptedAlchemy/pstack-codex	71	Codex

Hai repo port đầu được tạo bốn đến năm ngày sau commit đầu tiên. Đường cài chính thức cho Claude Code mãi tới 16/10/2026 mới có. Mình chưa kiểm nội dung các bản port, nên không đánh giá bản nào bám sát bản gốc hơn.

Mang gì về dùng ngay, không cần cài pstack

Đây là phần mình thấy giá trị nhất. Bạn dùng Claude Code, Codex hay agent nào cũng áp được:

Một file điều phối ngắn cộng nhiều playbook nhỏ. Giữ một file ánh xạ loại việc sang playbook, mỗi playbook một file. Yêu cầu agent chép nguyên các bước vào todo list và ghi skip: <lý do> cho bước bỏ qua.
Đặt tên cho nguyên tắc. Viết những luật ngắn có tên, kèm câu "bạn đã bỏ qua luật này khi...". Yêu cầu agent nói nguyên tắc nào đã làm thay đổi quyết định nào.
Sửa repo, đừng sửa prompt. Bị sửa sai cùng một lỗi hai lần thì biến nó thành kiến trúc, kiểu dữ liệu hoặc lint có thông báo lỗi chỉ đúng cách làm. Tài liệu là lựa chọn cuối.
Kết luận cho merge phải đến từ agent không viết code. Tác giả vẫn tự kiểm tra, nhưng bước xác minh quyết định thì giao cho một agent khác, tốt nhất là họ model khác. Coi CI xanh là dữ kiện đầu vào, không phải kết luận.
Chạy dài thì đặt điều kiện dừng, không đặt thời lượng. Đây là kỷ luật của playbook hillclimb.md và skill /show-me-your-work: mỗi vòng một thay đổi, một phép đo để giữ hay revert, một dòng trong file nhật ký TSV. Thứ gì "có thể giúp" mà không có bằng chứng thì gỡ ra. Hướng dẫn 07-overnight.md còn dặn chỉ để vòng lặp chạy một mình khi nó đã chứng tỏ đáng tin, và ghi rõ /loop là tính năng có sẵn của Cursor, không phải skill của pstack.
Một skill xác minh riêng cho dự án. Có các phần khởi động, kiểm tra sức khoẻ, thao tác, thu bằng chứng, dọn dẹp và script phụ trợ, kèm một CLI nhỏ cho agent gọi và một bản đồ tính năng mô tả cách tới và cách kiểm từng tính năng. Chỉ tính là xong khi đã chạy trọn một lần, và bảo trì nó như hạ tầng.
Bắt agent nói lại vấn đề trước khi sửa. Đưa agent tài liệu gốc (thread, báo lỗi) và yêu cầu nó nói lại vấn đề bằng lời của nó, thay vì nêu giả thuyết của bạn.
Trả lời câu hỏi thiết kế bằng prototype, không bằng tranh luận trên giấy. Dựng vài bản thử dùng một lần, đo hoặc chụp lại, rồi mới chọn. Review đối kháng để dành cho bản phác đã có kiểu dữ liệu và chữ ký hàm.

Câu hỏi thường gặp

pstack có dùng được ngoài Cursor không? Có. Repo chính thức hỗ trợ Cursor và Claude Code. Các harness khác như Codex, Pi hay T3 Code dùng bản port của cộng đồng. Với đường cài chính thức cho Claude Code, các bước cần tính năng riêng của Cursor (Automations, cloud agent, Bugbot) bị bỏ qua kèm một dòng Skipped in Claude Code, và phần review nhiều họ model bị thu hẹp. Các bản port xử lý chuyện này theo cách riêng của từng người port.

Cài pstack có làm tốn token không? Hầu hết skill chỉ nạp khi được gọi, nên cài xong mà không dùng thì tốn rất ít. Dùng /poteto-mode thì tốn hơn hẳn một phiên thường, vì nó sinh subagent và hội đồng review. Lauren khuyên chỉ dùng cho việc khó và chọn model rẻ hơn cho các vai viết code qua /setup-pstack.

Nên bắt đầu từ đâu? Đọc file skills/poteto-mode/SKILL.md và playbook sửa bug. Hai file này cho thấy gần hết tư duy của cả bộ, và bạn chép ý về được mà không cần cài gì.

Dùng bài này trong agent của bạn

Lấy API key

Chép đoạn dưới, dán vào Claude Code, Codex hay agent bạn đang dùng. Agent đọc bài rồi đối chiếu với repo đang mở.

Dán vào agent

Đọc bài "Mổ xẻ pstack: bộ skill của Lauren Tan biến coding agent thành một quy trình kỹ thuật" trên modernEngineer rồi áp dụng vào repo này.
1. Gọi tool content_get của MCP server modernengineer với locale "vi", slug "pstack-teardown". Nếu chưa nối MCP hoặc bị từ chối quyền, đọc thẳng trang https://modernengineer.dev/vi/library/pstack-teardown.
2. Tóm tắt các bước chính của bài, chỉ ra bước nào áp dụng được cho repo này.
3. Đề xuất thay đổi cụ thể và hỏi tôi trước khi sửa file.

Nối MCP cho Claude Code (một lần)

terminal

claude mcp add --transport http modernengineer \
  https://api.modernengineer.dev/mcp \
  --header "Authorization: Bearer <API key>"

Cách nối Codex, Cursor và client khác

Bài mở cho mọi người: chưa nối MCP thì agent vẫn đọc được thẳng từ link bài.

Phiên bản: v1.0.0
Cập nhật: 29/10/2026
Giấy phép: Bảo lưu mọi quyền
Slug: pstack-teardown