57 skills (repositories by Sma1lboy) · sorted by popularity
Fan out N parallel workers, drain them, and return one report. Use for /swarm, 'swarm this', or parallel coverage, races, gauntlets, and exploration.
The English summary is being prepared. Showing the original description.
Explain a body of work plainly so a person actually understands it. Runs the `how` and `why` skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
TypeScript best practices. Use when reading or editing any .ts or .tsx file.
The English summary is being prepared. Showing the original description.
Cut AI tells from any writing. Must always apply.
The English summary is being prepared. Showing the original description.
Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for /technical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.
The English summary is being prepared. Showing the original description.
HyperFrames CLI dev loop. Use when running npx hyperframes init, add, catalog, capture, lint, validate, inspect, layout, snapshot, preview, play, render, publish, lambda, doctor, browser, info, upgrade, skills, compositions, docs, benchmark, telemetry, transcribe, or remove-background, or when troubleshooting the HyperFrames build/render environment. Entry point for AWS Lambda cloud rendering (`hyperframes lambda deploy / render / progress / destroy / policies`).
The English summary is being prepared. Showing the original description.
Best practices for Remotion - Video creation in React
The English summary is being prepared. Showing the original description.
All animation knowledge for HyperFrames — atomic motion rules, multi-phase scene blueprints, scene transitions, broader motion-design techniques, AND the seven runtime adapters (GSAP default, plus Lottie, Three.js, Anime.js, CSS keyframes, Web Animations API, TypeGPU). Use for any motion or animation task: pick 2-4 rules and compose, or load a blueprint, or look up runtime-specific API (e.g. GSAP eases / Lottie player / Three.js mixer). HyperFrames-native: single paused timeline, seek-safe, deterministic.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
Use for "how does X work", code walkthroughs before changing something, and placement / ownership / layering questions ("where should this live", "which package owns this", "is this the right layer"). Explains subsystem architecture, runtime flow, onboarding mental models. Can critique architecture. Use why for motivation.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
Run an extremely strict maintainability review for abstraction quality, giant files, and spaghetti-condition growth. Use for a thermo-nuclear code quality review, thermonuclear review, deep code quality audit, or especially harsh maintainability review.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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, dispatch the Changesets workflow (or run `scripts/release.sh` locally), 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 rove", "发版", "release.sh", or "bump the version". Never force-pushes; always verifies the release landed on `main`.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
Apply when writing stateful logic, or when code branches a lot or repeats a shape assumption across files. Encode the domain in a structure instead of scattered conditionals.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
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.'
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.