snowzhaozhj
UserDesktop viewer and analyzer for Claude Code sessions — Rust + Tauri + Svelte
Categories
Indexed Skills (27)
openspec-apply-change
Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
openspec-archive-change
Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
openspec-bulk-archive-change
Archive multiple completed changes at once. Use when archiving several parallel changes.
openspec-continue-change
Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
openspec-explore
Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
openspec-ff-change
Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.
openspec-new-change
Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.
openspec-onboard
Guided onboarding for OpenSpec - walk through a complete workflow cycle with narration and real codebase work.
openspec-propose
Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
openspec-sync-specs
Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
openspec-verify-change
Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
bug-hunt
用户**显式**触发的 bug 主动猎查 skill——按 scope 扫一组文件 / crate / commit range，输出**带证据 + 置信度 + 严重度**的 bug 报告，不动业务代码。**只有**用户说 `/bug-hunt` 或显式说"扫一遍 X 找 bug / 帮我 audit X / X 这个 crate 有没有潜在 bug / 主动找 bug / bug hunt / 静态过一遍 X" 时才用。**不要**在用户问"为什么 X 不工作"时自动触发——那是 `debug-first` 的领地。**不要**在 PR review 时触发——那是 `code-review`。本 skill 专管"对一段没人喊救的代码主动 audit"。
bump-version
同步 bump workspace 版本号三处（Cargo.toml / src-tauri/Cargo.toml / src-tauri/tauri.conf.json）→ 跑 `just release-check`（版本一致 + preflight + lock 同步）。**只在**用户显式 `/bump-version <new>` 或自然语言"bump 版本 / 升版本号 / bump 到 X.Y.Z / 发 vX"时触发——模型不能自主调用，因为这是发版动作必须用户授权。完整发版流程见 `release-runbook` skill。
debug-first
已开始排查 bug 时的诊断节拍——4 步主流程 + 3 条贯穿约束防"光读代码瞎猜"。**只要**用户报"X 不工作 / 还是有问题 / 上次修的还在 / 为什么挂 / 怎么回事 / 跑不通 / 跑不起来 / fail 在哪 / 报错 / 异常 / 出问题了 / 不正常 / 行为不对 / 调一下 / 调查一下 / 看下为什么 / 定位下 / debug / code-review 发现 / PR 还有问题"或显式 `/debug-first`，**都用这个 skill** 先过一遍。**与 preflight 互补**：`修 bug / 实现 X / 帮我做 Y` 等开工信号走 `preflight`（开工 4 件套）；`为什么 / 排查 / 定位 / 不工作 / 还是有问题` 等诊断信号走本 skill（不动业务代码，只约束诊断流程）。
mark-tasks-done
批量勾选 `openspec/changes/<name>/tasks.md` 指定 section 范围内的 `- [ ]` → `- [x]`，跳过"下次 port 同步位点 / future notes / 备忘"等非活动节。**仅**在用户**显式发起命令**时触发：`/mark-tasks-done <change> [--sections N-M]` 或"把 port-foo 的任务勾上 / 把 port-foo 的任务批量勾上 / 一次性勾完 port-foo"等明确点名 change 的指令。**不是** `/opsx:apply` 默认节拍的一部分——后者按 `.claude/rules/opsx-apply-cadence.md` 要求"完一项 TaskUpdate 一项"逐个勾，模型禁止在 apply 流程中自主调用本 skill。
port-dashboard
⚠️ **已过期**（2026-05-23）：原依赖 `openspec/followups.md` 按 capability 切章节，已迁移到 GitHub Issues + `openspec/TS_BASELINE_DEVIATIONS.md` + `openspec/README.md::路线图`，本 skill 不再有承载场景。看进度用 `gh issue list` / `gh issue list --milestone vX.Y`；TS 偏差预警直接 Read `openspec/TS_BASELINE_DEVIATIONS.md`。仅显式 `/port-dashboard` 时才调用。
refactor
代码质量审计工具——扫描指定 scope（file / crate / surface / workspace）输出结构化 findings。
ts-ui-compare
对比原版 TS renderer 组件（`../claude-devtools/src/renderer/`）与 Rust 版 Svelte 组件（`ui/src/`）的功能 / 样式 / 交互差距，输出差异报告 + 移植建议。**仅**用户显式 `/ts-ui-compare <组件名>` 时触发——模型不能自主调用，因为这是一个需要逐文件细读的开销大动作，且 CLAUDE.md 已默认 UI 改动"优先对齐原版"（feedback_align_with_original 记忆），通常不需要专门跑这个 skill 才能知道方向。
dep-update
检查 Cargo workspace + ui 前端依赖更新状态，列出可升级项、breaking risk、安全公告。**只要**用户说"检查依赖 / 依赖更新 / outdated / 有没有新版本 / upgrade deps / 升级依赖"或显式 `/dep-update`，**都用这个 skill**。
session-insights
Analyze Claude Code sessions — errors, token usage, costs, search, diagnostics, recall.
e2e-http-verify
用 cdt-cli HTTP server + vite proxy + 浏览器 `?http=1` 入口跑端到端真数据验证**用户可感知 + HTTP transport 暴露**路径的修法。**只要**用户说"用 cli 起 server / 用 http 接口验证 / 浏览器自动化测试 / 真数据 e2e / chrome devtools 端到端 / 验证修法 / 用户感知 bug 复现 / 桌面端看不到修复 / sidebar 显示异常 / 切 group 慢 / 列表渲染 / 卡顿"或显式 `/e2e-http-verify`，**都用这个 skill**。**agent 在以下时机也宜自动调用**（无需用户念关键词）：(a) 改完 HTTP route / SSE 路径 / list_sessions / sidebar 渲染 / IPC 字段被前端消费的路径准备宣告完成前；(b) 用户报"我重启了桌面端还是没修好" / "看不见修复" / "刷新没用"。**不适用**（避免 over-trigger）：纯 Tauri 专属 API（通知 / 托盘 / setBadgeCount）/ 纯 backend 内部重构 / 没有用户可见路径的纯算法改动 / 纯样式微调 / bump version / docs。避免每次重新摸 vite proxy / SSE prelude / BrowserTransport 路由 / 端口冲突 / chrome-devtools mcp evaluate_script 陷阱，也避免修完只跑 unit test + mockIPC 就声称完成（mockIPC fixture ≠ 真后端数据，桌面端 binary 不一定用上新代码）。
insta-review
审查并接受 insta 快照变更。默认走 `INSTA_UPDATE=no` 跑测试产 `.snap.new` → 逐一 diff 让用户确认 → 通过后 `INSTA_UPDATE=always` 覆盖 + `git add tests/snapshots/`。**只要**用户说"review snapshots / 更新快照 / 接受 insta / snapshot 测试挂了 / insta 失败"或显式 `/insta-review`，**都用这个 skill**——不要自己手跑 `INSTA_UPDATE=always` 盲接受，那会把回归当 OK。
preflight
开工 30 秒自检——fetch + 分支 / OpenSpec 适用性 / 探索方式三件套。**只要**用户发出开工信号（"开始干 / 帮我做 X / 先做 A 再做 B / 实现 Y / 修 bug"）或显式 `/preflight`，**都用这个 skill** 先跑一遍——避免落入"在 main 直接编辑 / 跳过 OpenSpec / 不用 Explore subagent / 从过期 origin/main SHA 起 worktree"四个 CLAUDE.md 已固化为硬约束的高频 friction。
release-runbook
完整发版流水线（preflight → bump → release-check → PR → wait-ci → merge → tag → 监控 release.yml → publish draft）+ v0.1.0–v0.5.3 已踩坑的 known-failures playbook（matrix race / Windows MSI 字母版本号 / minisign 链 / lock 不同步 / Gatekeeper / Linux .deb 升级限制）。**用户说 `/release-runbook X.Y.Z` 或"发版 / release / 发个 patch / bump 到 X.Y.Z / 发 vX"时都用这个 skill**，不要自己散步骤跑——历史上每个 step 都有踩过的坑。
ts-parity-check
对比 TS 源（`../claude-devtools`）与 Rust 端口指定 capability 的文件映射，并查 `openspec/TS_BASELINE_DEVIATIONS.md` 看是否有该 capability 相关的 TS 偏差预警 + 当前 GitHub Issues backlog 里的相关项。**用户说 `/ts-parity-check <capability>` 或"对比一下 chunk-building 的 TS 与 Rust / 这个 cap 还有 TS 偏差吗"时都用这个 skill**——不要自己手 grep 比一遍。
wait-ci
Poll `gh pr checks <pr>` 直到全绿或失败；失败时自动 `gh run view --log-failed` 过滤 FAILED/panicked/error 行提炼真正的错误。**只要**刚 `git push` 完 / 用户说"等 CI / CI 过了没 / 看 CI 结果 / CI 跑没跑完 / 跑完没"或显式 `/wait-ci [pr]`，**都用这个 skill**——CLAUDE.md "What to do first" 第 6 条已把"PR push 后 SHALL `/wait-ci` 直到全绿"列为硬约束（`scripts/check-openspec-archives.sh` 等 CI-only check 本地 preflight 拦不下来），不能 push 完就走人。
perf
性能统一入口——含 SessionDetail 首屏 bench 跑分（references/bench-session-detail.md）和 idle CPU 系统性诊断（references/diagnose-idle-cpu.md）。**只要**用户提到性能 / 慢 / 卡顿 / 风扇起转 / IPC 慢 / SessionDetail 首屏 / 加载耗时 / payload 大 / 大会话 / idle CPU 高 / 后台烧 / 偶尔卡 / 线程多 / 进程占 X% CPU / 电池掉得快，或显式 `/perf` / `/perf-bench` / `/perf-cpu-diagnose`，**都用这个 skill**——不要自己手跑 cargo test / sample / top 后乱解读数字。
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.