Get Shit Done - Hệ thống phát triển dựa trên đặc tả và meta prompt

 (github.com/gsd-build)
12 điểm bởi GN⁺ 2026-03-19 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đây là một hệ thống nhẹ giúp tự động hóa phát triển dựa trên đặc tả (SDD) trong các môi trường như Claude Code, hỗ trợ hoàn thành dự án mà không cần quy trình làm việc phức tạp
  • Thông qua kỹ thuật ngữ cảnh, cấu trúc hóa prompt dựa trên XML và điều phối đa tác tử, hệ thống ngăn hiện tượng suy giảm chất lượng mã do AI mất ngữ cảnh (context rot)
  • Với các lệnh như /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, hệ thống tự động hóa toàn bộ vòng đời phát triển từ định nghĩa ý tưởng → lập kế hoạch → thực thi → kiểm chứng
  • Đảm bảo khả năng truy vết và hiệu quả bằng Git commit nguyên tử cho từng đơn vị công việc và thực thi song song theo làn sóng (wave execution)
  • Đây là công cụ được các kỹ sư tại Amazon, Google, Shopify, Webflow sử dụng, giúp tăng độ tin cậy và năng suất của phát triển dựa trên AI

Tổng quan

  • Get Shit Done (GSD) là một hệ thống quản lý meta prompt và ngữ cảnh nhẹ hoạt động trong nhiều môi trường phát triển AI như Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Antigravity
  • Hệ thống giải quyết vấn đề context rot, khi chất lượng ngữ cảnh suy giảm trong quá trình AI viết mã, và tạo ra kết quả nhất quán dựa trên đặc tả
  • Hoạt động trên cả Mac, Windows và Linux, có thể cài đặt bằng lệnh npx get-shit-done-cc@latest

Bối cảnh ra đời (Why I Built This)

  • Được tạo ra để giải quyết vấn đề các công cụ dành cho tổ chức lớn yêu cầu những quy trình không cần thiết và quá phức tạp
  • GSD được thiết kế theo nguyên tắc giữ sự phức tạp bên trong hệ thống, giữ workflow đơn giản
  • Bên trong, hệ thống thực hiện kỹ thuật ngữ cảnh, định dạng prompt XML, điều phối tác tử con và quản lý trạng thái
  • Người dùng có thể hoàn thành dự án chỉ với các lệnh đơn giản

Tính năng chính và workflow (How It Works)

  • Toàn bộ quy trình phát triển gồm 6 giai đoạn

    1. Khởi tạo dự án: hỏi về ý tưởng, ràng buộc, tech stack rồi tạo PROJECT.md, ROADMAP.md và các tệp liên quan
    2. Giai đoạn thảo luận: xác định chi tiết triển khai để tạo CONTEXT.md
    3. Giai đoạn lập kế hoạch: nghiên cứu song song và lập kế hoạch, tạo các đơn vị công việc có cấu trúc XML
    4. Giai đoạn thực thi: thực thi song song theo wave dựa trên phụ thuộc, commit và kiểm chứng cho từng tác vụ
    5. Giai đoạn kiểm chứng: chạy test tự động và xác nhận từ người dùng, nếu thất bại sẽ tự tạo kế hoạch sửa lỗi
    6. Lặp lại và hoàn tất cột mốc: lặp lại từng giai đoạn rồi gắn thẻ phát hành

  • Quick Mode xử lý nhanh một tác vụ đơn lẻ, và có thể điều khiển chi tiết bằng các cờ --discuss, --research, --full

Công nghệ cốt lõi (Why It Works)

  • Kỹ thuật ngữ cảnh: quản lý ngữ cảnh toàn dự án theo từng tệp (PROJECT.md, REQUIREMENTS.md, STATE.md v.v.)
  • Định dạng prompt XML: định nghĩa rõ từng tác vụ và bao gồm cả quy trình kiểm chứng
  • Điều phối đa tác tử: vận hành song song các tác tử chuyên biệt theo từng giai đoạn nghiên cứu, lập kế hoạch, thực thi và kiểm chứng
  • Git commit nguyên tử: commit theo từng đơn vị công việc để bảo đảm khả năng truy vết và phục hồi dễ dàng
  • Thiết kế mô-đun: có thể tự do thêm, chèn hoặc sửa các giai đoạn, giúp quản lý dự án linh hoạt

Hệ thống lệnh (Commands)

  • Workflow cốt lõi: /gsd:new-project, /gsd:plan-phase, /gsd:execute-phase, /gsd:verify-work
  • Hỗ trợ thiết kế UI: /gsd:ui-phase, /gsd:ui-review
  • Phân tích codebase: /gsd:map-codebase
  • Quản lý dự án: /gsd:add-phase, /gsd:insert-phase, /gsd:complete-milestone
  • Tiện ích: /gsd:quick, /gsd:health, /gsd:stats, /gsd:debug, /gsd:note v.v.

Thiết lập và cấu hình (Configuration)

  • Trong tệp cấu hình .planning/config.json, có thể điều khiển chế độ, mức chia nhỏ giai đoạn, hồ sơ mô hình, tác tử workflow, song song hóa và chiến lược phân nhánh Git
  • Hồ sơ mô hình có thể chọn giữa quality, balanced, budget, inherit
  • Có thể điều chỉnh chất lượng và tốc độ bằng các công tắc như workflow.research, workflow.plan_check, workflow.verifier

Bảo mật và xử lý sự cố (Security & Troubleshooting)

  • Các tệp nhạy cảm như .env, secrets/, *.pem, *.key nên được thêm vào deny list của Claude Code để chặn truy cập
  • Nếu sau khi cài đặt lệnh không được nhận diện, nên khởi động lại runtime hoặc cài đặt lại
  • Trong môi trường Docker, có thể giải quyết lỗi đường dẫn bằng cách thiết lập CLAUDE_CONFIG_DIR
  • Có thể gỡ toàn bộ thành phần bằng tùy chọn --uninstall

Cộng đồng và giấy phép

  • Hỗ trợ các bản port cộng đồng cho OpenCode, Gemini CLI và Codex
  • Phát hành theo giấy phép MIT
  • “Claude Code is powerful. GSD makes it reliable.” — Công cụ giúp tăng độ tin cậy cho Claude Code

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-03-19
Ý kiến trên Hacker News

  • Trước đây tôi từng dùng Plan mode cùng với Superpowers, nhưng cuối cùng thấy chỉ cần Plan mode là đủ
    Những framework kiểu này khá tốt cho các tác vụ fire-and-forget cần nghiên cứu, nhưng có cảm giác tiêu tốn token gấp hơn 10 lần
    Chất lượng đầu ra cũng không khác biệt nhiều, nên tôi thường xuyên đụng trần Max plan

    • Tôi đã lấy các tính năng brainstorm·design·implementation planning của Superpowers và gắn vào lớp triển khai dựa trên Ralph
      Khi phần lập kế hoạch triển khai kết thúc, nó tự động tiếp tục mà không hỏi thêm đầu vào từ tôi, và phải chạy trong Docker sandbox
      Đó là vì thiết lập quyền có rủi ro, nhưng dù sao tôi cũng nghĩ như vậy an toàn hơn
      Hiện tại nó hoạt động tốt và giúp tăng năng suất, nhưng có vẻ đây mới chỉ là giai đoạn giữa của hành trình
    • Tôi thì ngược lại, đã chuyển từ Plan mode sang Superpowers
      Sau khi xem công bố phiên bản mới nhất, tôi thử lại thì thấy kết quả ổn định hơn nhờ nhiều lớp cross-check và self-review
      Có thể làm thủ công, nhưng Superpowers tự động hóa quy trình đó nên tiện hơn rất nhiều
    • Tôi đã thử cùng một tác vụ với GSD và Plan Mode; Plan Mode hoàn thành cả phần triển khai cơ bản chỉ trong 20 phút, còn GSD mất vài tiếng
      GSD tạo ra mã có tính đến toàn bộ ngữ cảnh của dự án, còn Plan Mode chỉ triển khai đúng mức cần thiết ở mức MVP
      Tùy workflow hay quy mô công việc mà ưu nhược điểm rất rõ
    • Plan mode của GitHub Copilot gần đây trở nên kỳ lạ sau khi thêm plan memory
      Đầu ra dài dòng hơn, nhưng chi tiết lại mơ hồ hơn
      Chỉ tăng thêm các bước như “design”, “figure out”, rồi chuyển thẳng sang triển khai mà không có câu hỏi tiếp theo
    • Tôi cũng có trải nghiệm tương tự. Tôi đã đốt sạch phí thuê bao Claude và API credit của cả một tuần chỉ để nhận được khoảng 500 dòng code
      Nó còn có lúc chỉnh sửa test hoặc cho ra kết quả vô nghĩa
      Cuối cùng tôi phải tự hướng dẫn thủ công để hoàn thành MVP, và cách đó hiệu quả hơn hẳn

  • Dạo này có quá nhiều meta framework kiểu này, nhưng tôi gần như chưa thấy cái nào thực sự chứng minh được năng suất
    Phần lớn chỉ lãng phí token và làm ô nhiễm context window
    Cuối cùng cách tốt nhất vẫn là giữ đơn giản, chỉ cung cấp thông tin cần thiết và lặp theo thứ tự Plan → Code → Verify

    • Trong bài “The AI Developer’s Descent Into Madness” của Apenwarr, tình huống “agent tự tạo framework của chính nó” được châm biếm khá sắc bén
    • Tôi đã tự làm một mini framework kết hợp Claude và Codex
      Nhìn Codex bắt được lỗi mà riêng Claude tạo ra thì tôi thấy không thể giao phó hoàn toàn cho một agent đơn lẻ
    • Tôi dùng cách thiết kế spec trực quan
      Tôi thiết kế luồng màn hình của app bằng hình ảnh, rồi xuất nó ra markdown có cấu trúc để LLM hiểu ngữ cảnh theo từng màn hình
      So với spec chỉ dựa trên văn bản, cách này giúp phát hiện trước các trạng thái bị thiếu hoặc luồng lỗi
    • Rốt cuộc các meta framework kiểu này cũng chỉ là công cụ cá nhân hóa kiểu .vimrc hay .emacs.d
      Với người tạo ra nó thì hữu ích, nhưng với người khác lại có thể thấy vô dụng

  • Tôi cho rằng hệ thống Spec-Driven là thứ được định sẵn để thất bại
    Spec viết bằng tiếng Anh không thể kết nối mã thực tế với hành vi thực tế
    Vấn đề này thực ra đã được giải quyết bằng kiểm thử tự động
    Hành vi của hệ thống phải được mã hóa thành các bài test có thể thực thi
    Khi LLM tạo phần triển khai, nó cũng phải viết test trước và kiểm chứng tính nhất quán bằng mutation testing
    Tôi đã tổng hợp nội dung liên quan trong bài này và ví dụ trên GitHub

    • Spec ngôn ngữ tự nhiên không có khả năng mở rộng, nhưng nếu từ đó tạo ra formal spec thì vẫn có tiềm năng
      Cuối cùng nó vẫn phải được biểu đạt dưới dạng code
    • Cũng từng có bài viết “A sufficiently detailed spec is code”, nhưng tôi không tái hiện được kết quả của OpenAI
      Xem liên kết
    • Spec Driven Development có tên nghe giống TDD, nhưng hướng đi thì hoàn toàn ngược lại
    • Xem test chỉ như sản phẩm đầu ra của spec là logic sai lầm
      Spec bao quát phạm vi rộng hơn test rất nhiều
      Cũng có rất nhiều trường hợp LLM phớt lờ test hoặc tự ý sửa đổi chúng

  • Tôi đang dùng một hệ thống AI cá nhân, nhưng vẫn đang cân nhắc có nên công khai hay không
    Nó được tùy biến theo đúng công việc của tôi, nên việc bảo trì riêng một bản công khai là khá nặng nề
    Thay vì để người khác dùng trực tiếp, tôi muốn họ tham khảo hệ thống của tôi để chia sẻ các pattern

    • Không nhất thiết phải bảo trì
      Trong thời đại AI, chỉ riêng việc chia sẻ cảm hứng và ý tưởng cũng đã đủ giá trị rồi

  • Tôi đã thử dùng GSD trong một hackathon của nhóm, nhưng nó mất quá nhiều thời gian để hiểu codebase, và còn tiêu tốn token rất mạnh
    Lỗi khi tạo transcript của agent cũng xảy ra thường xuyên
    Để làm vài tính năng nhỏ thì đây là công cụ quá mức cần thiết
    Điều tôi rút ra rất đơn giản — viết spec tốt + lặp lại với Plan mode hiệu quả hơn nhiều

  • Tôi thấy các ràng buộc thiết kế của Beads khá gò bó nên đã tự làm một công cụ tương tự
    Phiên bản của tôi dùng SQLite làm nền tảng, và có thêm khả năng đồng bộ hai chiều với GitHub
    Cốt lõi là trò chuyện với model trước để tạo ra file spec rõ ràng
    Khi có file đó, model sẽ không quên, và càng nhiều chi tiết thì chất lượng đầu ra càng cao
    Tôi đã dùng Claude để biến một ý tưởng ấp ủ từ lâu thành prototype, và kết quả tốt hơn kỳ vọng

    • Nếu gọi đó là “nước sốt bí mật” thì hơi quá, vì RPI (research-plan-implement) vốn đã là khái niệm có trong tài liệu chính thức
      Model vẫn là hệ thống xác suất, nên không thể có trí nhớ hoàn hảo
      Việc đóng gói nó như thể vừa phát hiện ra một bí quyết mới là phóng đại

  • Tôi đã dùng Superpowers, và GSD lần này trông cũng tương tự nên khá tò mò muốn so sánh

    • Tôi đã dùng cả hai, và GSD quá phức tạp và chậm
      Quick mode làm lệch khỏi mục đích ban đầu, còn Superpowers là một điểm trung gian khá ổn
    • Prompt có cấu trúc chắc chắn là hữu ích
      Nếu đưa các framework kiểu này vào repository, rồi để AI cải thiện chính framework đó, thì nó cũng hữu dụng cho công việc sáng tạo
      Tuy nhiên kiểu cấu trúc này có lẽ chỉ là một mẹo tạm thời, và khi model được huấn luyện đủ tốt thì nó sẽ tự nhiên biến mất
    • Superpowers viết toàn bộ code ngay từ giai đoạn lập kế hoạch, rồi các agent cấp dưới chỉ việc sao chép lại nguyên xi, nên khá kém hiệu quả
      GSD đã giải quyết vấn đề này, nhưng vì quá nhiều bước nên tốc độ chậm
    • Tôi đã test Superpowers khi chuyển blog từ Hugo sang Astro
      Spec mà Superpowers tạo ra rất chi tiết nhưng thiếu vài tính năng (ví dụ: RSS, analytics), còn spec cộng tác đề xuất migration song song thì linh hoạt hơn
      Cuối cùng tôi nhờ Claude so sánh và hợp nhất hai spec để tạo ra bản hoàn chỉnh
      Xem so sánh chi tiết
    • Tôi không chắc có thực sự cần một CLI wrapper hay không
      Chỉ với Claude skills thôi cũng đã có thể triển khai đủ rồi

  • Tôi đã dùng GSD rất tập trung trong 3 tháng, và nó hoàn thiện hơn nhiều so với speckit mà tôi dùng trước đây
    Ngay cả các tác vụ phức tạp cũng được tự động xử lý tới 95%
    5% còn lại tôi hoàn tất bằng kiểm thử thủ công
    Tôi thậm chí đã ra mắt cả sản phẩm SaaS (whiteboar.it) bằng nó
    Model bản thân nó cũng đã tiến bộ, nhưng mức tăng năng suất là điều rất rõ ràng

    • Tôi cũng có trải nghiệm tương tự
      Vì tiếc tiền thuê bao FreshBooks nên tôi đã tự làm một ứng dụng macOS Swift bằng GSD
      Từ trích xuất biên lai tự động đến phân loại danh mục đều được triển khai bằng Anthropic API
      Ban đầu nó là web app, nhưng khi thêm các tính năng như tích hợp camera thì dần phát triển thành ứng dụng desktop hoàn chỉnh
      Nhờ GSD mà tôi đã hoàn thành một ứng dụng kế toán cá nhân

  • Rốt cuộc công cụ thực sự cần thiết là công cụ tiết kiệm token
    Nhưng hiện vẫn chưa có thứ như vậy
    Claude Code cũng tiêu tốn quá nhiều token trong các dự án lớn

  • Tên của “bộ file Markdown này” nghe quá sến súa

    • Nếu đặt nó dưới thư mục “Languages” thì có lẽ còn đỡ hơn
    • Nhưng dù sao vẫn còn khá hơn “gstack”, đúng không?