atgreen
UserMirror of https://cave.moxielogic.com/atgreen/secscan-skill
Categories
Indexed Skills (23)
beads
Use when working in a repository that uses bd or Beads for durable project task tracking, issue dependencies, blocker management, multi-session handoff, or shared work memory. Trigger when the user asks to find ready work, claim or close tasks, create follow-up work, inspect blockers, recover project context, or choose between local planning and persistent project tracking.
secscan
In-session, token-efficient LLM security scan of a repo (SAST triage). A lightweight, native Claude Code pipeline — survey → threat-model → deep-dive → adversarial-verify → report — using Read/Grep/Glob (and optional subagents), no external tooling. Use when asked to "security scan", "find vulnerabilities", "SAST", "audit this code for security", or "secscan".
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". Not for polishing code that already works — that's whittler
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". Not for writing the failing test that drives new code — that's test-first
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". Not for the understand-and-get-buy-in step before a design exists — that's shaping
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). To mechanically scan the current diff for bugs, use the /code-review command; this skill is the practice of seeking independent review and receiving feedback well
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. Not for turning an already-agreed design into ordered tasks — that's planning
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. Not for wiring a known design thinly end-to-end (that's walking-skeleton), nor for polishing working code (whittler)
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. Not for a full readability-and-elegance pass over working code — that's whittler
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". Not for verifying a finished change before claiming it works — that's evidence-before-claims
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. Not for a throwaway probe to answer an unknown you'll then delete — that's spike-and-stabilize
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". Not for getting something working the first time (builder), nor for a single targeted redundancy removal (subtraction-first)
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
dispatching-subagents
Chooses whether and how widely to parallelize permitted work. Use for fan-out search, independent build/spike/review tasks, adversarial verification, or host-budget decisions. Not for isolating writers after parallelism is chosen — that's using-worktrees
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"
hacking-workflow
Coordinates a non-trivial git-hosted change from intent through verified integration. Use at the START when the user says "let's build X", "hack on X", "start a hacking session", "run the loop", "new project", or "implement this". Not for a quick direct artifact — that's builder
using-beads
Use for durable task tracking when the current work is inside a Git repository — tasks, deferred TODOs, bugs, dependencies, "beads", "bd", "backlog", "file an issue", or "what's ready". Not for temporary or non-Git scratch work, even when writing code
using-hackinator
Use when the user asks which Hackinator mode or skill fits, wants orientation to the hacker ethic, or has not yet distinguished building from refining. Not for a concrete new build or prototype — that's builder — or polishing working code — that's whittler
using-worktrees
Isolates permitted concurrent edits or risky experiments in separate Git working directories. Use when agents may race, a throwaway branch is needed, or the user says "worktree", "isolation", or "keep main clean". Not for deciding whether to parallelize — that's dispatching-subagents
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"
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
beads
Use when working in a repository that uses bd or Beads for durable project task tracking, issue dependencies, blocker management, multi-session handoff, or shared work memory. Trigger when the user asks to find ready work, claim or close tasks, create follow-up work, inspect blockers, recover project context, or choose between local planning and persistent project tracking.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.