rfhold

Use when docs/specs/changes/{name}/tasks.md is user-approved and contains stages with unchecked stage-completion boxes, when about to write implementation code for a planned change, or when resuming work on a change with partially-complete stages — implements tasks one stage at a time, dispatching subagents in parallel or sequential batches as the plan specifies, running one Stage Verification at each stage boundary and recording one Evidence block per stage.

Use when docs/specs/changes/{name}/ contains delta specs but no tasks.md yet, or when a previously-reviewed change has been revised in writing-specs — validates each delta operation's preconditions against current stable specs, checks scenario coverage and RFC 2119 language, then hands inline findings to plan-review which drafts the approval-gated plan.

Use when the user mentions superspec, when starting a spec-driven change, when unsure which workflow stage applies, or when the repo contains docs/specs/ or docs/specs/changes/ and work is about to begin — establishes source-of-truth rules and routes to the correct stage skill (brainstorming, writing-specs, review-changes, plan-review, execution, code-review) before any other action.

Use when brainstorming has settled requirements in chat and delta specs do not yet exist for the change, or when review-changes returned CRITICAL findings that require revising an existing delta — produces delta specs under docs/specs/changes/{name}/specs/{domain}/spec.md using heading-as-identifier requirements, RFC 2119 language, and Given/When/Then scenarios, with a Change Overview header capturing Why/Impact/Non-goals.

Use when docs/specs/changes/{name}/tasks.md has every stage marked `- [x]` with evidence, or when user says "review the change", "ship it", "merge the delta", "archive the change", or a prior code-review returned CRITICAL findings that execution has addressed — verifies every ADDED/MODIFIED requirement has code and tests, re-runs every stage's verification command against recorded evidence, then applies the delta wholesale in RENAMED→REMOVED→MODIFIED→ADDED order and archives the change.

Use when docs/specs/changes/{name}/ has delta specs validated by review-changes but no tasks.md yet, or when user says "plan this change", "write the plan", "what are the tasks" — produces tasks.md grouped into stages with canonical subagent dispatch phrasings, mapping every ADDED/MODIFIED requirement to tasks, with verification and evidence recorded at the stage boundary (not per task). This is the workflow's sole user-approval gate.

Use when the user says "add X", "build X", "fix X", "change X", "I want to", or otherwise requests any feature, bug fix, or behavior modification, and requirements have not yet been settled in conversation — explores intent and scope with the user before any spec is written.

Uses local machine audio I/O helpers for quick speech loops. Use when user asks to speak text with say.sh, capture microphone audio with capture.sh, or test TTS-to-STT by playing and recording on the same machine.

Writing idempotent pyinfra v3 deploy scripts, inventories, facts, and reusable @deploy packages. Use when user mentions "pyinfra", asks to "write a deploy", "create an inventory", "automate server setup", or needs help with operations like apt, files, systemd, git, pip, server tasks, or debugging pyinfra deploys. Do NOT use for Ansible, Terraform, or other IaC tools.

Creates Slidev presentations as Markdown slide decks for developers. Use when user says "make slides", "create a presentation", "make a slide deck", "write a talk", "presentation about", "slides for", "slidev", or asks to turn notes/content into a presentation. Outputs a slides.md file in ~/presentations/ and provides the command to run it.

Operating tmux panes to interact with TUI applications and manage long-lived processes. Use ONLY when the task requires interactive terminal use — such as sending keystrokes to a running TUI (lazygit, nvim, htop, k9s), starting persistent background processes (servers, watchers), or the user explicitly asks to use a tmux pane. Do NOT use for ordinary shell commands — prefer the Bash tool for those.

Manage Technitium DNS Server via its HTTP API. Use when working with DNS zones, records, blocked domains, query logs, or DNS resolution through Technitium. Trigger phrases: "technitium", "dns zone", "dns record", "blocked domain", "query log", "dns log", "resolve domain", "block list", "A record", "CNAME record", "MX record", "technitium API".

Reference for the rfhold homelab infrastructure at holdenitdown.net. Use when working with Kubernetes clusters (romulus, pantheon), deploying services, writing Pulumi stacks, configuring ingress or DNS, referencing service URLs, understanding storage (Ceph, NAS, S3), or asking about any homelab host or node. Trigger phrases: "deploy to homelab", "what namespace", "which cluster", "homelab service", "holdenitdown.net", "romulus", "pantheon", "Pulumi stack".