Pstack: quy trình sáu stage của một engineer Cursor khi ship code với AI

1. Pstack là gì và Lauren Tan là ai

Video mở bằng việc giới thiệu Lauren Tan. Theo Eric, hiện chị là principal engineer tại SpaceX, thuộc technical staff tại Cursor, từng là staff engineer tại Meta, và là core member của team React. Gần đây chị open source toàn bộ kiến thức của mình, gồm workflow, skill và principle (nguyên tắc) khi viết code, vào một repo tên là Pstack.

Eric nói video sẽ trả lời ba câu hỏi: Pstack chính xác là gì, có những skill nào, và các skill đó khác ra sao so với những bộ skill mà kênh đã review trước đây. Ai xem tới cuối video còn được nghe những điều Eric rút ra sau khi đọc bộ skill phát triển phần mềm của chị.

Eric chuyển sang sơ đồ do chính anh tạo ra, phân rã toàn bộ workflow của chị, các skill và những principle chị theo mỗi khi viết code. Anh chia skill của chị vào sáu stage, tức toàn bộ vòng đời phát triển phần mềm với AI (AI software development lifecycle). Về vòng đời này anh đã làm một video riêng và để link ở trên màn hình. Anh bắt đầu từ stage đầu tiên là planning.

Như vậy video đi theo trục chính là sáu stage đó, và với mỗi stage Eric cho thấy có những workflow nào, mỗi workflow gọi những skill nào, rồi đặt chúng cạnh các skill mà anh đã dùng và review ở những video trước. Ngoài workflow và skill, nhánh thứ ba của sơ đồ là principle, những nguyên tắc chị theo mỗi khi viết code, và phần này được để lại cuối video.

2. Stage 1, Planning: học code trước, rồi lập kế hoạch cho việc lớn

Ở planning, Eric nói rằng khi xây ứng dụng thì ta luôn bắt đầu bằng lập kế hoạch, nhưng skill của Lauren ở đây chủ yếu phục vụ dự án brownfield, tức dự án đã có sẵn code. Stage này có hai workflow: learn the code first (học code trước) và plan a big job (lập kế hoạch cho một việc lớn).

Với workflow học code, có ba skill. Muốn biết code chạy thế nào thì dùng skill how. Muốn biết vì sao code lại chạy theo cách này thì dùng skill why. Skill teach kết hợp cả how và why, và về cơ bản đó chính là workflow học code trước.

Với workflow lập kế hoạch, nếu muốn chia một task hay một dự án thành các ticket nhỏ hơn, ta dùng skill figure-it-out và skill show-me-your-work. Hai skill này ghi lại các quyết định vào một file Markdown tài liệu hẳn hoi.

Cá nhân Eric nói anh có lẽ sẽ không dùng skill planning của chị, vì chị không thật sự tập trung vào giai đoạn planning. Skill của chị chủ yếu hướng tới cải thiện ứng dụng có sẵn, chẳng hạn một cuộc migration lớn hay một thay đổi lớn, và với việc đó thì skill của chị rất đạt chuẩn. Nhưng với solo builder, hoặc khi xây ứng dụng từ đầu, Eric thiên về skill của Matt Pocock hoặc Superpowers. Đó là hai bộ skill anh dựa vào nhiều, hơn là dùng skill planning của Lauren.

3. Stage 2, Design: nhiều model cùng thiết kế rồi gộp lại

Stage thứ hai là design. Đây là phần ta thiết kế cách triển khai trước khi viết dù chỉ một dòng code. Ở đây chỉ có một workflow, tên settle the code shape (chốt hình dạng của code).

Skill đầu tiên là architect. Nó kích hoạt skill arena, để nhiều model khác nhau và nhiều AI agent khác nhau cùng toả ra (fan out) và mỗi bên tự làm một bản thiết kế. Khi các agent mang về nhiều bản design, ta gọi skill interrogate: một AI model sẽ chấm các kết quả đó rồi gộp lại thành một báo cáo design duy nhất.

Eric nhấn mạnh điều này rất khác Matt Pocock hay các bộ skill khác mà kênh từng review. Trước đây ta chủ yếu dựa vào một model duy nhất. Cách của Lauren thì dựa vào nhiều model khác nhau, như Opus, GPT hay Grok, bất cứ model nào ta nghĩ ra được. Cho chúng toả ra, so sánh kết quả, lấy phần tốt nhất của từng tầng model, rồi tổng hợp thành một báo cáo design trước khi sang stage kế tiếp. Đó là stage design của chị.

4. Stage 3, Build: TDD và TypeScript best practices

Stage thứ ba là building, với hai workflow. Workflow thứ nhất là viết code theo test-driven development, tức write it test-first. Viết test trước cũng dùng skill tdd. Eric cho biết anh đã tự so sánh các skill TDD của Pstack, của Matt Pocock và của Superpowers, và trên màn hình là bảng phân tích sự khác biệt giữa các skill đó.

Bảng chia theo tình huống, ví dụ sửa bug nhanh, feature mới làm một mình, đội cần kỷ luật chặt. Vì có quá nhiều skill test-driven development đã được review, nếu muốn biết skill nào hợp với mình nhất, Eric bảo bạn mở trang đó; anh sẽ để link ở cuối video.

Khi đã có skill TDD, còn có skill typescript-best-practices. Lauren Tan, người tạo Pstack, chủ yếu làm việc với React, mà React thì dùng TypeScript. Vì vậy skill này buộc AI xây ứng dụng theo các TypeScript best practice.

5. Cleanup diff: deslop và vì sao không để comment trong code

Workflow thứ hai của stage build là clean up the diff, với skill deslop (tên trong video đăng 15/10/2026; ngày 17/10/2026 repo pstack liệt kê skill này dưới tên unslop). Trước hết nó so sự khác nhau giữa nhánh main và nhánh hiện tại. Rồi nó chạy thêm một số kiểm tra: comment thừa, try/catch (tức các exception về lỗi), biến không có type, nesting quá sâu. Tất cả những thứ này nên bị loại khỏi code, theo best practice về cách viết code không mang dấu vết AI slop.

Mục tiêu là giữ nguyên hành vi (behavior) bằng cách chạy test để chắc chắn điều đó, và cuối cùng nó đưa ra một bản tóm tắt dài một đến ba câu.

Eric muốn chỉ ra một điểm: skill này gỡ comment thừa. Vì sao chị lại muốn gỡ comment? Vì trong Pstack có hẳn một skill tên no-comments. Lý do chị chủ trương không comment trong code là AI nhiều khi đọc comment thay vì đọc code. Giả sử comment nói hàm này trả về A, nhưng code của hàm lại trả về B. AI nghe theo cái nào? Có khi AI chỉ nhìn comment chứ không nhìn code. Vì thế chị bỏ comment, để loại bớt nhiễu, và AI sẽ nhìn vào code thay vì comment.

Eric kết lại rằng đó là toàn bộ quy trình build trong Pstack của Lauren Tan.

6. Stage 4, Test: dựng skill để chứng minh app chạy thật

Stage kế tiếp là testing, có ba workflow, và Eric đi qua từng cái một. Workflow đầu tiên là prove the application works (chứng minh ứng dụng chạy), dùng skill create-verification-skill.

Nó khác skill TDD ở chỗ nào? TDD chủ yếu viết functional test hay unit test, còn create-verification-skill chủ yếu tạo end-to-end test. Eric lưu ý rằng trước khi tạo end-to-end test, ta phải dựng môi trường, dựng database, dựng server, tức dựng gần như đúng cách một người dùng khởi chạy ứng dụng: launch, chẩn đoán (diagnose) khi có sự cố, điều khiển hành vi người dùng thật (drive), thu thập bằng chứng (evidence), dọn dẹp (cleanup). Phần cleanup nghĩa là đôi khi phải gỡ database hay server tạm đã bật lên, và có một số hàm trợ giúp (helper) dọc đường.

Nói gọn lại, Eric thấy giá trị nằm ở chỗ skill này viết ra cả một quy trình để AI agent tự dựng ứng dụng lên và tự điều khiển nó như người dùng thật, thay vì chỉ viết một bài test rời rạc. Muốn làm được vậy, agent phải biết ứng dụng khởi động bằng lệnh nào, cần database nào, cần server nào, và phải biết gỡ chúng đi khi xong.

Theo trang mô tả trên màn hình, skill đọc repo (chứ không phải bạn) để biết cách launch, drive và capture proof; rồi nó viết file verify-<app>/SKILL.md với các phần Launch, Doctor, Drive, Evidence, Cleanup, Helpers; thêm một thư mục features/ với mỗi feature một file; chạy các bước của chính nó một lần từ đầu tới cuối; và chỉ bạn tới skill maintain.

Eric diễn giải: skill này viết ra một skill khác để dựng cả luồng end-to-end đó. Viết end-to-end test là mấu chốt, nhưng việc dựng cả luồng, tức AI agent sẽ khởi động bằng cách nào và chạy lệnh gì, thì cần một skill để tạo ra loại verification này. Ngoài ra có thêm vài quy tắc, ví dụ một feature một folder thay vì nhét mọi feature vào cùng một folder, mỗi feature tự chạy các bước của nó một lần từ đầu tới cuối, rồi dẫn bạn tới skill maintaining.

7. Swarm, blast-radius và tấn công chính diff của mình

Sau đó còn một skill nữa là swarm. Thay vì để một AI agent chạy hết từ đầu tới cuối, vừa launch vừa test các trang, ta "swarm": cho nhiều agent khác nhau, thậm chí chọn model khác nhau, mỗi agent lo một phần nhỏ, rồi cuối cùng gộp thành một báo cáo duy nhất. Đó là phần "prove it on the real application".

Eric đặt phần này cạnh skill TDD ở stage trước: TDD viết test nhỏ, còn phần prove it on the real application thì chạy ứng dụng thật từ đầu tới cuối rồi mới nói là nó chạy.

Workflow thứ hai của stage test là vet the change and the number, gồm blast-radius (tìm xem thay đổi có thể làm hỏng gì) và benchmark-checklist (kiểm tra nhanh các con số tốc độ có hợp lý không).

Workflow cuối của stage test là attack the diff (tấn công chính diff). Nó dùng lại skill interrogate từ stage design: có nhiều AI agent cùng cố phá thay đổi của bạn. Cụ thể, nó biết sự khác biệt, tức so nhánh main với nhánh feature hiện tại để xem code đã đổi gì, rồi cho các AI model khác nhau bật lên, thử xem có phá được thay đổi mình vừa làm hay không.

Ngoài ra còn có skill thermo-nuclear-code-quality-review. Eric nói anh không biết họ nghĩ ra cái tên này từ đâu. Skill này làm một lớp review cực kỳ gắt để xem có cách nào làm code đơn giản hơn nhiều hay không, và nó khá giống một skill mà kênh đã review trước đây. Nói cách khác, nó thử xem có thể refactor code tốt hơn nữa không.

Đó là những workflow trong stage testing, và Eric thấy chúng rất thú vị.

8. Stage 5, Deploy: đưa pull request tới lúc merge

Stage cuối trong phần lõi là deployment. Hiểu đơn giản, ta đang cố đưa feature lên: mọi thứ đã được test, sẵn sàng merge vào pull request. Việc đầu tiên là làm cho pull request dễ review. Nhưng ai cũng có phong cách viết riêng, ngay cả bộ skill Super Board của Eric cũng có phong cách riêng cho việc này, nên tuỳ bạn muốn pull request của mình được review ra sao. Bạn có thể tham khảo skill make-pr-easy-to-review của chị để xem cách dọn gọn một pull request.

Có cả một bộ skill cho toàn bộ pipeline. babysit trông chừng cả pull request: nếu sắp merge thì canh để nó merge trọn vẹn. fix-merge-conflicts xử lý lúc bạn sắp merge pull request mà một người khác trong team cũng đang merge, gây ra xung đột với thay đổi của bạn; skill này giải xung đột rồi kiểm tra lại build. get-pr-comments liệt kê các review comment thành các action. fix-ci sửa các CI check đang fail, tức pipeline CI/CD.

Đó là những gì chị đã xây thành cả một pipeline, và nếu quan tâm bạn có thể xem thêm.

Eric nhắc lại rằng đây là những mắt xích mà chị đã xây thành cả một pipeline, từ lúc pull request được tạo cho tới lúc nó merge được, và với anh phần này đáng để tham khảo nếu bạn muốn một quy trình trông coi pull request trọn vẹn.

9. Stage 6, Maintain và các skill dùng bất cứ lúc nào

Stage thứ sáu là maintaining: làm sao thu thập các vấn đề rồi quay vòng về stage planning. Theo Eric, chị không có skill nào cho phần này; trong sơ đồ, cột Maintain ghi rằng stage này chưa có skill trong Pstack. Trái lại, kênh của Eric đã review rất nhiều skill maintaining, và Super Board của anh có sẵn bộ skill cho giai đoạn đó, bạn cũng có thể xem.

Vậy là sáu stage của chu trình phát triển phần mềm trong skill của chị đã xong. Tiếp theo là nhóm skill phụ mà ta có thể kích hoạt bất cứ lúc nào, ở bất cứ chỗ nào trong quá trình phát triển, rồi cuối video là phần principle.

Với nhóm skill phụ, đầu tiên là router skill, tên poteto-mode. Nếu bạn gặp một tình huống mà không biết nên kích hoạt skill nào, hãy bật chế độ này và giải thích vấn đề, nó sẽ cố chọn đúng skill để xử lý. Ngoài ra có các setup skill (setup-pstack, poteto-help), nhóm catch-up and plain talk, nhóm skill viết, và nhóm cải thiện Pstack theo thời gian.

Eric đặc biệt thích nhóm catch-up và plain talk, nhất là để recall. Giả sử bạn đổi bối cảnh, đang làm nhiều project khác nhau và muốn nhớ lại mọi chuyện đã xảy ra tới giờ, thì có một nhóm skill để dùng cho việc bắt kịp tình hình. Anh đã gom chúng vào các nhóm, và nếu muốn xem chi tiết hơn bạn có thể mở trang của anh.

10. Principles: vì sao là skill chứ không phải system prompt

Phần cuối là các principle. Trong Pstack có rất nhiều principle skill. Bạn có thể hỏi: sao chúng là skill mà không để vào system prompt?

Lý do là nếu giữ mọi quy tắc và nguyên tắc trong system prompt thì đó sẽ là một file khổng lồ chứa rất nhiều token. Hãy nghĩ rằng mỗi tin nhắn bạn gửi cho AI đều bắt nó đọc cả system prompt đó, trong khi phần lớn thông tin có thể không liên quan tới việc bạn đang làm. Nên Pstack để các principle trong nhiều skill riêng, kèm một bản đồ chỉ mục (index map) cho biết khi nào nên kích hoạt cái nào.

Vì có quá nhiều principle, Eric chỉ chọn ra những cái anh thấy thật sự hữu ích, dựa trên những gì anh đã có trong Super Board của mình. Principle đầu tiên là keep it small (giữ cho nhỏ). Nó rất giống một skill mà kênh đã có từ trước, nên anh không bàn thêm.

11. Principle attack-the-premise: dừng vòng lặp sửa lỗi

Trong nhóm design for shape (thiết kế hình dạng), Eric muốn nói về principle thú vị tên attack-the-premise. Có lúc ta nhờ AI sửa một bug; nó sửa xong, lỗi vẫn còn, sửa lần nữa, lỗi vẫn còn. Và điều xảy ra là nó cứ quay vòng: sửa rồi bị chặn, sửa rồi bị chặn, và có cảm giác AI hoàn toàn không sửa nổi bug đó.

Skill này, như Eric nói, bắt AI dừng lại và đặt câu hỏi về giả định: liệu mình có đang đi đúng hướng không, trước khi cho AI tiếp tục tập trung vào hướng đó. Eric thấy đây là một skill rất hữu ích và anh định thêm nó vào bộ skill Super Board của mình.

12. Principle type-system-discipline và điều Eric mang về

Nhóm principle kế tiếp là code structure and safety (cấu trúc code và an toàn), cụ thể là type system discipline. Đôi khi một biến có thể có nhiều type hoặc nhiều trạng thái khác nhau, nên điều quan trọng là phải từ chối các trạng thái bất khả thi (impossible states). Ví dụ, một khoản thanh toán không thể vừa đã trả (paid) vừa đang chờ (pending) cùng lúc. Với những vấn đề như vậy, ta cần một principle xử lý chúng, và Eric cũng sẽ thêm cái này vào Super Board.

Eric tổng kết đó là những principle anh thấy thật sự có giá trị và nhiều khả năng sẽ đưa vào quy trình phát triển của chính mình. Có lẽ còn những principle khác mà Super Board của anh đã bao phủ rồi, và nếu bạn quan tâm có thể mở trang của anh. Anh sẽ để cả sơ đồ Pstack này trong phần mô tả video để mọi người truy cập.

Anh cũng nhắc rằng ngoài ba principle trên, các principle còn lại của Pstack nằm trong cùng sơ đồ, được gom theo nhóm như design the shape và code structure and safety, nên người xem có thể tự mở từng cái để đọc.

Cuối video, Eric mời người xem bấm like nếu thấy hữu ích, và bình luận cho biết nên review framework spec-driven development nào khác trên kênh. Rồi anh chào tạm biệt và hẹn video sau.