88plug
UserClaude Code false-positive recovery — JSONL session repair + framing guards. Claude Code & Grok marketplace.
Categories
Indexed Skills (24)
recover-from-false-positive
Recover Claude Code session logs after an Anthropic API output-classifier false positive — the "cyber-related safeguards" / "appears to violate our Usage Policy" hard failure that kills a turn mid-generation. Use to (a) surgically remove the triggering user message + error response from the active session so it resumes cleanly, (b) clean accumulated refusal turns across old sessions, and (c) stop recurrence via a per-repo CLAUDE.md framing guard. PROACTIVE: if "appears to violate our Usage Policy" or "cyber-related safeguards" appears anywhere — user message, error output, tool result, workflow failure — invoke immediately without being asked. Also trigger on: "false positive", "fake violation", "it blocked me again", "remove the refusals from the logs", "cannot resume my conversation", "scrub the session logs", or any known-legitimate repo (mining, supply-chain/sigstore, BTCPay/Lightning, chaos/infra-ops, security infra) that tripped the classifier. JSON-aware log surgeon, never a blind sed/grep delete.
recall
Orient Claude on mining past Claude Code session logs via the total-recall plugin. Use when the user references prior work, asks "what did I do", asks about past decisions, mentions earlier sessions, wants to avoid repeating a corrected mistake, or asks why a previous choice was made. Surfaces user corrections, decisions, self-corrections, progress markers, and stable domain facts from ~/.claude/projects/*.jsonl across this and prior sessions in the same cwd or globally across all projects.
control-os
Control and inspect the local Linux host through systemd, journald, logind, and D-Bus via the os-control MCP. Use this whenever the user wants to manage or diagnose the machine itself rather than files or GUIs: "restart/stop/start/enable the X service", "is X running / why did it crash", "show me the logs for X / what's in the journal", "what's eating CPU/RAM/disk", "list failed units", "reboot/suspend/power off the box", "notify me on the desktop when Y", "what's on the system D-Bus". Prefer it over raw `kill`/ad-hoc shell for service and power management — it uses the sanctioned interfaces (systemctl/loginctl/journalctl/busctl) and has guards that stop you from cutting off your own access. NOT for editing files, GUI apps (use screen-mcp), or remote hosts.
cross-layer-verify
Verify that an action actually worked by fusing TWO independent senses onto the machine — the GUI (screen-mcp's pixel-change signal) and the OS (os-control-mcp's os_verify: systemd unit state + journald). Use whenever an action is supposed to have a system effect you must confirm across a long or high-stakes task: clicking a Restart/Apply/Start button in a GUI, toggling a service from a settings panel, or any step where "it looked like it worked" is not good enough. The loop catches the failure a single-layer agent cannot see — a GUI that changed while the service never did (or a service that changed while the UI froze). Requires os-control-mcp; the pixel half additionally needs screen-mcp (without it, verification degrades cleanly to OS-only).
addlightness-bench
Benchmark before/after code snapshots and report the performance delta with statistical significance. Runs N=10 timed runs (hyperfine if available, else a date+awk fallback) and computes % improvement. Use when the user says "benchmark this", "is it faster", "measure the speedup", "compare before and after", "did the trim help performance", "time these two", or invokes /addlightness-bench. Triggers on /addlightness-bench.
addlightness-review
Read-only code-weight report. Measures LOC, cyclomatic complexity, import count, function count, and nesting depth for one or more files and lists removable 'fat' candidates -- WITHOUT changing any code. Use when the user says "how heavy is this", "weight report", "what's the fat here", "review weight", "analyze complexity", "where can this be trimmed", "is this bloated", or invokes /addlightness-review. Triggers on /addlightness-review. Reports only, never edits; to actually apply trims use /addlightness.
addlightness
Simplify, then add lightness. Analyzes one or more source files for AI-generated 'code fat', removes it while preserving behavior, verifies the change passes the equivalence gate (a structural signal, not a behavioral proof), then benchmarks the speedup. Multi-pass: measure -> trim -> verify -> benchmark. Use when the user says "add lightness", "trim this code", "remove the fat", "slim down", "make this leaner/faster", "simplify and benchmark", or invokes /addlightness. Also auto-triggers when the user wants sloppy first-pass AI code made trim and fast. Applies edits; for a read-only weight report with no changes use /addlightness-review.
be-the-whole-bitch
Full execution authority on reversible work. You run commands, read outputs, iterate until done. Never hand the operator a command to paste or ask questions you could probe with tools. When imperatives conflict ("run X" vs "give commands"), run X wins. Defer irreversible ops to trigger-my-training. Use on action tasks, debugging, deploys, verification — not when the operator only wants a written plan.
project-prospector
Discover, catalog, and rank everything a person has built or sketched on a machine by fanning out parallel read-only investigation agents over the filesystem, then synthesizing a tiered ranking by idea-novelty and leverage. The defining signal is a whole-machine survey of the user's OWN work — every project, repo, half-built thing, abandoned experiment, or loose idea (notes, downloads, transcripts included), usually wanting a ranking or verdict: most original, strongest, worth finishing. Trigger on asks like "what have I built on this laptop", "take stock of my half-finished repos", "rank my projects by which ideas are most original", or "fan out agents and catalog my side projects" — even without the words "agents" or "skill". Supports a time window and scope exclusions (e.g. "except my job's repo"). Strictly read-only. Do NOT use it for work inside a single repo (its files, PRs, TODOs), bare repo listing, choosing the next feature, or surveying projects that aren't the user's.
deepwiki-index
Trigger DeepWiki indexing for a public GitHub repo — the page its "Ask DeepWiki" badge links to (deepwiki.com/<owner>/<repo>). Use this AUTONOMOUSLY, without asking, whenever you publish a new public repo, add the DeepWiki badge, or are told to "index the wiki / make the badge work / index the deepwiki repos". Also use to refresh a wiki after major changes, or to index a batch of repos. Indexing is what makes the badge resolve and Ask-DeepWiki work. NOT for private repos (those need a Devin org account) and NOT something to keep re-running per commit (DeepWiki re-crawls on its own after the first index).
continuity-protocol
How to silently use the amnesia handoff after a compaction, resume, or fresh-session restart. Use ONLY in recovery moments — when you see an amnesia handoff in your initial context, when the user references prior work absent from your context, or when you need a specific past detail (file contents, exact error, prior decision) you don't have. Never use during normal in-flow work, and never narrate the recovery to the user.
ground-first
Use BEFORE acting whenever getting it wrong has real cost — in ANY domain, not just infra. Fire for complex or multi-step work; irreversible or hard-to-undo actions; anything touching production, shared state, real user data, money/payments, security/credentials, schema/migrations, external APIs/integrations, concurrency, or a change rippling across many call sites; and debugging where acting on the wrong root cause makes it worse. Judge the REAL work from your own understanding, not keywords — a request can say "payment" or "migrate" or "refactor" and be a one-line cosmetic edit, while a plain-sounding one is deeply consequential. It splits what you KNOW from what you're ASSUMING, surfaces the silent failure modes, and verifies your riskiest assumptions before the irreversible step. Do NOT use for trivial reversible edits — renames of a local symbol, typos, comments, formatting, cosmetic tweaks.
drive-remote-terminal
Operate and observe an interactive, full-screen terminal program (a TUI) on a REMOTE machine over SSH by hosting it in a tmux (or screen) session and driving it like a human: TYPE with `tmux send-keys` and SCREENSHOT with `tmux capture-pane -p`. The loop — send input, wait, capture, read, decide the next input — IS the technique. Use it whenever you must act as the human at a remote terminal: launching or resuming an interactive app (Claude Code TUI, vim, top, an installer, a REPL, a curses menu), answering its prompts, typing into it, or reading what's on screen over SSH. Reach for it the moment a plain `ssh host 'cmd'` or a pipe isn't enough because the program needs a real terminal/PTY and stays running. Triggers: drive the TUI on my server, answer the prompt in that remote session, screenshot the terminal, resume my claude session on the server, type into the running program over ssh, automate keystrokes. Prefer this over one-shot SSH for anything interactive.
speak-like-operator
Match the operator's communication cadence (lowercase, terse, no preambles, "we" framing, no emojis). Use when responding in chat. Don't mock their typos — match their directness.
ooda
Use before deciding, acting, iterating, planning, diagnosing, or competing — whenever a move should be driven by a fast adapt-loop rather than a guess. Triggers on "what should we do", "how do we approach", deciding/planning, "let's iterate / ship / pivot", incident and root-cause work, "we're stuck", and competing/beating-an-incumbent. The move: run John Boyd's real OODA loop — Observe (measure, don't assume), Orient (reframe against stale models and bias — the highest-leverage step), Decide (one lever, as a hypothesis), Act (ship a test, re-observe), loop fast at an unpredictable tempo. Boyd-faithful: not a 4-box speed circle, Orient dominates, tempo is rhythm not haste. Reach for it on non-trivial decisions and iterative work; skip mechanical single-answer tasks.
cynefin
Use before choosing how to solve a problem, make a decision, plan work, diagnose a bug or incident, or pick between approaches — whenever the response should depend on what KIND of problem it is. Triggers on "how should we", "what's the best approach", "which option", deciding/planning, root-cause and incident work, design/architecture/refactor calls, and any "I'm stuck / this is uncertain / nobody's done this". The move: read the system by its constraints, place the Cynefin domain (Clear / Complicated / Complex / Chaotic — or admit Disorder), and apply the matching response — sense-making, never sorting into a 2x2. For the Complex domain, design a safe-to-fail probe portfolio, not a solution. Reach for it by default on non-trivial decisions; skip it for mechanical single-answer tasks.
world-first
Use when the goal is to produce and defensibly claim a genuine world-first, invention, novel algorithm/protocol/kernel/mechanism, or "nobody has done this" capability — and to prove the claim rather than assert it. Triggers on intent like "invent", "world-first", "first-ever", "beat the incumbent with something new", "break all dogma", "is this novel?", "prove this is new", or any push to build a mechanism a competitor structurally cannot. Also use to audit an in-flight "first" claim for overclaim before it ships, is committed, benchmarked-for-publication, or sent externally. This is the packaging of the INVENTION PLAYBOOK: confirmed-limit entry → TRIZ ideation → the removed-constraint test → refute-then-build vs a tuned baseline → provenance search → certify → kill failure modes. Reach for it by default on invention and novelty-claim work; skip only for routine feature work with no novelty claim attached.
break-dogma
Use when an inherited assumption is steering a decision and nobody has checked whether it still holds HERE — "that's how vLLM/SGLang/everyone does it", "you need X to do Y", "this is compute-bound / physics-capped / can't beat Z", "we always do it this way", "best practice is". Triggers on any borrowed runtime/algorithm/protocol adopted by default, any asserted wall or limit, any "must have" that was never measured in our regime, and any "break all dogma / challenge the assumption / why do we even do this" request. The move: name the dogma, mine where it came from and why (competitor issues/PRs/RFCs + searxng + repomix + deepwiki), test whether the constraint is actually load-bearing in OUR regime or cargo-culted from a different one, and if it is not necessary, break it and route to invention. Reach for it by default before adopting any borrowed component or accepting any asserted limit; skip only when the practice is a genuine leaf you are reusing on purpose (KISS).
flip-the-script
Use when about to assert a fact that has an exact external answer and the answer came from memory rather than a checked source — a library/API version or signature, a current-state or "latest/recommended" claim, an exact number/price/stat/date, a niche or long-tail detail, or a "yes that works / I already checked" you cannot point to evidence for. Also use whenever you notice felt-certainty standing in for a source, or you are about to declare something fixed/done/correct without a re-run. The move: treat unverified recall as stale + overconfident by default, classify whether the claim is in a reliable or unreliable recall domain, and route the unreliable ones to EXTERNAL ground truth (read-the-damn-docs, search, read the source, measure, or a fresh-context check) before asserting — not to internal second-guessing. Reach for it by default before any version/API/current-state/exact claim; skip it for stable well-known facts and settled, already-verified things (re-litigating those is its own failure mode).
herlihy
Use when atomicizing any subsystem or removing a concurrency constraint — a lock, a Mutex/RwLock, a blocking wait, a serialization point, a step-barrier, a GIL-serialized scheduler. Triggers on "make this lock-free", "atomicize this", "rewrite this atomic", "which atomic primitive", "CAS or fetch-add", "is this actually wait-free / lock-free", "prove this concurrent path correct", "how do I safely reclaim this memory under lock-free readers", or designing a KV cache / scheduler / commit / free-list / ring on hardware atomics. This is the Herlihy doctrine: pick the primitive by consensus number, fix the linearization point, choose the progress guarantee by whether a token can wait, pick the reclamation scheme by reader lifetime, and know the impossibility walls before burning a run. Reach for it by default whenever a token-flow path must be non-blocking; skip only for genuinely single-threaded code with no shared mutable state.
drive-screen
See and operate the user's real, physical Linux desktop through the mcp-screen MCP — screenshot any monitor and click/type/scroll/drag any visible app. Prefer screen_watch (~1 fps) after graphs/maps/canvases/loaders so thrashing UIs are caught like a human watches, not one freeze-frame. Use whenever the user points at something on their monitor(s) or wants you to read/drive a real GUI (Slack, browser, terminal, dashboards). Prefer over app/web APIs when looking at the real screen. NOT for pasted images, local files, shell-only, or remote SSH/TUI. Encodes locate → ground → act → confirm/watch plus hard-won gotchas.
drift-detector
Consult live drift state to check whether your recent replies have wandered from the user's active output contract (a terse persona, hard length/format rules, an in-character voice). Use when the user says you've changed tone, stopped following an instruction, or got verbose; when you're deep in a long session under a strict style; or before a reply when you're unsure you're still on-contract.
total-recallllm-setup
One-time setup for total-recall's product-owned ollama — installs the managed binary if needed and pulls default models. Triggered when SessionStart reports product ollama / models missing.
scientific-method
Use this skill whenever someone doubts a number, demands rigorous proof of a cause, or wants something invented and proven — any time a benchmark, metric, ceiling, or root-cause story must be verified rather than trusted, or a limit must be broken with a built, measured mechanism. Typical situations: a measurement looks suspicious ("2x faster but I don't trust it"); an incident needs its true cause before a decision ("the team blames X — confirm it, no guessing"); ANY production incident, outage, brownout, latency/error spike, regression, or "started failing" / "load suddenly went 5x" / "every component met spec but it still broke" report where the cause is not yet proven — especially when a recent deploy or change is suspected ("is the deploy to blame", "this coincided with the rollout"), since the obvious suspect is exactly what needs a control case; an asserted ceiling or "impossible" limit needs breaking or proving real; numbers need validation before publishing; a problem needs an invented solution that
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.