Recently Added
Fresh skills just added to the collection. Be the first to try them out!
character
by dcramer
Make a game character for Terra (a base body, an NPC, a body template or morph) from a design sheet to a rigged, animated, checked model in the game: concept image, Tripo model and auto-rig on the Studio subscription, conversion onto our skeleton, the rig checker, export, and a look in the sandbox's workbench. Use when asked to make, generate, rig or fix a character or humanoid model.
building
by dcramer
Work on Terra's construction (terra_build and the game's building): walls, floors, roofs, openings, decks and stairs of cubes, their materials, kits and dressed pieces, how they are drawn, damaged and taken down, and the checks that hold them. Covers the scope (D333), the agents' routine, which checks a change of geometry, look, performance or material must pass, where each concern lives in the code and data, how to measure, and what to report. Use for any task that changes or judges building, its kits or its checks, so a brief needs to say only the task.
blender
by dcramer
Work in Blender for Terra, headless through tools/blender/run.sh or live in the developer's open Blender through its MCP server (mcp__blender__* tools). Use when asked to open, inspect, clean up, fit, render or export a model or .blend in Blender, or when a Blender MCP call fails.
release-readiness
by RunLumi
Prepare or review LinePaycheck for TestFlight, App Store submission, signing/configuration, privacy, StoreKit, versioning, or release-critical changes.
payroll-domain
by RunLumi
Change or review LinePaycheck pay calculation, time semantics, agreement rules, reconciliation, money types, or canonical payroll fixtures. Use whenever a task can change an expected-pay number or its explanation.
mobile-ui-qa
by RunLumi
Visually and behaviorally verify LinePaycheck iOS UI in Simulator and maintain Maestro flows. Use for SwiftUI layout, navigation, onboarding, sheets, forms, accessibility selectors, visual polish, or E2E regression work.
ios-feature
by RunLumi
Implement or materially change a LinePaycheck native iOS feature. Use for SwiftUI screens, app state, navigation, adapters, StoreKit, persistence, OCR, export, or other iOS product work.
passo
by JonathanSantos
Conduz um pedido de código pelo Passo, passo a passo, com o dev aprovando. Use quando pedirem algo "com o passo", ou para qualquer mudança de código, feature, bug ou projeto num repositório com a pasta .passo/.
model-tuning
by taloncjones
Cross-model behaviors and per-family tuning deltas for the current Claude families (Opus, Sonnet, Fable) plus the model-retirement playbook. Use when authoring or pruning skills, subagent prompts, Workflow scripts, or API calls that pin a model, set effort, budget tokens, or handle safety-classifier refusals or forced-tool-use errors - when prompting for code review, frontend work, or unattended agent runs - and when a model is added, retired, or an alias moves to a new model.
kickoff
by taloncjones
Use when the user wants to continue a saved task after a restart, resume from a handoff, or move an existing task between Claude and Codex.
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.
handoff
by taloncjones
Use when the user wants to pause work, restart the runtime, change sessions, or preserve a task for another Claude or Codex session.
codex-spec-review
by taloncjones
Obtain a bounded independent Codex review of one explicit frozen specification.
codex-plan-review
by taloncjones
Obtain a bounded independent Codex review of one explicit frozen implementation plan.
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.
brief
by taloncjones
Use for a forward-looking morning brief - what to focus on today. Aggregates time-relevant todos across all registered repos and joins them with PRs awaiting your action and your active Jira tickets. Trigger on "morning brief", "what's on today", "daily brief", "what should I work on".
brainstorming
by taloncjones
Use before creative or behavior-changing work - features, components, new behavior - to agree intent and design before any implementation.
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-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).
dotfiles-run-and-operate
by taloncjones
Day-to-day operation of an already-installed dotfiles machine. Load when asked to "update the dotfiles", "reload zsh", clean up leftovers from a retired plugin (its uninstall function is the only surviving entry point for both Superpowers and ECC; their install/update entry points are retired and no longer exist), run dotfiles-repair, prep a repo with setup-claude, explain claude account routing (claude-account, the claude() wrapper, work vs personal), find where machine state lives (~/.claude, ~/.claude-work, cache stamps, plugin dirs), or understand .todos/.planning worktree hydration. NOT for first-time environment setup (dotfiles-build-and-env), debugging a broken symptom (dotfiles-debugging-playbook), or Claude Code platform internals (claude-code-platform-reference).
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).
dotfiles-research-frontier
by taloncjones
The open-problems map for this repo -- where it can advance beyond what chezmoi/stow-class dotfiles tools do (they manage files; this repo manages an AGENT operating environment). Load when asked "what should we work on next", "what are the big open problems", "where is this repo ahead of / behind the state of the art", "is there a research angle here", or when scoping a new improvement slice and you need the ratified priority list with first steps and falsifiable milestones. Each problem names its existing repo asset, three concrete first steps, and the exact measuring command that decides success. NOT the executable cloud runbook (dotfiles-cloud-first-campaign), NOT the evidence-bar discipline for landing a change (dotfiles-research-methodology), NOT settled history (dotfiles-failure-archaeology).
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-external-positioning
by taloncjones
Load BEFORE any action that touches the public surface of this repo -- committing new file types, vendoring or deriving from upstream code, adding a dependency or plugin, publishing/README changes, or deciding whether something belongs in this repo at all. Covers what may NEVER land in the tree (secrets, employer config, 1Password vault names, per-model audit files), the enforcement stack (block_secrets hooks, retired-ECC-derived pre-commit scan, public-safety.test.sh, .gitignore), MIT/NOTICE licensing duties, the upstream trust map (the retired Superpowers, the retired ECC, the compromised GSD original), and the public/private split. Trigger phrases -- "is this safe to commit", "can this go in the repo", "add this upstream tool", "update NOTICE", "license question", "is the repo safe to be public", "should this be private". NOT for the mechanics of committing (dotfiles-change-control), running the test suites (dotfiles-validation-and-qa), or why a hook blocked you (dotfiles-debugging-playbook).