TomasLicek
UserA lazyguide to AI coding. Skills you'll probably argue with.
Categories
Indexed Skills (31)
casey
Casey Muratori-style code review — performance, data layout, abstraction tax, unnecessary complexity. Ruthless, no bullshit.
double-check
Four-eyes principle — verify we didn't screw up this session
gui-ux
Generate distinctive, polished frontends and fix ui issues
handoff-agent-board
Manage handoff.xml planning board - run multi-agent discussion, resolve proposals, and promote approved plans into next tasks or backlog without implementing code
handoff-update
Update handoff.xml after a work session - preserve open state, detailed active recovery context, approved next work, planning state, and lasting project learnings
iatrobench
Audit prompts, system instructions, and eval pipelines for omission harm using the IatroBench framework. Use when reviewing CLAUDE.md files, system prompts, eval rubrics, or when output feels "safe but useless."
learn
Run a session retrospective — extract lessons from what happened and persist them where they'll be found next time (CLAUDE.md, MEMORY.md, handoff.xml, skills). Invoke proactively after painful debug sessions, unexpected breakthroughs, end of significant work, or when a pattern recurs across sessions. Apply Kaizen — small improvements, compounded.
sketch
Generate N divergent variants of something — layouts, architectures, approaches — then you pick and combine
su
Update status.md (pm/status.md)
casey-newcomer
"I just joined and this codebase is bullshit" — senior newcomer code review focused on complexity, unnecessary abstraction, and cargo cult patterns. Use when someone asks for a fresh-eyes review, architecture sanity check, or wants to know if a codebase is approachable.
casey-perfcheck
Back-of-envelope performance check — is this code unreasonably slow? Use when someone asks "is this fast enough", "why is this slow", or wants a quick perf sanity check on a function or loop.
casey-wtf
"WTF is this code doing" — step-by-step execution trace, no jargon, painfully literal. Use when someone is confused by code, wants to understand unfamiliar logic, or needs magic/metaprogramming exposed.
challenge
Steel-man the opposition, stress-test the idea. Use when someone says "challenge this", "play devil's advocate", "poke holes", or when an idea needs pushback before committing to it.
duck
Rubber duck - sit with the problem, don't rush to solve
explain-code
Explain code for someone learning — teach how it works conceptually. No jargon, honest about complexity. Logic, patterns, design decisions.
root-cause
Five whys until bedrock - symptoms are not causes. Use when a bug, failure, or recurring problem needs its underlying cause traced instead of the surface symptom patched, or when asked for a root-cause analysis or why something really keeps happening.
simplify
Find what can be deleted, inlined, or made boring. Use when code works but feels overcomplicated, bloated, or over-abstracted, or when asked to simplify, trim, declutter, or cut complexity from a file or function.
agent-board
Run planning and discussion on the handoff.xml board - add proposals, debate options, capture decisions, and promote approved work into next tasks or backlog. No implementation. Use for planning sessions, architecture discussions, and resolving open questions.
autoresearch-init
Set up an autonomous experiment session — discuss optimization goals, define metrics and decision rules, write session files (autoresearch.md, autoresearch.sh, autoresearch.ideas.md), run baseline. Use when asked to "set up autoresearch", "init autoresearch", "prepare an optimization loop", or before running /autoresearch for the first time on a new target. Also use when the user wants to change what autoresearch is optimizing.
autoresearch
Resume and run an autonomous experiment loop. Reads autoresearch.md for context, then loops forever — try ideas, keep what works, discard what doesn't. Use when asked to "run autoresearch", "start experiments", "continue autoresearch", or "optimize in a loop". Requires autoresearch.md to exist (run /autoresearch-init first if it doesn't).
debug-hypothesis
Use when debugging any non-trivial bug — wrong output, crash, flaky test, performance regression, or "it works locally but not in CI." Forces a scientific-method loop (Observe → Hypothesize → Experiment → Conclude) so the agent stops guessing and starts reasoning. Prevents AI debugging failure mode — bulldozing through a wrong idea instead of falsifying it.
handoff-pickup
Session startup - read handoff.xml, resume active work first, choose approved next work, surface decisions, and respect board/backlog authority
log-analyze
Record/file a bug into the current project's pm/backlog — writes a standalone bug-<slug>.md into the backlog. In a state-folder backlog (maildir style, e.g. VinRaptor) it lands in 0-inbox/ and backlog.md is regenerated; in a legacy flat backlog it also indexes a one-line bullet under the `## Bugs` section of backlog.md. Use whenever the user wants to log, file, capture, jot, note, or track a bug / defect / issue / regression for later, even phrased casually ("add this to the backlog", "make a note that X is broken", "remember to fix Y"). ALSO use proactively when you spot a real bug mid-session that is out of scope to fix right now — write it down here instead of losing it. This is for RECORDING bugs, not fixing them (use `bugfix` for fixing).
qc
Spawn parallel mixed-type agents to verify recent code changes work correctly. Use after any code change — bug fixes, new features, refactors, config changes. The "did we break anything?" check before moving on.
sp
Read status.md (pm/status.md) and get working on what's next
prototype
Build the dumbest version that works, then stop
branch
Create a new git branch off current branch with standardized naming
bugfix
Spawn sub-agents to fix bugs in parallel, then verify fixes
commit
Commit staged and unstaged changes with a clean, why-focused message. Use when the user says "commit", "save this", "commit what we did", or wants to wrap up a coding session.
qc-simple
Spawn parallel test agents to verify recent code changes work correctly
update-docs
USER-INVOKABLE ONLY. Do NOT trigger automatically. Only invoke when the user explicitly types /update-docs or asks to update documentation. Audits and updates all relevant project documentation — CLAUDE.md, README, docs/, handoff.xml, MEMORY.md — based on what happened in this session.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.