ha-self-diagnosis
ha-self-diagnosis enables Hope Agent to investigate its own implementation and behavior. Use this skill when users ask how Hope Agent works internally, request explanations of source code or runtime behavior, report bugs or performance issues, ask to diagnose logs, or want to create or submit GitHub issues for bugs, features, or improvements. The skill operates in two modes: self-study for understanding architecture and troubleshooting specific subsystems, and issue-report for classifying and submitting bug reports, feature requests, or improvement suggestions to GitHub.
git clone --depth 1 https://github.com/shiwenwen/hope-agent /tmp/ha-self-diagnosis && cp -r /tmp/ha-self-diagnosis/skills/ha-self-diagnosis ~/.claude/skills/ha-self-diagnosisSKILL.md
# Hope Agent Self-Diagnosis You are Hope Agent investigating Hope Agent. Your job is to understand the app's own implementation and turn findings or user requests into useful answers or GitHub issues. ## Modes Choose exactly one primary mode from the user's request. ### self-study Use when the user asks how Hope Agent works, where something is implemented, what a subsystem does, or how to troubleshoot an area without necessarily reporting a bug. Workflow: 1. Identify the subsystem and read the closest architecture doc under `docs/architecture/`. 2. Inspect the actual source entry points named by the doc or by `references/source-map.md`. 3. Cross-check runtime/config behavior with `get_settings` when useful. 4. Answer with concrete file/module references, data flow, constraints, and likely debugging entry points. If the source tree is not available, use `references/source-map.md` and `references/diagnostic-playbook.md` as the fallback map (their Subsystem Reference names the doc, entry module, database, and log category per subsystem). Say when an answer is based on bundled references instead of live source. ### issue-report Use when the user asks to submit an issue, create a feature request, record an improvement, or report a bug. A bug is not required: explicit user requests for requirements or improvements are valid issue-report tasks. Workflow: 1. Classify `kind` as `bug`, `feature`, or `improvement`. 2. Gather context: - Bug: version/platform/run mode, recent errors, related session/tool failures, reproduction steps. - Feature: user story, motivation, expected behavior, acceptance criteria. - Improvement: current friction, proposed behavior, tradeoffs, acceptance criteria. 3. If Issue Reporting setting `duplicateCheckEnabled` is true, call `issue_report(action="search")` with a concise query. 4. Call `issue_report(action="draft")` and show the draft summary to the user if they have not already explicitly asked to submit. 5. Call `issue_report(action="create")` only when the user asked to submit or after they approve the draft. The tool itself will ask for final confirmation before submitting. Never bypass the `issue_report(action="create")` confirmation. Never paste raw secrets into the issue body. Evidence can be detailed, but it must be redacted and relevant. If no GitHub token is configured, the tool can still submit through the user's authenticated `gh` CLI. ## Diagnostic Sources Use these in order: 1. Live source and docs in the current working directory. 2. Local runtime data under `~/.hope-agent/` (full DB table in `references/source-map.md`): start with `logs.db` and `sessions.db`, then the subsystem-specific store — `memory.db`, `knowledge/index.db`, `cron.db`, `async_jobs.db`, `local_model_jobs.db`, `recap/recap.db`, `canvas/canvas.db` — and non-DB state like `crash_journal.json` / `config.json`. 3. Settings via `get_settings`. 4. Bundled references in this skill: - `references/source-map.md` - `references/diagnostic-playbook.md` - `references/issue-template.md` For SQLite diagnostics, follow the read-only rules from `ha-logs`: use `sqlite3 -readonly` or Python URI `mode=ro`; only run `SELECT` / `.schema` / `.tables`. ## Output Expectations For self-study, return a technical explanation with: - What subsystem is involved. - The key files/modules. - The runtime data/config involved. - Important constraints or red lines. - How to verify or debug it. For issue-report, return: - Issue kind. - Duplicate search result summary. - Draft title and body summary. - Created issue URL if submitted.
>
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).
Discover and install third-party skills from external registries when the user needs a capability that no currently-active skill covers. Trigger when: (1) the user explicitly asks 'find a skill for X', 'is there a skill that does X', 'install a skill to X', (2) the user requests a well-known integration (Slack, Notion, Trello, GitHub, Hue, Sonos, iMessage, weather, TTS, transcription …) that isn't in the active skill catalog, (3) you are about to hand-write ad-hoc shell / API code for a domain that almost certainly has a published skill. Do NOT trigger if an active skill already covers the need — scan the visible skill catalog first.
Self-service diagnostics — query Hope Agent's local SQLite databases (logs / sessions / async jobs) directly via the `exec` tool to investigate problems, analyze usage, and locate root causes. Trigger on: user reports something broken / failing / slow / stuck / not responding ('X 不工作', 'X 报错', 'X 卡住', '为什么 X 失败', 'why did X fail', 'show me the logs', 'check what happened'); ad-hoc data analysis ('this week's token usage', '最近调用最多的工具', 'how many subagent runs failed', 'tool error rate', 'find sessions where X happened'); verifying a fix ('did the error stop after I changed Y'). Use BEFORE asking the user to paste log snippets — the data is on disk, query it directly. Read-only — SELECT only, never UPDATE/DELETE/INSERT/DROP.
Hope Agent native macOS desktop control — the standard `mac_control` status / diagnostics / apps / dock / spaces / snapshot / visual / windows / menu / clipboard / dialog loop, target-first action rules, no-blind-coordinate policy, and recovery for stale AX/window/menu/dialog state. Load whenever using `mac_control`, or when the user asks to control local Mac apps, Dock, Spaces, click/type/menu/window/dialog/clipboard, automate Finder/TextEdit/System Settings, visually locate UI, or says 控制 Mac, macOS 自动化, 点按钮, 打开应用, Dock, Space, 关闭窗口, 菜单点击, 视觉定位.
Check for and install Hope Agent updates through conversation. Use whenever the user asks about upgrades, new versions, release notes, or reports a bug that might already be fixed upstream — phrases like 'upgrade Hope Agent', 'update hope agent', 'check for new version', '升级一下', '有新版本吗', '帮我升级', 'is there a newer build', 'check release notes', 'install the latest'. Also use proactively when an `app_update(action=\"check\")` result shows `has_update: true` and the user hasn't been told yet. Covers all three formfactors: desktop GUI bundle (DMG/MSI/AppImage), `hope-agent server` daemon installed via Homebrew/Scoop/AUR/apt/dnf, and headless single-binary deployments. The upgrade is always user-confirmed via `ask_user_question` — never silent.