gstack cho Claude Code: Quy trình 23 tác tử thực sự làm gì

gstack Claude Code là một hệ điều hành, không phải một bộ prompt

Cách hình dung hữu ích về gstack Claude Code là một hệ điều hành kỹ thuật được xây dựng trên Claude Code. Mỗi công cụ cung cấp cho Claude một vai trò, một quy trình và các đầu ra mong đợi. Khi kết hợp với nhau, những công cụ đó thể hiện các quan điểm về cách phần mềm nên đi từ ý tưởng đến môi trường sản xuất.

Một lời nhắc chung có thể là:

Review my implementation plan.

Một quy trình theo vai trò đặt ra câu hỏi cụ thể hơn:

/plan-eng-review

Kỹ năng đó có thể hướng dẫn Claude xem xét kiến trúc, các thành phần phụ thuộc, các dạng lỗi, khả năng kiểm thử, rủi ro triển khai và trình tự thực hiện. Một kỹ năng lập kế hoạch hướng sản phẩm có thể xem xét cùng kế hoạch đó về giá trị đối với người dùng và phạm vi. Một kỹ năng hướng thiết kế có thể phản biện các chi tiết tương tác thay vì ranh giới giữa các thành phần backend.

Điểm khác biệt là tính lặp lại nhất quán. Mỗi thành viên trong nhóm không cần phải nhớ một lời nhắc đánh giá dài 40 dòng hay tự nghĩ ra danh sách kiểm tra riêng. Kỹ năng chứa sẵn quy trình.

Sự đánh đổi cũng quan trọng không kém: gstack đưa quy trình của người khác vào kho mã của bạn. Nó giả định rằng nhiều lượt đánh giá, QA rõ ràng và công việc phát hành có cấu trúc xứng đáng với lượng ngữ cảnh và thời gian tiêu tốn. Điều đó thường phù hợp với những thay đổi trong môi trường vận hành thực tế, nhưng lại quá mức cần thiết cho một lỗi chính tả hay một tập lệnh nội bộ dài hai dòng.

23 công cụ theo vai trò thực sự bao quát những gì

Danh sách cụ thể trong kho mã có thể thay đổi, nên tôi coi các tệp trong bản đã lấy về SKILL.md là nguồn có thẩm quyền thay vì dựa vào ảnh chụp màn hình hay mô tả khi ra mắt. Điểm quan trọng trong kiến trúc là sự phân chia trách nhiệm.

Đó là lý do gọi gstack là một “bộ sưu tập lời nhắc” chưa phản ánh hết giá trị của nó. Đầu ra lập kế hoạch làm cơ sở cho việc triển khai mã; việc triển khai mã tạo ra bản diff; đánh giá và QA kiểm tra kỹ bản diff đó; phát hành và tài liệu đóng gói kết quả.

Đó cũng là lý do “quy trình 23 tác tử” có thể gây hiểu nhầm. Điều thực sự xảy ra khi bạn gọi một kỹ năng là Claude Code tải các hướng dẫn và thực hiện quy trình tương ứng bằng những công cụ có sẵn trong phiên hiện tại. Trừ khi một kỹ năng ủy nhiệm công việc một cách rõ ràng, sẽ không có 23 tiến trình hoạt động liên tục cùng chia sẻ một trạng thái toàn cục.

Lập kế hoạch có chủ đích chồng lặp

Các lượt đánh giá sản phẩm, kỹ thuật và thiết kế có phần chồng lặp. Đó là chủ đích.

Hãy xét một tính năng được đề xuất: “xuất toàn bộ hoạt động của khách hàng”:

• Đánh giá sản phẩm đặt câu hỏi liệu người dùng cần bản xuất đầy đủ hay báo cáo đã lọc.
• Đánh giá kỹ thuật đặt câu hỏi liệu dữ liệu xuất có vừa bộ nhớ không và cơ chế thử lại hoạt động như thế nào.
• Đánh giá thiết kế đặt câu hỏi trạng thái xuất, thông báo lỗi và các điều khiển tải xuống xuất hiện ở đâu.
• QA đặt câu hỏi điều gì xảy ra khi không có bản ghi, liên kết hết hạn và tác vụ bị gián đoạn.

Trong thực tế, sự phân chia này phát hiện những giả định dễ bị bỏ qua trong một kế hoạch triển khai chung. Cái giá phải trả là tải lại ngữ cảnh nhiều lần. Nếu kế hoạch đã dài 8,000 token, ba lượt đánh giá có thể trở nên tốn kém và tạo ra những nhận xét trùng lặp.

Đánh giá và QA là những công việc khác nhau

/review chủ yếu dựa trên bằng chứng từ mã: bản diff, kiểu dữ liệu, kiểm thử, các vị trí gọi và quy ước của kho mã. /qa và /browse có thể thu thập bằng chứng khi chạy từ chính ứng dụng.

Sự phân chia đó là một trong những ý tưởng nổi bật của gstack. Một bản diff có thể trông đúng trong khi kết quả hiển thị lại không thể sử dụng được. Ngược lại, kiểm tra luồng thuận lợi trên trình duyệt có thể đạt trong khi phần triển khai lại gây ra tình trạng tranh chấp hoặc lỗ hổng vượt qua kiểm tra quyền.

Một trình tự thực tế có thể như sau:

/plan-eng-review
/careful
# Implement the approved plan in Claude Code
/review
/qa
/document-release
/ship

Đừng coi đó là một quy trình bắt buộc. Với việc di chuyển cơ sở dữ liệu, đánh giá kỹ thuật và lập kế hoạch hoàn tác có thể quan trọng hơn nhiều so với thiết kế trực quan. Với một lỗi hồi quy CSS, /browse, đánh giá thiết kế và QA có thể là quy trình cốt lõi.

Cài đặt gstack mà không tin tưởng mù quáng

Cách cài đặt thông thường ở cấp người dùng đặt kho mã trong thư mục kỹ năng của Claude Code và chạy tập lệnh thiết lập của kho mã:

git clone https://github.com/garrytan/gstack.git \
  ~/.claude/skills/gstack

cd ~/.claude/skills/gstack
./setup

Khởi động lại Claude Code sau khi thiết lập nếu các lệnh mới chưa được nhận diện ngay. Sau đó kiểm tra các kỹ năng đã cài đặt thay vì mặc định rằng số lượng được công bố vẫn khớp với bản mã bạn đã lấy về:

find ~/.claude/skills/gstack \
  -name SKILL.md \
  -print |
  sort

find ~/.claude/skills/gstack \
  -name SKILL.md |
  wc -l

Một sai lầm thường gặp là chạy tập lệnh cài đặt vì kho mã phổ biến mà không đọc xem chúng thay đổi những gì. gstack chứa cơ chế thực thi quy trình, chứ không chỉ là Markdown thụ động. Trước khi chạy thiết lập, hãy kiểm tra nó:

cd ~/.claude/skills/gstack
git status --short
git log -1 --oneline
sed -n '1,240p' setup

Khi triển khai cho một nhóm, hãy ghim vào một commit đã được đánh giá thay vì âm thầm bám theo trạng thái mới nhất của kho mã:

git clone https://github.com/garrytan/gstack.git vendor/gstack
cd vendor/gstack
git checkout <reviewed-commit-sha>
./setup

Quy trình cài đặt cụ thể và các thành phần phụ thuộc có thể thay đổi khi dự án phát triển. Vì vậy, README hiện tại và tập lệnh thiết lập của kho mã nên được ưu tiên hơn các lệnh sao chép từ một bài viết cũ, kể cả bài viết này.

Thiết lập quyền Claude Code cho quy trình

Một số công cụ gstack cần quyền truy cập rộng để kiểm tra tệp, chạy kiểm thử, thao tác trình duyệt hoặc tương tác với Git. Điều đó không có nghĩa là mọi công cụ đều nên được cấp quyền shell và phát hành không hạn chế.

Ở cấp dự án, một .claude/settings.json có thể thiết lập cấu hình quyền cơ sở thận trọng:

{
  "permissions": {
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(git push:*)",
      "Bash(git push --force:*)"
    ]
  }
}

Hãy coi đây là chính sách mẫu, không phải tệp có thể dùng nguyên trạng cho mọi trường hợp. Điều chỉnh các lệnh theo trình quản lý gói, trình chạy kiểm thử và phiên bản Claude Code của bạn.

Việc chủ động từ chối git push đặc biệt hữu ích trong giai đoạn đánh giá. /ship vẫn có thể kiểm tra mức độ sẵn sàng phát hành, nhưng con người vẫn nắm quyền thực hiện thao tác cuối cùng gây thay đổi qua mạng. Sau khi nhóm hiểu quy trình, bạn có thể quyết định liệu việc cấp quyền push với phạm vi giới hạn chặt chẽ có hợp lý hay không.

Ngoài ra, hãy kiểm thử các kỹ năng thao tác trình duyệt trên môi trường staging hoặc với dữ liệu cục bộ được tạo sẵn. Tự động hóa trình duyệt bằng phiên đăng nhập vào môi trường vận hành thực tế có thể thay đổi các bản ghi thật nếu quy trình nhấp vào một điều khiển có tác dụng phá hủy.

Áp dụng một phần trước khi áp dụng toàn bộ hệ thống

Tôi sẽ không đưa toàn bộ 23 công cụ vào một nhóm ngay ngày đầu tiên. Hãy bắt đầu từ những điểm mà quy trình hiện tại của bạn làm thất thoát nhiều thông tin nhất.

Một ma trận đánh giá hợp lý là:

Chạy nhóm công cụ đã chọn trên một số thay đổi thực tế và ghi lại:

• Những phát hiện nào dẫn đến thay đổi mã hoặc phạm vi?
• Những phát hiện nào bị trùng lặp?
• Bao nhiêu ngữ cảnh phải được nhắc lại?
• Các tài liệu và đầu ra được tạo có luôn đồng bộ với phần triển khai không?
• Những lệnh nào yêu cầu các quyền mà nhóm sẽ không cấp trong CI?
• Các nhà phát triển có hiểu khi nào nên gọi từng vai trò không?

Chi phí ngữ cảnh không chỉ là lý thuyết. Mỗi vai trò cần trạng thái kho mã, yêu cầu và các quyết định trước đó. Các phiên riêng biệt có thể làm mất cơ sở lý luận; một phiên dài có thể tích tụ các giả định lỗi thời. Tôi lưu kế hoạch đã được phê duyệt trong một tệp của kho mã, chẳng hạn như docs/plans/export-jobs.md, rồi yêu cầu từng quy trình sử dụng tài liệu đó. Các tệp được lưu bền vững đáng tin cậy hơn việc kỳ vọng ngữ cảnh hội thoại đóng vai trò bộ nhớ dự án.

Hành vi được ghi trong tài liệu so với tuyên bố quảng bá

Tuyên bố có cơ sở là gstack cung cấp 23 công cụ Claude Code theo vai trò và một quy trình có định hướng rõ ràng bao quát vòng đời phần mềm. Bạn có thể xác minh hành vi đó bằng cách đọc các kỹ năng đã cài đặt và chạy chúng trong một kho mã thử nghiệm.

Những tuyên bố rộng hơn như tạo ra nhiều đầu ra hơn đáng kể, thay thế một nhóm kỹ thuật hay rút ngắn nhiều tuần xuống còn vài giờ vẫn là quảng bá cho đến khi được chứng minh trong môi trường của bạn. Kết quả phụ thuộc vào chất lượng kho mã, độ bao phủ kiểm thử, mức độ mơ hồ của nhiệm vụ, lựa chọn mô hình, quyền truy cập và nhà phát triển giám sát công việc.

Danh mục mô hình hiện tại cũng không xóa bỏ những ràng buộc này. Sonnet 4.6 có thể là lựa chọn mặc định thực tế cho công việc lập trình kéo dài, trong khi Haiku 4.5 có thể phù hợp với các tác vụ phân loại hoặc viết tài liệu nhẹ hơn. Ngữ cảnh 1M của Fable 5 có thể hỗ trợ xử lý khối lượng tài liệu rất lớn, và gpt-5.6-sol cung cấp thêm một lựa chọn hướng kỹ thuật trong các môi trường được hỗ trợ. Không mô hình nào biến lời nhắc theo vai trò thành kiến thức sản phẩm đã được xác minh hay bằng chứng từ môi trường vận hành thực tế.

Những điểm thực tiễn cần ghi nhớ

• Hãy coi gstack là một quy trình phát triển có định hướng rõ ràng, được triển khai thông qua các kỹ năng Claude Code.
• Hãy hiểu “23 tác tử” là các công cụ theo vai trò, không phải các tiến trình hoạt động liên tục được tự động điều phối.
• Cài đặt từ kho mã nguồn, kiểm tra setup, và cố định một commit đã được rà soát để nhóm sử dụng.
• Bắt đầu với hai hoặc ba quy trình xử lý những vấn đề đã biết trong quá trình bàn giao.
• Lưu các kế hoạch và quyết định đã được phê duyệt trong tệp để các vai trò cùng sử dụng ngữ cảnh được lưu giữ lâu dài.
• Tách biệt việc rà soát mã với kiểm thử chất lượng khi chạy; chúng phát hiện những loại lỗi khác nhau.
• Hạn chế quyền truy cập thông tin bí mật, phiên làm việc trên môi trường sản xuất, thao tác đẩy mã lên Git và lệnh triển khai trong quá trình đánh giá.
• Đo lường những phát hiện hữu ích và lỗi đã tránh được, thay vì số lệnh được gọi.
• Chỉ áp dụng toàn bộ hệ thống vận hành khi chi phí thực hiện quy trình thấp hơn tổn thất từ những lỗi mà nó ngăn ngừa.