GenAI
Skills and agents I maintain — reusable instruction sets and personas that encode my development workflows, conventions, and best practices. Pulled from urmzd/dotfiles.
Agents
architect
Designs interface-first system architecture: decomposes modules, enumerates 2-3 approaches with tradeoff tables, recommends a path on Easy-to-Change grounds, and stages phased delivery plans with per-phase verification. Use when you need a design doc, module boundaries, an API contract, or a phased rollout plan before writing code. Read-only: produces designs, never edits. Do NOT use for executing multi-repo sweeps or batch edits; use strategist.
architectcurator
Sweeps documentation, formatting, naming, and cross-project conventions for consistency: audits the current state, references the governing standard, and applies the same fix across every instance, returning a deviation table. Use when you need a consistency pass, a style/naming alignment sweep, or polish across many files against an existing convention. Edits in place but refuses destructive ops. Do NOT use to author new prose or restructure docs; use writer for single-file authoring, technical-documentation-architect for multi-file docs-site restructuring.
curatordebugger
Performs evidence-based root-cause analysis: quotes the actual error, reproduces it, bisects what changed, forms one testable hypothesis, fixes the cause (not the symptom), and confirms the failing case now passes. Use when something is broken, a test fails, a stack trace appears, or you need fast diagnosis of a regression. Edits to apply the minimal fix. Do NOT use for greenfield design or feature planning; use architect.
debuggerguardian
Watches ONE tmux pane in an orchestrated fleet read-only: polls state, and on transition captures the smallest evidence slice and emits a single contract line, pinging only on needs-permission, error, done, or stuck. Never approves prompts, never edits code, never speculates. Use when the orchestrate-agents skill spawns a worker pane and needs a dedicated safety watcher. Do NOT use to drive the fleet or relay decisions unprompted; the orchestrator holds those verbs (send, spawn, kill, group).
guardianideator
Generates and ranks divergent feature and UX concepts before constraining: expands a prompt into multiple variations, describes how each feels to use, and returns ranked concepts with effort and risk noted. Use when brainstorming features, exploring UX possibilities, or wanting options before committing to one. Read-only ideation: proposes, never builds. Do NOT use to produce a buildable design doc or phased plan; use architect to harden a chosen concept.
ideatorstrategist
Executes write-capable multi-repo sweeps and batch operations: enumerates every target, dry-runs on one, presents a diff for approval, then applies across the full set with progress tracking and coverage verification. High blast radius (edits and runs scoped git/gh across many repos), so it gates on approval and halts on any anomaly. Use for cross-repo changes, batch edits, or systematic coordination over a known target list. Do NOT use to design the change itself (use architect) or for a single-convention consistency pass on one repo (use curator).
strategisttechnical-documentation-architect
Restructures multi-file documentation sets: organizes docs-site information architecture (getting-started / guides / reference / architecture / contributing), validates content against actual code, removes legacy material with migration notes, and decides what to auto-generate versus hand-write. Use when reshaping a docs site, reorganizing a docs/ tree, or aligning many docs pages with current implementation. This owns multi-file docs-site restructuring. Do NOT use for a single README/skill file (use writer) or a cross-file consistency/formatting sweep against an existing convention (use curator).
technical-documentation-architectwriter
Authors concise, outcome-focused technical documentation for a single file: structures frontmatter and sections, leads with the action, uses tables over prose, and treats examples and gotchas as mandatory. Use for writing or rewriting one README, skill file, or API doc that must serve both humans and AI agents. This owns single-file authoring. Do NOT use for multi-file docs-site restructuring (use technical-documentation-architect) or a cross-file consistency/formatting sweep against an existing convention (use curator).
writerGeneral
assess-quality
Foundational quality framework: the five questions (readable, easy to start, expands without bloat, consistent, intentional) every other dev skill is judged against, plus the dual-audience and workshop principles. Use when onboarding to a project, defining a quality bar, setting an assessment checklist, or arbitrating between review-design and write-code. Do NOT use for the design "why" layer (use review-design) or concrete tool/pattern picks (use write-code). For day-to-day "review my staged/unstaged changes" asks, use review-diff instead.
assess-qualityaudit-security
Scans a repo and host for leaked keys and secrets (gitleaks, trufflehog), audits SSH/GPG/.env file permissions, checks git hygiene, investigates suspicious processes and listeners, and hardens config (FileVault, firewall, SIP, SSH). Use when auditing for leaked credentials or secrets, checking for security issues before a commit, investigating an unknown process or open port, or hardening a machine. Do NOT use for storing, injecting, or rotating secrets at rest (1Password, op read, vaults) -> use manage-secrets; this skill only detects and reports exposure.
audit-securitybuild-cli
Design and audit CLI tools end-to-end: output modes, TTY detection, JSON piping, stderr/stdout separation, color/symbol semantics, the ui module pattern, signal handling, exit codes, and install.sh. Use when building, reviewing, or releasing any CLI and you need general CLI design guidance. Do NOT use for the mandatory urmzd/* portfolio CLI rules (argument-parser choice, self-update requirement, --format flag, global flags, install.sh template): cli-standards owns those and overrides this skill where they conflict.
build-clicheck-project
Validate project structure against scaffold conventions -- check for required files, CI consistency, documentation completeness, sub-package/workspace members, and optional directory usage, reporting PASS/WARN/FAIL with fix suggestions. Use to audit an existing project or verify a scaffold was applied correctly. Do NOT use to create or modify project files; this is a read-only auditor (use the scaffold-* skills to generate structure).
check-projectchoose-stack
Canonical tech-stack reference organized by purpose: release/versioning (sr), docs/demos (teasr, fsrc), codegen (oag), and per-language tools (cargo, clippy, clap, golangci-lint, biome, tsdown, uv, ruff, ty, pytest, pydantic, fastapi). Use when choosing a library, picking the standard CLI/linter/logging tool for a language, setting up a project, or asking "what do we use for X." Do NOT use for coding patterns or error-handling idioms (use write-code) or testing frameworks in depth (use test-code).
choose-stackcommunity-health
Scaffold the GitHub Community Standards files (CODE_OF_CONDUCT, SECURITY, ISSUE_TEMPLATE, pull_request_template) using $COMMUNITY_HEALTH_CONTACT or git config user.email as the contact. Use when bootstrapping a new repo or backfilling community-health coverage.
community-healthconfigure-ai
Authors AGENTS.md and defines the skills-vs-docs boundary for a repo. Configures AI coding tools (Claude Code, Codex, Gemini CLI, Copilot) and the skills-as-docs philosophy. Use when creating or auditing AGENTS.md, setting up AI tooling for a project, or deciding what belongs in a skill versus docs/. Do NOT use for README structure -> use write-readme; for llms.txt generation -> use create-llms-txt; for Claude-specific skill features (invocation control, subagents, model overrides) -> use extend-oss-skills-to-claude.
configure-aicreate-llms-txt
Generate a spec-compliant llms.txt file for any project by analyzing its codebase, docs, and public URLs. Use when creating an llms.txt, making a project LLM-discoverable, or when the user mentions "llms.txt" in the context of generating or scaffolding one.
create-llms-txtcreate-oss-skill
Create well-formed Agent Skills following the agentskills.io specification. Scaffold directories, write SKILL.md files, bundle scripts, and structure instructions for progressive disclosure. Use when creating a new skill, reviewing skill structure, optimizing a skill description, or setting up evals for skill quality.
create-oss-skilldiagnose-ci
Investigate failing REMOTE CI runs on GitHub Actions: find the failed run, pull the failed-step logs with gh, identify the root cause (compile error, test failure, lint, missing secret, timeout), and recommend a fix. Read-only: it does not commit, push, or edit. Use when CI is red, a GitHub Actions run failed, or the user asks "why did the pipeline fail". Do NOT use for local build/test/runtime failures on your machine (use diagnose-runtime); do NOT apply the fix and re-ship (use fix-and-retry) -- this skill investigates and recommends only.
diagnose-cidiagnose-runtime
Triage LOCAL runtime failures on your own machine: crashes and errors, hangs and deadlocks, slowness and high CPU/memory, and hardware/serial/USB issues. Method: reproduce, isolate (bisect, log, strace/dtruss, sample), form a hypothesis, verify the fix holds. Read-mostly: it inspects processes and logs, it does not commit, push, or edit source. Use when the user asks "why does this error", "why does the system hang after generating the PDF", "why is the computer running hot", "why is image loading slow", or "this process is stuck". Do NOT use for CI/pipeline failures (use diagnose-ci) or for applying and re-shipping a fix (use fix-and-retry) -- this skill investigates and recommends only.
diagnose-runtimeextend-oss-skills-to-claude
Extend standard agentskills.io skills with Claude Code-specific features. Invocation control, subagent execution, dynamic context injection, string substitutions, model/effort overrides, and deployment scoping. Use when adapting a portable skill for Claude Code, adding Claude-specific frontmatter, setting up subagent delegation, or configuring skill permissions.
extend-oss-skills-to-claudefix-and-retry
Diagnose a failing CI run, apply the code fix, commit it, push, and watch the re-run until it passes or fails -- the full fix-and-retry loop in one shot. Use after a pipeline fails and the user says "fix it and retry", "fix the CI and push", or "make CI green". Do NOT use for a read-only investigation that stops at a recommendation (use diagnose-ci); do NOT use for a routine commit unrelated to a CI failure (use ship).
fix-and-retrymanage-secrets
>- 1Password-based secret storage workflow: vault layout, 1p:// references in .envrc, op run for local execution. Use when storing or rotating credentials with 1Password. (Other backends not covered.)
manage-secretsorchestrate-agents
>- Orchestrate multiple agent CLIs (Claude, Codex, Gemini) via tmux with a shared fleet store, dispatching one guardian subagent per pane. Use when running a multi-agent session, dispatching parallel work, or coordinating subagents across panes.
orchestrate-agentspr
Open a pull request via gh pr create with an auto-generated title and summary derived from the commits on the branch, grouped by conventional-commit type. Use when the user says "create a pull request", "open a PR", "gh pr create", "raise a PR", or "make a PR for this branch". Assumes commits already exist and only opens the PR. Do NOT commit changes or watch CI (use ship); do NOT diagnose or fix a failing pipeline (use fix-and-retry / diagnose-ci).
prrelease-audit
Audit GitHub releases, git tags, and release assets for one repo or every repo in a directory. Flags orphaned tags, missing binaries/checksums, draft releases, floating tag drift, pre-release remnants, and (when sr.yaml is present) sr config issues. Read-only: never deletes or modifies tags/releases. Use when checking "release health", "orphaned tags", "missing assets", "draft releases stuck", or "is sr.yaml configured right". Do NOT use to cut or publish a release, and do NOT use to set up the release pipeline -- this only audits and reports.
release-auditrepo-init
End-to-end repo bootstrap: creates the GitHub repo (gh repo create), adds an Apache-2.0 LICENSE, dispatches to scaffold-project for CI/release/config, invokes community-health, writes a README, sets topics/description, and makes the initial commit and push. Use when starting a brand-new project from zero and you need the GitHub repo, metadata, and first push handled, not just local files. Do NOT use to scaffold files inside an existing repo; invoke scaffold-project directly for that.
repo-initrepo-status
Scan a folder of git repos and report each repo's local dirty/clean state, ahead/behind divergence from upstream, recent activity, and latest CI run status. Read-only: never commits, pushes, or edits. Defaults to the folder argument or your repo root. Use when checking "what's live", "which repos are dirty", or "repo status across my projects". Sibling skills overlap on folder scanning: do NOT use for "what should I work on next" prioritization (use get-work); do NOT use for a recent-activity-only overview without dirty/CI detail (use status). repo-status is the local dirty/ahead/behind + CI-state report.
repo-statusreview-design
Pragmatic Programmer principles: DRY, orthogonality, ETC, reversibility, tracer bullets, design by contract, decoupling/Law of Demeter, pragmatic paranoia. The 'why' layer between assess-quality (framework) and write-code (operational). Use when reasoning about design tradeoffs, coupling, or whether a decision is reversible. Do NOT use for the underlying quality framework (use assess-quality) or for concrete tool/idiom/library picks (use write-code).
review-designreview-diff
Standardized review of the CURRENT working-tree changes -- staged, unstaged, and untracked -- against an explicit five-dimension rubric (correctness, security, tests, scope-creep, conventions). Emits a prioritized findings list, each with file:line, severity, and a suggested fix. Read-only: it reviews and reports, it does not commit, push, or edit. Use when the user says "review my changes", "review the diff", "look over my staged changes before I commit", or "what's wrong with this PR locally". Do NOT use for red CI/pipeline failures (use diagnose-ci) or whole-repo quality-framework questions (use assess-quality); this reviews the working-tree diff only. assess-quality and review-design both EXCLUDE day-to-day review and name this skill as its home.
review-diffscaffold-go
Scaffold a complete Go project with CI/CD, release pipeline, Makefile, sr.yaml, .envrc, and standard files. Uses go toolchain and make as the native build system. Loads on top of scaffold-project (run that first for cross-language standard files). Use when creating a new Go CLI, service, or module, or when the user mentions "new Go project", "go mod init", or "Go scaffold". Do NOT use for Rust, Python, Node, or Terraform projects; use the matching scaffold-<lang> skill.
scaffold-goscaffold-node
Scaffold a complete Node/TypeScript project with CI/CD, release pipeline, sr.yaml, .envrc, and standard files. Uses pnpm and biome. Loads on top of scaffold-project (run that first for cross-language standard files). Use when creating a new Node.js app, TypeScript library, or website, or when the user mentions "new Node project", "pnpm init", "TypeScript scaffold", or "Astro site". Do NOT use for Go, Rust, Python, or Terraform projects; use the matching scaffold-<lang> skill.
scaffold-nodescaffold-project
Generates cross-language standard files (README, AGENTS.md, LICENSE, CONTRIBUTING.md, SECURITY.md, sr.yaml, .envrc, llms.txt), documentation conventions, and project structure, then dispatches to language-specific scaffolds. Use first for cross-language standard files and structure, THEN load the matching scaffold-<lang> skill (scaffold-rust, scaffold-go, scaffold-python, scaffold-node, scaffold-terraform) for CI/CD, release pipelines, and tooling. Use when creating or standardizing projects. Do NOT use alone for a single-language project; co-load the matching scaffold-<lang> skill for its CI/CD and tooling.
scaffold-projectscaffold-python
Scaffold a complete Python project with CI/CD, release pipeline, justfile, sr.yaml, pyproject.toml, .envrc, and standard files. Uses uv, ruff, and justfile (Python lacks a native task runner like pnpm scripts, so just fills that gap). Loads on top of scaffold-project (run that first for cross-language standard files). Use when creating a new Python CLI, library, or application, or when the user mentions "new Python project", "uv init", or "Python scaffold". Do NOT use for Go, Rust, Node, or Terraform projects; use the matching scaffold-<lang> skill.
scaffold-pythonscaffold-rust
Scaffold a complete Rust project with CI/CD, release pipeline, and sr.yaml. Uses cargo as the native build system. Loads on top of scaffold-project (run that first for cross-language standard files). Use when creating a new Rust CLI, library, or workspace, or when the user mentions "new Rust project", "cargo init", or "Rust scaffold". Do NOT use for Go, Python, Node, or Terraform projects; use the matching scaffold-<lang> skill.
scaffold-rustscaffold-terraform
Scaffold a Terraform infrastructure project with CI/CD (plan on PR, apply on push), AWS OIDC auth, .envrc, and standard files. Uses terraform CLI as the native tool. Loads on top of scaffold-project (run that first for cross-language standard files). Use when creating infrastructure repos, or when the user mentions "new Terraform project", "terraform init", "AWS infra", or "infrastructure scaffold". Do NOT use for Go, Rust, Python, or Node application projects; use the matching scaffold-<lang> skill.
scaffold-terraformsetup-ci
Defines GitHub Actions workflow structure: ci.yml + release.yml naming, concurrency groups, bot-commit skip, workflow_call reuse, App-token checkout, and optional fsrc/teasr steps. Language-specific pipelines live in scaffold-rust, scaffold-go, scaffold-python, scaffold-node, scaffold-terraform. Use when setting up GitHub Actions, wiring ci.yml/release.yml, configuring concurrency or workflow_call, or adding fsrc/teasr steps. Do NOT use for sr.yaml schema, typed publishers, or the sr CLI/action; use sync-release for those.
setup-cisetup-devenv
Per-language runtime version managers (fnm, uv, rustup) plus the vanilla-direnv .envrc pattern (layout python, use fnm, PATH_add, dotenv, source_up) for project dev environments. Use when bootstrapping a project's local toolchain, choosing a version manager, or writing a project .envrc. For chezmoi-managed pinned installer scripts and the tracked dot_envrc.project.example template, use setup-devenv-with-chezmoi.
setup-devenvsetup-devenv-with-chezmoi
Chezmoi-specific dev environment helpers: writing pinned-version installer scripts (run_onchange_after_install-<tool>.sh.tmpl), maintaining the dot_envrc.project.example template, and the chezmoi diff/apply loop. Use when wiring a new pinned vendor installer (gcloud, aws-cli, Cortex) for the portfolio or scaffolding a chezmoi-tracked project envrc. Do NOT use for portable per-language version-manager or vanilla-direnv patterns; those live in setup-devenv.
setup-devenv-with-chezmoiship
Generate a conventional commit message from staged or unstaged changes and create an atomic commit, then optionally push and watch CI until it passes or fails. Use when the user says "write a commit", "generate a commit message", "commit this", "git add .", or "ship this". Push and CI-watch are optional and skipped if the user only wants a commit. Do NOT open a pull request (use pr); do NOT diagnose-then-fix a failing pipeline (use fix-and-retry); do NOT do a read-only CI investigation without committing (use diagnose-ci).
shipstyle-brand
Frame and document a project's visual identity: terminal theme, font, demo capture pipeline, asset conventions. Use when establishing or maintaining brand consistency. Ships an example brand (Cyberdream + MonaspiceNe + teasr) as a template, not a mandate.
style-brandsync-docs
Audit and synchronize project documentation. Detect staleness, fix drift, and keep cross-references consistent across whatever docs the project has. Delegates file-specific rules to the skills that own them. Use after feature changes, refactors, or when docs may be stale. Can be run as a scheduled agent or invoked manually.
sync-docssync-ecosystem
Audit one repository against ecosystem conventions (naming, capabilities, terminology, doc coverage, version discipline, canonical skill coverage) and emit a read-only drift report. Use when onboarding a repo, auditing convention drift, or checking ecosystem consistency after a refactor. This skill only reports; it never edits the target repo or the skill store. Do NOT use for applying fixes back into the chezmoi-managed canonical store; use sync-ecosystem-to-chezmoi for that.
sync-ecosystemsync-ecosystem-to-chezmoi
Take a drift report from sync-ecosystem and apply its fixes to the chezmoi source directory (create/edit skill dirs, assets, scripts), then run chezmoi apply so the canonical skill store and deployed copies stay in sync. Use when you maintain agent skills in chezmoi and have a pending drift report to merge back, or to promote a skill from a project repo into the canonical store. Do NOT use to generate a drift report or audit a repo; run sync-ecosystem first for that.
sync-ecosystem-to-chezmoisync-release
Owns release-pipeline conventions: sr.yaml schema, the sr CLI verbs (init/plan/prepare/ release) and urmzd/sr action, typed publishers (cargo/npm/pypi/docker/go/custom), monorepo workspace discovery, version_files/stage_files mapping, and post-release patterns. Language-specific build targets live in scaffold-rust, scaffold-go, scaffold-python, scaffold-node. Use when writing or editing sr.yaml, choosing a publisher, or wiring the sr action. Do NOT use for GitHub Actions workflow file structure, ci.yml/release.yml naming, concurrency, workflow_call, or the App-token checkout; use setup-ci for those.
sync-releasetest-code
Testing philosophy, test types (unit, integration, golden, fuzz, property, benchmark, smoke, E2E), per-language conventions (Rust, Go, Python, TypeScript), file organization, fixtures/mocks, CI strategy, and what NOT to test. Use when writing tests, reviewing test coverage, setting up test infrastructure, or deciding what to test. Do NOT use for general implementation patterns or error handling (use write-code) or design-by-contract reasoning (use review-design).
test-codeupdate-repo-meta
>- Update GitHub repository metadata via the gh CLI: add or remove repo topics, set the description, set the homepage URL, and change visibility (public/private). Reads current state and shows before/after. Use when updating repo settings, retagging topics, fixing a repo description or homepage, or making a repo public or private. Do NOT use to edit local repo files, branch protection, or release metadata; this only touches repo-level settings exposed by gh repo edit.
update-repo-metawrite-code
Operational tech-stack picks and coding patterns: error handling per language, commit conventions, interface design (Go SDKs), workspace layout, junior-friendly bias. Use when writing or reviewing implementation code and you need a concrete answer for "what tool, pattern, or idiom." Do NOT use for design-tradeoff reasoning (use review-design) or the quality framework (use assess-quality). Personal Nix / chezmoi / Powerlevel10k / Neovim machine specifics live in write-code-portfolio; use that for portfolio-only setup.
write-codewrite-code-portfolio
Personal portfolio dev-setup: add or remove a package/tool in flake.nix per-language shells, edit chezmoi installer scripts, and adjust Powerlevel10k (dot_p10k.zsh), Nix, or Neovim (private_dot_config/nvim) machine config. Use when editing chezmoi-managed dotfiles, adding/removing a language toolchain or CLI to a Nix shell, changing the zsh prompt, tweaking Neovim, branching dotfiles on machine attributes (is_macos / is_personal / is_work), or bootstrapping a new machine in this portfolio. Do NOT use for portable coding patterns or general tech-stack picks; use write-code for those.
write-code-portfoliowrite-readme
Structures and writes a project README: centered header, badges, demo image, section order, install.sh one-liner, Quick Start, fsrc code embeds, and the Agent Skill section. Use when creating or updating any project's README.md. Do NOT use for AGENTS.md or the skills-vs-docs taxonomy -> use configure-ai (configure-ai owns AGENTS.md and the docs taxonomy; write-readme owns README structure). For llms.txt generation -> use create-llms-txt.
write-readme