dotfiles

Use whenever executing, continuing, resuming, or finishing an implementation plan or plan directory. Orchestrates assigned worker dispatch, integrated test-first discipline, progress checkpointing, isolated workspaces, checkpoint integration, and blocker batching.

Create implementation plans directly from user requirements when no reviewed RFC is available or the user explicitly declines RFC-first planning. Decomposes work into self-contained sub-plans with full iterative multi-agent plan review.

Create implementation plans from a reviewed RFC. Uses the RFC as the approved design baseline, decomposes it into executable sub-plans, and runs RFC-specific plan review.

Use whenever implementing or fixing production code, writing or changing tests, reviewing test quality, applying TDD, or diagnosing tests that pass without proving behavior. Ensures tests are requirement-grounded and reach behavioral RED before implementation.

Use when turning a settled design direction, brainstorming outcome, context anchor, or architecture discussion into a codebase-grounded RFC. Produces self-contained RFC documents with verified current architecture, chosen design, tradeoffs, risks, stable references, and planning handoff context without creating implementation plans.

Create project-specific plan reviewer agents that integrate with the planning-project-features workflow. Use when a project needs domain-specialized reviewers for sub-plans (e.g., Go code reviewer, API layer reviewer, database reviewer) or when the planner warns that no suitable local reviewer exists for a sub-plan's domain.

Decompose large efforts directly from user requirements when no reviewed RFC is available or the user explicitly declines RFC-first epic planning. Produces a persistent epic plan with rich feature descriptions that feed into planning-project-features separately.

Decompose a reviewed RFC into sequenced features for a single project. Uses the RFC as the approved design baseline and produces a persistent epic plan reviewed for RFC fidelity and feature decomposition.

Route epic planning to the correct workflow. Recommends RFC-first design when no RFC exists, sends reviewed RFCs to RFC-backed epic planning, and sends explicit opt-outs to direct epic planning.

Route feature planning to the correct workflow. Recommends RFC-first design when no RFC exists, sends reviewed RFCs to RFC-backed planning, and sends explicit opt-outs to direct planning.

Maintain concise feature-level working memory across sessions, teammates, and agents. Use when work spans multiple conversations; involves meaningful decisions, rejected alternatives, unresolved questions, or teammate/subagent handoffs; requires durable context before, during, or after brainstorming, planning, debugging, or implementation; or when the user asks to resume, continue, hand off, preserve context, or keep an anchor updated. When active, update the anchor as decisions are made instead of waiting for an end-of-session summary. Skip for quick one-off questions, trivial edits, and work whose full context fits safely in a single short interaction.

Use when exploring a problem space before implementation or planning. Turns rough ideas into validated, codebase-grounded RFCs through collaborative dialogue — challenges assumptions, explores alternatives, and converges on a committed design direction before final RFC authoring.

Manage dotfiles with chezmoi. Use whenever editing or reviewing chezmoi source files in this repo, including `dot_*`, `private_dot_*`, `dot_config/`, `private_dot_config/`, `.chezmoitemplates/`, `.chezmoiignore`, and `*.tmpl`; adding files to chezmoi; validating source changes with status/diff/dry-run; debugging source/target mapping or missing changes; or asking how a dotfile is managed. In sandboxed agent work, validate with diff/dry-run and do not run write-capable `chezmoi apply` or `--force`. For command uncertainties, use Context7.

Document system architecture, design decisions, layer boundaries, and how components connect and communicate. Use when (1) a project's architecture is undocumented, (2) agents can't figure out how the system fits together, (3) after major refactoring that changed system structure, or (4) onboarding developers who need to understand the big picture. References domain concepts — never redefines them.

Document business processes and workflows that a system implements. Describes end-to-end flows like user registration, order fulfillment, or payment processing — how domain entities move through the system. Use when (1) business workflows are undocumented, (2) a flow spans multiple components and no single component's docs tell the full story, (3) agents need to understand end-to-end behavior to implement changes, or (4) stakeholders need visibility into how the system handles a business process. NOT for development processes — those belong in skills and contribution guidelines.

Create documentation for specific components or areas of a codebase. Analyzes targeted code sections and produces structured documentation useful to both humans and AI agents. Use when (1) documenting an undocumented component or module, (2) building initial docs for a new area, (3) an agent discovers documentation gaps during codebase exploration, or (4) onboarding documentation is needed for a complex subsystem. Always targets a specific component — never documents the entire codebase at once.

Document business domain concepts, terminology, entity relationships, and domain rules for a project. Produces documentation that establishes the shared language used by both humans and AI agents. Use when (1) a project's domain concepts are undocumented, (2) agents misinterpret business terminology, (3) onboarding new team members who need to understand the business model, or (4) domain knowledge is scattered across code and needs consolidation. This is the most foundational documentation layer — all other docs reference it.

Create user-facing documentation for libraries — the kind of docs you'd find on a static documentation site. Guides readers through the library with an engaging, conversational tone, real code examples drawn from the actual codebase, and a navigable site-like structure. Use when (1) a library has no user-facing docs beyond inline code comments, (2) existing docs are API references with no narrative guidance, (3) users need task-oriented guides to accomplish common goals, or (4) a library's docs need restructuring into a browsable, site-ready format. Do not use for internal architecture, process, component, or domain docs; use the corresponding documenting-* skill instead.

Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.

Manage nono sandbox profiles and their shell launch wrappers in this dotfiles repo. Use when editing private_dot_config/nono/profiles, nono profile schemas, dot_agents/shell wrappers, SSH signing access for sandboxed agents, or adding/renaming agent-specific nono profiles.

Create GitHub Pull Requests with consistent, high-quality titles and descriptions. Use when opening a PR on GitHub — covers title formatting, summary, decision log, and before/after comparison.

Build Go binaries for local development or release. Use when you need to compile the project, troubleshoot build failures, or understand the build pipeline.

Create and troubleshoot GitHub Actions workflows. Use when editing .github/workflows files, setting up CI/CD pipelines, configuring matrix builds for multi-platform testing, debugging failing workflows, adding caching or artifacts, running E2E tests in containers, or asking "why is my workflow failing" or "how do I test on multiple OSes".

Configure and troubleshoot Zsh shell. Use when editing .zshenv, .zprofile, .zshrc, .zlogin, or .zlogout, setting up powerlevel10k prompt, configuring oh-my-zsh or sheldon plugin manager, fixing PATH or environment variables, debugging slow shell startup, setting up completions/compinit/fpath, or working with zsh-autocomplete, zsh-autosuggestions, or zsh-syntax-highlighting plugins.

Develop CLI applications in Go. Use when creating or modifying CLI commands, adding flags or arguments, implementing command workflows, building interactive prompts, handling signals and exit codes, or working with stdin/stdout/stderr. Currently uses Cobra for command structure and Huh for interactive UI.

Lint and format Go code. Use when you need to run linters, fix lint errors, format code, or understand why a linter is complaining.

Run E2E tests of the installer inside Docker containers on supported Linux distributions (Ubuntu, Debian, Fedora). Use when (1) verifying installer behavior on Linux, (2) testing new installer flags or features end-to-end, (3) running the installer in a controlled environment, (4) reproducing or debugging Linux-specific issues, or (5) validating that changes work across all supported distros before pushing to CI.

Run Go unit tests, coverage reports, and benchmarks. Use when you need to run tests, check coverage, run benchmarks, or regenerate mocks after interface changes.

Test the installer's interactive GPG key setup using an expect script that automates GPG prompts. Use when (1) testing GPG key generation end-to-end, (2) verifying the installer handles GPG prompts correctly, (3) debugging GPG-related failures in CI or containers, or (4) modifying the GPG setup flow and needing to validate it interactively.

Apply Go coding standards when writing or modifying Go code. Use when implementing functions, using dependency injection, handling errors idiomatically, or working with interfaces. For test conventions, use the `writing-go-tests` skill instead.

Write Go tests following project conventions. Use when creating test files, writing unit or integration tests, choosing mocks, or setting up test fixtures. Covers test naming, assertions, mock usage, table-driven patterns, and common pitfalls.

Implement proven backend architecture patterns including Clean Architecture, Hexagonal Architecture, and Domain-Driven Design. Use when (1) designing new backend systems from scratch, (2) refactoring monolithic applications for better maintainability, (3) establishing architecture standards for a team, (4) migrating from tightly coupled to loosely coupled architectures, (5) implementing domain-driven design principles, (6) creating testable and mockable codebases, or (7) planning microservices decomposition.

Apply Go best practices, idioms, and conventions from golang.org/doc/effective_go. Use when writing, reviewing, or refactoring Go code to ensure idiomatic, clean, and efficient implementations.