Vượt qua bài toán khó với ak:problem-solving

Dùng ak:problem-solving khi tiến độ bị chặn bởi complexity, cách nghĩ thông thường, pattern lặp lại, assumption ẩn hoặc bất định về scale. Skill chọn một kỹ thuật reasoning tập trung, áp dụng có hệ thống và ghi insight bạn có thể xác minh trước planning hay implementation.

Chọn ak:problem-solving khi bạn thực sự bị kẹt

Dùng ak:problem-solving khi

• Behavior tương tự đã tích lũy nhiều implementation hoặc special case.
• Approach quen thuộc không đủ và bạn cần framing mới.
• Cùng một problem shape xuất hiện ở nhiều phần của hệ thống.
• Solution đề xuất phụ thuộc một “must” chưa được chất vấn.
• Production limit, edge case hoặc scale behavior còn chưa rõ.
• Bạn không biết kỹ thuật reframing nào phù hợp obstacle.

Chọn workflow khác khi

• Code hỏng, test fail hoặc behavior sai. Dùng workflow debug hay fix để chứng minh root cause.
• Bạn cần repository fact hoặc file location. Dùng ak:scout.
• Bạn cần delivery contract đã chấp nhận hoặc so sánh implementation approach. Dùng ak:brainstorm.
• Bạn cần implementation plan theo phase. Dùng ak:plan.
• Bạn đã biết correction và muốn implementation. Dùng ak:cook.

Chuẩn bị project và runtime

Trước khi bắt đầu:

• Hoàn thành Làm quen và xác nhận Engineer Kit đã được cài cho runtime cùng scope đang dùng.
• Mô tả obstacle chính xác, không chỉ desired solution.
• Nêu điều đã thử, bằng chứng đã loại bỏ nó và constraint được cho là cố định.
• Cung cấp representative example, scale assumption hoặc repeated case khi chúng là trung tâm vấn đề.
• Giữ project evidence liên quan khả dụng để kiểm tra insight được tạo ra.

Chạy Skill

/ak:problem-solving "Draft persistence has four storage paths, each with different retry and cleanup rules. Every new editor state adds another branch. Find a simpler model without changing the stored document format."

/ak:problem-solving "Draft persistence has four storage paths, each with different retry and cleanup rules. Every new editor state adds another branch. Find a simpler model without changing the stored document format."

$ak:problem-solving "Draft persistence has four storage paths, each with different retry and cleanup rules. Every new editor state adds another branch. Find a simpler model without changing the stored document format."

Skill nhận một problem description và dispatch theo symptom. Skill không có mode flag được công bố.

Khớp obstacle với kỹ thuật

Có thể kết hợp kỹ thuật sau một lần thử tập trung. Sequence hữu ích gồm tìm recurring pattern trước khi simplify, hoặc kiểm tra inverted model ở scale.

Mô tả problem rõ ràng

Input hữu ích cung cấp:

• Symptom: dạng stuckness cụ thể.
• Current model: hệ thống hoặc decision hiện hoạt động thế nào.
• Evidence: example, measurement, failed attempt hoặc repeated case.
• Constraints: điều đã được chứng minh cố định và điều mới chỉ là assumption.
• Success test: observation chứng minh reframing hữu ích.

Với ví dụ draft, hãy liệt kê bốn path, lifecycle chung, branch tiếp tục tăng, compatibility requirement hiện có và test cho thấy một abstraction có xử lý mọi case hiện tại không.

Hiểu điều gì xảy ra trong một lần chạy

1. Skill phân loại obstacle. Skill khớp concrete symptom với một kỹ thuật chính thay vì áp dụng mọi framework cùng lúc.
2. Skill tải phương pháp tập trung. Skill chỉ dùng detailed guidance cần cho kỹ thuật đã chọn.
3. Skill áp dụng phương pháp. Skill inventory variant, ép metaphor, abstract repeated shape, đảo assumption hoặc test scale extreme theo phương pháp.
4. Skill kiểm tra boundary. Skill xác định nơi insight đề xuất không phù hợp và phân biệt reframing hữu ích khỏi analogy không an toàn hoặc trang trí.
5. Skill ghi điều có và không hiệu quả. Skill nêu insight, bằng chứng còn cần và lý do direction bị loại không đứng vững.
6. Skill chỉ kết hợp khi cần. Nếu phương pháp đầu không giải quyết obstacle, Skill chọn kỹ thuật bổ sung hoặc đề nghị problem nhỏ hơn, góc nhìn mới hay workflow khác.

Giữ quyền phê duyệt và an toàn ở bạn

Các boundary quan trọng:

• Metaphor chỉ hữu ích ở nơi behavior map với hệ thống thật; Skill phải xác định nơi nó hỏng.
• Inverted assumption bị loại khi tạo điều kiện không an toàn, như tin input chưa validate.
• Scale game là reasoning exercise trừ khi có measurement hoặc load test thực. “Lớn hơn một nghìn lần” tự nó không phải performance evidence.
• Simplification chỉ hợp lệ khi mọi current case bắt buộc fit rõ và acceptance behavior giữ nguyên.
• Skill không nên sửa product code hoặc biến insight thành implementation nếu chưa có workflow được duyệt riêng.
• Workflow theo source không cần external provider, credential, cost hay publication.

Xác minh kết quả

Kết quả hoàn tất nên cung cấp:

• Stuck type đã xác định cùng kỹ thuật được chọn.
• Evidence cùng assumption dùng khi reframing.
• Application từng bước của kỹ thuật ở abstraction level hữu ích.
• Một hoặc nhiều candidate insight với failure boundary rõ.
• Record các direction đã thử nhưng không đứng vững.
• Check cụ thể cần để validate insight mạnh nhất.
• Next workflow đề xuất: thêm evidence, debugging, brainstorming, planning hoặc implementation.

Chỉ coi insight sẵn sàng cho planning khi nó giải thích observed case, tôn trọng confirmed constraint và có validation method giới hạn.

Xử lý sự cố hoặc tiếp tục

Tiếp tục với ak:brainstorm để so sánh cause-aligned approach hoặc ak:plan sau khi insight vượt evidence check. Chỉ dùng ak:cook cho implementation contract đã duyệt.

Biết các giới hạn hiện tại

• Các kỹ thuật tổ chức reasoning; chúng không cung cấp domain fact chưa được đưa vào hoặc kiểm tra.
• Success metric trong method là heuristic, không bảo đảm abstraction hoặc scale work có giá trị.
• Cách gọi Cursor bằng slash là bằng chứng do người dùng xác minh, không chứng minh runtime parity đầy đủ.
• Stable và beta package cùng kỹ thuật cùng reference ak:problem-solving. Thay đổi runtime ở beta không làm đổi workflow này.