Fix — Sửa bug

Phân tích và sửa bug tự động. Tuân thủ nguyên tắc: tìm root cause TRƯỚC, fix SAU. Tự động detect loại bug và chọn strategy phù hợp.
Cập nhật bộ claudekit mới: Các lệnh /fix:test, /fix:ui, /fix:ci, /fix:types, /fix:hard, /fix:fast, /fix:logs, /fix:parallel đã bỏ. Thay bằng /fix (auto-route theo mô tả), /investigate (iron law: no fix without root cause), /verify (confirm fix works). Xem cấu trúc skill mới để biết đầy đủ.

Cú pháp


Luồng hoạt động bên trong

Khi bạn gõ /fix "API returns 500 when creating order", đây là 6 bước xảy ra:
1

Bước 1: Scout (BẮT BUỘC — không bao giờ skip)

Kích hoạt ck:scout skill HOẶC spawn 2-3 Explore subagents song song. Mục tiêu: hiểu codebase TRƯỚC khi đưa ra giả thuyết.
  • Tìm: affected files, dependencies, related tests, recent changes (git log)
  • Đọc ./docs nếu chưa quen project
Output: Step 1: Scouted — 12 files mapped, 5 dependencies, 3 tests found
2

Bước 2: Diagnose (BẮT BUỘC — không bao giờ skip)

Phân tích root cause có hệ thống. KHÔNG đoán.
  1. Ghi lại pre-fix state: error messages, failing test output, stack traces
  2. Kích hoạt ck-debug skill (systematic debugging + root cause tracing)
  3. Kích hoạt ck:sequential-thinking — hình thành giả thuyết qua lý luận
  4. Spawn Explore agents song song test từng giả thuyết
  5. Nếu 2+ giả thuyết sai → tự động kích hoạt ck:problem-solving
  6. Tạo diagnosis report: confirmed root cause, evidence chain
Output: Step 2: Diagnosed — Root cause: missing Site relation in Prisma include, Evidence: stack trace line 42
3

Bước 3: Complexity Assessment

Phân loại độ phức tạp trước khi chọn workflow:
4

Bước 4: Fix Implementation

Implement fix dựa trên diagnosis findings. Fix ROOT CAUSE, không fix triệu chứng. Minimal changes, follow patterns hiện có.
5

Bước 5: Verify + Prevent (BẮT BUỘC)

  1. Verify: Chạy ĐÚNG commands từ pre-fix state. So sánh output.
  2. Regression test: Thêm/update test cho issue vừa fix. Test PHẢI fail nếu bỏ fix.
  3. Prevention gate: Thêm defense-in-depth nếu applicable.
  4. Parallel verification: Typecheck + lint + build + test chạy song song.
Nếu verify fail → quay lại Bước 2. Sau 3 lần fail → question architecture, hỏi user.Output: Step 5: Verified — before: HTTP 500, after: HTTP 201, 2 tests added, 1 guard added
6

Bước 6: Finalize (BẮT BUỘC)

  1. Report summary: confidence score, root cause, changes, files, prevention
  2. docs-manager subagent cập nhật ./docs/
  3. Hỏi user commit qua git-manager subagent
  4. Viết journal entry
Hard Gate: KHÔNG được đề xuất hay implement fix trước khi hoàn thành Bước 1-2 (Scout + Diagnose). Fix triệu chứng là THẤT BẠI. Tìm root cause trước.

Ví dụ thực tế


So sánh với chat trực tiếp


Khi nào dùng / không dùng


Quy trình Fix chính

/fix "mô tả" — Intelligent Routing & Auto-Fix

Tự động detect loại bug từ mô tả, chạy scout + diagnose + fix + verify:
Skill auto-detects từ keywords:
  • type, typescript, error TS → TypeScript fix
  • ui, layout, responsive, css → UI/CSS fix
  • github actions, ci/cd, build failed → CI/CD analysis + fix
  • test, jest, failing test → Test fix
  • logs, error logs, stack trace → Log analysis + fix
  • race condition, concurrent, complex → Deep analysis + brainstorm
  • Default → Auto-detect based on codebase context
Output: Root cause → fix applied → tests pass → verified.

/investigate "mô tả" — Iron Law: Find Root Cause FIRST

Phá vỡ assumption, tìm root cause trước khi fix bất kỳ thứ gì.
  • Bắt buộc scout (understand codebase)
  • Bắt buộc diagnose (find evidence chain)
  • NO fix until root cause confirmed
Output: Diagnosis report + evidence + confirmed root cause (không fix code). Khi dùng: Khi bạn không chắc nguyên nhân, cần deep understanding trước khi fix.

/verify — Confirm Fix Works

Chạy tests, typecheck, linting, build → xác nhận fix không gây lỗi mới:
Output: Test results + linting + type check + before/after comparison. Khi dùng: Sau khi /fix hoặc manual fix, cần xác nhận không gây regression.

Lưu ý & Best Practices

Sai lầm phổ biến:
  • Fix triệu chứng thay vì root cause → bug quay lại tuần sau
  • Không viết regression test → same bug tái phát khi refactor
  • Skip /investigate cho bugs phức tạp → fix sai hướng
  • Không chạy /verify sau khi fix → regression bugs lọt vào production
Tips từ team:
  • Bugs phức tạp? Dùng /investigate TRƯỚC /fix
  • Luôn kết thúc bằng /verify — xác nhận fix không gây lỗi mới
  • Viết test reproduce bug — đảm bảo fix đúng chỗ
  • Nếu bug quay lại → dùng /investigate để tìm root cause thực sự
→ Xem thêm: Best Practices tổng hợp

Quy trình fix khuyên dùng

1

Investigate (nếu nghi ngờ root cause)

Tìm root cause trước (bắt buộc với bugs phức tạp).
2

Fix

Skill auto-routes dựa trên mô tả, diagnose, và fix.
3

Verify

Chạy tests, typecheck, linting → xác nhận không regression.

Chi tiết lệnh Fix (Accordion)

Prefix: /fix "bug description"Tự động detect loại bug từ mô tả, chạy scout → diagnose → fix → verify. Không bao giờ fix mà không biết root cause.
Skill auto-detects từ keywords và codebase context:
  • TypeScript errors → typecheck + fix type definitions
  • UI/layout issues → CSS analysis + responsive fix
  • CI/CD failures → GitHub Actions logs analysis
  • Test failures → test code + source code diagnosis
  • Performance → profiling + optimization
  • Complex bugs → deep analysis + architecture review
Output: Root cause → fixed code → tests pass → verified.Khi dùng: Bất kỳ bug nào. Default choice.
Prefix: /investigate "bug description"Phá vỡ assumptions, tìm confirmed root cause không implement fix.
  • Bắt buộc scout (hiểu codebase)
  • Bắt buộc diagnose (tìm evidence chain)
  • Report root cause + evidence
Output: Detailed diagnosis report + root cause + evidence (NO code changes).Khi dùng:
  • Bugs phức tạp, không chắc root cause
  • Cần deep understanding trước fix
  • Multiple hypotheses, need evidence-based confirmation
Prefix: /verifyChạy tests, typecheck, linting, build → so sánh before/after.
Output:
  • Test results (number passed/failed)
  • Type check: strict mode pass?
  • Linting: warnings/errors?
  • Build: successful?
  • Regression check: new failures introduced?
Khi dùng: Sau /fix hoặc manual code changes, xác nhận không gây regression.