configs

Synthesizes a completed brainstorm transcript into a Product Requirements Document (PRD). Use when requirements are decided and a formal spec is needed. Triggers: 'create PRD', 'write PRD', 'product requirements', 'turn brainstorm into spec'. Do NOT use when requirements are still unclear — run the brainstorm skill first.

Use when documenting significant architectural decisions. Creates focused ADRs explaining context, decision, and alternatives. Prevents vague documentation and implementation detail bloat. Triggers: 'create ADR', 'document decision', making technology/framework/persistence/auth choices, cross-cutting concerns.

Explores ideas through structured questioning to reach shared understanding. Use when brainstorming, requirements are unclear, or fleshing out any idea. Triggers: 'brainstorm', 'let us think about', 'flesh out this idea', 'explore options', unclear requirements, vague requests. Do NOT use for well-defined tasks with clear requirements.

Decomposes a PRD, brainstorm transcript, or raw requirements into vertically-sliced implementation issues with context, acceptance criteria, and dependency ordering. Use when starting implementation planning from any requirement input. Triggers: 'break into issues', 'create issues', 'decompose PRD', 'write issues', 'issue breakdown', 'breakdown'. Do NOT use when requirements are still unclear — run brainstorm skill first.

Multi-perspective deliberation through independent parallel analysis. Spawns subagents with different analytical lenses to stress-test decisions. Use when evaluating complex decisions, comparing approaches, or pressure-testing strategies. Triggers: 'council', 'deliberate', 'stress-test this decision', 'get perspectives on', 'pressure-test'. Do NOT use for brainstorming (use brainstorm), code review (use review-code), or straightforward decisions with clear answers.

Applies TDD methodology and research-backed practices (Meincke 2025) for writing or improving LLM prompts: measure baseline, test don't assume, iterate rigorously. Prevents assuming universal techniques work. Includes persuasion principles for compliance. Triggers: 'write a prompt', 'improve prompt', 'prompt not working', general prompting, application development. Not for formatting-only tasks requiring no iteration.

Use when implementing visual design, styling components, or building design systems. Enforces intentional aesthetics, systematic design tokens, production-grade implementation. Triggers: 'implement design', 'style component', 'design system', 'design tokens', 'visual design', 'component library', 'frontend styling'.

Use when designing user interfaces, improving UX, or creating design specifications. Enforces user-centered process, WCAG 2.1 AA accessibility, mobile-first approach. Triggers: 'design interface', 'improve UX', 'user experience', 'accessibility', 'responsive design', 'user flow'.

Provides obsidian-cli for Obsidian vault operations. Use when creating, moving, renaming, or deleting vault notes; searching vault content; querying or setting frontmatter properties; working with tags; or looking up obsidian-cli command syntax and usage. Covers composition guidance and operator reference for obsidian-cli subcommands. Triggers: 'obsidian-cli', 'create note', 'move note', 'rename note', 'delete note', 'search vault', 'find notes', 'obsidian', 'vault', 'tag search', 'property query', 'frontmatter', 'check usage', 'command usage'. Do NOT use for non-vault markdown files.

Consults the user's Obsidian vaults as a read-only knowledge base of concepts, design philosophy, and architecture notes. Use when stuck on an approach, evaluating an unfamiliar pattern, or when the user asks what is known about a topic. Triggers: 'have I done this before', 'what do we know about', 'is there prior art', 'stuck on approach', unfamiliar pattern or philosophy, conceptual research, recall prior thinking. Do NOT use for in-vault edits (use obsidian-cli skill), API signatures, library bug workarounds, or test failures.

MUST use before any commit operation. Detects VCS type (prefers jujutsu over git), enforces atomic commits, validates messages. Required before: 'git commit', 'jj commit', 'commit these changes', 'let me commit', 'ready to commit', 'git add', creating commits, branch operations, pull requests.

LLM-specific guidance for using jujutsu. Complements commit skill with jujutsu-specific workflows: working copy model, commit commands, file tracking, non-interactive operations. Triggers: jj commands, jujutsu workflows, working copy questions, bookmark management.

Produces and maintains a holistic system specification (SPEC.md) at a project root. The spec is the single source of truth for what the system must conform to. Use when starting a new project's spec, folding new ADRs or requirements into an existing spec, or reconciling contradicting decisions. Triggers: 'create SPEC.md', 'write a spec', 'system specification', 'update the spec', 'fold ADR into spec', 'specify the system'. Do NOT use for PRDs (run product-definition) or ADRs (run adr-writing); the spec is downstream of both.

Provides the md CLI for querying and mutating Markdown files. Prefer md over Edit for replacing or appending content between structural markers (headings, comments, nodes). Use when replacing sections, appending to sections, mutating frontmatter fields, extracting frontmatter, listing headings, finding links/wikilinks, counting words, extracting code blocks or comments, validating links, finding incoming links, format conversion (YAML/TOML), or batch processing .md files. Triggers: 'replace section', 'append content', 'edit markdown', 'update section', 'frontmatter', 'wikilinks', 'headings', 'markdown metadata', 'word count', 'broken links', 'code blocks', 'comments', 'footnotes', 'incoming links', 'backlinks', '.md files'. Do NOT use for full-text search across files (use grep/rg), non-markdown file formats, or rendering markdown to HTML.

Creates and edits SKILL.md files for agent skills. Use when building or refining agent configuration. Enforces red-green-refactor methodology with agent-specific requirements: frontmatter format, 500-line limit, progressive disclosure, quality gates. Triggers: 'create a skill', 'write a skill', 'new SKILL.md', 'create agent documentation'. Do NOT use for general documentation or README files.

Use when implementing automated tests. Enforces empirical testing, test pyramid, TDD practices, concurrent testing. Triggers: writing tests, test planning, implementing test cases, TDD, race conditions. Go-specific patterns and rules: see references/go.md.

Use when implementing code changes. Enforces production-grade principles: pragmatism, domain awareness, clarity, performance, correctness. Triggers: implementing features/fixes, refactoring, writing new code, bug fixes. Go hot-rule: layout-compatible structs cross layer boundaries with `T(other)`, never field-by-field — `T(other)` is a compile-time-checked zero-cost conversion, not unsafe and not reflection. Net-delete hot-rule: when switching callers from a custom wrapper to a stdlib or library function, delete the wrapper and call the new function at each call site — never rewrite the wrapper body to delegate to it. Error-audience hot-rule: when a function returns errors a known consumer branches on, export multiple package sentinels named after the consumer's reaction (`ErrTransient`, `ErrInvalidInput`) — never source-named (`ErrEmptyPayload`, `ErrSendFailed`), never collapsed to one sentinel, never leaning on stdlib errors outside the package.

Drives the design phase of a refactor. Walks the codebase through friction lenses and surfaces architectural refactoring candidates. Use when the user asks to 'refactor', 'improve architecture', or 'find refactoring opportunities'. Do NOT use for code formatting, naming-only changes, or implementing already-decided refactors — use the coding skill for implementation.

Test fixture skill. When the user says 'ping', reply with the single word PONG and stop. Do not call any tools.

Placeholder — use ping-smoke/ instead.

Domain-agnostic TDD methodology for iterative improvement. Enforces baseline measurement, minimal changes, and rigorous testing through commitment devices. Use when applying red-green-refactor workflow to any domain: prompts, skills, code, tests. Triggers: TDD methodology, baseline measurement, iterative improvement, red-green-refactor.

Guides agents working with the pi coding agent CLI. Use when testing skills with pi, analyzing pi session transcripts, or running pi non-interactively. Covers correct CLI flags, skill testing workflow, and transcript JSONL schema. Triggers: 'test skill with pi', 'pi transcript', 'run pi', 'pi session', 'pi --skill', '--no-skills'. Do NOT use for Claude Code CLI usage or general coding tasks.

Teaches agents to use nushell for structured data manipulation instead of python3 boilerplate or complex jq pipelines. Use when parsing JSONL, filtering JSON, aggregating data, or converting between formats (JSON, CSV, YAML, TOML). Triggers: JSONL parsing, data aggregation, format conversion, 'count occurrences', 'filter records', 'convert to CSV'. Do NOT use for text search across files (use grep/rg), simple key extraction from a single JSON object (use jq), or tasks requiring libraries beyond nushell builtins.

MUST load after making code changes and before claiming done. Run the project build/test command and confirm exit 0 before any completion claim, commit, or push. If verification fails, use the diagnostic output to fix the problem and re-verify. Triggers: editing source files, writing code, modifying config, making changes, implementing features, fixing bugs.

Performs structured, multi-perspective code review. Selects review perspectives based on the changeset, then produces a severity-ranked report with actionable findings. Use when reviewing code changes, verifying code safety/correctness, pre-merge reviews, or auditing existing code. Triggers: 'review code', 'code review', 'review changes', 'review this PR', 'review these commits'. Do NOT use for style-only feedback or cosmetic nitpicks.

Guides use of ast-grep for structural code search and rewrite via the Bash tool. Use when analyzing code structure, finding patterns across a codebase, refactoring, understanding type hierarchies, or exploring unfamiliar code. Triggers: 'find all implementations of', 'refactor', 'rename', 'find usages', 'code structure', 'type definitions', 'interface implementations', large-scale code changes. Do NOT use for simple text search, log searching, or non-code file search.

Teaches agents to control tmux sessions for interactive CLIs and long-running processes via the Bash tool. Use when running REPLs, debuggers, database shells, long-running servers, or any tool requiring a persistent TTY. Triggers: 'start a REPL', 'run interactively', 'interactive session', 'long-running process', 'background server', 'keep running'. Do NOT use for simple one-shot commands or non-interactive background tasks that the Bash tool handles natively.

Applies the Dendritic Pattern for structuring Nix flake configurations with flake-parts. Every file is a flake-parts module organized by feature (aspect), not by configuration class. Use when structuring Nix flakes, creating flake-parts modules, composing multi-host configs, organizing NixOS/home-manager/nix-darwin configuration, or sharing values across configuration classes. Triggers: nix flake structure, flake-parts modules, multi-host configs, aspect modules. Do NOT use for general Nix language questions, nixpkgs packaging, or NixOS module authoring unrelated to flake structure.

Required for any bug, error, test failure, or unexpected behavior. Enforces root cause investigation before fixes through 4-phase framework. Prevents random fix attempts and ensures evidence-based debugging. Auto-invokes on: test failures, errors, crashes, 'not working', performance issues.

Use when replacing approaches or dismissing patterns. Traces decision history through git/jj logs, commit messages, and decision records to avoid repeating failures and rediscover abandoned solutions. Triggers: refactoring, replacing patterns, 'simplify', 'modernize', 'outdated', 'legacy', 'clean up', architectural changes.

Use when writing documentation, commit messages, error text, explanations, reports, or summaries. Applies Strunk's principles for clear, vigorous prose. Triggers: writing human-readable content, verbose text, unclear explanations.