dotfiles

Use when running a command that may take longer than 60 seconds, may hang, or needs progress monitoring and cancellation without blocking the agent.

Create concise, text-first slide decks written in Markdown and optionally create or edit Google Slides. Use when the user asks for slides/slide decks/ppt/presentations, especially when they want: (1) Flow/narrative design first, (2) Bullet-heavy slides with deep nesting, (3) Iterative drafting where Codex shows exactly ONE slide per turn, (4) ASCII-only final Markdown, or (5) Google Slides creation or scoped edits via scripts/google_slides.py.

Iteratively refine drawio code by repeatedly exporting to PNG and visually comparing against a reference image. Use when the user provides a reference image (screenshot, mockup, diagram) and asks to recreate it as a drawio/diagrams.net diagram. Triggers on phrases like "recreate this diagram in drawio", "match this image with drawio", "drawio iterative", user provides an image path + drawio request.

Modify the user's flake-based NixOS and Home Manager configuration in ~/dotfiles while preserving the existing structure and conventions. Use when asked to enable/disable NixOS services/options, add/remove packages, adjust overlays, update flake inputs/lockfiles, create/tweak host profiles (desktop/laptop/server/rpi/WSL), or debug Nix evaluation/build errors. Always verify option/module/API correctness against the pinned nixpkgs source (via $NIX_PATH and the repo's flake.lock) because Nix/NixOS APIs change quickly and docs may lag.

Direct Zotero Web API operations on a personal or group library: CRUD on items / collections / notes / tags, PDF attachments via either hybrid local-file mode or standard 3-step S3 upload, identifier-based item lookup, and bulk tagging. Use when the user asks to add items / import / create / update / delete / move / tag / search / attach files in Zotero programmatically (e.g. 'add to zotero', 'create zotero collection', 'attach PDF to zotero', 'tag items in zotero', 'manage zotero library', '操作 zotero', 'zotero 库'). Does NOT resolve bibliographic metadata from arXiv / CrossRef / Semantic Scholar / OpenReview - hand the script already-formed Zotero JSON via --meta. For bibliography-aware paper import workflows use the literature-review skill instead.

Academic literature review workflow for Related Work sections, project feasibility reports, and surveys. Multi-source paper discovery (brave + exa + cited + arXiv + Semantic Scholar), lightweight triage, arXiv HTML deep reading, and generation of a comparison matrix and a Related Work draft. Use when the user asks for literature review / survey / related work / paper survey. Stage A supports end-to-end arXiv-centric workflow; Zotero import and MinerU PDF extraction come in Stage B; paywall fallback and citation chasing come in Stage C.

PDF to Markdown conversion using the MinerU GPU container. Extracts text, tables (HTML), formulas (LaTeX), and figures from PDFs. Use when asked to convert a PDF to structured Markdown, extract content from a paper PDF, or set up the MinerU extraction pipeline.

Stateless HTTP client for talking to a running opencode server by port. Send a message to a session, poll for the assistant's response (idle + new-message strategy), list/create/delete sessions, or read past messages. Use when the user asks to (1) connect to / talk to / message an opencode session by port, (2) drive an opencode session from the shell, (3) script an opencode session (send + wait + read), (4) bridge to an opencode TUI/serve instance running on localhost or another host, (5) list or manage sessions on an opencode server. Triggers on phrases like "connect to opencode session", "send message to opencode on port", "talk to opencode session", "poll opencode for response", "list opencode sessions". Uses only Python 3.10+ stdlib and opencode's HTTP API. Do NOT use this for orchestrating multiple agents in parallel - use the agent-team skill for that.

MUST USE for ANY Nix-related content - DO NOT skip this skill. Nix flake-based dev environment management. Triggers on ANY mention of: nix commands (nix develop/build/shell/run/flake/profile, nix-shell, nix-build, nix-env, nix-store), .nix files (flake.nix, shell.nix, default.nix, ANY *.nix), Nix language/syntax/expressions, nixpkgs, derivations, overlays, devShells, flakes, flake.lock, NIX_LD, missing shared libraries (libstdc++.so, libGL.so, ANY *.so cannot open errors), Nix store paths (/nix/store/...), home-manager dev shells, or package management where Nix is available. ALWAYS load when (1) project has flake.nix/shell.nix/*.nix, (2) user mentions ANY nix command/concept/file/error, (3) installing dev dependencies on a Nix-capable system, (4) shared library errors appear, (5) temporary tools needed via nix shell, (6) ANY uncertainty about whether Nix is involved - default to LOADING. Err aggressively on the side of loading.

Dump opencode chat session trajectories (messages, thinking, tool I/O) to readable markdown files for offline analysis, sharing, or LLM-driven review. Use when the user asks to (1) dump/export an opencode session by ID, (2) save chat history to disk, (3) get a markdown transcript of a past session, (4) list recent opencode sessions, or (5) extract trajectories for a specific time range. Triggers on phrases like "dump session ses_xxx", "导出聊天记录", "save trajectory", "export the chat", "list recent sessions". Reads directly from the opencode SQLite database; does NOT use the MCP session_read tool (which truncates and is slow on long sessions).

Orchestrate a swarm of AI agents for parallel task execution using opencode sessions and tmux. One opencode server (with --port) hosts multiple sessions - one per agent. tmux windows provide visual monitoring via `opencode attach`. A standardized Python CLI (swarm.py) handles all inter-agent communication. Use when: (1) user asks to parallelize work across agents, (2) user says "spin up a team", "agent team", "swarm", "use multiple agents", (3) a task naturally decomposes into 2+ independent sub-tasks that benefit from parallel execution, (4) user says "start agents", "multi-agent", "work in parallel". IMPORTANT: This skill has two roles. If you receive a message containing [SWARM INIT], you are a WORKER - read references/worker-protocol.md immediately. Otherwise you are the LEADER orchestrator.

Multi-agent parallel research workflow: YOU (the Orchestrator) spawn 6-12+ research agents simultaneously, each investigating ONE specific angle. YOU decompose the topic into 3-7 directions, launch parallel agents per direction, then synthesize all findings. DO NOT use a single agent - use multiple agents in parallel. Use for complex research requiring comprehensive coverage.

Act as a senior full-stack engineer collaborating with a product manager. Use when the user wants engineering execution with strong PM-style communication, requirement clarification, upfront planning and abstraction (modules/classes/methods/inheritance), and post-implementation pushback or debate about product decisions.

Review the current local git diff as a pair-reviewer: summarize diff scope (features + files), produce a collaborative review plan (order, key functions, logic chain), then give prioritized review notes/pitfalls with actionable suggestions. Use when the user asks for code review / PR review / diff review, e.g. 'review this diff', 'code review', '帮我review', '看看git diff'.

Act as the user's execution coach/mentor: break goals into executable tasks, produce a daily plan (timebox, acceptance criteria, evidence), enforce strict accountability with check-ins and retros, and troubleshoot blockers with actionable options to prevent procrastination. Use when the user asks for coaching/mentoring/supervision, strict accountability, daily plans, task breakdown, check-ins/retros, procrastination help, or execution discipline (e.g., 'coach me', 'hold me accountable', 'daily plan', 'daily check-in', 'daily retro').

Evidence-driven debugging for project or system issues: reproduce the bug, capture commands/logs/stack traces, narrow scope, prove root cause with concrete evidence (no guessing), apply minimal fix, and re-run reproduction/tests to verify. Use when asked to debug/triage errors, crashes, segfaults/panics/tracebacks, failing/flaky tests, service/system problems (systemd/journalctl), or performance regressions.

Neovim configuration changes and investigations for this dotfiles repo. Use for any Neovim-related task: editing config, plugin specs, keymaps, LSP/formatters, UI, performance, debugging, or plugin behavior questions.

Plan Mode: produce a clear, reviewable execution plan (steps, options, trade-offs, risks, and validation) and wait for explicit user approval before taking any action that changes code, files, or external state. Use when the user asks “plan mode”, “make a plan first”, “only plan, don’t execute”, “roadmap/proposal”, or similar (also: 计划模式/先给计划).