cc-fix

Fix

Process Sovereignty Statement: This skill is a fix/debug workflow explicitly invoked by the user, and already includes two independent processes: Fix Mode and Debug Mode. It is forbidden to invoke any external skill that would take over the fix/debug process during the execution of this process; this skill itself is the debug process, and there is no need to nest another layer. Business-domain skills (such as cc-redis-safety、cc-api-contract-safety、cc-external-system-debugging、cc-payment-callback-safety、cc-time-zone-safety and other security/convention skills whose trigger conditions match) are loaded normally as needed, serving only as defensive references and not taking over the process. This statement is based on the principle of the user's explicit instruction taking precedence: when $cc-fix is explicitly invoked, this skill holds control over the main fix/debug process.

Use this skill when the user explicitly asks to fix a problem, locate a bug, or enter a debug process.

Do not use for:

Ordinary feature implementation
Language or framework style conventions
Formal code review
Environment-level risk assessment

Mode

Before entering fix, if a mainline task in the project is in 进行中, and this fix is only a temporary insertion, first use cc-task-state or directly add an "interruption record" in the mainline task file, stating where you got to, why you switched out, the recovery entry point, and the next step, then enter the fix process.

Fix Mode

Suitable for scenarios where the problem boundary is relatively clear and it can be fixed directly.

Confirm the expected behavior and the current symptoms.
Read the relevant code paths.
Make the minimal effective fix.
Perform targeted verification on the original problem path.
State the residual risks.

Debug Mode

Suitable for scenarios where the symptoms are clear but the root cause is unclear.

Reproduce or describe the symptoms.
Propose specific hypotheses.
Verify the hypotheses with low-cost checks.
Make the minimal fix based on evidence.
Re-test the original problem path.

Supplementary checks

When encountering frontend-backend integration, list pages, pagination, filter options, or detail page anomalies, additionally use cc-api-contract-safety
When encountering anomalies in external black-box systems such as browsers, editors, CDN/WAF, clipboard, IM platforms, third-party SaaS, etc., or when two consecutive rounds of code-reasoning-based fixes are no-ops, additionally use cc-external-system-debugging, capture real data first before reasoning
If the fix will interrupt the current mainline task, prioritize recording a checkpoint; only create a separate task for an inserted fix that has an independent scope and may span multiple rounds
First verify the real interface response, the unified success response format, and the pagination structure, then decide whether to fix the backend root cause or retain temporary frontend compatibility
If a compatibility branch is retained, its exit conditions must be stated, and dual-format compatibility must not be solidified for the long term

Output requirements

Clearly distinguish symptoms, hypotheses, fixes, and verification.
If this fix interrupted a mainline task, clearly state whether a checkpoint has been added and how the mainline will be resumed.
When there is no evidence, do not claim that the root cause has been found.
Do not expand the problem scope just because it is convenient during debugging.

Expand as needed

Direct fix:references/fix-mode.md
Structured investigation:references/debug-mode.md
Post-fix verification:references/verification-after-fix.md