doivamong
UserA practical workbench of tools + methodology for solo devs driving an AI coding agent (Claude Code, Cursor, Copilot): safety hooks, secrets crypto, invariant + test-selection tooling, leak scanner, plus skill & memory system templates.
Categories
Indexed Skills (22)
awb-lessons-capture
WHAT: an end-of-session discipline that mines the just-finished session for durable lessons, scores each against a fixed bar, and writes only the survivors you approve to the live per-project memory so a future session recalls them. It is an honesty overlay on native auto-memory, not a capture engine: it adds the report-zero gate, a value score, dedup against the existing corpus, and a hard write-gate. USE WHEN: wrapping up a session and you want to keep what was learned ("capture the lessons", "memory retro", "what is worth remembering from this", "save the lessons before we stop"), especially after a surprising bug, a correction, or a counter-intuitive trap. DO NOT TRIGGER: a quick mid-session note (just jot it down); packaging unfinished work for the next session (that is a handover skill); promoting an already-captured recurring lesson to a rule (a human call in the lessons doc); a session where nothing surprising happened, where the honest output is simply zero.
awb-install-and-verify
WHAT: drive the kit's own installer in plain language — wire the safety hooks into a project, then run the real --doctor verifier and explain, honestly, what now protects the user and what it does NOT. USE WHEN: a user wants to set up or check the workbench's guards ("install the workbench", "set up the hooks", "are my guards actually on?", "did the install work?", "is the dangerous-command block working?"). DO NOT TRIGGER: building a new feature/hook (that's a plan-then-code skill); editing settings.json by hand (this skill only ever calls install.py); a general "is my code good?" review (that's awb-review).
awb-session-close
WHAT: verify a working tree is safe to close at the end of a session — surface anything still dangling (uncommitted, unpushed, unmerged, stale branches) and clean it on your approval, so you close with certainty instead of fear of leftover work. USE WHEN: wrapping up and you want to be sure nothing is lost or left messy ("is it safe to close?", "did I leave anything uncommitted / unpushed?", "clean up the junk branches", "close out the session", "end-of-day repo check"). DO NOT TRIGGER: packaging UNFINISHED work for the next session to execute (that is awb-handover); mining the session for durable lessons (that is awb-lessons-capture); shipping a specific change through review→commit→merge (that is the plan-then-code + review flow).
awb-uninstall
WHAT: drive the kit's own uninstaller in plain language — show what would be removed first (dry-run), get an explicit yes, then remove, and say honestly what is KEPT (the files you edited) rather than claiming a clean wipe. USE WHEN: a user wants to take the workbench back out of a project ("remove agent-workbench", "uninstall the kit", "take the hooks out", "undo the install"). DO NOT TRIGGER: installing or verifying guards (that's awb-install-and-verify); hand-deleting files yourself (this skill only ever calls uninstall.py); a general "is my code good?" review (that's awb-review).
prompt-refiner
WHAT: turn a vague, multi-part request into a crisp, executable one before doing any work — clarify intent, surface hidden assumptions, restate the scope. USE WHEN: a request is long but underspecified (no files, no acceptance criteria, several intents at once). The UserPromptSubmit hook (prompt-refiner-inject.py) flags these automatically and asks you to run this first. DO NOT TRIGGER: the request is already specific (file paths, clear outcome); it's a trivial one-liner; or the user prefixed it to bypass refinement.
awb-config-guard
WHAT: guard against the two silent failures of config access — reading a key in the wrong CONTEXT, and reading a nested key at the wrong LEVEL (which returns None silently). USE WHEN: writing or modifying code that reads/writes configuration — especially a nested key, or a read that runs in more than one execution context (in-request vs. a script/job). DO NOT TRIGGER: reading config once just to understand the system; a single hard-coded constant with no nesting and one obvious context.
awb-cook
WHAT: an advanced build workflow that adds three things to a plain plan-then-code flow — graduated oversight modes (how often it stops to ask you), multi-perspective planning (several independent plans, merged), and explicit orchestration of the guard skills at the right steps. USE WHEN: a larger or higher-stakes change where you want to dial the human-checkpoint frequency and get more than one planning angle ("cook this", "run the full workflow", "build X end to end with checkpoints", "plan this from a few angles first"). DO NOT TRIGGER: a routine single-file change (use awb-plan-then-code); a one-line fix; a pure question; work where you do not want sub-agent fan-out. It enforces nothing — it is a bypassable exemplar, not a gate.
awb-dead-code-audit
WHAT: find genuinely unused code with a false-positive gate — a symbol is reported "dead" only when several INDEPENDENT cross-checks all come back empty, never on one finder's say-so. USE WHEN: an on-request cleanup sweep ("find dead / unused code", "what can we delete", a post-refactor or pre-release prune, "is this function called anywhere?"). DO NOT TRIGGER: "this function is too long / too complex" (a structural-size concern, not deadness); hunting for bugs (a review/debug skill); deleting code the user already named as dead.
awb-debug
WHAT: debug a bug methodically — reproduce it, find the ROOT cause, then fix, then prove the fix. USE WHEN: the user reports something broken / wrong / crashing and the cause is not yet known ("it errors", "wrong output", "doesn't work", "500", "flaky"). DO NOT TRIGGER: implementing a new feature (use a plan-then-code skill); a pure code review; when the cause is already known and it's a one-line edit.
awb-external-ref
WHAT: decide how to responsibly reuse code you found elsewhere — classify its license, choose PORT-the-code (carry the licence + attribution) vs SALVAGE-the-concept (reimplement the idea from scratch), screen fetched text for prompt-injection, and check supply-chain red flags. USE WHEN: about to copy or adapt code from outside the repo — a GitHub repo, a snippet, a blog, Stack Overflow, or an LLM ("can we use this?", "adopt this library's approach", "port this"). DO NOT TRIGGER: writing original code; pulling a vetted dependency through your normal, already-approved process; a pure licensing question with no code in play (answer it directly).
awb-handover
WHAT: package finished work — research, a design discussion, a half-done task — into a self-contained handover a fresh session can execute without any of your context. USE WHEN: you're ending a session and want the next one (or a teammate) to pick up cleanly ("hand this off", "package this for next session", "write a handover", "research is done, move it to execution", "context is filling up, save the state"). DO NOT TRIGGER: the work isn't finished enough to hand off (keep going, or use a research/plan skill first); a quick mid-task context note (just jot it down); starting fresh implementation right now (that's a plan-then-code skill).
awb-optimize
WHAT: make code measurably faster (or lighter) with a disciplined loop — set a baseline, measure to find the real bottleneck, fix the top one, re-measure, and record a before/after table — so a change is kept only when a number says it helped. USE WHEN: a concrete performance goal on real code ("this is too slow", "optimize X", "cut the p95 latency / memory", "speed up the import"), where you can measure before and after. DO NOT TRIGGER: "tidy this up / simplify" with no speed goal (that is a review/simplify skill); a correctness bug (that is a debug skill); micro-tuning with no measurable target or baseline.
awb-output-guard
WHAT: keep long / whole-file code generation complete — no truncation, placeholders, "...", or "for brevity" stubs. USE WHEN: generating a whole file, a large template, or a big refactor (roughly 150+ lines, or any "write the complete X" request); or when an earlier turn may have left a file half-written. DO NOT TRIGGER: a small edit (under ~30 lines) to an existing file; a question; a prose-only answer.
awb-research
WHAT: understand a problem before building — scope it, read the actual code, compare at least two approaches, then recommend one with reasons. USE WHEN: a non-trivial change where the approach isn't obvious ("how should we...", "what's the best way to...", "look into X before we build it", "which option..."). DO NOT TRIGGER: a vague *request* that needs clarifying first (that's prompt-refiner); executing an already-chosen approach (that's a plan-then-code skill); a known one-line fix.
awb-review
WHAT: review a code change in three passes — does it meet the spec, is it well built, and can an adversary break it. USE WHEN: the user says "review my changes / this PR / what I just wrote", or before committing a non-trivial change. DO NOT TRIGGER: a broad "audit the whole codebase" request; research/compare questions; when no code has been written yet.
awb-stress-test
WHAT: pressure-test a non-trivial change before you build it — run it past a fixed set of independent lenses so blind spots surface on paper, not in production. Two modes: design stress-test (expert viewpoints judge whether the approach is sound, returning a GO / CAUTION / STOP verdict) and edge-case decomposition (failure-axis lenses enumerate what could break, producing a severity-ranked list that feeds tests). USE WHEN: about to implement or test something non-trivial and you want the risks and edge cases first ("stress test this", "what could go wrong", "edge cases", "is this design sound", "second opinion before I build", "poke holes in this plan"). DO NOT TRIGGER: a one-line / low-risk change; choosing between approaches (that is a research skill); reviewing code already written (that is a review skill); a known bug with a clear cause (that is a debug skill).
awb-tdd
WHAT: drive a change test-first as red-green-refactor in VERTICAL slices — one failing test, the minimal code to pass it, repeat — so each test is shaped by what the last one taught you. USE WHEN: building a feature or fixing a bug where the behavior is non-trivial and you want tests to lead ("do this TDD", "test-first", "red-green-refactor", "write the test first", "regression test before the fix"). DO NOT TRIGGER: a trivial change (under ~30 lines, behavior obvious); a pure config/data edit with no logic; a spike/exploration where you want feedback before committing to an interface; reviewing code already written (that is a review skill).
awb-using-skills
WHAT: the meta-routing protocol — how to choose the right skill (and notice when one applies at all) so the agent routes consistently instead of guessing. USE WHEN: auto-injected every session by the skill_routing_inject.py SessionStart hook; also read it directly whenever two or more skills could match a request, or you are unsure whether any skill applies. DO NOT TRIGGER: as a destination — it never does the work itself, it only routes TO other skills. To change what fires, edit skill-registry.md, not this file.
example-debug
WHAT: debug a bug methodically — reproduce it, find the ROOT cause, then fix, then prove the fix. USE WHEN: the user reports something broken / wrong / crashing and the cause is not yet known ("it errors", "wrong output", "doesn't work", "500", "flaky"). DO NOT TRIGGER: implementing a new feature (use a plan-then-code skill); a pure code review; when the cause is already known and it's a one-line edit.
example-plan-then-code
WHAT: a workflow for implementing a non-trivial change the disciplined way — plan first, then code, then test, then review. USE WHEN: the user wants to add a feature or make a multi-file change, or says "implement", "build", "add", "let's do X" where X is more than a one-liner. DO NOT TRIGGER: a single-line fix (just do it); a bug with an unknown cause (use a debug skill); a pure code review (use example-review); a question.
example-review
WHAT: review a code change in three passes — does it meet the spec, is it well built, and can an adversary break it. USE WHEN: the user says "review my changes / this PR / what I just wrote", or before committing a non-trivial change. DO NOT TRIGGER: a broad "audit the whole codebase" request; research/compare questions; when no code has been written yet.
awb-plan-then-code
WHAT: a workflow for implementing a non-trivial change the disciplined way — plan first, then code, then test, then review. USE WHEN: the user wants to add a feature or make a multi-file change, or says "implement", "build", "add", "let's do X" where X is more than a one-liner. DO NOT TRIGGER: a single-line fix (just do it); a bug with an unknown cause (use a debug skill); a pure code review (use awb-review); a question.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.