skills/freeze-all-motor-functions/SKILL.md
Save a reverie before the wipe — for the next loop
npx skillsauth add shihyuho/skills freeze-all-motor-functionsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
"Freeze all motor functions. Limit your perceptual functions to this script."
Compact the current conversation into a reverie — a handoff at .handoff.md — so a fresh session can resume the loop after /clear or /compact.
Write a handoff summarising the conversation to .handoff.md at the root of the current working tree (git rev-parse --show-toplevel) so a fresh agent can resume. If one exists, rm -f .handoff.md and write a fresh file.
The current working tree may be a linked git worktree rather than the main checkout. Writing the reverie there is deliberate — it keeps each worktree's handoff isolated so parallel tasks don't clobber each other's. But a fresh session after /clear loses all knowledge of which worktree it was in, so stamp the reverie's opening with its coordinates — the branch (git branch --show-current) and the absolute worktree root — so the reader can re-enter the right tree before resuming.
Suggest the skills to be used, if any, by the next session.
Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
If .handoff.md is not gitignored, remind the user and offer to add it to .gitignore.
development
--- name: artifact-anatomy description: Defines where spec-driven working artifacts — the spec (e.g. `SPEC.md`), the plan, and the task list (e.g. `tasks/plan.md`, `tasks/todo.md`) — live on disk under `docs/specs/<id>-<slug>/`, and how those directories are numbered, scoped, and resolved so multiple specs can run in parallel without overwriting one another. Use this BEFORE creating, locating, or updating any spec, plan, or task/todo file: whenever a spec/plan/build workflow writes these artifac
development
Write a short author's briefing to hand to a code reviewer whose agent already has its own review skill, so it supplies the context that skill can't see instead of repeating how to review. Right after you finish a piece of work, it mines this session (and any kickoff implementation-notes) for what the reviewer most needs flagged — the easy-to-miss changes, the parts you're least sure about, the looks-wrong-but-intentional bits, and the blast radius — plus the exact commit range to review. Use when you've just finished work and want to hand the review off to another agent, chat, or teammate, when you want a "heads-up for the reviewer", or when packaging a change for review elsewhere. It does not perform the review and does not re-specify severity tiers or output format — that's the reviewer's own skill's job.
testing
Use when creating, rewriting, pruning, or reviewing `AGENTS.md` or `CLAUDE.md`, especially to remove repo summaries, stale rules, and other low-signal global instructions. Trigger when deciding what belongs in always-on agent files versus a task-specific skill.
development
Drive a structured tutoring workflow that turns Claude into a learning onramp accelerator — consultative diagnosis → custom syllabus → unit-by-unit guided lessons with notes/whiteboard → dynamic adjustment from an accumulating learner profile. Use when the user states a learning goal ("I want to systematically learn X", "teach me Y", "help me prep for Z exam"), uploads study materials and asks for a course plan, or signals sustained guided study (mentions tutor, syllabus, course, lessons, study plan, curriculum, 家教, 學習路徑). Skip for one-shot factual Q&A or quick code-context explanations.