skills

Run a named TaskMate automation playbook against the Vikunja board: groom (backlog hygiene), split (break oversized tasks into subtasks), review (weekly retro with celebration), celebrate (kudos on completed work), unstick (research the most stuck task), triage (route inbox tasks). Dry-run by default; --apply executes mutations. Custom playbooks in .claude/taskmate/playbooks/ or ~/.config/taskmate/playbooks/ override built-ins. Use for scheduled automation (claude -p "/taskmate:auto groom --apply") or when the user asks to groom, clean up, triage, split, or review their task board.

Daily radar over the Vikunja board: scan open tasks and surface the ONE most valuable signal (overdue urgent task, stuck priority, decision that unblocks others, quick win, imminent deadline) as a short actionable nudge — or stay silent when nothing deserves attention. Read-only. Use when the user asks 'what should I work on', 'anything urgent?', 'morning briefing', 'task pulse', or on a schedule via claude -p.

Manage tasks in Vikunja (the open-source task manager): list, search, create, update, complete, prioritize, label, assign, relate, move, and comment on tasks and projects via a bundled token-efficient CLI. Self-heals when unconfigured by collecting server URL and API token. Use when the user mentions Vikunja, their task board/server, 'add a task', 'what's on my plate', 'what should I work on', 'my todo list', task grooming or triage, or when acting as a task companion working a shared board. Do NOT use for code TODO comments, GitHub/GitLab issues, or Claude Code's internal session task tools.

Guided TaskMate/Vikunja setup: create or update a connection profile (server URL + API token), choose user vs companion mode, pick a persona, bind the current repo to a Vikunja project, and schedule automations. Use when the user says 'set up taskmate', 'connect vikunja', 'configure my task server', wants to add a second profile/account, or when any TaskMate command reports not_configured or a 401.

Advance a long-horizon project by exactly one CID-loop iteration (update-state → define-next → advance → review), with rigor adjusted to the project's current phase (new/poc/mvp/stable). Use when explicitly asked to "run the build loop", "advance the project", "run one CID iteration", on /long-horizon:build, or when an automation (/goal, /loop, a scheduled task) drives autonomous building. Requires a CID context pack at .cid/ (create one with /long-horizon:init). NOT for one-off edits, questions, or reviewing unrelated work.

Set up a project for Continuous Iterative Development (CID): interview the user about the goal, stack, quality gate, and milestones; draft a target.md with runnable Verify criteria; and scaffold the CID context pack at .cid/ so the /long-horizon:build loop can run. Invoked explicitly via /long-horizon:init — model invocation is disabled below, because setting up the loop (interview, settings.json permission rules) is a deliberate human act. Works on empty directories (greenfield) and existing codebases (brownfield). NOT for running iterations (use /long-horizon:build) or checking progress (use /long-horizon:status).

Self-improvement pass for a CID-loop project: analyze the iteration journal, learnings, issues, and git history for loop-level problems (repeated NEEDS_WORK, drift, oversized steps, recurring blockers), then propose harness improvements — and with the "apply" argument, apply at most one bounded policy tuning. Use when asked to "run a retro on the loop", "tune the build loop", "why does the loop keep failing", or on /long-horizon:retro. NOT for reviewing code (the review role does that) or advancing the project (use /long-horizon:build).

Report where a CID-loop project stands without advancing it: current phase, convergence toward the target, last verdicts, open issues, blockers, and the suggested next action. Read-only. Use when asked "where does the project stand", "show loop status", "how is the build loop doing", or on /long-horizon:status. NOT for running an iteration (use /long-horizon:build) or setting up a project (use /long-horizon:init).

Triage and act on a code review. Takes reviewer feedback — from a human, a PR, or an external agent that lacked your plan and chat history — and works through it without assuming the reviewer is right. Verifies each item against the actual current code, applies the straightforward, valid, relevant, small, and uncontested fixes directly, and escalates the load-bearing or risky ones — anything that affects performance, backward compatibility, public API/behavior, or needs a larger refactor — to you as easy-to-read options, then runs the project's quality gates before reporting. Use when you say "address this review", "apply the review feedback", "go through the review comments", "handle the PR feedback", "act on this code review", "fix what the reviewer found", or after /code-review or an external agent produces findings. Do NOT use to *produce* a review (use code-review or high-stakes for that), nor to apply every suggested change blindly without verifying.

Review an idea, concept, system, challenge, or problem against the 8 rules of bio-cybernetics (Frederic Vester) and report on its viability. Maps the subject's feedback loops, scores each of the 8 rules (aligned / at-risk / violated), surfaces the 2-3 highest-leverage fixes, and judges whether the design is self-sustaining or on a path to runaway growth, brittleness, energy waste, or collapse. Use when asked to "apply bio-cybernetics", "do a cybernetic review", "check Vester's rules", "is this sustainable / viable / will it scale without collapsing", "find the feedback loops", or to pressure-test the long-term health of a product, business model, org design, policy, or architecture. Do NOT use for routine tasks with an obvious agreed solution.

Produce a reliable, high-stakes-grade result for ANY task — code, writing, research, ops — by treating the work as guilty until independent skeptics fail to break it. Runs the task through a dynamic many-subagent adversarial-verification Workflow that hunts for ten specific failure modes (silent assumptions, unmanaged confusion, hidden inconsistencies, unsurfaced tradeoffs, no pushback, sycophancy, subtle conceptual errors, overcomplication, dead code, orthogonal damage) and loops until they come back clean. Use this whenever the cost of a quiet mistake is high, when the user says "do this carefully / for real / no mistakes / high stakes", invokes /high-stakes, or asks for maximum effort / ultracode-grade rigor on a task they care about — even if they don't name the failure modes.

Apply systems thinking to a problem, decision, or situation. Classifies the problem as a clear, complicated, complex, or chaotic system, diagnoses it with the DART framework (Deconstruct, Analyze, Recognize, Test), surfaces hidden parts/connections/patterns and traps (incentive/cobra effects, delayed feedback loops), and recommends the action protocol that fits the system type. Use when asked to "apply systems thinking", "think in systems", "what kind of problem is this", "how should I approach this", "analyze this decision/situation", "should I X or Y", or when facing a messy call where the right approach is unclear. Do NOT use for routine tasks that already have an obvious, agreed solution.

Create and maintain a "For Coding Agents" reference page in project documentation. Generates dense, prescriptive documentation optimized for AI coding agents — architecture maps, decision dispatch tables, constraints catalogs, side effects matrices, task recipes, change playbooks, and common mistakes. Use when asked to "create agent docs", "update agent reference", "add docs for agents", "write coding agent documentation", or "update the for-coding-agents page". Also triggers on "agent-oriented docs", "AI-friendly reference". Do NOT use for general documentation, API reference generation, or user-facing tutorials.

Design command-line interface parameters and UX: arguments, flags, subcommands, help text, output formats, error messages, exit codes, prompts, config/env precedence, and safe/dry-run behavior. Use when you're designing a CLI spec (before implementation) or refactoring an existing CLI's surface area for consistency, composability, and discoverability.

Customize and extend Zensical documentation sites with interactive pages, custom templates, JavaScript widgets, and CSS styling. Use when working on documentation site customization including: (1) creating custom or interactive doc pages, (2) adding JavaScript widgets or third-party libraries to docs, (3) overriding templates or partials, (4) adding/modifying CSS styles, (5) creating custom page layouts (landing pages, demos, dashboards), (6) configuring zensical.toml settings, (7) integrating external JS frameworks into doc pages. Triggers on: docs site, documentation page, interactive demo, custom template, zensical, extra_css, extra_javascript, overrides, template block, page layout, widget integration. Do NOT use for: writing or editing markdown documentation content, general MkDocs questions (this is Zensical-specific), or reading/viewing existing docs pages.

Simplify Python code for clarity and maintainability. Use when users say "simplify", "simplify this code", "clean up Python", "refine this code", "make this simpler", "simplify recent changes". Delegates to the python-code-simplifier agent.

Fetch transcripts and subtitles from YouTube videos. Use when users want to get, download, extract, or read a YouTube video transcript or subtitles. Triggers on "get transcript", "youtube transcript", "fetch subtitles", "transcribe video", "video transcript", "what does this video say". Requires uvx with youtube-transcript-api.