# Mọi skill Claude Code Cole Medin dùng cho cả quy trình phát triển

[Cole Medin](https://homus.dev/speakers/cole-medin) · [Cole Medin](https://homus.dev/orgs/cole-medin)

> Bộ skill Claude Code của Cole Medin theo hai vòng lặp: PRD, spec, cắt ticket, rồi prime, plan, implement, validate, review, PR; trọng tâm là validation first.

Topics: Skills, Coding Agents, Workflow, Plugins

Canonical: https://homus.dev/talks/every-claude-code-skill-i-use-to-drive-my-entire-development-process

## 1. Hơn một năm không tự viết một dòng code nào

Cole Medin mở đầu bằng một câu mà chính anh cũng thấy khó tin khi nói ra: đã hơn một năm nay anh không tự tay viết một dòng code nào. Điều đó nghe điên rồ vì cả đời anh là một engineer. Thậm chí khi mới mở kênh YouTube, anh còn ngồi chỉ cho người xem từng dòng một cách build AI agent. Còn bây giờ, anh dựa vào AI coding assistant cho mọi phần trong quy trình phát triển của mình.

Hệ thống anh đã chốt cho bản thân, và đã chạy rất ổn suốt nửa năm nay, thật ra khá đơn giản nhưng rất hiệu quả. Về cốt lõi, nó chỉ là một bộ sưu tập skill.

Anh giải thích lại skill là gì: với các coding agent như Claude Code hay Codex, một skill chỉ là một prompt dùng lại được. Nó là một workflow dẫn coding agent đi qua một quy trình nhất định. Cole có một loạt quy trình như vậy, gói lại thành một bộ skill, và giờ anh tặng nó cho người xem. Trong video này, anh muốn cho thấy toàn bộ những skill anh dùng mỗi ngày, cách người xem có thể đưa chúng vào quy trình của mình, hoặc chỉ lấy cảm hứng từ chúng nếu muốn.

Anh nói rõ là anh hiểu nhiều người đã có sẵn một bộ skill, đã có AI coding workflow của riêng mình. Anh không chờ đợi ai vứt bỏ những thứ đó để chuyển sang dùng toàn bộ skill của anh. Nếu bạn chỉ muốn nhặt vài skill hay, hoặc lấy vài ý tưởng anh nói trong video rồi đưa vào cách làm hiện tại, cứ thoải mái. Ngày nay chuyện đó dễ tới mức bạn chỉ cần chỉ coding agent vào một repo như thế này và nói "tôi thích cái này" hoặc "lấy giúp tôi skill này", rồi để nó đưa vào hệ thống bạn đang có.

Cách Cole định nghĩa skill: một prompt dùng lại được, dẫn coding agent đi qua một quy trình. Toàn bộ quy trình phát triển của anh chỉ là một bộ skill như thế.

## 2. Một thư viện để chọn, không phải một framework

Điều quan trọng nhất Cole muốn người xem hiểu về bộ skill này: chúng rất tối giản (minimalistic) và plug and play. Nghĩa là bạn không phải dùng hết. Muốn lấy vài cái, hay chỉ vài ý tưởng, đều được.

Anh so sánh với một số agentic coding framework đang có, ví dụ [GitHub Spec Kit](https://github.com/github/spec-kit) hay [Gas Town](https://github.com/steveyegge/gastown). Anh nói rõ đây là những dự án rất ấn tượng, đừng hiểu lầm. Nhưng khi muốn dùng Gas Town hay GitHub Spec Kit, về cơ bản bạn phải theo toàn bộ quy trình AI coding của họ. Cả software development lifecycle đã được định nghĩa sẵn cho bạn. Và thường thì cách đó không chạy tốt nhất, trừ khi bạn chưa có gì để bắt đầu.

![README của repo Gas Town trên GitHub](https://homus.dev/photos/MbiMwgbGdxw-0203.jpg)

README của Gas Town: một hệ thống điều phối nhiều agent (Claude Code, GitHub Copilot, Codex, Gemini) với work state lưu trong git-backed hook. Cole lấy nó làm ví dụ cho loại framework bắt bạn theo cả một quy trình.

Như anh đã nói, anh giả định là bạn đã có một quy trình ở mức nào đó. Vì vậy thứ anh đưa ra là một thư viện để bạn chọn cái mình muốn. Lấy bất kỳ skill nào rồi tuỳ biến nó theo codebase hay theo cách bạn thích làm việc cũng cực kỳ dễ, và đó là một trong những điều lớn mà video sẽ đi qua.

Còn nếu bạn thật sự bắt đầu từ con số không, chưa có bộ skill nào, thì cứ dùng hết. Đây là danh sách đầy đủ mọi skill Cole dùng cho cả vòng phát triển của mình. Phần sau của video, anh sẽ nói về cách tiếp cận validation first: làm sao để "let the model cook", để model tự làm, mà vẫn tin được kết quả. Anh nói thẳng đây là phần quan trọng nhất trong toàn bộ quy trình. Đó cũng là trọng tâm của khoá Agentic Coding anh dạy trong cộng đồng Dynamous, nơi anh đi sâu vào toàn bộ AI software development lifecycle bằng chính những skill này. Anh nhắc tới khoá học một câu rồi chuyển sang phần cài đặt.

## 3. Cài bộ skill bằng plugin marketplace của Claude Code

Cole muốn cho thấy việc cài các skill này và đưa chúng vào project của bạn dễ đến mức nào. Anh mở README của repo (repo [Cole's AI Skills](https://github.com/coleam00/skills) trên GitHub). Vì phần lớn người xem dùng Claude Code, anh đóng gói bộ skill thành một plugin trong Claude Code Marketplace. Các coding agent khác anh sẽ nói ngay sau đó.

![README mục Bring them in với hai lệnh cài plugin trong Claude Code](https://homus.dev/photos/MbiMwgbGdxw-0439.jpg)

Mục "Bring them in" trong README: chạy hai lệnh bên trong Claude Code để thêm marketplace rồi cài plugin. README cũng ghi các plugin skill có namespace, nên gọi theo dạng `/skills:piv-implement`, và cả bộ chỉ tốn khoảng 4.200 token context luôn bật (chỉ phần description, phần thân chỉ nạp khi skill chạy).

Cách làm: bạn copy lệnh thứ nhất, vào Claude Code đang chạy sẵn, và thêm marketplace của anh. Trong lúc lệnh đó chạy, anh copy lệnh thứ hai để thực hiện việc cài đặt thật sự. Hai lệnh trên màn hình là:

```
/plugin marketplace add coleam00/skills
/plugin install skills@cole-medin
```

Lệnh thứ nhất xong thì anh chạy lệnh cài. Claude Code đưa ra vài lựa chọn phạm vi cài. Nhìn chung anh khuyên chọn cái trên cùng: nó cài skill cho bạn dùng ở mọi codebase (phạm vi user). Bạn cũng có thể chỉ cài cho repository hiện tại đang mở Claude Code, hoặc cài cho mọi collaborator nếu đang làm việc theo team. Nhưng thường thì cứ chọn cái đầu tiên. Lệnh chạy xong trong vài giây.

## 4. Kiểm tra sau khi cài, và cách dùng với coding agent khác

Cài xong, nếu gõ lệnh plugins, bạn sẽ thấy mọi plugin đã cài, trong đó có Cole's AI Skills. Bạn cũng thấy chúng khi chạy `/skills`. Mọi thứ trong repository có ngay để dùng. Chẳng hạn gõ `/piv`, bạn thấy toàn bộ các lệnh của vòng lặp mà lát nữa anh sẽ nói kỹ hơn.

![Danh sách skill trong Claude Code sau khi cài plugin](https://homus.dev/photos/MbiMwgbGdxw-0403.jpg)

Màn hình `/skills` trong Claude Code sau khi cài: 76 skill, trong đó các skill của bộ này hiện dưới namespace `skills:` (ablate-ai-layer, agent-browser, ast-grep, build-dark-factory, hooks-create, opportunity-scan, piv-commit, piv-create-pr, piv-implement...), mỗi skill ghi số token ước tính và trạng thái "locked by plugin".

Nếu bạn dùng một coding agent khác ngoài Claude Code, việc cài cũng gần như dễ vậy. Cole nói nghe thì hơi sến, nhưng về cơ bản bạn chỉ cần copy URL của repository, đưa cho coding agent của bạn và nói: đây là một bộ skill cho Claude Code, tôi muốn bạn cài nó vào repo này cho coding agent này, ví dụ Codex, Pi hay GitHub Copilot. Và nó sẽ chạy. Mất vài phút, lâu hơn một chút, nhưng về cơ bản vẫn dễ như vậy để đưa bộ skill vào bất kỳ coding agent nào.

README hiện tại của repo còn liệt kê vài đường khác: cài thành file sửa được bằng `npx skills add coleam00/skills`, hoặc clone repo rồi copy từng thư mục skill vào `.claude/skills/` của project, hoặc nhờ agent làm hộ bằng một prompt như sau (trích từ README):

```
Clone https://github.com/coleam00/skills, look at the skills in `.claude/skills/`, and copy the ones
that fit this project into my `.claude/skills/` folder. Tell me which ones you picked and why.
```

## 5. Toàn cảnh quy trình: hai vòng lặp

Skill đã cài xong, giờ Cole nói tới việc bạn vừa "dính" vào cái gì. Anh muốn cho thấy toàn bộ quy trình phát triển và vị trí của từng skill trong đó. Anh báo trước là sẽ giữ ở mức khá high level: nếu đi vào chi tiết từng skill và chạy thử từng cái thì video sẽ dài hơn rất nhiều. Anh mời người xem để lại bình luận nếu muốn anh làm sâu phần nào trong một video khác, vì anh gần như có thể làm một video đầy đủ cho mỗi skill. Không phải vì chúng phức tạp, mà vì có quá nhiều best practice để học nếu muốn tận dụng tối đa quy trình. Còn lúc này, anh chỉ cho xem mọi thứ trông ra sao khi ghép lại: làm sao đi từ con số không tới code được ship bằng coding agent.

![Sơ đồ hai vòng lặp: outer loop và inner loop với tên các skill](https://homus.dev/photos/MbiMwgbGdxw-0503.jpg)

Outer loop (PRD, Spec, Tickets) chạy một lần mỗi epic, quyết định build cái gì; mỗi ticket đi vào inner loop (Prime, Plan, Implement, Validate, Review, PR) chạy một lần mỗi ticket, build và chứng minh nó chạy. Cạnh mỗi bước là tên skill tương ứng.

AI coding workflow của anh gồm hai vòng lặp. Đây là framework cực kỳ đơn giản giúp anh build bất cứ thứ gì dễ hơn.

- **Outer loop** là phần lập kế hoạch ở mức cao nhất: viết PRD và các tài liệu spec. Trên sơ đồ ghi: chạy một lần mỗi epic; greenfield thì là MVP của bạn, brownfield thì là sprint tiếp theo.

- **Inner loop** là nơi viết code. Ta lấy một ticket hay issue riêng lẻ, cùng coding agent lên plan cho phần việc đó, cho nó viết code, rồi validate code, trong khi chính coding agent cũng làm điều tương tự. Trên sơ đồ ghi: chạy một lần mỗi ticket, và các ticket độc lập có thể chạy cùng lúc.

Tất nhiên anh bắt đầu với outer loop vì đó là cách mọi việc khởi đầu. Ở outer loop, bạn làm ít hơn vì nó chỉ chạy một lần cho cả một khối việc lớn (Cole nói "once per ticket", còn trên sơ đồ ghi "once per epic").

## 6. Outer loop và skill PRD: cái gì và vì sao

Với greenfield development, tức bắt đầu một project từ đầu, outer loop là nơi bạn phác ra MVP: ta phải build gì để có proof of concept đầu tiên cho ứng dụng. Với brownfield development, khi làm trên một codebase có sẵn, đây là nơi bạn định nghĩa feature lớn hơn, hay nhóm feature bạn muốn cho sprint tiếp theo: bước tiến hoá kế tiếp của project là gì.

Skill đầu tiên dùng là skill PRD, vì PRD (product requirements document) định nghĩa cái gì (what) và vì sao (why) cho phạm vi công việc tiếp theo. Bạn đội chiếc mũ project manager để dẫn coding agent giúp bạn xác định: chính xác ta đang build cái gì? Vấn đề thật sự ta đang cố giải là gì? Bạn muốn chắc chắn rằng mọi thứ còn lại trong quy trình phát triển đều đang build một thứ ta biết là đáng build. Đó là điều được xác lập ở bước này.

Cole mở repo cho xem skill trông như thế nào. Trong thư mục `.claude/skills` của repository có skill `plan-create-prd`. Anh đã nói sẽ không đi sâu từng skill, nhưng ít nhất muốn cho xem cái này để người xem có vài ví dụ về cách các skill của anh thường hoạt động.

![Bản preview SKILL.md của skill Create PRD: Intent, Not Instructions](https://homus.dev/photos/MbiMwgbGdxw-0743.jpg)

Bản preview SKILL.md của `plan-create-prd`, tiêu đề "Create PRD: Intent, Not Instructions". File yêu cầu đọc trước mọi tài liệu tham khảo được truyền vào (phỏng vấn người dùng, support ticket, analytics, teardown đối thủ) làm bằng chứng; định nghĩa PRD là intent, còn AI spec là engineering decision; vai trò là một product manager sắc sảo bắt đầu từ vấn đề chứ không từ giải pháp; và có "anti-fluff rule": không bao giờ bịa yêu cầu nghe có vẻ hợp lý, chưa biết thì ghi "TBD, needs validation".

Phần lớn skill của anh nhận một argument, tức thứ bạn truyền vào. Khi vào Claude Code gõ `/plan-create-prd` và bấm tab để autocomplete, bạn thấy phần argument hint. Nó cho bạn biết có thể truyền gì vào, đầu vào của skill là gì để nó biết phải làm việc với cái gì. Trong file SKILL.md, dòng argument-hint trên màn hình là:

```
argument-hint: "[product idea] · [optional: paths to research / reference docs to ground in] (blank = start with questions)"
```

Ở đây bạn truyền ý tưởng sản phẩm. Nó có thể rất high level, kiểu "tôi muốn build một app theo dõi tài chính" (anh nói mình chỉ đang nghĩ ra một ví dụ ngẫu nhiên). Bạn không cần cụ thể, vì skill này sẽ phỏng vấn bạn. Nó sẽ hỏi rất nhiều câu để rút ra từ bạn những điều quan trọng cần định nghĩa trong một PRD: người dùng ta nhắm tới, giả thuyết ta phải chứng minh để thấy thứ này đáng build, và những thứ thường có trong một PRD. Skill dạy agent: đây là những gì ta cần rút ra từ người dùng, tức là bạn, và đây là cách ta trình bày chúng thành một tài liệu PRD.

## 7. Một PRD thật do skill tạo ra

Video có một đoạn quảng cáo cho Agora.

Sau đó Cole cho xem nhanh một ví dụ: một PRD anh đã tạo bằng skill này, cho một tính năng gọi là "conversation recall" của một AI tutor. Trong đó có problem statement, evidence, và mọi section mà ta bảo agent tạo ra sau khi nó phỏng vấn mình.

![Một PRD mẫu với mục Hypothesis gồm điều kiện đúng và sai](https://homus.dev/photos/MbiMwgbGdxw-1003.jpg)

PRD mẫu "conversation recall": mục "Why it is not table stakes" giải thích vì sao tính năng này đáng làm, rồi mục Hypothesis viết theo dạng có thể bác bỏ: "We believe..." kèm điều kiện "We'll know we're RIGHT if..." (tỉ lệ hỏi lại câu gần trùng giảm ít nhất một phần ba trong bốn tuần, ít nhất 20% người dùng có từ ba conversation trở lên dùng đường recall) và "We'll know we're WRONG if...". Ngay dưới là mục Target User & JTBD.

Điểm quan trọng ở đây: PRD hoàn toàn không mô tả ta sẽ build các feature mới này vào codebase ra sao. Ta chỉ giữ ở mức what và why, vì có một skill riêng định nghĩa spec. Spec mới là phần how, đi vào architecture cho phần implementation.

## 8. Skill spec: vì sao phần "how" phải tách riêng

Việc tách đôi này rất quan trọng, theo Cole, vì đây thật sự là hai conversation khác nhau bạn sẽ có với coding agent. Trước hết bạn mô tả và làm rõ what và why. Sau đó bạn mới lên architecture, đi sâu vào phần technical implementation, tức how: ta sẽ build bộ feature tiếp theo bằng cách nào.

Vì vậy anh khuyên chạy hai skill này trong hai conversation riêng. Anh không demo skill spec (trên sơ đồ là `/plan-architecture`) vì quy trình rất giống skill PRD: agent phỏng vấn bạn, rồi dựa theo một template để tạo tài liệu architecture. Giờ bạn có nó làm artifact thứ hai, đi vào bước tạo ticket.

Outer loop của Cole: PRD (what và why) và spec (how) được tạo trong hai conversation riêng, mỗi cái ra một tài liệu; cả hai cùng đi vào skill cắt epic thành ticket.

Như vậy mỗi conversation tạo ra một tài liệu, và các tài liệu đó đi vào bước cuối của outer loop. Lý do: giờ đã có toàn bộ phạm vi công việc cho epic tiếp theo được lên kế hoạch, ta cần chia nó thành những mẩu việc nhỏ vừa miệng (bite-sized) để không giao cho agent một yêu cầu quá lớn trong mỗi conversation.

## 9. Slice Epic: cắt epic thành ticket

Trách nhiệm của skill này là lấy hai output trước đó, map các dependency, tìm ra phần nào làm song song được, tức là dựng sân khấu cho mọi inner loop khi ta bắt tay vào development thật. Cole chuyển sang Claude Code để cho xem.

Tên skill ở bước này là `/piv-slice-epic`, vì ta lấy epic và cắt (slice) nó thành các mẩu việc nhỏ. Skill nhận hai argument: tài liệu spec hay architecture, và PRD. Có cả hai, nó biết what, why và how, nên có thể tạo và map mọi dependency.

![Claude Code với lệnh /piv-slice-epic và argument hint](https://homus.dev/photos/MbiMwgbGdxw-1143.jpg)

Gõ `/piv-slice-epic` trong Claude Code, argument hint hiện ra: epic cùng trang architecture đi kèm (đường dẫn hoặc URL Confluence/Jira); với greenfield thì là một PRD.

```
/piv-slice-epic [epic + its linked architecture page (paths or Confluence/Jira URLs); a PRD for greenfield]
```

Bạn cũng thấy là có thể truyền trang Confluence nếu muốn. Nhiều công ty Cole làm việc cùng không lưu PRD và spec ở máy, họ lưu trên Confluence. Nên anh muốn skill này thật linh hoạt: PRD nằm trên Confluence hay là file Markdown đều không quan trọng. Skill sẽ lấy được tài liệu, miễn là nó có MCP server để vươn tới nơi bạn lưu tài liệu.

Bạn đưa hai đường dẫn hoặc URL, và skill sẽ tạo ra mọi ticket để bạn implement trong inner loop. Bạn sẽ dành phần lớn thời gian ở inner loop, vì outer loop chỉ chạy một lần mỗi epic. Các skill outer loop rất, rất quan trọng, nhưng các skill inner loop bạn sẽ dùng nhiều hơn hẳn, vì có thể bạn có tới hàng chục ticket nếu epic lớn. Với từng ticket một, ta sẽ đi qua quá trình plan, implement và validate.

Skill slice cho ra một loạt mẩu việc riêng lẻ. Chúng có thể là tài liệu Markdown, GitHub issue hay Jira ticket, không quan trọng. Điểm chính là mỗi ticket là đầu vào cho trọn một inner loop.

## 10. Inner loop bắt đầu bằng skill prime

Ở inner loop, ta chỉ coding agent vào ticket đó và nói: đây là thứ ta muốn implement, tôi muốn bạn khám phá codebase và giúp tôi lên plan cho phần implementation cụ thể này.

Cole thường bắt đầu bằng một skill prime, cụ thể là `prime-codebase`. Anh có vài biến thể khác: nếu muốn agent hiểu một phần cụ thể của codebase, ví dụ bạn chỉ làm front end, thì có skill riêng cho phần đó (trên sơ đồ là `/prime-backend` và `/prime-frontend`). Còn `prime-codebase` là bản tổng quát hơn: nó khám phá codebase, có thể theo góc nhìn của issue cụ thể bạn đưa vào. Nếu bạn đưa một Jira ticket hay một file Markdown cho phần việc tiếp theo, nó sẽ khám phá codebase ở những chỗ liên quan tới thứ bạn muốn build. Argument hint trên màn hình là:

```
/prime-codebase [jira-issue-keys] [confluence-page-ids]
```

Dù thế nào, điều quan trọng là coding agent có global rules của nó, nhưng ngoài ra thì ở đầu một conversation nó khá "ngốc". Nên về cơ bản bước này chỉ là nạp context (context loading).

Cách Cole chia conversation trong inner loop: prime và plan chạy liền nhau trong cùng một conversation để plan dùng được context vừa nạp; implement chạy trong một conversation mới, chỉ mang theo file plan.

Chạy xong skill prime thì ta tới skill plan, nơi ta thật sự lên plan công việc cùng agent. Điều quan trọng cần hiểu về skill plan: ta chạy nó trong chính conversation vừa chạy prime. Cole nói có lẽ anh nên mở một conversation thật cho cụ thể, nhưng chắc người xem đã hiểu ý: bạn gõ `/prime-codebase` hay gì đó, rồi sau khi agent khám phá xong codebase, ta dùng phần đó làm context để đi vào `/piv-plan-implementation`. Ở đây bạn cũng có thể truyền ticket đang làm, nếu chưa truyền ở bước prime. Phần đó không bắt buộc.

## 11. Skill plan: agent phỏng vấn bạn rồi mới viết plan

Giờ ta lên plan cho ticket cụ thể này. Quy trình thật ra khá giống lúc tạo PRD hay tài liệu spec: agent bắt đầu bằng việc phỏng vấn bạn, hỏi một loạt câu để chắc là hai bên hiểu giống nhau về mọi thứ.

Lý do: điều nguy hiểm nhất ở đây là coding agent tự đặt giả định về thứ bạn thật sự muốn build hay cách bạn muốn build nó. Vì LLM sẽ rất tự tin đưa ra những giả định tệ hại. Đó là lý do ta cần cả một workflow: agent hỏi bạn rất nhiều, nghiên cứu codebase rất nhiều, và chỉ sau đó mới tạo plan file để đi vào implementation.

Cole nói: đúng, bỏ nhiều thời gian ở đầu là xứng đáng. Anh biết là tới giờ ta còn chưa viết một dòng code nào, nhưng đây là cái giá để có kết quả đáng tin với AI coding assistant. Đảm bảo hai bên hiểu giống nhau, tạo plan, rồi implement từ plan đó.

![Plan mẫu: Feature Conversation search over message content](https://homus.dev/photos/MbiMwgbGdxw-1523.jpg)

Output mẫu của skill plan: "Feature: Conversation search over message content". Plan mở đầu bằng lời dặn kiểm lại documentation, pattern trong codebase và độ hợp lý của task trước khi implement; phần Feature Description chỉ ra những mảnh đã có sẵn (endpoint `GET /api/conversations/search`, hàm `searchConversations()`, full-text search bằng tsvector và `ts_rank`) kèm số dòng, và việc cần làm là nối chúng lại.

Đây là output của skill planning. Trừ khi bạn đã tuỳ biến skill (anh sẽ nói ở cuối video), format của plan luôn giống nhau. Một trong những thứ ta quy định trong skill planning chính là template: ta luôn muốn có feature description và user story. Đây là điều làm cho các skill đáng tin và lặp lại được (reliable và repeatable): với mọi skill có tài liệu output như thế này, anh đều có một template cho coding agent làm theo.

Plan có problem statement, solution statement, những gì nằm ngoài phạm vi (out of scope) và các non-goal. Bạn có thể đổi mọi section nếu muốn, nhưng với anh, cấu trúc này chạy rất tốt làm chỉ dẫn cho agent trước khi vào implementation.

Vì giờ ta đã đi vào chi tiết của một phần việc cụ thể, plan còn chỉ đích danh những chỗ trong codebase: context cần tham chiếu, các file phải đụng tới, documentation cần đọc. Thậm chí có cả implementation plan từng task một cho các file cần tạo và sửa.

## 12. Testing strategy và cách làm validation first

Phần quan trọng nhất của cả tài liệu plan là testing strategy. Cole muốn dành vài phút cho phần này, vì đây là thứ thật sự làm cách làm của anh nổi bật so với người khác: cách anh để coding agent định nghĩa validation strategy trước khi viết một dòng code nào.

Bạn thấy nó khá đầy đủ: có unit test, integration test, các edge case ta muốn agent test. Có mọi lệnh cụ thể agent sẽ chạy cho linting, type checking, unit testing, integration testing, và cả manual validation: làm sao drive ứng dụng giống như một người dùng thật, dùng những công cụ như agent browser để agent tự làm browser automation. Đây là phần quan trọng nhất của plan.

![Phần Integration Tests, Edge Cases và Validation Commands trong plan](https://homus.dev/photos/MbiMwgbGdxw-1623.jpg)

Trong plan mẫu: Integration Tests (một test `httpx.AsyncClient` qua app FastAPI thật cho `GET /api/conversations/search`, để chứng minh route vẫn được resolve trước `/conversations/{conv_id}`), danh sách Edge Cases (query trống, query chứa `&`, `%`, `_` và dấu nháy đơn, ba tin nhắn cùng khớp chỉ hiện một lần, user khác có cùng cụm từ, tin nhắn rất dài phải cắt, gõ nhanh khiến response cũ về sau response mới...), rồi tới Validation Commands bắt đầu từ Level 1: Syntax & Style.

Anh giải thích vì sao: chiến lược validation first càng ngày càng tốt lên khi LLM càng mạnh. Anh gọi nó là test-driven development, nhưng cho agent. Nếu bạn là engineer, bạn biết TDD nghĩa là gì; nếu không thì cũng đừng lo. Về cơ bản, trước khi viết một dòng code, ta lên kế hoạch xem sẽ test code đó thế nào.

![Phần Validation First, Let the Model Cook trên sơ đồ](https://homus.dev/photos/MbiMwgbGdxw-0243.jpg)

Phần "Validation first, let the model cook" trên sơ đồ: "TDD, but for agents". Bên trái, mỗi task mang check của riêng nó, viết vào plan trước khi có code (endpoint trả đúng shape, token rotation thì token cũ ngừng chạy, error path thì lỗi to chứ không im lặng). Bên phải, năm lớp check từ nông tới sâu: compile và lint, unit, các mảnh chạy cùng nhau, agent có tự chạy được sản phẩm không, và những gì stack của bạn có thêm. Lớp thứ tư được ghi là không bao giờ được bỏ qua: đó không phải test suite mà là agent dùng app như một người dùng và tự nhìn output.

Điều này quan trọng vì nó có nghĩa là thứ ta nhận lại từ agent không bao giờ là lần thử đầu tiên của nó. Agent viết và chạy được mọi test đã định nghĩa trong plan, nên tự lặp lại trên chính công việc của mình. Ta phải can thiệp ít hơn nhiều. Ta nhận lại ít "AI slop" hơn hẳn khi agent tự chạy được mọi test này và tự sửa việc của nó.

Mọi thứ ta sẽ build trong ticket này, như một endpoint hay phần error handling, ta đều cùng agent ghi rõ trong plan: ta sẽ test cái đó bằng cách nào. Cole khuyên khi tạo plan, hãy tự đọc qua, xem validation có ổn không, documentation agent sẽ tham chiếu có ổn không. Vì nếu plan tốt, giờ bạn đang rất cụ thể về điểm đích. Bạn đang nói: đây là hình dạng của "xong", và đây là cách bạn validate để tin vào điều đó.

## 13. Cụ thể về đích đến, không cụ thể về đường đi

Như anh đã nói, chiến lược này càng mạnh khi LLM càng giỏi. Boris Cherny, người tạo ra Claude Code, mới nói điều này tháng trước: bạn muốn mô tả task, mô tả các guardrail và exit criteria, gồm cả validation, rồi cứ để model tự làm và quay lại sau một lúc.

![Trích dẫn của Boris Cherny trên sơ đồ](https://homus.dev/photos/MbiMwgbGdxw-1803.jpg)

Câu trích trên sơ đồ, ghi nguồn Boris Cherny, creator of Claude Code, Y Combinator, tháng 7/2026: mô tả task, mô tả guardrail, mô tả exit criteria, rồi "let the model cook" và quay lại sau một chút. Phía trên là dòng nhắc lớp check thứ tư không bao giờ được bỏ.

Cole nói anh rất thích câu đó: "Just let the model cook". Câu thần chú ở đây là: bạn muốn thật cụ thể về đích đến, chính xác bạn đang tìm gì, validation strategy là gì. Rồi bạn để agent tự dựng con đường tới đó. Bạn không phải cụ thể về phương tiện.

Đó là lý do anh nói validation strategy là phần quan trọng nhất của plan thời nay. Miễn là agent có harness và chỉ dẫn để test và lặp lại trên công việc của mình, nó sẽ tới đích, vì nó tự dựng đường đi: nó viết code và thích nghi được với mọi thứ trục trặc trong lúc tự kiểm việc của mình.

Anh thích điều này vì nó giúp ta hình dung nên dồn thời gian vào đâu. Khi đi qua inner loop, tài liệu plan đôi khi khá choáng ngợp với toàn bộ context reference, các file sẽ tạo và sửa. Nhưng đừng lo quá về những thứ đó. Tất nhiên vẫn quan trọng là kiểm cả plan, nhưng anh "cho phép" bạn tập trung chủ yếu vào validation strategy và vào việc chắc chắn agent thật sự hiểu bạn muốn build gì.

## 14. Skill implement trong một conversation mới

Để khép nhanh inner loop: ta lấy tài liệu plan vừa tạo và đưa nó vào skill implement. Và ta làm việc này trong một conversation hoàn toàn mới.

Ta tách ở đây, giống như đã tách skill PRD và skill spec, vì công việc implementation rất khác với planning. Conversation planning của bạn có lẽ đã rất dài. Ta muốn tránh context rot, vì các LLM có một "dumb zone", vùng mà chúng bị quá tải thông tin, y như con người. Và vì tài liệu plan ta vừa xuất ra thật sự là context duy nhất cần để viết code, ta có thể đi thẳng vào skill implement trong một conversation mới.

Cụ thể, anh gõ `/piv-implement`, và argument duy nhất là đường dẫn tới plan. Trong VS Code, anh chỉ việc bấm chuột phải, copy full path của file plan, dán vào đây, rồi gửi đi. Đó là tất cả những gì phải làm.

```
/piv-implement
```

Trong conversation mới, skill implement đi qua plan từng task, và chạy luôn các bước validation đã ghi trong plan; lỗi thì agent tự sửa rồi kiểm lại.

Trong lúc implementation đi qua plan, agent sẽ tự động chạy các bước validation có trong plan. Nên thật ra bước validate được gắn sẵn vào implementation. Bạn có thể chạy nó như một bước riêng: anh có hẳn một skill riêng nếu bạn muốn một lần validate độc lập. Nhưng thường thì hai việc diễn ra cùng lúc.

## 15. Review của chính bạn và pull request

Khi agent báo đã xong, bạn tự làm code review và manual testing nếu muốn. Thông thường, nhất là nếu bạn thiên về kỹ thuật, Cole vẫn khuyên kiểm lại việc của agent. Việc bạn đã ghi rõ validation strategy từ đầu không có nghĩa là agent sẽ làm hoàn hảo.

Nên hãy validate theo cách bạn muốn. Đây là phần review do chính bạn làm, và anh có các skill đi kèm để giúp bạn review (trên sơ đồ là `/piv-review-changes`, `/piv-review-pr` và `/piv-fix-review-findings`, với ghi chú "a fresh context, not the author's", tức review bằng một context mới chứ không phải context của người viết).

Rồi bạn kết thúc ticket đó bằng cách mở một pull request. Thường thì bạn dùng thứ như GitHub để quản lý codebase. Pull request là lời đề xuất: đây là phần việc tôi đã làm trong inner loop cho ticket này, giờ tôi đề xuất merge nó vào codebase chính. Trên sơ đồ, bước PR ghi "a human makes the final call", kèm `/piv-commit` và `/piv-create-pr`.

Đoạn cuối của inner loop theo Cole: review, mở pull request, review PR, merge, rồi quay lại inner loop với ticket tiếp theo cho tới khi xong mọi ticket.

Làm xong, bạn review pull request, thấy ổn thì merge, rồi chỉ việc chuyển sang ticket tiếp theo và chạy lại inner loop, cho tới khi xử lý hết mọi ticket đã tạo bằng skill slice.

Và đó là toàn bộ workflow. Cole nói video dài hơn anh dự tính một chút, nhưng anh muốn chuẩn bị cho người xem thật kỹ. Đó là toàn bộ quy trình phát triển. Dù không chạy skill nào, giờ bạn biết chúng ghép với nhau ra sao: khi nào chạy trong conversation mới, khi nào tiếp tục cùng một conversation như với prime và plan.

## 16. Tuỳ biến skill bằng chính coding agent

Bạn hoàn toàn có thể tuỳ biến mọi skill theo ý mình. Cole cố làm mỗi skill tối giản nhất có thể, nhưng chắc chắn trong đó vẫn có vài quan điểm riêng của anh, như thế nào là cấu trúc tốt nhất cho một PRD hay một plan, hay agent nên phỏng vấn bạn ra sao.

Nếu muốn sửa bất kỳ file nào, việc đó thật ra rất dễ. Cách anh thường làm: mở một conversation với Claude, lấy file SKILL.md của skill PIV cần sửa, chẳng hạn skill plan implementation, copy nó, dán vào và nói: "Hey Claude, tôi muốn đổi XYZ trong skill này".

![VS Code với cây thư mục skills và Claude Code ở terminal](https://homus.dev/photos/MbiMwgbGdxw-2203.jpg)

Cây thư mục `.claude/skills` trong VS Code, mỗi skill là một thư mục chứa SKILL.md (piv-implement, piv-plan-implementation, piv-review-changes, piv-slice-epic...), còn Claude Code chạy sẵn ở terminal bên cạnh để nhận yêu cầu sửa skill.

Anh không bao giờ tự tay viết skill hay chỉnh skill bằng tay. Anh luôn để coding agent sửa dựa trên một mô tả cơ bản anh đưa. Nên nếu có gì bạn không thích trong các skill này khi đưa chúng vào, khi chọn từ thư viện anh đưa, thì rất dễ chỉnh cho đúng thứ bạn cần. Muốn đổi cấu trúc hay đổi template, cứ dùng coding agent để làm.

Cole hy vọng người xem thấy các skill này hữu ích, dù dùng hết hay chỉ một phần. Anh sẽ tiếp tục bổ sung vào repository, biến nó thành nơi gom mọi skill anh dùng cho mọi việc. Hiện tại phần lớn trong repo là các skill cốt lõi cho SDLC của anh, nhưng anh còn nhiều thứ đã lên kế hoạch. Anh kết video bằng lời mời like và subscribe nếu người xem muốn thêm nội dung về skill và AI coding.

## Nguồn và liên kết

- Tên gốc: Every Claude Code Skill I Use to Drive My Entire Development Process
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=MbiMwgbGdxw](https://www.youtube.com/watch?v=MbiMwgbGdxw)

- Kênh YouTube Cole Medin (Cole Medin): [youtube.com/channel/UCMwVTLZIRRUyyVrkjDpn4pA](https://www.youtube.com/channel/UCMwVTLZIRRUyyVrkjDpn4pA)

- Repo Cole's AI Skills, toàn bộ skill trong video (README có hai lệnh cài plugin, cách cài bằng `npx skills`, và bảng mô tả từng skill theo nhóm Prime, Plan, PIV loop, Issues): [github.com/coleam00/skills](https://github.com/coleam00/skills)

- GitHub Spec Kit, toolkit spec-driven development Cole lấy làm ví dụ framework: [github.com/github/spec-kit](https://github.com/github/spec-kit)

- Gas Town, hệ thống điều phối nhiều coding agent: [github.com/steveyegge/gastown](https://github.com/steveyegge/gastown)

- Tài liệu Claude Code về skill: [code.claude.com/docs/en/skills](https://code.claude.com/docs/en/skills)

- Tài liệu Claude Code về plugin: [code.claude.com/docs/en/plugins](https://code.claude.com/docs/en/plugins)

Nguồn: https://homus.dev/talks/every-claude-code-skill-i-use-to-drive-my-entire-development-process · cập nhật 2026-10-09