taloncjones
@taloncjones
Public Skills
herdr-orchestration
by taloncjones
Use to run the director - a Claude-led standing per-repo orchestrator over Herdr that turns a designated Jira ticket or repo todo into a briefed worker session in a worktree workspace, tracks it through a hook-fed event log, and dispatches an independent reviewer before handing back for merge. Preferred launch is claude --agent director in a herdr pane; also trigger when the user says "kick off <TASK>", "what's queued", "status", or asks the director or orchestrator to supervise delegated work. Codex participates through bounded UI/prose/review work; requires HERDR_ENV=1.
dotfiles-debugging-playbook
by taloncjones
Symptom-to-fix triage for this dotfiles repo. Load when something is BROKEN and you need to diagnose it -- plugin skills/commands missing from a session, settings.json truncated, dangling or write-through symlinks, "git refuses to commit" or wrong commit identity, SSH offering the wrong key, a guard hook blocking a commit, a cloud session missing its config, blank statusline, dead hooks, zsh nags, prettier rewriting files unexpectedly, or a worktree missing .todos/.planning. Trigger phrases: "why is X missing", "commit blocked", "hook didn't run", "wrong identity", "symlink broken", "plugin not installed". NOT for routine operation (dotfiles-run-and-operate), proving healthy state from first principles (dotfiles-verification-toolkit), or the history of past investigations (dotfiles-failure-archaeology).
dotfiles-docs-and-writing
by taloncjones
Use when writing or updating any doc of record in this dotfiles repo -- README.md, repo CLAUDE.md, claude/global-instructions.md, claude/operating-principles.md, codex/AGENTS.md, NOTICE -- or when authoring a new skill or slash command file. Trigger on "update the README", "document this", "where should this fact live", "add a skill", "add a command", "the docs are stale", "docs drift", or any house-style question (emoji tags, dash style, commit-message format). Not for platform mechanics content itself (use claude-code-platform-reference), change gating and review process (use dotfiles-change-control), or public-repo/licensing posture decisions (use dotfiles-external-positioning).
dotfiles-config-and-flags
by taloncjones
Catalog of every environment variable, script flag, and config knob in this dotfiles repo -- consumer, default, effect, and whether it is production, test-only, or emergency-bypass. Load when asking "what does VAR do", "is there a flag for X", "how do I skip a hook", "what reads CLAUDE_CONFIG_DIR / CLAUDE_CODE_REMOTE / GSD_HOOK_REPAIR" (the retired ECC's ECC_VENDOR_LANGS no longer exists), "why is --local ignored", "what keys does settings.json.tmpl own", or before adding a new flag. NOT for diagnosing breakage (dotfiles-debugging-playbook), running the update/plugin lifecycle (dotfiles-run-and-operate), platform semantics of the vars Claude Code itself defines (claude-code-platform-reference), or recreating a machine (dotfiles-build-and-env).
co-review
by taloncjones
Freeze a finished change, collect two or four independent review seats by change class, and evaluate one fail-closed final-gate report.
ship
by taloncjones
Use when a branch or PR is implementation-complete and the user wants it taken through the explicit merge gate and cleanup.
co-review
by taloncjones
Freeze a finished change, collect two or four independent review seats by change class, and evaluate one fail-closed final-gate report.
dotfiles-validation-and-qa
by taloncjones
What counts as evidence in the dotfiles repo, the full test-suite inventory with run commands, how to add and register a new test, and the known coverage gaps. Load when asked "how do I run the tests", "is there a test for X", "add a test", "what does this test failure mean", "is this change verified", or before claiming any change is done. Not for diagnosing a live broken machine (dotfiles-debugging-playbook), not for step-by-step proof recipes of symlinks/plugins/identity (dotfiles-verification-toolkit), and not for the change-gating rules themselves (dotfiles-change-control).
voice
by taloncjones
Use before posting any outward-facing text an agent wrote (PR title or body, PR comment, Jira title, description, or comment, code comment or docstring) to run an independent voice pass with Codex. Trigger on "voice pass", "de-generify this", "make this sound human", "check this PR body". Returns a rewrite plus what changed and why; never posts, edits, or commits on its own.
todos
by taloncjones
Use when capturing, listing, completing, or reviewing cross-session todos for a repo. Trigger when the user says "track this", "add a todo", "what todos are open", "mark that done", or wants a persistent backlog that survives across sessions (unlike the built-in TodoWrite tool, which is session-only).
post-merge
by taloncjones
Use after a PR is merged to tear down its worktree/branch and sync its Jira ticket. Removes the merged branch's git worktree (handling submodule-bearing worktrees), deletes the local + lingering remote branch, sweeps co-review leftovers, then transitions the linked Jira issue to Done, assigns it to me, adds it to the current sprint, sets its epic, and posts a resolution comment. Finally distills tagged agent lessons into
dotfiles-change-control
by taloncjones
Load BEFORE making, committing, or reviewing ANY change in the dotfiles repo. Covers change classification (tracked asset vs installer logic vs machine-local template vs vendored-untracked vs project .claude config), the full gate chain (guard hooks, bin/dotfiles-tests, public-safety scan, CI), commit/branch/PR rules, and the non-negotiables with their incident history. Trigger phrases -- "commit this", "open a PR", "why did my commit get blocked", "can I edit settings.json.tmpl", "can I edit these rules files", "hook blocked me", "bypass the hook". NOT for diagnosing why something is broken (dotfiles-debugging-playbook), running the tests as evidence (dotfiles-validation-and-qa), or historical why-decisions (dotfiles-failure-archaeology).
dotfiles-architecture-contract
by taloncjones
Load BEFORE proposing any structural or design change to the dotfiles repo, and whenever you catch yourself asking "why is it built this way", "can I just track this file", "why is settings.json not symlinked", "why two config dirs", "why is this untracked", or "can the SessionStart hook install the plugin". Documents the eight load-bearing design decisions with rationale, the invariants that must hold, and the known weak points, plus the install-layout reference (install flow, symlink and seed targets, hook catalogue) and the Codex plugin integration reference (codex-surfaces.py / codex-roles.py reconciliation, staging provenance). NOT for making/committing a change (dotfiles-change-control), diagnosing a breakage (dotfiles-debugging-playbook), or the blow-by-blow incident history (dotfiles-failure-archaeology).
dotfiles-verification-toolkit
by taloncjones
First-principles proof recipes for this dotfiles repo -- prove a symlink chain, a plugin install, a git identity resolution, an SSH key selection, a hook firing, a settings merge, a cloud snapshot, or worktree hydration, instead of trusting an exit code or an install log. Load when asked "prove it", "is it actually installed/linked/registered", "which identity/key does this repo use", "did the hook fire", "did the snapshot carry", or before claiming any install/link/config step succeeded. For interpreting a FAILED proof use dotfiles-debugging-playbook; for the packaged doctors and test runner use dotfiles-diagnostics-and-tooling.
dotfiles-failure-archaeology
by taloncjones
Chronicle of every settled investigation, dead end, and revert in this dotfiles repo, with commit hashes and lessons -- load BEFORE re-investigating anything that smells already-decided. Trigger on "why was X removed", "has this been tried before", "why doesn't the SessionStart hook install plugins", "should we re-add tiered orchestration / a per-task Codex gate", "can we reinstall gsd / get-shit-done", "why are ECC rules untracked", "why not mirror plugins into ~/.codex", or any proposal to revert a revert. For live symptom triage use dotfiles-debugging-playbook; for how changes are gated use dotfiles-change-control; for current design rationale use dotfiles-architecture-contract.
dotfiles-research-methodology
by taloncjones
Use when turning a hunch, idea, or half-diagnosed problem in this dotfiles repo into an accepted change -- when you are about to say "I think the cause is X", propose a new subsystem, or decide whether an experiment "worked". Trigger phrases -- "I have a theory", "should we build/add/try X", "is this fix real", "the test passed so we're done", "let's just remove it". Covers the evidence bar (one mechanism explains ALL observations), predict-before-run, the idea lifecycle (adopted AND retired both count as success), and where good ideas historically came from. NOT for executing an already-approved change (dotfiles-change-control), triaging a live failure (dotfiles-debugging-playbook), looking up a settled past investigation (dotfiles-failure-archaeology), or picking a new open problem to work on (dotfiles-research-frontier).
claude-code-platform-reference
by taloncjones
Load when you need Claude Code PLATFORM mechanics as used by this repo -- config-dir resolution and CLAUDE_CONFIG_DIR, what lives in ~/.claude, settings.json precedence and key ownership, plugin/marketplace internals (installed_plugins.json, known_marketplaces.json, marketplace manifests, CLI verbs), hook events/matchers/exit codes, skills vs commands vs agents, CLAUDE.md @import, cloud-container env vars and launch ordering, statusline wiring. Trigger phrases - "how do plugins actually install", "where does settings.json come from", "what is CLAUDE_CONFIG_DIR", "why did my hook not fire", "what runs at session start", "what is installed_plugins.json". This is the factual reference; for step-by-step operations use dotfiles-run-and-operate, for env recreation use dotfiles-build-and-env, for proving state use dotfiles-verification-toolkit.
weekly
by taloncjones
Compose my "Work Last Week / Work This Week" row for the weekly meeting Confluence page from my merged/open PRs and active Jira, and output it as a copyable block by default. Writes to my row only if I explicitly ask. Per-project config in ~/.claude/reconcile/projects.json.
herdr-orchestration
by taloncjones
Use when Codex is asked to contribute UI/UX direction, bounded UI implementation, prose, or independent review to a Claude-led Herd task. This installed compatibility entrypoint points to the canonical shared workflow; it does not make Codex the Herd controller.
writing-plans
by taloncjones
Use only when the owner asks for a task-by-task implementation plan from a reviewed PRD; the default pipeline implements straight from the PRD.
brainstorming
by taloncjones
Use before creative or behavior-changing work - features, components, new behavior - to agree intent and design before any implementation.
writing-specs
by taloncjones
Use after a design is approved in brainstorming, to write the PRD that the spec review gate checks and implementation works from.
claude-spec-review
by taloncjones
Obtain a bounded independent Claude review of one explicit frozen specification.
codex-spec-review
by taloncjones
Obtain a bounded independent Codex review of one explicit frozen specification.