Làm việc với Fable 5: Sửa bản đồ trước khi đi vào lãnh thổ

Ghi chú thực chiến · ClaudeKit

Fable 5 chỉ được tính trong subscription quota đến hết 7/7, vậy làm thế nào để làm việc với Fable hiệu quả? Tối qua mình tình cờ đọc được hai post chất lượng trên X — "A Field Guide to Fable: Finding Your Unknowns" (Thariq, @trq212) và "The Most Valuable Thing You Can Do With Fable 5" (Alex Finn). Ghép các insight đó vào ClaudeKit system, mình đúc rút thành một pipeline 6 giai đoạn với 3 custom skill kết hợp cùng ClaudeKit skills, fit khá sát với insight của Thariq về cách tìm unknowns trước khi code.

01 · Field Guide to Fable

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.

Ma trận Rumsfeld — 4 loại unknowns khi bạn viết một prompt

🟢 Known knowns

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.

🟡 Known unknowns

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ỏ.

🟠 Unknown knowns

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.

🔴 Unknown unknowns

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ử.

Nguyên tắc vàng: tìm unknowns càng sớm thì chi phí sửa càng rẻ — tìm sau khi đã 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.

02 · Ba gap của ClaudeKit

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.

· blindspot · Custom

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.

vùng lạ · domain mới · trước khi code

· impl-notes · Custom

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.

trong lúc code · edge case · ghi chú bàn giao

· quiz-gate · Custom

Không pass quiz tuyệt đối thì không merge. Đơn giản vậy thôi.

trước khi merge · hiểu biết · review PR

Đang ưu tiên chia sẻ cho Facebook Subscribers trước

Cả 3 skill hiện chỉ chia sẻ cho Subscribers trong lúc còn tinh chỉnh. Khi ổn định sẽ publish lên repo công khai — subscribe để nhận sớm.

Subscribe để nhận sớm

Chi tiết từng skill

Trước khi code

/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ồi git 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.

Deliverable chính: "a better prompt" — sẵn để paste thẳng vào /ck:brainstorm hoặc /ck:plan ở bước sau.

Trong khi code

/impl-notes — log deviation ngay lúc xảy ra

• File implementation-notes.md ghi 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.

Feed trực tiếp cho quiz-gate (deviations = quiz material tốt nhất) và /ck:journal.

Sau khi code

/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.

Verdict của gate là điều kiện để chạy /ck:git hoặc /ck:ship.

03 · Workflow đầu-cuối

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.

Giai đoạn 0 · Định vị unknowns

/blindspot

Qué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.

Giai đoạn 1 · Khám phá & thiết kế

/ck:brainstorm --html

Nhậ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).

Giai đoạn 2 · Kế hoạch

/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ù.

Giai đoạn 3 · Thực thi

/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.

Giai đoạn 4 · Gate hiểu biết

/ck:code-review + /quiz-gate

Code-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.

Giai đoạn 5 · Ship

/ck:git hoặc /ck:ship + /ck:journal

Commit/push hoặc PR pipeline, chỉ chạy sau khi gate ở giai đoạn 4 PASSED. Journal đọc impl-notes làm feed để reflect.

04 · Insight đắt nhất

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.

Gate 1 · Trước cook · /ck:plan red-team · Khử unknown unknowns của plan

Gate 2 · Trước cook · /ck:plan validate · Khử known unknowns của quyết định

Gate tuỳ chọn · Trước cook

/codex:adversarial-review\ trên plan

Gate chéo model — case critical

Cần OpenAI sub

Thực thi · /ck:cook

Gate tuỳ chọn · Sau cook

/codex:adversarial-review\ trên code diff

Khử unknown unknowns của chính model

Cần OpenAI sub

Gate 3 · Sau cook · Chốt · /quiz-gate · Khử unknowns của bạn về thứ vừa ship

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.

05 · Không phải lúc nào cũng full pipeline

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.

Quy tắc chọn: mỗi gate là phí bảo hiểm. Unknowns nhiều thì gate dày, unknowns ít thì gate mỏng. Chạy full pipeline cho task quen thuộc lãng phí đúng bằng việc skip gate cho task rủi ro.

06 · Bài toán chi phí pipeline

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ẻ.

Usage trap cần nhớ: built-in 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.

07 · Gate chéo model

Codex — đưa một model khác vào kiểm tra Claude

Điều kiện\ 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

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:

Prompt mẫu — Copy & dùng

/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:

1. Codex adversarial chạy round 1, trả findings verbatim.
2. 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.
3. NGƯỜI duyệt danh sách Accept — gate người, không bỏ được.
4. Claude apply các fix được duyệt + consistency sweep.
5. 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.

Vì sao không auto-loop: prompt của Codex là "break confidence in the change, not validate it" — reviewer được thiết kế để LUÔN tìm ra vấn đề sẽ không bao giờ nói "hoàn hảo". Auto-loop với reviewer như vậy là vòng xoay vô tận theo thiết kế. Người là điều kiện dừng duy nhất hợp lệ ("phần còn lại là nitpick, đi tiếp"). Lưu ý: --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.

08 · Đúc rút từ bài thứ hai

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.

Nguyên tắc 1 · Dồn Fable vào tầng system, không phải tầng task

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.

Prompt mẫu — Copy & dùng

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.

Nguyên tắc 2 · Audit từ artifacts thật thay vì brain dump

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.

Prompt mẫu — Copy & dùng

Đừ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.

Nguyên tắc 3 · Kiểm chứng bằng cách chạy

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.

Prompt mẫu — Copy & dùng

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.

Nguyên tắc 4 · Trigger redesign bằng rule of three

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ỏ.

Prompt mẫu — Copy & dùng

Đọ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ì.

Redesign chạy bằng evidence tích luỹ — mỗi lần sửa system đều xuất phát từ friction có thật và được kiểm chứng bằng một lần chạy thật.