Map vs Territory: khoảng cách đó chính là unknowns
Prompt/context bạn đưa cho Claude là bản đồ. Codebase và ràng buộc thực tế là lãnh thổ. Khoảng cách giữa hai thứ này gọi là unknowns.
Với Fable 5, chất lượng output bị giới hạn bởi khả năng làm rõ unknowns của người dùng — không phải bởi năng lực của model. Model càng mạnh, cái giá phải trả cho một bản đồ tồi càng lớn, vì nó sẽ tự tin thực thi sai hướng thay vì dừng lại hỏi.
Những gì bạn đã viết rõ trong prompt. Claude chỉ cần đọc và tuân theo — không cần đoán.
Những gì bạn biết mình chưa quyết định — trade-off, tên biến, chiến lược migration còn bỏ ngỏ.
Tiêu chuẩn kiểu "biết khi nhìn thấy" nhưng bạn không viết ra được thành lời — chỉ lộ ra khi output sai.
Câu hỏi bạn không biết là mình cần hỏi. Đây là khoảng trống nguy hiểm nhất — và là mục tiêu chính cần khử.
merge thì chi phí sửa đắt gấp nhiều lần, vì lúc đó lãnh thổ đã bị bản đồ sai định hình.
Ba custom skill tự viết để bù đúng ba khoảng trống
Không thuộc ClaudeKit core — 3 skill nhỏ dựng ra để bù đúng khoảng trống mà phương pháp này cần: tìm unknown unknowns trước khi code, log deviation ngay lúc xảy ra, và gate hiểu biết con người sau khi code.
Biến 'tôi không biết mình không biết gì' thành một prompt sắc bén, dán là dùng được.
Bắt từng lần lệch plan ngay lúc xảy ra — trước khi nó thành một bí ẩn.
Không pass quiz tuyệt đối thì không merge. Đơn giản vậy thôi.
Chi tiết từng skill
/blindspot — quét mù trước khi vào lãnh thổ
- Scout codebase + đào
git logđể tìm unknown unknowns của người dùng, không phải giải task hộ họ. - Mọi finding bắt buộc phải cite evidence: file cụ thể, commit hash, hoặc doc — không chấp nhận suy đoán chung chung.
- Trick giá trị nhất: tìm commit từng làm task tương tự (
git log --grep) rồigit show --stat <hash>— footprint file của nó chính là checklist touchpoint có sẵn, thường là artifact tín hiệu cao nhất.
/ck:brainstorm hoặc /ck:plan ở bước sau./impl-notes — log deviation ngay lúc xảy ra
- File
implementation-notes.mdghi Decisions / Deviations / Surprises tại thời điểm chúng xảy ra — không phải hồi tưởng cuối session như/ck:journal. - Standing rule nằm ngay trong HEADER của file — không dựa vào trí nhớ hội thoại, vì context compaction sẽ làm bay rule khi hội thoại dài ra. Bất kỳ agent nào đọc lại file cũng tự động "re-adopt" rule.
- Gặp edge case lệch plan → chọn phương án bảo thủ (reversible nhỏ nhất), log 4 dòng, đi tiếp — không dừng lại chờ user với quyết định có thể đảo ngược.
quiz-gate (deviations = quiz material tốt nhất) và /ck:journal./quiz-gate — người kiểm tra người
- Sinh HTML explainer về thay đổi (TL;DR, context, intuition, blast radius) kèm quiz hành vi — không phải trivia đổi tên biến.
- Gate chỉ pass khi trả lời đúng 100%. Sai câu nào → giải thích khái niệm bị hiểu sai bằng đúng đoạn code liên quan, rồi re-quiz câu mới nhắm đúng chỗ đó, lặp tới khi pass.
- Fix quan trọng đã áp dụng: report ban đầu chỉ chứa câu hỏi, answer key chỉ được ghi vào HTML sau khi gate resolve (pass hoặc abort) — nếu ghi trước, user đọc thấy đáp án thì gate vô nghĩa.
/ck:git hoặc /ck:ship.Pipeline 6 giai đoạn kết hợp custom skill với ClaudeKit
Mỗi giai đoạn là một lần trả-trước chi phí tìm unknowns.
/blindspotQuét codebase + git history → báo cáo unknown unknowns, potholes, và một prompt sắc hơn để mang sang giai đoạn 1.
/ck:brainstorm --htmlNhận prompt từ blindspot → scout + interview built-in → 2-3 approach + design doc.
Rủi ro cao: thêm /ck:predict (5 persona debate) hoặc /ck:scenario (edge case 12 chiều).
/ck:plan (hoặc --tdd)Xuất plans/<ts>-<slug>/plan.md + phase files.
Rủi ro cao: + red-team (hostile reviewers xé plan) rồi + validate (verify claims vs codebase thật).
Case critical (cần OpenAI sub): /codex:adversarial-review trên plan — gate chéo model, chạy cuối cùng sau red-team + validate: tấn công bản plan đã tôi luyện, tìm chỗ cả họ Claude cùng mù.
/impl-notes init → /ck:cook → /impl-notes review/impl-notes init tạo implementation-notes.md trong plan dir trước khi cook. /ck:cook <plan> implement — khi lệch plan: chọn phương án bảo thủ, /impl-notes log, đi tiếp. Cuối session: /impl-notes review distill learnings cho session sau.
/ck:code-review + /quiz-gateCode-review kiểm tra chất lượng code (máy check code); quiz-gate kiểm tra hiểu biết con người (người check người) — hai trục khác nhau.
Rủi ro cao (cần OpenAI sub): /codex:adversarial-review trên code diff — gate chéo model, chạy giữa /ck:code-review và /quiz-gate, focus text lấy từ mục Deviations của impl-notes.
/ck:git hoặc /ck:ship + /ck:journalCommit/push hoặc PR pipeline, chỉ chạy sau khi gate ở giai đoạn 4 PASSED. Journal đọc impl-notes làm feed để reflect.
3 gate cố định + 2 gate chéo model tuỳ chọn quanh ck:cook
Không phải các bước kiểm tra trùng lặp — mỗi gate nhắm đúng một trục unknown riêng, đứng ở hai đầu của bước thực thi. /quiz-gate luôn là gate chốt cuối: người là điều kiện dừng.
trên plan
trên code diff
Kéo ngang để xem đủ 6 node →
Gate 1 · /ck:plan red-team — agent kiểm tra agent
2-4 reviewer subagent persona thù địch xé bản plan tìm failure mode không ai nghĩ tới. Finding nào không có evidence file:line cụ thể bị auto-reject — tránh phàn nàn mơ hồ.
Gate 2 · /ck:plan validate — chạy sau red-team, trước cook
Verification pass check "map vs territory" theo nghĩa đen: grep codebase xem claims của plan (file, symbol, endpoint) có tồn tại thật không. Sau đó interview 3-8 câu để bạn chốt các assumption còn bỏ ngỏ. Thứ tự red-team → validate là chủ đích: để agent xé và sửa plan xong rồi mới chốt với người, tránh chốt trên bản nháp sắp bị sửa lại.
Gate tuỳ chọn · /codex:adversarial-review trên plan — trước cook, sau validate (cần OpenAI sub)
Chỉ cho case critical (migration, security, public contract). Chạy cuối cùng ở giai đoạn kế hoạch, sau khi plan đã được red-team + validate tôi luyện — tấn công bản plan hoàn chỉnh, tìm chỗ cả họ Claude cùng mù.
Gate tuỳ chọn · /codex:adversarial-review trên code diff — sau cook, trước quiz-gate (cần OpenAI sub)
Các gate cố định đều là Claude kiểm tra Claude — cùng model family, cùng blind spots, reviewer sẽ không bắt được lỗi mà chính nó cũng mắc. Gate chéo model đưa agent khác model (GPT-5.5) vào — khử đúng loại unknown còn lại: unknown unknowns của chính model. Focus text lấy từ mục Deviations của impl-notes. Chi tiết ở section 07.
Gate 3 · /quiz-gate — người kiểm tra người, gate chốt cuối
Gate cuối cùng trước ship, khử unknowns của chính bạn về những gì vừa được ship — code review máy (hay model khác) đã pass không có nghĩa là bạn hiểu hết behavior mới. Người là điều kiện dừng.
Scenario combos — đóng phí bảo hiểm tương xứng rủi ro
Full pipeline (giai đoạn 0→5) chỉ dành cho area lạ + scope mờ + rủi ro cao. Các tình huống thường gặp hơn cần combo mỏng hơn.
| Scenario | Combo dùng | Bỏ qua |
|---|---|---|
| Đã có plan từ session trước, giờ tiếp tục | /ck:watzup đọc trạng thái → đọc "Learnings for next session" trong impl-notes cũ → /impl-notes init → /ck:cook phase tiếp → /quiz-gate. Chưa có impl-notes cũ (vừa thêm 3 custom skills vào project đã dùng ClaudeKit từ trước)? Bỏ qua bước đọc Learnings — /impl-notes init tạo file mới trong plan dir đang active, learnings tích từ session này. |
Giai đoạn 0-2 — unknowns đã trả phí ở session trước |
| Bug fix nhỏ, area quen | /ck:fix → commit. Lòi deviation thì /impl-notes log |
Toàn bộ gate — quiz-gate cho fix 10 dòng là quá liều |
| Area lạ nhưng scope đã rõ | /blindspot <area> → paste better-prompt thẳng vào /ck:plan |
ck:brainstorm — không có gì để debate khi scope đã chốt |
| Domain mới hoàn toàn (không phải code) | /blindspot --domain (teach-first, học vocabulary) → /ck:brainstorm --html |
Scout codebase — gap nằm ở kiến thức, không phải repo |
| Rủi ro cao (public contract, security, migration) | Full pipeline + /ck:predict//ck:scenario ở giai đoạn 1 + red-team → validate ở giai đoạn 2 + /codex:adversarial-review ở giai đoạn 4 (nếu có OpenAI sub); quiz-gate bắt buộc |
Không bỏ gì |
| Claude kẹt — debug loop, fix đi fix lại không xong | /codex:rescue (cần OpenAI sub) — giao task cho GPT-5.5 nhìn từ blind spot khác; --resume tiếp thread cũ |
Đổi gate không giải quyết được — vấn đề nằm ở blind spot của model, cần model khác |
| Plan xong, rủi ro vừa — không đáng swarm red-team | /ck:plan validate — verify claims + interview chốt assumption → /ck:cook |
red-team (quá liều cho rủi ro vừa), /ck:predict//ck:scenario |
| Review PR người khác viết | /quiz-gate --pr <n> dùng một mình — quiz chính là cách đọc PR sâu |
blindspot, impl-notes — không phải code mình viết |
| Refactor thuần, behavior không đổi | /ck:code-review + test suite |
quiz-gate optional — không có behavior mới để hiểu sai |
Fable 5 tham gia công đoạn nào?
Nguyên tắc: chi phí tìm unknowns trả trước thì rẻ. Suy ra dồn model đắt nhất vào công đoạn phát hiện & quyết định, dùng model rẻ cho công đoạn thực thi theo chỉ dẫn — plan càng tốt thì model implement càng được phép rẻ.
| Công đoạn | Model | Vì sao |
|---|---|---|
/blindspot |
Fable 5 | Giá trị nằm ở diễn giải: đọc git history ra "pothole", nhận ra commit nào là pattern đáng theo. Model yếu chỉ liệt kê file. |
/ck:brainstorm, /ck:plan, /ck:predict |
Fable 5 | Quyết định kiến trúc — sai ở đây thì mọi công đoạn sau rẻ mấy cũng vô nghĩa. |
/quiz-gate (sinh câu hỏi) |
Fable 5 / Opus | Distractor tốt đòi hiểu behavior sâu hơn cả người viết code. Người trả lời là bạn, model chỉ ra đề. |
/ck:plan red-team |
Fable controller + Opus/Sonnet | Reviewer subagent chỉ cần tìm failure mode có evidence file:line (persona đã định sẵn — Opus dư sức). Adjudicate findings mới cần trí tuệ, chạy ở main session. Ví dụ per-subagent đẹp nhất pipeline. |
/ck:plan validate |
Sonnet/Opus | Verification pass là grep cơ học theo tier checklist. Trí tuệ nằm phía người trả lời — model chỉ cần ra câu hỏi đúng chỗ. |
/ck:cook theo plan chi tiết |
Sonnet | Plan tốt đã khử unknowns; thực thi là follow-the-map. Nơi tiết kiệm lớn nhất. |
/ck:code-review |
Opus/Sonnet | Review theo checklist + evidence; Fable chỉ đáng khi thay đổi chạm public contract. |
/impl-notes log, /ck:git, /ck:ship, /ck:watzup |
Haiku/Sonnet | Cơ học: append vài dòng, commit, tổng hợp status — không cần trí tuệ. |
/ck:scout raw discovery |
Haiku | Glob/Grep tìm file không đáng đốt Fable. Nếu dùng Explore/subagent để scout lớn, pin model rẻ trước; blindspot mới là tầng diễn giải phía trên. |
/codex:review, /codex:adversarial-review, /codex:rescue |
GPT-5.5 (usage OpenAI, subscription riêng) | Gate chéo model — không đốt token Claude, tách billing; giá trị nằm ở blind spot khác chứ không phải model mạnh hơn. |
Explore của Claude Code từ v2.1.198 có thể thừa hưởng model từ main conversation. Nếu main đang dùng Fable 5, Explore cũng có thể đốt Fable usage. Muốn scout rẻ mà không ảnh hưởng các subagent khác, tạo custom subagent explore.md với name: Explore và pin model: haiku hoặc model: sonnet. Xem Claude Code docs về built-in subagents.
Anti-pattern cần tránh: dùng Fable cho cook nhưng Sonnet cho plan — tức trả tiền model đắt để nó đoán unknowns lẽ ra phải được khử từ trước, đúng cái bẫy "map kém, territory đắt" mà bài viết cảnh báo.
Codex — đưa một model khác vào kiểm tra Claude
Mọi thứ trong section này cần subscription plan của OpenAI (ChatGPT Plus/Pro hoặc API) và Codex CLI đã login. Không có thì bỏ qua — pipeline 3 gate cố định phía trên vẫn đủ dùng.
Plugin codex-plugin-cc đưa Codex/GPT-5.5 vào Claude Code. Giá trị lõi không phải "model mạnh hơn" mà là model KHÁC: mọi gate nội bộ đều là Claude kiểm tra Claude — cùng training, cùng systematic bias, reviewer sẽ không bắt được lỗi mà chính nó cũng mắc. Codex có blind spots khác → khử được unknown unknowns của chính model.
Cài đặt
/plugin marketplace add openai/codex-plugin-cc /plugin install codex@openai-codex /codex:setup
Nếu dùng MCP Codex thay vì plugin
Codex CLI cũng có thể chạy như MCP server cho agent khác gọi vào, nhưng khi đi đường MCP thì Claude không còn bị bó trong command/gate của plugin. Nó có thể hỏi Codex ở brainstorm, plan, cook, review, close phase. Cách này dùng được, nhưng phải có guardrails rõ:
- Khi nào hỏi: chỉ hỏi ở checkpoint có rủi ro thật — critical plan, material code diff, security/migration/public contract, hoặc debug loop đã thử 2 hướng mà vẫn kẹt.
- Hỏi gì: mỗi lần gọi phải có artifact cụ thể, scope cụ thể, câu hỏi cụ thể, và tiêu chí reject finding không có evidence.
- Tối đa mấy round: mặc định 1 round; round 2 chỉ khi round 1 dẫn tới thay đổi material. Không chạy chuỗi ask → red-team → review → ask lại vô hạn.
- Ai quyết định cuối: Codex không tự approve plan, không tự đóng phase, không tự cho phép ship. Claude/human phải adjudicate từng finding: accept/reject kèm evidence, rồi mới sửa.
Trong Claude Code workflow, nếu dùng keyword/feature như ultracode để gọi Codex và spawn session review có quyền rộng hơn, hãy coi nó là review-only trừ khi người dùng explicit approve edit. Đừng dùng nó như default path: session review rộng + nhiều round rất dễ burst token nặng. Tham khảo thêm OpenAI docs về Codex MCP.
Vị trí từng command trong pipeline
| Command | Thời điểm | Vai trò |
|---|---|---|
/codex:adversarial-review trên plan |
Cuối giai đoạn 2, SAU red-team + validate | Gate chéo model thứ 3 trên plan — chỉ cho case critical (migration, security, public contract) |
/codex:adversarial-review trên code diff |
Giai đoạn 4, sau /ck:code-review, trước /quiz-gate |
Use case chính hãng ("review before shipping") — challenge design choices, hidden assumptions, tradeoffs; focus text lấy từ mục Deviations của impl-notes |
/codex:rescue |
Bất kỳ lúc nào Claude kẹt (debug loop) | Escape hatch — --resume giữ thread Codex riêng theo session |
/codex:review |
Giai đoạn 4 | Second opinion khi kết quả /ck:code-review đáng ngờ; không nhận focus text nên KHÔNG dùng cho plan |
Review gate (/codex:setup --enable-review-gate) |
Mỗi turn có code edit | Mặc định TẮT — xem lý do bên dưới |
Prompt mẫu — adversarial review trên plan
Đặt Codex ở tầng review thứ 3, sau khi plan đã được tôi luyện — nói rõ điều đó để nó không tìm lại thứ tầng dưới đã bắt:
/codex:adversarial-review --wait Đây là implementation plan tại plans/<dir>/, chưa phải code — đã qua red-team và validate nội bộ. Đừng verify chi tiết file/symbol. Thay vào đó: (1) challenge HƯỚNG ĐI — đây có phải cách tiếp cận đúng không, có alternative đơn giản hơn không; (2) hidden assumptions mà plan đứng lên trên nhưng không nói ra; (3) tradeoffs bị đánh giá một chiều; (4) pressure-test các phase liên quan [điền risk area thật: auth/data loss/rollback/race].
Plan chưa commit được tính là working-tree change (untracked files reviewable); plan đã commit thì thêm --base <ref>.
Vòng xử lý findings — human trigger, KHÔNG auto
Adversarial-review bị khoá read-only, trả output verbatim. Vòng lặp do người điều khiển:
- Codex adversarial chạy round 1, trả findings verbatim.
- Claude (Fable/Opus) adjudicate: Accept/Reject từng finding kèm evidence — finding trùng quyết định đã verify thì reject có dẫn nguồn.
- NGƯỜI duyệt danh sách Accept — gate người, không bỏ được.
- Claude apply các fix được duyệt + consistency sweep.
- Round 2 chỉ khi fix vừa apply là thay đổi material; focus text trỏ đúng vùng đã sửa. Tối đa 2 round.
--resume chỉ có ở rescue; adversarial-review stateless — round 2 phải tự mang context trong focus text.
Review gate — vì sao mặc định TẮT
Bản auto duy nhất của plugin là Stop hook review mọi turn có code edit. Ba lý do để tắt:
- Timeout tới 900s mỗi turn — mỗi lượt edit phải chờ review xong mới đi tiếp.
- Không thấy loop guard cứng trong code — chính OpenAI cũng cảnh báo vòng lặp Claude-Codex.
- Nghịch lý per-turn gating: chỉ đáng cho unattended run, nhưng OpenAI khuyên chỉ bật khi đang ngồi monitor — mà người đang canh thì người đã là gate rồi.
Thay thế: /codex:adversarial-review chạy một lần ở giai đoạn 4 — cùng độ phủ, một lần trả phí, có người adjudicate.
Redesign system của bạn — đúng cách
Bài của Alex Finn đưa cùng luận điểm với Thariq nhưng ở tầng cao hơn: thay vì sửa từng bản đồ, hãy nâng cấp cái máy vẽ bản đồ — chính coding operating system của bạn. Dưới đây là 4 nguyên tắc để áp dụng ngay.
Một flaw ở tầng system trả giá lãi kép trên mọi task — nên một session Fable dành cho redesign coding loop sẽ amortize trên hàng trăm session cook sau đó. Fable đáng tiền nhất khi output là cấu trúc tái sử dụng (system, skill, plan), rẻ nhất khi output chỉ là một lần thực thi.
Thay vì làm ngay task này, hãy thiết kế cho tôi một skill/workflow tái sử dụng để MỌI task cùng loại về sau chạy qua nó. Loại task: [mô tả]. Output cần: quy trình từng bước, file SKILL.md (nếu phù hợp), và tiêu chí đo để biết nó có đang hoạt động tốt không.
Cho Fable đọc trực tiếp rules/, skills, và git history của bạn — dữ liệu thật về cách bạn làm việc mạnh hơn nhiều so với lời tự kể. Artifacts phản ánh hành vi thực tế; lời kể phản ánh hình dung về hành vi.
Đừng hỏi tôi làm việc thế nào — lời tự kể không đáng tin. Hãy đọc: thư mục rules/, danh sách skills đang cài, và `git log --oneline -50` của repo này, rồi tự dựng lại bức tranh workflow THỰC TẾ của tôi. Chỉ ra 3 chỗ friction lớn nhất, mỗi chỗ phải cite file hoặc commit làm bằng chứng — không nhận nhận định không có dẫn chứng.
System mới phải được chạy thử trên một task thật rồi đo output — system chỉ lộ điểm yếu dưới tải thật, không lộ trong lúc thảo luận. Prototype trước, mở rộng sau.
System/skill vừa thiết kế xong: chạy thử nó trên đúng MỘT task thật sau đây: [task]. So sánh với cách làm cũ theo 3 tiêu chí: thời gian, số lần phải sửa lại, chất lượng output. Nếu không hơn rõ rệt, liệt kê chỗ cần chỉnh — đừng khen.
Cùng một loại friction xuất hiện ≥3 lần trong impl-notes / journal / retro thì mới đáng redesign đúng system đó. Vòng lặp: work → tích deviations → retro lộ pattern → redesign → chạy thử → giữ hoặc bỏ.
Đọc implementation-notes.md và journal/retro gần nhất của tôi. Nhóm các deviation/friction theo loại. Loại nào xuất hiện từ 3 lần trở lên? Với MỖI loại đó, đề xuất một thay đổi system NHỎ NHẤT khử được nó. Loại nào dưới 3 lần: bỏ qua, đừng đề xuất gì.