Nếu bạn là solo developer đang code với AI — chắc bạn đã từng gặp cái tường này. Mở Claude Code lên, bắt đầu mô tả feature, viết code, yêu cầu sửa lỗi, viết thêm code… và đâu đó khoảng message thứ 30, AI bắt đầu quên mọi thứ. Nó tái tạo lại bug bạn đã fix. Nó mâu thuẫn với quyết định nó đưa ra trước đó. Response ngắn lại, cẩu thả hơn. Bạn đang chiến đấu với công cụ nhiều như đang dùng nó.
Đây là context rot — kẻ giết thầm lặng của solo development với AI.
GSD (Get Shit Done) là một hệ thống meta-prompting và context engineering mã nguồn mở được xây dựng đặc biệt cho Claude Code, giải quyết vấn đề này một cách có hệ thống. Hướng dẫn này đưa bạn qua toàn bộ workflow sử dụng một project thực tế: ginbok.com — blog kỹ thuật song ngữ xây trên Next.js 14 (frontend) và Episerver Optimizely CMS 12 (backend), được phát triển và vận hành hoàn toàn bởi một người.
Vấn Đề: Context Rot
Claude Code có context window 200.000 token. Nghe có vẻ khổng lồ — và đúng là vậy. Nhưng khi session kéo dài, điều tinh tế xảy ra. Mỗi tin nhắn, mỗi code block, mỗi qua lại thu hẹp "bộ nhớ làm việc" mà Claude có thể sử dụng hiệu quả. Đến khi bạn đã trao đổi 40 lần, các quyết định ban đầu — lựa chọn kiến trúc, quy ước đặt tên, bug bạn đã fix ở giờ đầu tiên — đã trôi xuống đáy ngăn xếp context. Claude vẫn "thấy" chúng về mặt kỹ thuật, nhưng chất lượng suy luận giảm sút.
Các nhà nghiên cứu gọi đây là lost-in-the-middle: LLM giỏi nhớ những thứ ở đầu và cuối context, nhưng kém ở phần giữa. Một session code dài hầu như toàn bộ là phần giữa.
Với ginbok.com, đây là vấn đề thực tế. Project có hai phần chính — Next.js frontend deploy trên Vercel và Optimizely CMS backend tại api.ginbok.com — cộng thêm MCP server tùy chỉnh ginbok-mcp để quản lý CMS. Một session code có thể đụng đến API routes, content model CMS, cấu hình pipeline Azure DevOps, và biến môi trường Vercel. Không có cấu trúc, context sụp đổ rất nhanh.
Giải pháp của GSD rất thanh lịch: đừng để context quan trọng trôi vào phần giữa. Thay vào đó, mọi công việc đều diễn ra trong một sub-agent context mới với chỉ thông tin liên quan được tải vào. Session chính vẫn nhẹ. Sub-agents làm việc nặng.
Bước 0: Cài Đặt GSD
Prerequisites: Node.js 18+, Claude Code CLI, Git.
# Điều hướng đến project root
cd ginbok-frontend
# Cài GSD locally
npx get-shit-done-cc@latestInstaller hỏi hai câu:
- Runtime → chọn
Claude Code - Location → chọn
Local(cài vào./.claude/commands/gsd/)
Khởi động Claude Code:
claude --dangerously-skip-permissionsFlag --dangerously-skip-permissions cho phép GSD chạy các bash command (git commit, tạo file) mà không cần dừng lại hỏi bạn mỗi lần. Đây là cố ý — GSD được thiết kế để chạy tự động. Nếu muốn kiểm soát chi tiết hơn, thêm các rule allow cụ thể vào .claude/settings.json.
Verify:
/gsd:helpBước 1: Map Codebase Hiện Có
ginbok.com là brownfield project — đã có code, conventions, và pipeline deploy sẵn. Trước khi khởi tạo, cho GSD biết nó đang làm việc với gì:
/gsd:map-codebaseLệnh này tạo ra các agent song song phân tích stack, kiến trúc, quy ước đặt tên, và các đặc thù hiện có. Với ginbok.com, phân tích sẽ phát hiện:
- Next.js App Router với TypeScript
- Episerver content API tại
api.ginbok.comvới JWT auth - MCP server tùy chỉnh
ginbok-mcpcho các thao tác CMS - Azure DevOps CI/CD pipeline deploy lên Vercel
- Nội dung song ngữ (EN/VI) với các language branch riêng trong CMS
Codebase map này được lưu trữ và tham chiếu trong mọi bước planning và execution sau. Planner sẽ không đề xuất Redux nếu nó thấy bạn đang dùng Zustand. Nó sẽ không đề xuất một API layer mới nếu thấy MCP server đã xử lý các thao tác CMS.
Sau đó khởi tạo:
/gsd:new-projectGSD phỏng vấn bạn về những gì bạn muốn xây dựng tiếp theo — không phải về những gì đã tồn tại, vì nó đã biết rồi. Với ginbok.com, bạn có thể mô tả:
"Tôi muốn thêm ước tính thời gian đọc vào mỗi bài viết, hiển thị cạnh ngày đăng. Tính từ số từ trong body bài viết. Định dạng: '5 min read'. Không cần thay đổi backend — body HTML đã có từ CMS API rồi."
GSD tạo ra:
PROJECT.md— vision project, tóm tắt stack, luôn được loadREQUIREMENTS.md— scope v1/v2 rõ ràngROADMAP.md— các phaseSTATE.md— quyết định và vị trí hiện tại, tồn tại giữa các session
Bước 2: Discuss Phase (Định Hình Trước Khi Xây)
/gsd:discuss-phase 1Bước này là điều phân biệt GSD với các cách tiếp cận "chỉ generate code" ngây thơ. Trước khi bất kỳ kế hoạch nào được tạo, GSD xác định các vùng mờ trong phase — những quyết định có vẻ nhỏ nhặt nhưng ảnh hưởng đến mọi thứ về sau.
Cho feature thời gian đọc của ginbok.com, nó có thể nêu ra:
- Tính toán có cần strip HTML tags trước khi đếm từ không, hay dùng thư viện?
- Tốc độ đọc giả định là bao nhiêu (200 wpm? 250 wpm)?
- Bài rất ngắn hiển thị "1 min read" hay "less than 1 min"?
- Nó xuất hiện ở đâu trong UI — post card, post header, hay cả hai?
- Có cần song ngữ không (bài tiếng Việt đọc khác tiếng Anh)?
Bạn trả lời một lần, ở đây. Câu trả lời đi vào 1-CONTEXT.md. Mọi bước sau đều đọc file này. Bạn không bao giờ phải giải thích lại.
❌ Không có discuss: executor implement thời gian đọc chỉ trong post header, bạn nhận ra nó cũng cần có trong post card, và bây giờ bạn đang giữa session giải thích cấu trúc UI từ đầu.
✅ Có discuss: "post card VÀ post header" được khóa lại trước khi một dòng nào được lên kế hoạch.
Bước 3: Plan Phase
/gsd:plan-phase 1Planner đọc codebase map, CONTEXT.md, và REQUIREMENTS.md, sau đó tạo ra các atomic task plan. Mỗi plan đủ nhỏ để execute trong một fresh context window.
Cho feature thời gian đọc, các plan có thể là:
1-01-PLAN.md— Utility function readingTime (lib/utils/readingTime.ts)1-02-PLAN.md— Tích hợp vào component PostCard1-03-PLAN.md— Tích hợp vào PostHeader + nhãn song ngữ
Mỗi plan được cấu trúc XML:
<task type="auto">
<n>Tạo utility readingTime</n>
<files>lib/utils/readingTime.ts</files>
<action>
Strip HTML tags từ body string.
Đếm từ (split theo whitespace).
Chia cho 238 wpm (tốc độ đọc thầm trung bình).
Trả về ceiling. Giá trị tối thiểu: 1.
Export: readingTime(html: string): number
</action>
<verify>Unit test: body 476 từ trả về 2, body 50 từ trả về 1</verify>
<done>Function export từ lib/utils/readingTime.ts, tests pass</done>
</task>Chính xác. Không mơ hồ. Verification tích hợp sẵn. Một plan checker agent validate từng plan trước khi bạn thấy chúng.
Bước 4: Execute — Wave Execution Tỏa Sáng
/gsd:execute-phase 1Đây là bước thú vị nhất về mặt kỹ thuật. Executor nhóm các plan thành các wave dựa trên dependencies:
Wave 1 (song song):
└── 1-01: utility readingTime (không có dependency)
Wave 2 (song song):
├── 1-02: tích hợp PostCard (phụ thuộc 1-01)
└── 1-03: PostHeader + song ngữ (phụ thuộc 1-01)
Điểm mấu chốt: mỗi executor sub-agent có fresh 200k token context riêng. Nó chỉ load plan cụ thể, project context, và các file cần đụng đến. Không có lịch sử conversation tích lũy. Không có context rot.
Context session chính của bạn vẫn ở mức 30–40% trong khi sub-agents làm việc. Bạn có thể mở terminal khác, pha cà phê, hoặc review output của phase trước.
Sau execution, mỗi task hoàn thành có atomic git commit riêng:
a1b2c3 feat(1-01): add readingTime utility with HTML stripping
d4e5f6 feat(1-02): integrate reading time into PostCard
g7h8i9 feat(1-03): add reading time to PostHeader with EN/VI labelMỗi commit có thể revert độc lập. Nếu PostHeader integration có layout issue, bạn revert đúng commit đó — utility và PostCard vẫn nguyên vẹn.
Bước 5: Verify — Human + AI Cùng Kiểm Tra
/gsd:verify-work 1GSD dẫn bạn qua các deliverable thực tế từng cái một:
"Post card trên homepage có hiển thị ước tính thời gian đọc cạnh ngày đăng không?"
"Trên bài tiếng Việt, nhãn có hiện bằng tiếng Việt ('5 phút đọc' thay vì '5 min read') không?"
Bạn test trên trình duyệt. Có hoặc không. Nếu có gì bị lỗi, mô tả vấn đề — GSD tạo ra debug agent chẩn đoán nguyên nhân và tạo fix plan sẵn sàng để execute lại. Không debug thủ công.
Bước 6: Ship
/gsd:ship 1Tạo pull request với body tự động tóm tắt những gì đã được xây. Azure DevOps pipeline chạy build và deploy lên Vercel khi merge.
Sau đó lặp lại cho feature tiếp theo, hoặc để GSD tự detect:
/gsd:nextQuick Mode: Cho Maintenance Hàng Ngày
Không phải mọi thay đổi trên ginbok.com đều cần nghi lễ đầy đủ. Fix sitemap bị hỏng, điều chỉnh CSS variable, cập nhật MCP tool — đây là các task một lần:
/gsd:quick
> What do you want to do? "Fix double-path resolution bug trong next.config.js rootDirectory"GSD tạo plan nhẹ trong .planning/quick/ và execute với cùng đảm bảo — fresh context, atomic commit — mà không cần chu trình đầy đủ. Với solo dev đang vận hành site thực, đây là mode bạn sẽ dùng nhiều nhất cho maintenance.
Mental Model: Tại Sao Cái Này Hoạt Động
Hầu hết AI coding tool thất bại ở quy mô lớn vì chúng coi conversation là workspace. GSD coi các file là workspace và conversation là một lớp điều khiển mỏng phía trên.
Mọi context quan trọng đều sống trong file: PROJECT.md, REQUIREMENTS.md, 1-CONTEXT.md, 1-01-PLAN.md. Sub-agents load đúng những gì cần. Không có gì tích lũy trong context chính. Codebase map nghĩa là GSD đã hiểu stack của bạn trước khi bạn gõ một lệnh nào.
Với ginbok.com — một site song ngữ thực với CMS tùy chỉnh, CI/CD pipeline, và MCP server — cấu trúc này là điều làm cho AI-assisted development bền vững trong nhiều tháng, không chỉ một session.
Bắt Đầu Ngay
# Project hiện có
cd your-project
npx get-shit-done-cc@latest
claude --dangerously-skip-permissions
/gsd:map-codebase
/gsd:new-project
# Project mới
mkdir my-project && cd my-project && git init
npx get-shit-done-cc@latest
claude --dangerously-skip-permissions
/gsd:new-projectRepo tại github.com/gsd-build/get-shit-done — MIT license, 39k stars, được maintain tích cực.
Thôi đừng chiến đấu với context window nữa. Để GSD quản lý nó cho bạn.