atgreen/hackinator

finishing

Use when an implementation is complete and ready to land — deciding how it integrates and cleaning up. "finish this", "land it", "wrap up", "ship it", "merge", "make a PR", "I'm done — now what"

using-hackinator

Use when starting creative build or craft work, deciding which hackinator skill fits, or when the user says "hack on this", "let's build something", "make it nice", or invokes the hacker ethic

whittler

Use when working code needs to become elegant, minimal, and a joy to read — polishing, refining, simplifying, or when the user says "make it nice", "clean this up", "make it beautiful", "tighten this", "it works but it's ugly"

builder

Use when making an idea real from scratch, prototyping, spiking, scratching an itch, or when the user says "build this", "hack this up", "let's make something", "prototype", "get it working"

hacking-workflow

Use at the START of any non-trivial build or change in a git repo — "let's build X", "hack on X", "start a hacking session", "run the loop", "new project", "implement this". The spine that sequences shaping → planning → build → craft → verify → review →…

evidence-before-claims

Use before claiming ANYTHING works, passes, is fixed, or is done — before every commit, PR, task hand-off, or "it should work now". Triggers on the urge to say done, or words like "should", "probably", "that fixes it", "all green"

planning

Use after a design is approved and before implementing anything architectural — turning an agreed direction into an ordered, testable set of tasks. "write a plan", "break this down", "what are the steps", "plan the implementation"

reviewing-work

Use after finishing a task or feature and before it lands — getting an independent review, and handling the feedback well. "review this", "code review", "check my work", or when receiving review comments (from a person, a subagent, or Codex)

shaping

Use at the very start of any non-trivial build, BEFORE writing code or scaffolding — turning a rough idea into an understood, agreed direction. "let's build X", "I want to make Y", "how should I approach Z", or any request where the goal isn't yet pinned down

test-first

Use when implementing keeper code — any behavior meant to last, and especially when fixing a bug. Triggers on writing a function/feature you intend to keep, "add a test", "TDD", or the urge to write the code first and test it "after"

consulting-codex

Use when stuck on a tricky problem, second-guessing a design decision, or wanting an independent model to cross-check or try to break your work — "ask codex", "second opinion", "am I missing something", "another set of eyes", "is this right"

dispatching-subagents

Use when work can be split across subagents or parallel tool calls — fan-out search, independent build/spike/review tasks, adversarial verification — or when deciding how many things to run at once without overwhelming the host or ballooning total runtime

naming-as-design

Use when code feels tangled or needs a comment to explain what something is, when reaching for a name and nothing fits, or when a name is vague (data, tmp, handle, process, manager, util, doStuff) and the fuzziness hides a fuzzy design

reading-like-prose

Use when making code a joy to read — a function is hard to follow top to bottom, nesting is deep, the reader has to scroll up to understand, or high-level intent is buried under low-level detail

spike-and-stabilize

Use when a genuine unknown blocks progress — "can this even be done?", an unfamiliar API or library, an uncertain approach — and you're tempted to either research forever or build production code around something you don't yet understand

subtraction-first

Use when improving existing code and the instinct is to add — a wrapper, a flag, a layer, a helper, a config option — before checking whether removing something is the better move; or when code feels bloated, over-engineered, or hard to hold in your head

using-beads

Use at the start of and throughout ANY git-hosted work — tracking tasks, deferred TODOs, discovered bugs, follow-ups, dependencies, or "while I'm here" ideas. Triggers include "beads", "bd", "track this", "backlog", "file an issue", "what's ready to work on",…

using-worktrees

Use when parallel agents or experiments need to edit files without racing each other, when you want a throwaway branch you can build in and discard, or when the words "worktree", "isolation", or "keep main clean" come up

walking-skeleton

Use when starting anything new and unsure where to begin, tempted to build the interesting component first, or when a prototype has many parts that don't yet connect end to end

writing-skills

Use when adding a new hackinator skill, editing an existing one, or reviewing whether a skill is well-formed — before writing the SKILL.md, and before considering it done