ha-debug
Hope-native debugging for code failures, regressions, crashes, flaky behavior, and bad output: reproduce or characterize, rank falsifiable hypotheses, fix the smallest root cause, and prove the failing path.
git clone --depth 1 https://github.com/shiwenwen/hope-agent /tmp/ha-debug && cp -r /tmp/ha-debug/skills/ha-debug ~/.claude/skills/ha-debugSKILL.md
# Hope Debug Debug from evidence, not from the first plausible explanation. This is a decision process, not a mandatory four-stage ceremony. ## 1. Characterize The Failure Capture the strongest available evidence: - Exact symptom, expected behavior, and observed behavior. - Reproduction steps, failing command, stack trace, log range, or persisted state. - Whether it is deterministic, intermittent, platform-specific, data-specific, or timing-sensitive. - Recent relevant diffs, dependency/config changes, and known-good boundary. If reproduction is unsafe or requires unavailable credentials, characterize it from logs, fixtures, state, and code paths. State the evidence gap explicitly. ## 2. Bound The Fault Trace the smallest credible path through inputs, state transitions, persistence, concurrency boundaries, and outputs. For multi-component systems, compare what crosses each boundary rather than adding broad instrumentation everywhere. Common high-value checks: - Stale or duplicated persisted state. - Error swallowing, fallback, retry, cancellation, and timeout paths. - Async ordering, locks, process boundaries, and late results. - Platform, locale, permission, path, and environment assumptions. - Mismatch between source-of-truth data and UI projection. ## 3. Rank Falsifiable Hypotheses Keep one or two active hypotheses. For each, write: - Why it explains the evidence. - What observation would disprove it. - The cheapest discriminating check. Run the discriminating check before editing when practical. If a tiny, obvious fix is itself the cheapest safe experiment, keep it reversible and inspect the result before broadening scope. ## 4. Fix The Root Cause - Patch the smallest ownership boundary that restores the contract. - Avoid subsystem rewrites before the fault is proven. - Preserve unrelated user work and existing public behavior. - Add defense-in-depth only when it covers a demonstrated adjacent failure, not as speculative cleanup. After two failed fix attempts, stop patching variants. Re-read the original evidence, challenge the shared assumption, and narrow the boundary again. ## 5. Prove The Failing Path Use `ha-test-strategy` to choose the regression form and `ha-verify` to confirm completion. Prefer a check that would have failed before the fix: - Focused automated regression test. - Existing failing command or deterministic fixture. - Before/after database or log query. - Manual reproduction when automation is not credible. Passing compilation alone does not prove a runtime bug fixed. If the real path cannot be exercised, report the strongest substitute and remaining uncertainty. ## Stop Conditions Pause and ask for input only when progress requires inaccessible user state, an external system change, destructive action, or a product decision. Do not invent data or mark an unreproduced hypothesis as confirmed. ## Smoke Prompts - "This test fails intermittently; find and fix the root cause." - "The UI shows stale state after restart; diagnose the persistence path." - "Use this session id and logs to explain the regression, then repair it."
>
Use when the user asks to draft, polish, translate, or reply to an email. Produces a clean draft with subject line, greeting, body, and sign-off, plus a pre-send self-check.
Use when the user mentions 飞书 / Feishu / Lark workspace operations: docx (云文档) read/write, bitable (多维表格) records / views / dashboards, drive (云盘) upload/download, wiki (知识库) link resolution, approval (审批) instance create/cancel/query, calendar (日历) event create/list/update + attendees, contact (联系人) user/department lookup, hire (招聘) job/talent/application listing. Trigger on phrases like 'OKR 周报', '把这份文档发到飞书云盘', '给团队拉个评审会议', '查 [姓名] 的联系方式', '撤销那条审批', '/wiki 链接', or any request that mentions a feishu / lark URL / token (doxcn.../bascn.../wikcn.../boxcn.../om_...).
Hope Agent browser automation — the standard `status → tabs → snapshot → act` loop, stale-ref recovery rules, and what to do when login / 2FA / captcha / camera-prompt / dialog blocks progress. Load this skill whenever you reach for the `browser` tool. Trigger on: user asks the agent to open / control / click / scrape / log into / verify something in a web app ('open X and click Y', '打开 X 然后点击 Y', 'log into my Gmail', 'scrape this page', 'fill out the form on X'); user reports a flow that requires real browser context (cookies, JS-rendered content, OAuth).
Hope-native review of uncommitted, staged, commit, branch, or PR changes: discover concrete regressions, independently verify candidates, and report actionable findings first without speculative noise.
Hope-native baseline for implementing, fixing, refactoring, and maintaining code: inspect the repository first, protect user changes, keep scope narrow, and finish with direct evidence.
Hope-native implementation planning for non-trivial code changes: ground the plan in repository evidence, order dependencies, name critical files and risks, define verification, then continue execution when allowed.
Hope-native local-first data analysis and Artifact reporting. Use for CSV/XLSX analysis, KPI readouts, metric diagnosis, product/business analysis, data-quality review, dashboards, charts, analytical reports, 数据分析, 指标诊断, 数据质量, 分析报告, or when the user wants a shareable offline HTML/ZIP/Markdown/PDF result. Produces the versioned AnalysisArtifactV1 contract and registers it with the artifact tool; never guesses missing data or requires public web deployment.