Sma1lboy
@Sma1lboy
Public Skills
rove
by Sma1lboy
Use when controlling Rove tasks, parallel coding attempts, hosted agent sessions, task lifecycle, or the daemon-owned issue tracker from a shell. Also the ONLY channel for messaging another agent session on this machine — rove api send, never a peer/MCP side channel.
release
by Sma1lboy
Autonomously cut a Rove (@sma1lboy/rove) release end-to-end — detect the semver bump from pending changesets (flagging an upstream minor you didn't intend), run the release gates, bump/tag/push via scripts/release.sh, then poll the GitHub Actions Release workflow with gh until npm publish completes, diagnosing CI failures (npm token, registry 404, lint, branch mismatch) instead of leaving them silent. Use when the user says "cut a release", "ship a version", "release Rove", "release kobe", "发版", "release.sh", or "bump the version". Never force-pushes; always verifies the release landed on main.
why
by Sma1lboy
"Use for 'why does X work this way', 'why we picked Y', '为什么这么设计', design rationale, regressions, or where a magic number came from. Fans out one investigator per evidence category — in this repo that starts with the local decision record (ADRs, docs/design, the daemon issue store, the changelog, wisp) plus git history, and adds MCP-backed categories when the session has them — then returns a cited read with the gaps named. Use how for what the code does at runtime."
pstack
by Sma1lboy
Rigorous engineering mode for nontrivial work in this repo — a set of named principles plus the leaf skills that apply them. Use when the user says "pstack", "go deep", "be rigorous", "认真做", or when a task involves architecture, a real bug, a refactor, or anything the user will not be watching. Ported from cursor/plugins pstack by Lauren Tan (MIT); see ATTRIBUTION.md.
principle-make-operations-idempotent
by Sma1lboy
"Apply when designing commands, lifecycle steps, or processing loops that run amid crashes, restarts, and retries. Converge to the same end state regardless of partial prior runs."
figure-it-out
by Sma1lboy
"Design an auditable playbook when no narrower one fits: a large migration, an ambitious multi-part change, or work a human reviews after stepping away. Scales rigor to the task, runs a hypothesis loop, and logs decisions via show-me-your-work. Use for /figure-it-out, 'figure it out', a large migration, or when no narrower playbook applies."
principle-sequence-verifiable-units
by Sma1lboy
"Apply to multi-step work (sweeps, migrations, runs of similar edits) and to how you stack commits and PRs. Break work into small units that each end in a verifiable state, check each before the next, and order delivery so the sequence proves itself to a reviewer."
principle-encode-lessons-in-structure
by Sma1lboy
"Apply when you catch yourself writing the same instruction a second time, or notice a recurring correction. Encode the rule as a lint, metadata flag, runtime check, or script instead of more text."
principle-redesign-from-first-principles
by Sma1lboy
"Apply when integrating a new requirement into an existing design. Redesign as if the requirement had been a foundational assumption from day one, instead of bolting it on."
principle-experience-first
by Sma1lboy
"Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship fewer polished features over more rough ones."
principle-build-the-lever
by Sma1lboy
"Apply to any non-trivial work, not just bulk work: edits, migrations, analyses, checks. Build the tool that does it or proves it (codemod, script, generator, or a skill your subagents follow) instead of working by hand. The tool is the artifact a reviewer can rerun."
principle-prove-it-works
by Sma1lboy
"Apply after completing a task, before declaring done. Verify against the real artifact (run the feature, read the actual value, inspect the diff), not a proxy, self-report, or 'it compiles.'"
principle-exhaust-the-design-space
by Sma1lboy
"Apply when facing a novel UI interaction or architectural decision with no precedent in the codebase. Build 2-3 competing prototypes and compare side by side before committing."
principle-type-system-discipline
by Sma1lboy
"Apply when designing types, reviewing a function signature, or writing code in any statically-typed language. Make illegal states unrepresentable, brand semantic primitives, parse external data at boundaries, refuse to lie to the compiler, exhaust variants, derive from authoritative schemas."
principle-separate-before-serializing-shared-state
by Sma1lboy
"Apply when concurrent actors might write to the same file, branch, key, or state object. Eliminate the sharing first; serialize structurally only when one shared writer is a real invariant."
tdd
by Sma1lboy
"Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested."
show-me-your-work
by Sma1lboy
"Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why, evidence, result). Local by default; commit it when a reviewer needs the trail to trust the result. Use for /show-me-your-work, autonomous or multi-phase runs, or work a human reviews after stepping away."
principle-fix-root-causes
by Sma1lboy
"Apply when debugging. Trace each symptom to its root cause and fix it there; reproduce first, ask why until you reach it, resist nil-check guards that silence crashes."
interrogate
by Sma1lboy
"Use for \"interrogate\", \"adversarial review\", \"multi-model review\", \"challenge this\", \"stress test this code\", \"find blind spots\", or \"tear this apart\". Multiple LLM reviewers challenge changes from independent angles."
principle-laziness-protocol
by Sma1lboy
"Apply when refactoring, evaluating diff size, or tempted to add abstractions, layers, or signal threading. Bias toward deletion and the smallest change that solves the problem."
blast-radius
by Sma1lboy
"Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', or reviewing a small diff you don't trust."
principle-subtract-before-you-add
by Sma1lboy
"Apply when sequencing an addition, refactor, or rewrite. Remove dead weight, redundant validators, and stub references first, then build on the simpler base."
principle-outcome-oriented-execution
by Sma1lboy
"Apply during planned rewrites and migrations with explicit phase boundaries. Converge on the target architecture; don't preserve smooth intermediate states with throwaway compatibility code."
principle-minimize-reader-load
by Sma1lboy
"Apply when reviewing or shaping code that's hard to trace. Count layers between question and answer, and hidden state in the reader's head; collapse one-caller wrappers and shrink mutable scope."