dotfiles

Loads up-to-date reference material from upstream git repos for nushell, zellij, jj, niri, ghostty, opencode, atuin, helix, starship, direnv, and flake-parts. Use when working on any of these tools and the answer depends on current syntax, APIs, defaults, or behavior that may have changed since training cutoff. Fetches chapters on demand via raw.githubusercontent.com; always cites the raw source URL.

Reference for the prr offline PR review file format. Covers comment types (PR-level, file, inline, spanned), snips, code suggestions, format constraints, common mistakes, and troubleshooting. Load when generating, validating, or editing a `.prr` file. The `review` skill loads this as needed.

Workflow for reviewing a GitHub PR offline using prr. Covers reading PR context, fetching the diff into a .prr file, supporting the user as they write inline comments in their editor, and validating the file. Use when the user wants to review a pull request, prepare a review, or run prr get/edit/status. Do NOT run prr submit — the user posts reviews themselves. Do NOT use for non-PR work (general codebase exploration, RFCs, etc.).

Jujutsu (jj) version control workflow for dotfiles. Covers log, diff, status, commit, absorb, rebase, split, restore, file ops, bookmarks, git fetch, undo, conflict resolution, and six common local workflows. Use for any VCS operation. Do NOT use for git commands — this repo uses jj.

SOP for creating opencode skills and agents. Walks through the full authoring workflow from requirements gathering through validation. Covers two skill types: SOP skills (step-by-step processes with parameters, constraints, and validation gates) and reference skills (principle-based guides with bad/good examples). Includes frontmatter spec, description writing, progressive disclosure, and agent authoring. Use when building a new skill, creating a new agent, or setting up skill/agent directories.

Enforces clean coding conventions for any implementation task. Covers guard clauses, extract method, immutability, define errors out of existence, naming, and comment-driven development. Use when writing, editing, fixing, implementing, or reviewing code at the function or file level. Do NOT use for API design, module boundaries, or service structure — use software-architecture instead.

Systematic debugging protocol emphasizing empirical investigation over code reasoning. Covers the observe-hypothesize-experiment-narrow loop, establishing failure conditions, gathering evidence from logs and VCS history, forming specific testable hypotheses, and designing experiments that distinguish between alternatives. Use when investigating crashes, test failures, unexpected behavior, or any situation where the system is not doing what it should.

Technical protocol for designing and structuring non-trivial software. Covers the impure-pure-impure sandwich, bounded contexts, event-driven patterns, dataflow modeling, and dependency rejection. Use when designing APIs, adding endpoints, defining module boundaries, structuring services, handling side effects, or deciding what should be public vs internal. Keywords: functional core, imperative shell, bounded context, event sourcing, CQRS, data pipeline, idempotency, short-circuiting. Do NOT use for function-level code style or refactoring within a single file — use code-writing instead.

Breaks complex tasks into ordered sub-tasks with dependencies. Use when a task requires multiple implementation steps that cannot be expressed as a single delegation.

Adversarial interview mode that walks the full decision tree one question at a time. Activated when the user wants more rigor than normal discussion — stress-testing a plan, getting grilled on a design, or mentions "grill me", "help me decide", "what are the options", "tradeoffs", "RFC", "design doc".

Guidelines for creating clear, readable Mermaid diagrams. Covers minimal styling, preferring many small focused diagrams over one large diagram, participant naming, structured flow control with alt/else/loop/opt, consistent message patterns, and common patterns for API endpoints and error handling. Use when creating sequence diagrams, flowcharts, architecture diagrams, or any visual representation of system behavior.