/ha-logs
Self-service diagnostics — query Hope Agent's local SQLite databases (logs / sessions / background 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
$ npx -y skills add shiwenwen/hope-agent --skill ha-logs --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/ha-logs
Context preview
The summary Claude sees to decide when to auto-load this skill.
Self-service diagnostics — query Hope Agent's local SQLite databases (logs / sessions / background 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
SKILL.md
ha-logs.SKILL.mdname: ha-logs
description: "Self-service diagnostics — query Hope Agent's local SQLite databases (logs / sessions / background 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."
version: 1.0.0
author: Hope Agent
license: MIT
requires:
anyBins: [sqlite3, python3]Hope Agent Logs — Self-Service Diagnostics
Hope Agent persists every log line, every session message, and background job state into local SQLite databases under `~/.hope-agent/`. You can query these directly via `exec` to investigate problems before asking the user. Treat this as your primary evidence source.
Iron rule: read-only
**SELECT only. Never UPDATE / DELETE / INSERT / DROP / ATTACH / VACUUM / CREATE / REPLACE.**
The DBs are live: write queries can corrupt session state, kill running streams, or wipe history. Open with `-readonly` (CLI) or `?mode=ro` (Python URI) so SQLite enforces it. If you genuinely need to modify state, use the dedicated tools (`update_settings`, `task_update`, etc.) or ask the user.
How to query
Use `exec` to run one of:
`sqlite3` CLI (Linux / macOS, usually preinstalled)
sqlite3 -readonly -cmd ".mode column" -cmd ".headers on" ~/.hope-agent/logs.db \
"SELECT timestamp, level, category, source, message
FROM logs
WHERE level = 'ERROR'
ORDER BY timestamp DESC
LIMIT 20;"Python fallback (Windows or no `sqlite3` on PATH)
python3 - <<'PY'
import sqlite3, os
p = os.path.expanduser("~/.hope-agent/logs.db")
con = sqlite3.connect(f"file:{p}?mode=ro", uri=True)
for r in con.execute("""
SELECT timestamp, level, category, source, message
FROM logs
WHERE level = 'ERROR'
ORDER BY timestamp DESC
LIMIT 20
"""):
print(r)
PYSchema discovery
sqlite3 -readonly ~/.hope-agent/logs.db ".schema logs"
sqlite3 -readonly ~/.hope-agent/sessions.db ".tables"
Databases
| Path | Purpose | |------|---------| | `~/.hope-agent/logs.db` | App logs from `app_info!`/`warn!`/`error!`/`debug!` macros | | `~/.hope-agent/sessions.db` | Sessions, messages, tasks, subagent runs, learning events, channel conversations | | `~/.hope-agent/background_jobs.db` | Unified background job cache (`exec` / `web_search` / `image_generate` plus subagent/group projections) | | `~/.hope-agent/recap/recap.db` | Cached recap analysis | | `~/.hope-agent/local_model_jobs.db` | Local LLM background jobs (download / preload) |
Key schemas
`logs.db` → `logs`
| Column | Type | Notes | |--------|------|-------| | `id` | INTEGER PK | | | `timestamp` | TEXT | ISO 8601 UTC, e.g. `2026-05-04T12:34:56.789Z` | | `level` | TEXT | `INFO` / `WARN` / `ERROR` / `DEBUG` | | `category` | TEXT | Subsystem tag — examples: `chat_engine`, `permission`, `mcp`, `channel`, `compact`, `failover`, `tool`, `provider`, `memory`, `cron`, `subagent`, `plan`, `config`, `skill` | | `source` | TEXT | Origin file/function (free-form, agent-set) | | `message` | TEXT | Rendered printf-style message | | `details` | TEXT | Optional JSON payload | | `session_id` | TEXT | Nullable, links to `sessions.db → sessions.id` | | `agent_id` | TEXT | Nullable |
Indexes: `timestamp DESC`, `level`, `category`, `session_id`.
`sessions.db` → `sessions`
`id, title, agent_id, provider_id, provider_name, model_id, reasoning_effort, created_at, updated_at, context_json, last_read_message_id, is_cron, parent_session_id, incognito, title_source`
`sessions.db` → `messages`
`id, session_id, role, content, timestamp, attachments_meta, model, tokens_in, tokens_out, reasoning_effort, tool_call_id, tool_name, tool_arguments, tool_result, tool_duration_ms, is_error, ttft_ms, tokens_in_last, tokens_cache_creation, tokens_cache_read, tool_metadata, thinking`
`role` ∈ `user` / `assistant` / `system` / `tool`. Tool calls land as paired rows: an `assistant` row with `tool_name`/`tool_arguments`, then a `tool` row with `tool_result` / `is_error` / `tool_duration_ms`.
`messages_fts` (FTS5 virtual table) provides full-text search over `content` for `user`/`assistant` rows — use it for keyword search:
SELECT m.id, m.session_id, m.role, snippet(messages_fts, 0, '<mark>', '</mark>', '…', 16)
FROM messages_fts
JOIN messages m ON m.id = messages_fts.rowid
WHERE messages_fts MATCH 'timeout OR rate_limit'
ORDER BY m.timestamp DESC
LIMIT 20;
`sessions.db` → `subagent_runs`
`run_id, parent_session_id, parent_agent_id, child_agent_id, child_session_id, task, status, result, error, depth, model_used, started_at, finished_at, duration_ms, label, attachment_count, input_tokens, output_tokens`
`status` ∈ `spawning` / `running` / `completed` / `failed` / `cancelled`.
`sessions.db` → `tasks`
Plan Mode task tracking — `session_id` + state columns. **Read only**; writes must go through `task_create` / `task_update` tools.
`sessions.db` → `learning_events`
`id, ts INTEGER (unix seconds), kind, session_id, ref_id, meta_json` — current `kind` values: skill CRUD, `tool_recall_memory` hits, MCP tool calls. `meta_json` is opaque JSON.
`background_jobs.db` → `background_jobs`
`job_id, session_id, agent_id, tool_name, tool_call_id, args_json, status, result_preview, result_path, error, created_at INTEGER (unix s), completed_at, injected, origin, approval_origin, incognito, pid, cancel_requested, kind, subagent_run_id, group_id`
`status` includes queued/running/awaiting-approval and t
Read more
name: ha-logs
description: "Self-service diagnostics — query Hope Agent's local SQLite databases (logs / sessions / background 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."
version: 1.0.0
author: Hope Agent
license: MIT
requires:
anyBins: [sqlite3, python3]Hope Agent Logs — Self-Service Diagnostics
Hope Agent persists every log line, every session message, and background job state into local SQLite databases under `~/.hope-agent/`. You can query these directly via `exec` to investigate problems before asking the user. Treat this as your primary evidence source.
Iron rule: read-only
**SELECT only. Never UPDATE / DELETE / INSERT / DROP / ATTACH / VACUUM / CREATE / REPLACE.**
The DBs are live: write queries can corrupt session state, kill running streams, or wipe history. Open with `-readonly` (CLI) or `?mode=ro` (Python URI) so SQLite enforces it. If you genuinely need to modify state, use the dedicated tools (`update_settings`, `task_update`, etc.) or ask the user.
How to query
Use `exec` to run one of:
`sqlite3` CLI (Linux / macOS, usually preinstalled)
sqlite3 -readonly -cmd ".mode column" -cmd ".headers on" ~/.hope-agent/logs.db \
"SELECT timestamp, level, category, source, message
FROM logs
WHERE level = 'ERROR'
ORDER BY timestamp DESC
LIMIT 20;"Python fallback (Windows or no `sqlite3` on PATH)
python3 - <<'PY'
import sqlite3, os
p = os.path.expanduser("~/.hope-agent/logs.db")
con = sqlite3.connect(f"file:{p}?mode=ro", uri=True)
for r in con.execute("""
SELECT timestamp, level, category, source, message
FROM logs
WHERE level = 'ERROR'
ORDER BY timestamp DESC
LIMIT 20
"""):
print(r)
PYSchema discovery
sqlite3 -readonly ~/.hope-agent/logs.db ".schema logs" sqlite3 -readonly ~/.hope-agent/sessions.db ".tables"
Databases
| Path | Purpose | |------|---------| | `~/.hope-agent/logs.db` | App logs from `app_info!`/`warn!`/`error!`/`debug!` macros | | `~/.hope-agent/sessions.db` | Sessions, messages, tasks, subagent runs, learning events, channel conversations | | `~/.hope-agent/background_jobs.db` | Unified background job cache (`exec` / `web_search` / `image_generate` plus subagent/group projections) | | `~/.hope-agent/recap/recap.db` | Cached recap analysis | | `~/.hope-agent/local_model_jobs.db` | Local LLM background jobs (download / preload) |
Key schemas
`logs.db` → `logs`
| Column | Type | Notes | |--------|------|-------| | `id` | INTEGER PK | | | `timestamp` | TEXT | ISO 8601 UTC, e.g. `2026-05-04T12:34:56.789Z` | | `level` | TEXT | `INFO` / `WARN` / `ERROR` / `DEBUG` | | `category` | TEXT | Subsystem tag — examples: `chat_engine`, `permission`, `mcp`, `channel`, `compact`, `failover`, `tool`, `provider`, `memory`, `cron`, `subagent`, `plan`, `config`, `skill` | | `source` | TEXT | Origin file/function (free-form, agent-set) | | `message` | TEXT | Rendered printf-style message | | `details` | TEXT | Optional JSON payload | | `session_id` | TEXT | Nullable, links to `sessions.db → sessions.id` | | `agent_id` | TEXT | Nullable |
Indexes: `timestamp DESC`, `level`, `category`, `session_id`.
`sessions.db` → `sessions`
`id, title, agent_id, provider_id, provider_name, model_id, reasoning_effort, created_at, updated_at, context_json, last_read_message_id, is_cron, parent_session_id, incognito, title_source`
`sessions.db` → `messages`
`id, session_id, role, content, timestamp, attachments_meta, model, tokens_in, tokens_out, reasoning_effort, tool_call_id, tool_name, tool_arguments, tool_result, tool_duration_ms, is_error, ttft_ms, tokens_in_last, tokens_cache_creation, tokens_cache_read, tool_metadata, thinking`
`role` ∈ `user` / `assistant` / `system` / `tool`. Tool calls land as paired rows: an `assistant` row with `tool_name`/`tool_arguments`, then a `tool` row with `tool_result` / `is_error` / `tool_duration_ms`.
`messages_fts` (FTS5 virtual table) provides full-text search over `content` for `user`/`assistant` rows — use it for keyword search:
SELECT m.id, m.session_id, m.role, snippet(messages_fts, 0, '<mark>', '</mark>', '…', 16) FROM messages_fts JOIN messages m ON m.id = messages_fts.rowid WHERE messages_fts MATCH 'timeout OR rate_limit' ORDER BY m.timestamp DESC LIMIT 20;
`sessions.db` → `subagent_runs`
`run_id, parent_session_id, parent_agent_id, child_agent_id, child_session_id, task, status, result, error, depth, model_used, started_at, finished_at, duration_ms, label, attachment_count, input_tokens, output_tokens`
`status` ∈ `spawning` / `running` / `completed` / `failed` / `cancelled`.
`sessions.db` → `tasks`
Plan Mode task tracking — `session_id` + state columns. **Read only**; writes must go through `task_create` / `task_update` tools.
`sessions.db` → `learning_events`
`id, ts INTEGER (unix seconds), kind, session_id, ref_id, meta_json` — current `kind` values: skill CRUD, `tool_recall_memory` hits, MCP tool calls. `meta_json` is opaque JSON.
`background_jobs.db` → `background_jobs`
`job_id, session_id, agent_id, tool_name, tool_call_id, args_json, status, result_preview, result_path, error, created_at INTEGER (unix s), completed_at, injected, origin, approval_origin, incognito, pid, cancel_requested, kind, subagent_run_id, group_id`
`status` includes queued/running/awaiting-approval and t
🦭 会记忆、能持续推进目标、会动态编排多 Agent 的跨端桌面 AI 助手,也可服务化常驻 NAS / 云端 | A cross-device desktop AI agent with memory, autonomous goals, dynamic workflows, and headless deployment
Repo: shiwenwen/hope-agent
Other skills on hope-agent.
- /email-draft
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.
Open skill - /feishu
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 +
Open skill - /ha-browser
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
Open skill - /ha-code-review
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.
Open skill - /ha-coding-common
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.
Open skill - /ha-coding-plan
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.
Open skill

