Quick Ref / Brainstorm command

Trước /ck:plan

/ck:brainstorm

Dùng khi hướng làm còn mơ hồ. Scout trước, chốt requirements cụ thể, tranh luận trade-off, rồi mới viết report và bàn giao sang /ck:plan.

01

Scout

02

Reqs rõ

03

Debate

04

Report path

Scout trước

Tóm tắt 3-6 findings trước Discovery.

Report trước

Bàn giao plan phải nhận path brainstorm report.

Không Task-spawn

planner/docs-manager là consultation inline.

Execution map

Bốn lane: scout, làm rõ, đánh giá, rồi đóng bằng report/handoff.

01

Scout

Context trước câu hỏi

1 Khảo sát BẮT BUỘC trước tiên — xác định loại dự án, modules, patterns, docs, plans

02

Làm rõ

Chốt 5 mục cụ thể

2 Khám phá AskUser lặp — trích 5 mục: output, acceptance, scope, ràng buộc, touchpoints
3 Phạm vi Phân tách nếu 3+ subsystem độc lập

03

Đánh giá

Trade-off và brutal honesty

4 Nghiên cứu planner agent + WebSearch + docs-seeker
5 Phân tích Đánh giá 2-3 hướng với pros/cons theo YAGNI/KISS/DRY
6 Tranh luận Brutal honesty — thách thức giả định, trình bày options
7 Đồng thuận Thống nhất hướng đi

04

Bàn giao

Report rồi chọn plan/end

8 Báo cáo Báo cáo markdown qua ck:project-organization
9 Bàn giao AskUser: /ck:plan --tdd (refactor/critical) · /ck:plan (default) · kết thúc
10 Nhật ký /ck:journal — entry kỹ thuật ngắn gọn

Prompt mẫu

Dùng prompt khác nhau cho brainstorm mới, plan trong cùng session, và plan từ session mới.

Start brainstorm

/ck:brainstorm Chọn hướng auth tốt nhất cho SaaS app hiện tại

Dùng khi: Hướng làm còn mơ hồ, cần scout repo và tranh luận trade-off trước.

Kết quả: Viết report tại plans/reports/brainstorm-260524-1908-auth-approach.md.

Cùng session

/ck:plan Lập plan triển khai hướng auth đã chốt trong brainstorm, dùng report vừa tạo làm context

Dùng khi: Vẫn đang ở session brainstorm và agent vừa tạo report.

Kết quả: Plan dùng context hiện tại cùng path report đã được bàn giao.

Session mới Recommended

/ck:plan plans/reports/brainstorm-260524-1908-auth-approach.md

Dùng khi: Sau brainstorm dài, nên start session mới để tránh đầy context.

Kết quả: Phải mention file path để plan đọc đúng brainstorm artifact.

Plan handoff

Trong session brainstorm, offer khi proposal đã duyệt, hết câu hỏi mở, report đã viết. Nếu đã clear/start session mới, phải có brainstorm artifact và mention đúng file path khi gọi plan.

/ck:plan --tdd

Recommend khi: Refactor, logic quan trọng, hoặc đã có test contract mạnh.

Kết quả: Cùng session: dùng context report vừa tạo. Session mới: gọi kèm path artifact.

/ck:plan

Recommend khi: Feature mới hoặc thay đổi tiêu chuẩn.

Kết quả: Plan triển khai theo phase từ brainstorm report.

End session

Recommend khi: Muốn plan sau hoặc bàn giao nơi khác.

Kết quả: Dừng sau report/journal.

Artifact tạo ra

Báo cáo tổng hợp Markdown

Brainstorm kết thúc bằng một file Markdown. File này là context chính để bàn giao sang /ck:plan.

1 file Markdown

Đường dẫn cụ thể

plans/reports/brainstorm-YYMMDD-HHMM-slug.md plans/reports/brainstorm-260524-1908-auth-approach.md

Nội dung report gồm

Đây là outline bên trong file report, không phải nhiều artifact riêng.

1 Mô tả vấn đề Vấn đề, mục tiêu, và bối cảnh repo đã scout.
2 Các hướng đánh giá 2-3 approach khả thi cùng trade-off chính.
3 Khuyến nghị cuối Hướng được chọn và lý do chọn.
4 Rủi ro triển khai Điểm dễ fail, dependency, hoặc assumption cần kiểm chứng.
5 Metrics thành công Tiêu chí biết giải pháp đã đúng và đủ.
6 Bước tiếp theo Cách bàn giao sang /ck:plan hoặc dừng lại.

Không bỏ qua design

Nguồn: SKILL.md / Anti-Rationalization

Các lý do thường nghe hợp lý nhưng bị SKILL.md chặn trước khi chuyển sang plan hoặc code.

1

Suy nghĩ

Việc này quá đơn giản, khỏi cần design

Thực tế

Việc nhỏ vẫn dễ phí thời gian khi assumptions bị ẩn.

2

Suy nghĩ

Tôi biết giải pháp rồi

Thực tế

Vậy viết ra rất nhanh. Design bằng chữ là checkpoint để cùng hiểu đúng.

3

Suy nghĩ

User muốn làm ngay, không muốn nói nhiều

Thực tế

Làm sai tốn thời gian hơn một vòng planning ngắn nhưng đúng.

4

Suy nghĩ

Cứ explore code trước đã

Thực tế

Brainstorm quyết định cần explore theo hướng nào. Follow process trước.

5

Suy nghĩ

Prototype nhanh thôi

Thực tế

Prototype thường thành production code. Design trước.

Quick Ref / Planning command

Sau brainstorm / khi scope đã rõ

/ck:plan

Dùng khi brief đã đủ rõ và cần tách thành phases, bước kiểm chứng, và lệnh bàn giao cho /ck:cook.

handoff

/ck:cook {absolute-path}

01

Brief rõ

02

Plan phases

03

Validate / red-team

04

/ck:cook

Không triển khai

Chỉ tạo plan và phase files.

CLI quản lý

Tạo và đổi trạng thái bằng ck plan.

ck plan Tham chiếu CLI

Bàn giao rõ

Kết thúc bằng validate, red-team, cook, hoặc dừng.

Execution map

Bốn lane chính: định vị scope, nghiên cứu, kiểm chứng, rồi bàn giao.

01 -> 11

01

Định vị

Chốt context trước khi plan

1 Kiểm tra Kiểm tra Plan Context: active / suggested / none
2 Quét chéo Quét plans dang dở, phát hiện blockedBy/blocks
3 Phạm vi Scope Challenge (bỏ nếu --fast hoặc trivial)
4 Chế độ Tự động phát hiện hoặc flag rõ ràng

02

Nghiên cứu

Lấy đủ bằng chứng

5 Nghiên cứu Spawn researcher agents (bỏ trong fast)
6 Phân tích Đọc docs, scout codebase nếu cũ
7 Lập kế hoạch Planner viết plan.md + phase files qua ck CLI

03

Kiểm chứng

Tìm điểm gãy sớm

8 Red Team Review đối kháng (2-4 reviewers)
9 Xác thực Verification pass + câu hỏi quan trọng

04

Bàn giao

Đưa plan vào cook

10 Hydrate Tạo Claude Tasks cho mỗi phase + bước quan trọng
11 Bàn giao Nhắc boundary → AskUser: validate/red-team/cook/end

Mode nên dùng

Bắt đầu với auto. Chỉ nâng mode khi scope hoặc rủi ro thật sự cần.

--auto Tự động

Research: Follows mode
Red-team: Follows mode
Validate: Follows mode
Cook: Follows mode

Prompt mẫu

/ck:plan Thiết kế lại luồng checkout để giảm lỗi thanh toán

Dùng khi

Brief đã đủ rõ, nhưng chưa chắc nên dùng fast, hard hay deep.

Kết quả

Agent tự chọn mức research, validate, red-team theo rủi ro.

--fast Nhanh

Research: Skip
Red-team: Skip
Validate: Skip
Cook: —

Prompt mẫu

/ck:plan --fast Đổi text CTA trong Pricing section

Dùng khi

Việc nhỏ, ít dependency, rollback dễ.

Kết quả

Ra plan nhanh, bỏ research/red-team/validate nặng.

--hard Khó

Research: 2 researchers
Red-team: Yes
Validate: Optional
Cook: —

Prompt mẫu

/ck:plan --hard Refactor auth flow nhưng giữ backward compatibility

Dùng khi

Nhiều ràng buộc kỹ thuật, nhưng chưa cần deep theo từng phase.

Kết quả

Có research và red-team để bắt rủi ro kiến trúc sớm.

--deep Sâu

Research: 2-3 + per-phase scout
Red-team: Yes
Validate: Yes
Cook: —

Prompt mẫu

/ck:plan --deep Tách billing module thành subscription, invoice, webhook

Dùng khi

Refactor lớn, nhiều dependency, tác động nhiều module.

Kết quả

Research sâu hơn, validate rõ hơn, phase có bằng chứng hơn.

--parallel Song song

Research: 2 researchers
Red-team: Yes
Validate: Optional
Cook: --parallel

Prompt mẫu

/ck:plan --parallel Tối ưu dashboard loading và chart rendering

Dùng khi

Có thể chia thành nhiều nhánh độc lập chạy song song.

Kết quả

Plan giữ boundary rõ để handoff sang cook với --parallel.

--two Hai hướng

Research: 2+ researchers
Red-team: After select
Validate: After select
Cook: —

Prompt mẫu

/ck:plan --two Chọn kiến trúc sync dữ liệu offline-first

Dùng khi

Cần so sánh hai hướng tiếp cận trước khi chốt plan.

Kết quả

Hai phương án được phân tích trước, rồi mới chọn hướng triển khai.

Flags thêm

Kết hợp với mode để đổi cách plan tạo test hoặc task.

--tdd

Tests-first mỗi phase

Composable flag: thêm cấu trúc tests-first vào từng phase.

Prompt mẫu

/ck:plan --deep --tdd Refactor billing module

Dùng khi

--deep --tdd là combo chính cho major refactor hoặc logic có contract quan trọng.

--no-tasks

Bỏ task hydration

Không tạo Claude Tasks sau khi plan xong.

Prompt mẫu

/ck:plan --fast --no-tasks Cập nhật copy trang guide

Dùng khi

Hợp với plan nhỏ hoặc docs-only, khi chưa muốn sinh task phụ.

Compose với mode

--tdd kết hợp được với mọi mode, nhưng chọn mode theo scope trước.

--hard --tdd

Complex, cần research

Khi task phức tạp nhưng chưa phải major refactor nhiều area.

--deep --tdd Recommended

Recommended cho risky refactor

Dùng khi refactor lớn, 5+ areas, architectural debt, hoặc cần per-phase scouting.

--parallel --tdd

Niche: song song + tests-first

Chỉ dùng khi có nhiều workstream độc lập và mỗi lane vẫn cần test gate.

Guide Đọc thêm: khi nào dùng --deep và --tdd Mở bài giải thích khi nào nên tăng độ sâu plan hoặc buộc tests-first. --deep --tdd →

Quick Ref / Implementation command

Sau /ck:plan hoặc feature brief

/ck:cook

Dùng khi đã có plan hoặc cần biến feature brief thành code. Scout trước, chốt 5 requirement, plan-gate, implement, test, review, rồi sync plan/docs/git/journal.

01

Plan path / brief

02

Scout + reqs

03

Code + test

04

Review + sync

Plan-first

Kể cả việc nhỏ: review plan trước khi code.

Scout-first

Tóm tắt repo 3-6 bullet trước mọi AskUser.

No side effects

Acceptance, tests, contracts, lint/type/build đều phải sạch.

Execution map

Bốn lane: định vị intent, lập plan có bằng chứng, implement/test, rồi review + sync lại artifacts.

01

Định vị

Mode, scout, requirements

1 Ý định Phát hiện mode từ input (plan path / từ khóa / flag rõ ràng)
2 Khảo sát BẮT BUỘC scan codebase: loại dự án, modules, patterns, docs, plans, contracts (chỉ bỏ khi có plan path)
3 Tóm tắt 3-6 gạch đầu dòng tóm tắt codebase cho user trước mọi câu hỏi làm rõ
4 Yêu cầu AskUser lặp — 5 mục chính xác: output, acceptance, scope, ràng buộc, touchpoints

02

Lập plan

Research + plan review

5 Nghiên cứu researcher agent (bỏ ở --fast / code mode) → Review Gate
6 Lập kế hoạch planner agent → plan.md + phase-XX files → Review Gate

03

Build

Implement, simplify, test

7 Triển khai Thực thi tasks theo phase; simplify có điều kiện qua code-simplifier
8 Test tester + debugger agents, 100% pass (bỏ nếu --no-test) → Review Gate

04

Đóng

Review, sync, journal

9 Review code-reviewer agent — 5 kiểm tra (acceptance, regression, contracts, patterns, lint/type/build); STOP qua AskUser nếu có side effect
10 Hoàn tất /ck:project-management đồng bộ plan → docs-manager → git-manager → /ck:journal

Mode nên dùng

Interactive là mặc định. Dùng flag khi cần rút ngắn research, tự duyệt, chạy song song, hoặc thực thi plan path có sẵn.

plan path

Code mode

Bỏ scout/research/plan, thực thi phase files có sẵn.

Lệnh mẫu

/ck:cook /abs/plans/260524-auth/plan.md

Dùng khi: Plan đã được review hoặc được bàn giao từ /ck:plan.

Kết quả: Đọc phase files, implement từng phase, test/review/finalize.

--fast

Fast

Bỏ research nặng nhưng vẫn phải scout -> plan -> code.

Lệnh mẫu

/ck:cook --fast Đổi copy CTA trên Pricing

Dùng khi: Scope nhỏ, rollback dễ, dependency ít.

Kết quả: Plan ngắn, user gate vẫn giữ trước code.

--auto

Auto

Tự approve work low-risk khi artifact + validator pass; high-risk vẫn dừng để user duyệt trước finalize/commit/ship.

Lệnh mẫu

/ck:cook --auto Thêm cache cho endpoint stats

Dùng khi: Bạn tin agent, risk thấp, acceptance rõ.

Kết quả: Chạy liên tục các phase low-risk, vẫn test/review; score chỉ tham khảo, không tự approve.

--parallel

Parallel

Nhiều feature độc lập được chia thành lane riêng.

Lệnh mẫu

/ck:cook --parallel Implement search, filters, export CSV

Dùng khi: 3+ workstream có file ownership rõ.

Kết quả: Multi-agent theo lane, merge qua review gates.

Prompt mẫu

Plan path Recommended

/ck:cook /abs/plans/260524-auth/plan.md

Dùng khi: Đã có plan.md và phase files.

Kết quả: Dùng context trong plan, không hỏi lại từ đầu.

Feature brief

/ck:cook Thêm email/password login với httpOnly session

Dùng khi: Chưa có plan nhưng output mong muốn rõ.

Kết quả: Scout -> 5 requirements -> research/plan -> implement.

--tdd

/ck:cook --tdd Refactor billing calculation giữ behavior hiện tại

Dùng khi: Refactor hoặc logic quan trọng.

Kết quả: Tests cho behavior hiện tại trước, verify lại sau implement.

Artifact tạo ra

Triển khai hoàn tất

Commits + đồng bộ trạng thái plan + nhật ký

1

Code merge qua git-manager

2

Tests 100% pass

3

code-reviewer duyệt (không regression, contracts còn nguyên)

4

plan.md + tất cả phase-XX.md đồng bộ qua /ck:project-management

5

docs cập nhật

6

/ck:journal đã ghi

Shortcut bị chặn

1

Suy nghĩ

Việc này đơn giản, code luôn

Thực tế

Task đơn giản vẫn có hidden contracts. Plan mất ít hơn rewrite.

2

Suy nghĩ

Hỏi user trước khi đọc repo

Thực tế

AskUser options phải dựa trên scout findings, không hỏi chung chung.

3

Suy nghĩ

Tests pass là xong

Thực tế

Còn phải walk touchpoints, contracts, lint/type/build và code-review.

Quick Ref / Review command

Sau /ck:cook hoặc /ck:fix, trước /ck:ship

/ck:code-review

Dùng khi cần review code với rigor đối kháng. Resolve input mode, qua spec compliance gate, scout edge case, code-reviewer sub-agent, rồi adversarial red-team chủ động phá code trước khi verify + report.

01

Input + diff

02

Spec gate

03

Quality + scout

04

Adversarial + report

Spec-first gate

Stage 1 phải pass — không bỏ qua sang Stage 2 khi spec chưa khớp.

Adversarial always-on

Stage 3 red-team chạy mọi lần. Scope gate chỉ miễn trivial.

Bằng chứng mới

Không claim done nếu chưa rerun tests/build với output mới.

Review map

Bốn lane: xác định input + diff, qua spec gate, quality review với scout, rồi adversarial red-team + verify + report.

01

Resolve

Input mode + diff acquisition

1 Xác định Input Tự nhận diện mode từ argument: #PR | commit | --pending | codebase | codebase parallel. Nếu mơ hồ, AskUserQuestion để chọn review target.
2 Lấy Diff Main agent lấy diff: gh pr diff #N · git show <sha> · git diff (staged + unstaged) · quét toàn bộ codebase. Không sub-agent ở bước này.

02

Spec gate

Stage 1 — code khớp plan/spec?

3 Stage 1: Spec Compliance HARD GATE — main agent xác minh code khớp plan/spec. Thiếu requirements? Có extras vô lý (YAGNI)? PASS → Stage 2 | FAIL → fix → chạy lại Stage 1.

03

Quality

Scout edge case + Stage 2 code-reviewer

4 Scout Edge Case Gọi /ck:scout tập trung edge case — 2-6 Explore sub-agent song song quét data flows, error paths, boundary conditions. Findings nuôi Stage 2.
5 Stage 2: Code Quality code-reviewer sub-agent — standards, security, performance, edge case từ scout. Với 3+ files: parallel scoped reviewer (vd backend + frontend).

04

Adversarial + Prove

Stage 3 red-team, verify, report

6 Stage 3: Adversarial Adversarial reviewer sub-agent (red team) chủ động phá code — security holes, false assumptions, race conditions, resource exhaustion, supply chain. Verdict: Accept / Reject / Defer.
7 Verification Gate IRON LAW — chạy build + tests, đọc output, xác nhận 0 failures với bằng chứng MỚI trước khi claim hoàn thành. Không "should" / "probably" / "seems to".
8 Report Review Findings nhóm theo severity (Critical / Important / Minor) với verdict từng finding. Recommendation: APPROVE | REQUEST CHANGES | BLOCK. Critical → chặn merge.

Input mode

Input mode quyết định target review. Pick một mode — agent auto-detect từ argument, hoặc AskUserQuestion nếu mơ hồ. Code-review không có "fast/auto" flag, mọi mode đều qua đủ 3 stage.

#123

PR mode

Fetch full PR diff qua gh pr diff #N.

Lệnh mẫu

/ck:code-review #123

Dùng khi: Review một PR đã mở trên GitHub.

Kết quả: Diff toàn bộ PR → 3-stage review → recommendation APPROVE / REQUEST CHANGES / BLOCK.

--pending

Pending

Review staged + unstaged changes trong working tree.

Lệnh mẫu

/ck:code-review --pending

Dùng khi: Trước commit, sau khi /ck:cook hoặc /ck:fix xong.

Kết quả: git diff (staged + unstaged) → 3-stage review → findings inline.

abc1234

Commit

Review một commit cụ thể qua git show <sha>.

Lệnh mẫu

/ck:code-review abc1234

Dùng khi: Audit commit cũ, post-mortem regression.

Kết quả: Diff đúng commit đó → 3-stage review tập trung phạm vi commit.

codebase parallel

Codebase parallel

Ultrathink edge case, rồi spawn nhiều adversarial reviewer song song.

Lệnh mẫu

/ck:code-review codebase parallel

Dùng khi: Audit sâu — security review, hardening trước launch.

Kết quả: Nhiều reviewer scope khác nhau, dedupe + prioritize theo severity.

Prompt mẫu

Pending Recommended

/ck:code-review --pending

Dùng khi: Vừa làm xong /ck:cook hoặc /ck:fix, chưa commit.

Kết quả: Review tất cả staged + unstaged trước khi commit / ship.

PR review

/ck:code-review #42

Dùng khi: PR đã mở, cần adversarial review trước merge.

Kết quả: Findings nhóm theo severity + verdict cho từng item.

Codebase audit

/ck:code-review codebase parallel

Dùng khi: Pre-launch hoặc security audit toàn project.

Kết quả: Nhiều reviewer scope khác nhau, severity-dedupe trong report.

Artifact tạo ra

Báo cáo Adversarial Review

Findings nhóm theo severity (Critical / Important / Minor) + verdict từng finding + recommendation merge

1

Mỗi finding: mô tả, file:line, severity, verdict (Accept / Reject / Defer)

2

Critical → CHẶN merge

3

Deferred → GitHub issue

4

Recommendation: APPROVE | REQUEST CHANGES | BLOCK

5

Verification gate (tests + build) PHẢI pass trước khi report finalize

Shortcut bị chặn

1

Suy nghĩ

Code compile được là review pass

Thực tế

Stage 1 spec compliance phải verify intent khớp plan/spec — compile không nói lên gì cả.

2

Suy nghĩ

Diff nhỏ, skim qua là được

Thực tế

Adversarial Stage 3 vẫn bắt buộc trừ khi đúng scope gate (≤2 files, ≤30 lines, không security).

3

Suy nghĩ

Tests pass nghĩa là an toàn merge

Thực tế

Critical findings vẫn chặn merge. Cần fresh evidence cho cả build + tests, không tin "should/probably".

Quick Ref / Fix command

Bug, CI đỏ, regression, production issue

/ck:fix

Dùng khi có lỗi cần sửa bằng bằng chứng. Chọn mode, scout trước, diagnose root cause, sửa đúng nguyên nhân, verify/prevent, review, rồi finalize.

01

Mode

02

Scout + diagnose

03

Root-cause fix

04

Verify + prevent

Root cause first

Không sửa symptom, không probably.

Exact repro

Lưu lỗi pre-fix và chạy lại đúng lệnh.

Prevention

Regression test, blast-radius, guard để lỗi không lặp lại.

Execution map

Bốn lane: mode/scout, diagnose root cause, fix đúng điểm, rồi verify/prevent + finalize.

01

Khởi động

Mode + scout evidence

0 Chế độ AskUser: Autonomous (mặc định) · Review · Quick · Parallel — hoặc truyền --auto/--review/--quick/--parallel
1 Khảo sát BẮT BUỘC — ck:scout hoặc 2-3 Explore song song: file ảnh hưởng, deps, tests, git log, patterns

02

Chẩn đoán

RCA có file:line

2 Chẩn đoán BẮT BUỘC — ck:debug + ck:sequential-thinking, capture pre-fix state, RCA dựa bằng chứng, không đoán
3 Định tuyến Phân loại Simple/Moderate/Complex/Parallel → workflow + chuỗi TaskCreate dependency (Moderate+)

03

Sửa

Đúng nguyên nhân gốc

4 Sửa Triển khai sửa NGUYÊN NHÂN GỐC — thay đổi tối thiểu, theo pattern hiện có

04

Chứng minh

Verify, prevent, finalize

5 Xác minh + Phòng ngừa BẮT BUỘC — chạy lại đúng repro pre-fix, regression test, quét blast-radius, code-reviewer delegate, artifact gate (workflow-artifact-gate.cjs --stage finalize), prevention gate, song song typecheck/lint/build/test
6 Hoàn tất Chuỗi BẮT BUỘC: /ck:project-management → docs-manager → TaskUpdate completed → git-manager (AskUser commit) → /ck:journal

Mode nên dùng

Autonomous là mặc định. Dùng review khi high-risk, quick chỉ cho lint/type nhỏ, parallel khi có nhiều issue độc lập.

--auto

Autonomous

Tự approve chỉ khi artifact + validator pass.

Lệnh mẫu

/ck:fix --auto login button returns 500

Dùng khi: Bug rõ, risk vừa/thấp, acceptance dễ verify.

Kết quả: Vẫn scout/diagnose/review đầy đủ trước finalize.

--review

Human review

Dừng ở mỗi step để user duyệt.

Lệnh mẫu

/ck:fix --review webhook duplicate charge

Dùng khi: Production, billing, auth, data loss, hoặc public contract.

Kết quả: Pause sau diagnosis/fix/verify với findings rõ.

--quick

Quick

Scout -> diagnose -> fix -> review nhẹ.

Lệnh mẫu

/ck:fix --quick TypeScript error in pricing card

Dùng khi: Trivial lint/type/single-file issue.

Kết quả: Nhanh hơn nhưng không bỏ root-cause check.

--parallel

Parallel

Mỗi issue độc lập một fullstack-developer lane.

Lệnh mẫu

/ck:fix --parallel checkout errors and dashboard chart crash

Dùng khi: 2+ lỗi độc lập, touchpoints tách nhau.

Kết quả: Task tree riêng, conflict được main agent surface.

Prompt mẫu

Standard bug Recommended

/ck:fix Login submit trả 500 trong local dev

Dùng khi: Cần agent tự chọn mode và scout repo.

Kết quả: Mode -> Scout -> Diagnose -> Root cause fix -> Verify.

High risk

/ck:fix --review Payment webhook double-charges paid orders

Dùng khi: Muốn dừng user gate ở mỗi step.

Kết quả: Không finalize/commit trước khi user duyệt.

CI failure

/ck:fix --quick npm run build fails after latest merge

Dùng khi: Lỗi build/type/lint có dấu hiệu nhỏ.

Kết quả: Fix nhanh nhưng vẫn rerun exact failing command.

Artifact tạo ra

Báo cáo sửa lỗi

Step markers + điểm confidence + nhật ký kỹ thuật

1

Root cause kèm file:line

2

Fix đúng đích

3

Regression test thêm

4

Quét blast-radius

5

Prevention guard đặt chỗ

6

Plan/task đồng bộ

7

Docs cập nhật

8

Nhật ký ghi lại

Shortcut bị chặn

1

Suy nghĩ

Tôi thấy lỗi rồi, sửa luôn

Thực tế

Thấy symptom không bằng hiểu root cause. Scout + diagnose trước.

2

Suy nghĩ

Thử đổi X xem sao

Thực tế

Random fix tạo bug mới. Phải có evidence chain.

3

Suy nghĩ

Fix xong, tests pass

Thực tế

Phải có prevention gate để bug class không lặp lại.

Quick Ref / Team orchestration

Parallel multi-session

/ck:team

Dùng khi cần spawn N teammate Claude Code song song với context window riêng — research từ nhiều góc, cook nhiều file, review nhiều focus, hoặc debug nhiều giả thuyết cạnh tranh.

01

Invoke

02

Pre-flight

03

Spawn N

04

Synth + close

Execution map

Bốn lane: setup pre-flight, spawn song song, điều phối qua hook + DM, rồi tổng hợp và đóng.

01 -> 07

01

Setup

Invoke + pre-flight check

1 Gọi /ck:team <template> <context> [flags] — chọn research / cook / review / debug + flag tuỳ chọn --devs/--researchers/--reviewers/--debuggers N, --delegate, --worktree
2 Tiền kiểm BẮT BUỘC — gọi thẳng TeamCreate(team_name); success thì tiếp, error thì ABORT (không fallback subagent). Env flag + CLI terminal + Opus 4.6 đều phải đúng

02

Spawn

Tách N + spawn song song

3 Tách N Tách input thành N work item độc lập (mặc định N=3) — angles (research) / task có file ownership + tester blocker (cook) / focuses (review) / giả thuyết cạnh tranh (debug). TaskCreate × N
4 Spawn Agent tool × N song song — model: opus, run_in_background: true, isolation: worktree (chỉ cho cook dev). Mỗi prompt có CK Context Block bắt buộc

03

Điều phối

Hook + DM giữa teammate

5 Điều phối Phản ứng theo hook TaskCompleted / TeammateIdle (fallback 60s qua TaskList). Teammate DM nhau qua SendMessage — adversarial trong debug, routed qua lead trong cook

04

Đóng

Synthesize + shutdown

6 Tổng hợp Lead đọc mọi report. research → research-summary-<slug>.md. cook → git merge --no-ff branch worktree tuần tự + BẮT BUỘC eval Docs impact. review → dedupe + ưu tiên CRITICAL/IMPORTANT/MODERATE. debug → giả thuyết còn sống = root cause
7 Đóng SendMessage(shutdown_request) × N → TeamDelete (KHÔNG params) → /ck:journal → báo user. Agent memory ở $HOME/.claude/agent-memory/<name>/ tồn tại độc lập

Templates

Chọn template theo nhu cầu. Mỗi template có default N teammate, behaviour riêng và artifact riêng.

research Mặc định N: 3

Research nhiều góc

Prompt mẫu

/ck:team research So sánh các hướng auth cho SaaS app

Dùng khi

Quyết định kiến trúc, đánh giá công nghệ, khảo sát đa góc.

Output

research-summary-<slug>.md — exec summary, comparative analysis, recommendations.

cook Mặc định N: 4 devs + 1 tester

Cook với dev có file ownership

Prompt mẫu

/ck:team cook plans/.../plan.md --devs 4 --worktree

Dùng khi

Triển khai feature nhiều file với dev song song trong worktree riêng.

Output

Branch merge qua git merge --no-ff + BẮT BUỘC eval docs sync + kết quả test.

review Mặc định N: 3

Review nhiều focus

Prompt mẫu

/ck:team review src/api --reviewers 3

Dùng khi

Review trước merge với lane song song: security, performance, test coverage.

Output

review-<slug>.md — dedupe theo severity (CRITICAL / IMPORTANT / MODERATE) + action items.

debug Mặc định N: 3

Debug giả thuyết cạnh tranh

Prompt mẫu

/ck:team debug "Webhook trả 500 không liên tục" --debuggers 3

Dùng khi

Bug khó reproduce, muốn dùng disproof đối kháng để hội tụ về root cause.

Output

debug-<slug>.md — root cause + evidence chain + giả thuyết đã disproven.

Artifact theo template

Report theo Template

Lead tổng hợp report sau khi mọi teammate xong. Đường dẫn cố định ở plans/reports/.

plans/reports/

research-summary / cook merge+docs / review-<slug> / debug-<slug>.md

Nguyên tắc bắt buộc

Năm điều này áp dụng cho mọi template — vi phạm = team không chạy đúng.

1 TeamCreate-first — KHÔNG fallback subagent khi fail
2 File ownership boundaries — dev không được trùng nhau trong cook tasks
3 CK Context Block trong MỌI spawn prompt — teammate cần để tìm reports/plans
4 Gọi teammate bằng NAME (không phải agent ID) ở field recipient + owner
5 Adversarial trong debug — để các giả thuyết cạnh tranh hội tụ bằng mutual disproof

Quick Ref / Visual utility

Read-only · không sửa code

/ck:preview

Xem file hoặc tạo giải thích trực quan, sơ đồ, và slide deck — trên browser hoặc dưới dạng trang HTML độc lập. Utility đọc/trực quan hóa, không sửa code.

01

Input

02

Định tuyến

03

Tạo

04

Output

Luồng xử lý

Một input (file path hoặc generate flag + topic) chạy qua bốn chặng: nhận input, định tuyến, tạo visual, rồi xuất ra browser hoặc HTML độc lập.

01 -> 05

01

Nhận input

File path hoặc generate flag + topic

1 Đầu vào Một file path, hoặc generate flag + topic (thêm --html để có trang browser)
2 Plan Context Hook inject plan active — visuals lưu vào {plan_dir}/visuals/ (fallback plans/visuals/)

02

Định tuyến + tạo

Chọn dạng, dựng prose + ASCII + Mermaid

3 Định tuyến Path → file preview/walkthrough · Topic → chọn explain/diagram/slides/ascii
4 Tạo Dựng prose + ASCII + Mermaid (cú pháp mermaidjs-v11); tech-graph cho SVG/PNG cấp publish

03

Xuất

Browser live hoặc HTML độc lập

5 Kết quả Markdown tự mở trên browser (Mermaid live) · --html = trang độc lập dễ chia sẻ

Cách dùng theo vai trò

View (không flag) nhận path để đọc/walkthrough file. Tám flag chia ba nhóm: Generate chọn dạng output từ topic; --html bọc bất kỳ generate flag nào thành trang độc lập; nhóm Review bắt buộc đi kèm --html.

View · không flag

Đọc file/thư mục có sẵn — plan dạng novel

<file.md>
Xem một file markdown (plan, phase, doc) trong novel-reader UI — Mermaid render trực tiếp.

Prompt mẫu
/ck:preview plans/.../plan.md
<dir/>
Truyền một thư mục để duyệt mọi doc bên trong — vd cả thư mục plan (plan.md + tất cả phase file).

Prompt mẫu
/ck:preview plans/260527-.../
<path>
View đọc file nguyên trạng. Khác với generate flag (--explain / --diagram / --slides / --ascii): chúng nhận topic mô tả bằng lời để dựng visual mới — không đọc path.

Prompt mẫu
/ck:preview src/auth/middleware.ts

Tạo

Chọn một dạng output từ topic

--explain
Giải thích trực quan code hoặc concept — narrative + ASCII + sơ đồ Mermaid

Prompt mẫu
/ck:preview --explain "luồng auth middleware"
--diagram
Sơ đồ kiến trúc và data-flow

Prompt mẫu
/ck:preview --diagram "vòng đời request"
--slides
Walkthrough từng bước dạng slide deck

Prompt mẫu
/ck:preview --slides "luồng onboarding"
--ascii
Sơ đồ ASCII thân thiện terminal (không cần browser)

Prompt mẫu
/ck:preview --ascii "cấu trúc thư mục"

Xuất

Kết hợp với mọi generate flag

--html
Trang HTML độc lập — kết hợp với mọi generate flag, mở thẳng trên browser

Prompt mẫu
/ck:preview --html --diagram "schema DB"

Review · tự bật --html

View diff, plan-vs-code, và recap

--diff [ref]
Review diff trực quan các thay đổi (yêu cầu --html)

Prompt mẫu
/ck:preview --diff HEAD~3
--plan-review [plan-file]
So sánh plan file với codebase thực tế — tự bật --html. Bỏ path để dùng active plan.

Prompt mẫu
/ck:preview --plan-review plans/.../plan.md

Bỏ path → dùng plan active
/ck:preview --plan-review
--recap [timeframe]
Snapshot context project theo khoảng thời gian (yêu cầu --html)

Prompt mẫu
/ck:preview --recap "tuần trước"

Hình thức xuất

Chế độ nào cần local server, chế độ nào self-contained.

Local server

markdown-novel-viewer

View (file / thư mục)
Markdown generation

Self-contained

Không cần server — mở thẳng browser

--html + generate flag
Review (--diff / --plan-review / --recap)

Dừng server /ck:preview --stop

Output trực quan

Giải thích / sơ đồ / slides / ascii
Markdown tự mở với Mermaid live
--html dễ chia sẻ, không cần server
Diff / plan-review / recap tạo visual cấp review

Tên file: {slug}.md (browser) · {slug}.html (độc lập)
Vị trí lưu: Plan active {plan_dir}/visuals/
Fallback plans/visuals/

Nguyên tắc cốt lõi

Năm điều định hình cách preview hoạt động — luôn an toàn, luôn chia sẻ được.

1 Chỉ đọc/trực quan hóa — không sửa code
2 --html độc lập — mở trên mọi browser, không cần server
3 Markdown mode render Mermaid trực tiếp qua markdown-novel-viewer
4 Visuals nằm cùng thư mục plan active
5 Kết hợp ck:mermaidjs-v11 (cú pháp) và ck:tech-graph (cấp publish)

Xem tất cả lệnh ClaudeKit

Cách ClaudeKit Hoạt Động

1. Hooks (Hệ thống ngầm)

2. Skills (Kiến thức có sẵn)

3. Agents (Các chuyên gia)

4. Workflows (Quy trình)

Hướng dẫn sắp ra mắt...

Hướng dẫn sắp ra mắt...

Execution map

Prompt mẫu

Plan handoff

Artifact tạo ra

Không bỏ qua design

Execution map

Mode nên dùng

Flags thêm

Execution map

Mode nên dùng

Prompt mẫu

Artifact tạo ra

Shortcut bị chặn

Review map

Input mode

Prompt mẫu

Artifact tạo ra

Shortcut bị chặn

Execution map

Mode nên dùng

Prompt mẫu

Artifact tạo ra

Shortcut bị chặn

Execution map

Templates

Artifact theo template

Nguyên tắc bắt buộc

Luồng xử lý

Cách dùng theo vai trò

Hình thức xuất

Output trực quan

Nguyên tắc cốt lõi

Pipeline

Bạn đã sẵn sàng để trải nghiệm?