Menu
Manually exercise code beyond the automated tests — python -c for libraries, curl for APIs, browser automation with screenshots for web UIs — and document the results. Use after tests pass, before declaring work done.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Run the compound engineering step — a short retrospective after a piece of work that folds what was learned back into CLAUDE.md, the skills, or the hoard. Use at the end of every significant task.
Sort out git messes and perform history surgery — undo/rewrite commits, resolve conflicted merges and rebases, recover lost code via reflog, find regressions with git bisect.
Save a newly-figured-out trick as a minimal working example in hoard/, so future sessions can reuse or recombine it. Use after solving something non-obvious for the first time.
Build a self-contained interactive or animated HTML page that explains how an algorithm or piece of code works. Use to pay down cognitive debt when a written explanation isn't enough.
Pre-pull-request checklist — verify the code works, the diff is reviewable, and the PR carries context and evidence of testing. Run before opening any pull request.
Proofread a document before publication — spelling, grammar, repetition, logical and factual errors, weak arguments, placeholder links. Reports issues; never rewrites the author's voice.
| name | manual-test |
| description | Manually exercise code beyond the automated tests — python -c for libraries, curl for APIs, browser automation with screenshots for web UIs — and document the results. Use after tests pass, before declaring work done. |
Passing tests do not prove the feature works as intended. Exercise the real thing, with the mechanism matching what the code is:
python -c "..."
(multiline strings are fine). No files needed./tmp (never in
the repo), compile/run them there.curl —
try a variety of endpoints, valid and invalid inputs, not just the happy path.uvx rodney --help first to learn the tool, then drive a real browser.
Take screenshots and actually look at them with your vision capability to
confirm the UI renders correctly — layout, menus, visual details./red-green-tdd so the case ends up
covered by the permanent automated suite.uvx showboat --help, then create a
document under notes/ (e.g. notes/api-demo.md). Use showboat note for
commentary, showboat exec to record commands with their real output, and
showboat image for screenshots. exec exists so the document shows what
actually happened, not what you hoped happened — never hand-write output.