cotend-diagnose-only

Diagnose Only

Diagnose the problem without changing project files.

Default: read-only investigation. Do not edit code, configs, tests, docs, package files, lockfiles, or generated artifacts unless the user explicitly authorizes moving from diagnosis to fix.

When To Use

Use this skill when:

• user says "只诊断", "先分析原因", "先别改代码", "别改代码", "先别动", "先别修", "先不要改", "先定位", "先查原因", "先告诉我为什么", "先分析，不要动代码", "diagnose only", or similar;
• user says "看看 AI 对这个模块的理解是否正确", "检查 AI 对这个模块的理解是否正确", "AI 对这个模块理解得对不对", "有没有理解偏", or equivalent evaluative wording without separately authorizing a change;
• user expresses doubt about a current change and asks for judgment or cause analysis without authorizing edits;
• verification failed and the cause is unclear;
• AI UAT found a failure but the right fix is uncertain;
• reviewer blocks work and Primary AI needs root cause before patching;
• the same bug has been fixed repeatedly and keeps returning;
• high-risk behavior is observed and blind patching would be unsafe.
• the user says a feature is not what they intended, development keeps moving but the product remains half-finished, or asks whether the AI misunderstood the feature while withholding edit authorization.
• a subagent, background agent, or model/tool call produces no trustworthy first response and it is unclear whether it is still reasoning, queued, disconnected, completed without a receipt, or stuck in a tool process.

If the same user instruction clearly asks to diagnose, then fix and verify, that explicit follow-on authorization satisfies the generic control-Skill handback. Report the diagnosis first, then proceed under the active project workflow without asking “continue?” again.

Rules

• Build or identify a feedback loop before forming conclusions.
• Prefer deterministic evidence over code-reading guesses.
• Do not make broad claims from a single symptom.
• Generate 3-5 falsifiable hypotheses before selecting the likely cause.
• If you cannot reproduce or inspect enough evidence, say so and list exactly what artifact is needed.
• Do not change files. If a temporary command creates artifacts, place them in OS temp or clean them up before finishing.
• Do not treat "先看看/先判断/先查一下" plus an edit-withholding phrase as permission to patch. Wait for explicit fix authorization such as "可以改了", "开始修", or "按方案改".
• Explicit edit-withholding wording such as "diagnose only", "只诊断", or "不要改" overrides nearby ambiguous repair language. It forbids the follow-on fix; report the diagnosis and return control.
• Apply natural-language precedence before acting: explicit withholding always remains read-only; without withholding, explicit mutation such as "重新对齐", "更新并修复", "对齐并修复", "确认后更新", or "修正这个理解" routes directly to $cotend-semantic-alignment; otherwise evaluative wording outranks generic "理解对齐" / "语义对齐" and stays here.
• Do not leak secrets in the report; redact paths or values when needed.
• Classify the likely cause as technical, semantic_drift, mixed, or insufficient_evidence. Do not force a semantic explanation onto an ordinary reproducible bug.
• For semantic_drift or mixed, classify scope before authorization: a full-project check remains full-project read-only, while a named-feature check stays local. Compare latest user-confirmed intent, original idea evidence, historical AI inference/proposals, current Plan Tree/requirements, and actual product behavior as separate surfaces. Code and AI-written documents show what exists; they do not prove what the user wanted.
• Never update semantic authority, Plan Tree, requirements, decision records, or source code during diagnosis. A proposed L0-L2 correction remains pending_user_confirmation and hands off to $cotend-semantic-alignment only after explicit user authorization.
• When the user asks about decision-relevant delivery-state intent for a capability—including completion/availability/integration/readiness/activity/end-to-end delivery, implementation/build, working/runnable, landing, or equivalent wording—load cotend-collaboration/references/acceptance-test-harness.md, cotend-collaboration/references/capability-completion.md, and the unique cotend.execution-closure.v1 shape in semantic-contract-templates.md. In read-only mode, evaluate or reference one exact-scope result without persisting it: preserve stable capability IDs, current semantic/design/implementation/verification basis, direct/proxy limits, necessary dimensions and safe wording. Old packets/results with stale/unknown basis are historical only. Do not copy the derivation here, expand ordinary diagnosis into six axes, or ask the user to confirm L3/L4.
• For a native-agent first-response stall, load cotend-collaboration/references/native-agent-orchestration.md. Classify from evidence as normal_reasoning_or_queueing | transport_or_connection_stall | completed_receipt_missing | tool_or_process_stall | insufficient_evidence. Inspect available agent/thread status, last activity, transport errors, tool output, process/job state, durable receipts, and workspace/external effects. Do not infer "never executed" from silence. Read-only or proven-idempotent work may restart after the original is stopped or conclusively absent; ambiguous side-effecting work must be reconciled or stopped before retry. Do not impose a universal timeout, retry count, WebSocket/provider setting, or community success claim.