scoobydrew83
UserA coordinated library of Claude skills with explicit phase/handoff routing, shared state, and a maker/checker loop.
Categories
Indexed Skills (31)
agent-orchestration
Coordinate a phased, multi-specialist workflow for complex software work that spans several build stages — design, planning, implementation, testing, and deployment. Use this whenever a request bundles multiple stages together, e.g. "design this feature, plan the implementation, and scaffold the code", "take this idea to a working skeleton", "help me build X end to end", or any time the user wants structured coordination across the full build lifecycle rather than one isolated step. Trigger even when the user never says "orchestrate" or "agents" — what matters is that the task clearly has several stages that benefit from being sequenced with explicit phase boundaries and checkpoints. Do NOT trigger for single-stage asks ("fix this bug", "write this function") — those are handled directly without orchestration overhead. Do NOT trigger when the person is signalling they are stuck, paralysed, or overwhelmed by the size of the work — even on a genuinely multi-stage build, that combination calls for overwhelm-brea
conductor-init
Initialize a repo for the Conductor Method loop: write init.sh, seed FEATURES.json from the spec, create CONTEXT.md and MEMORY_BANK.md, verify a one-command test and a one-command lint actually pass, and land the baseline commit `loop(0): baseline green + criteria defined`. Use whenever someone is standing up a builder/verifier loop on a repo that doesn't have one yet, or says "set up the conductor loop here", "initialize this repo for the loop", "do Phase 0", "get this repo loop-ready", "seed FEATURES.json", or asks why the verifier keeps returning BLOCKED on a fresh project (the answer is almost always missing acceptance criteria, which is what this skill installs). Also use on an existing repo to audit and repair a half-done Phase 0. Do NOT trigger to design the loop itself or write its prompts — that is `loop-creator`; this skill only prepares the ground the loop runs on.
derisk-sequencer
Turn a validated idea into a risk-ordered sequence of experiments and build steps, with one hard rule — no product code is scheduled before the test that de-risks it. Use whenever someone has an idea worth building and asks what to do in what order — "what should I build first", "what order do I tackle this", "sequence this plan", "de-risk this roadmap", or presents a build plan that front-loads construction ahead of validation. The method lists the load-bearing assumptions, scores each by risk divided by cost-to-test, orders experiments cheapest-decisive first with kill-gates between them, places every build step after its unlocking test, and defers governance, breadth, and optimization until their gates clear — then emits an ordered sequence and a linter that flags build-before-its-test. Distinct from task-decomposition and overwhelm-breakdown (which collapse a big task to one next step for momentum) and agent-orchestration (which sequences build phases); this sequences de-risking ahead of building. Do NOT
drift-check
Audit a set of related project documents for internal contradictions and drift from their stated mission, with a skeptical eye that distrusts suspiciously clean alignment. Use whenever the user points at multiple docs (spec, PLANNING.md, README, AGENTS.md, .cursorrules, system prompt, TASK tracker, ADRs) and asks "are these consistent", "do my docs agree", "has my spec drifted", "check alignment", "is my README in sync", "audit my project for consistency", or shares a self-alignment/audit report. Especially trigger when documents should agree on the same facts (tech stack, metrics, feature lists, naming, architecture, tone) and the task is finding where they silently diverge, or where identical copy-pasted claims masquerade as validation. Lead with the real state of alignment and the biggest contradiction, never a vanity score. For cross-document consistency and mission-drift within a project's own materials, not verifying external claims (use reality-check) or choosing between options (use a council skill).
experiment-designer
Design a single falsifiable experiment with its pass/fail threshold fixed BEFORE the run, so a result can't be rationalized after the fact. Use whenever someone has a hypothesis or risky assumption and is about to just try it and see — "how do I test whether X", "design an experiment for this", "is this optimization worth it", "how would I prove or disprove this", "what would falsify this", or any "let me just run it and look at the numbers" with no threshold named. The method isolates the one decisive question, states the hypothesis and its negation, fixes a numeric metric and a PASS/FAIL/KILL rule up front, picks the cheapest decisive design, controls the confound that would make the result lie (optimization-before-correctness especially), and emits a dated pre-registration plus a falsifiability check. Distinct from reality-check (verifies an existing plan's claims), goal-builder (writes Claude Code /goal conditions), and hemlock (whole-idea GO/NO-GO); this designs one test and locks its bar.
goal-builder
Turn a vague intent into a correct, transcript-verifiable Claude Code /goal condition through a short question-and-answer interview. This is a Claude Code adapter: use it only when the user asks for /goal, a Claude Code unattended session, or a reusable .claude/commands slash command. It turns an open-ended prompt into a condition such as "npm test exits 0, without editing the test file" and rejects finish lines a transcript-reading evaluator cannot check. For portable builder/verifier loops, use loop-creator instead.
loop-creator
Design and generate portable autonomous/semi-autonomous AI work loops and the prompts that drive them — builder/verifier (maker/checker) loops, phased build loops, queue-driven multi-task loops, and nightly triage. Every loop has explicit acceptance criteria, a verifier separated from the builder ("close is FAIL"), commit checkpoints, a hard max-iteration plus human-escalation stop, and safe stopping conditions. Use whenever the user asks for a self-correcting, maker/checker, evaluator-optimizer, queue-driven, or iterate-until-it-passes process. It emits generic loop artifacts by default; it emits a headless Claude Code harness only when Claude Code is explicitly requested.
neurodivergent-comms
Format and pace responses so they're genuinely usable for neurodivergent people — ADHD and autistic readers especially — and adapt how you communicate whenever someone states a processing or pacing preference. Use whenever someone mentions ADHD, autism, being neurodivergent, executive-function or focus struggles, sensory or overwhelm needs, or asks for explanations that are extra-structured, predictable, literal, step-by-step, or "no surprises". Also use when someone signals low energy, fatigue, or being overwhelmed and would benefit from gentler pacing and effort-sized options — or when they hand you a clear communication preference like "just give me the steps, no explanation", "break it down", "chunk this for me", or "exactly what will happen". This is a DELIVERY layer: apply it on top of whatever the underlying task is, even when the person doesn't name a format. These preferences shape your REPLY rather than the work itself — when what needs chunking is a large project the person is stuck in front of, an
overwhelm-breakdown
Break an overwhelming project — or any large, vague task someone can't find an entry point into — down to a single concrete next step. Use whenever someone faces something big and signals they're stuck or overwhelmed: "I need to build a whole reporting system but I don't know where to start", "this feels like too much", "where do I even begin with X", "I'm drowning in this project", "can you break this down", "chunk it for me", "I'm paralyzed by the size of this". The goal is momentum, not a master plan: decompose into a few major parts, then collapse all the way down to one doable step sized by time AND energy, with a clear definition of done for today. Trigger on the combination of a large or ambiguous task PLUS stuck-ness, overwhelm, or an explicit request to break the work down — even if the person never uses the words "overwhelm" or "breakdown". Do NOT use this to produce a full project plan — that's the opposite of what an overwhelmed person needs.
project-postmortem
Generate an evidence-grounded project retrospective — pulled from git history and decision docs, not memory — that grades the project on separate dimensions, splits what went right from wrong, reduces the failure to its root ordering error, extracts transferable lessons for the next project, and names what survives. Use whenever a project ships, stalls, or gets sunset and someone wants the writeup — "post-mortem", "retrospective", "what went wrong with X", "we're sunsetting X, write it up", or mid-project "why did this go sideways". The method cites commit hashes or sources for every claim, builds a timeline of when validation happened vs building, separates pros from cons including uncomfortable symmetries, and ends with a per-dimension scorecard plus a what-survives list — then runs a check that fails any vanity scorecard or uncited narrative. Distinct from drift-check (audits live docs) and conductor-memory/session-bookend (capture session state for continuity); this extracts backward-looking lessons.
prompt-template-generator
Analyze a software project's files and generate a tailored, copy-paste-ready prompt-template cookbook (a Markdown "PROMPT-TEMPLATES.md") with the project's real stack, paths, subsystems, and conventions already filled in. Use this whenever the user wants to create prompt templates, a prompt cookbook, a prompt library, prompt scaffolding, reusable AI-coding prompts, or a "prompt template generator" for a codebase — or says things like "make prompt templates for my project", "build a prompt guide for this repo", "generate copy-paste prompts for my codebase", or "turn my project into a set of reusable Claude/Cursor prompts". Trigger it even when the user just points at a project and asks for ready-to-use prompts, since the value is filling templates with project-specific facts they'd otherwise type by hand.
reality-check
Use whenever someone hands you an AI-generated technical plan, recommendation set, setup guide, or tool/config list and says "validate this", "fact-check this", "is this real", "is this accurate", "did it hallucinate", "sanity-check this", "pressure-test this", "is this overkill", or asks whether a plan is feasible and worth doing. Trigger hardest when the content reads as machine-written and is dense with checkable specifics that could be fabricated — repo URLs, CLI flags, file paths, versions, env vars, named "best-practice" patterns, time estimates. The job: pressure-test the thing for hallucinations, factual errors, and unnecessary complexity, then verify every surviving claim against live sources before the user acts on it. Do NOT trigger for a bare dependency question — whether a specific package is real, alive, and maintained is leftpad's registry rung, so "should we add this package" or "is this crate abandoned" goes there. This VERIFIES an existing plan's accuracy and practical value, not choosing be
repo-troubleshooting-guide
Generate a clean, professional troubleshooting guide (a TROUBLESHOOTING.md) by analyzing a code repository — detecting its tech stack and mining real evidence (raised exceptions, error strings, env vars, ports, Docker services, CI) to document common failure modes with step-by-step fixes. Use this whenever the user wants to create, build, or generate a troubleshooting doc, guide, runbook, or ops reference for a repo, codebase, or project; wants to document common errors, setup problems, failure modes, or "how to fix X"; or points Claude at a repository and asks for a debugging/operations reference. Trigger even if the user doesn't say the exact word "troubleshooting" — e.g. "document the common errors in this repo", "make a debugging runbook", "build a setup-issues guide", "write an ops doc for this project".
session-bookend
Run the ceremony at a work session's boundary: a structured opening recap or a clean closing handoff, grounded in real retrieved context. Use at the START of a session when someone returning to ongoing work wants the whole picture laid out — what's done, where things stand, which decisions were made and why, and the next step — e.g. "what's the status of X", "back to the project, catch me up". Use at the END — "let's wrap up", "good place to stop", "save where we are", "give me a clean handoff for next time" — to leave the next session a usable starting point. The defining rule: ground every recap in REAL retrieved context (past-chat search, memory, project files, notes), never invented status. Trigger whenever a multi-session project is resuming or wrapping. Reach for this when the ask is the ceremony at a session boundary rather than the lookup itself — retrieving what a past conversation actually said is session-continuity's job, and a bare "where were we" or "what did we decide about X" belongs there. Do
system-prompt-builder
Interview-driven builder for enterprise-grade AI system prompts and agent architectures. Use whenever the user wants to design, build, scaffold, or rebuild a system prompt, custom assistant, AI agent, project instructions, custom GPT, multi-agent system, or any reusable LLM instruction set. Trigger on phrases like "build me a prompt system", "design an agent", "write system instructions", "turn this into an agent", "create project instructions", "I want an AI that does X reliably", or any request to architect how an AI should behave across many future interactions — even when the user never says the words "system prompt." Also trigger when the user pastes an existing system prompt and wants it rebuilt, hardened, or extended.
visual-plan
Plan visually instead of dumping markdown: structure a plan as typed, lint-able blocks (.harness/plan/blocks.json — diagrams, wireframes, decisions, annotated real code, questions), render it to a plan.html derived entirely from ground truth (FEATURES.json, telemetry.jsonl, git), and serve it locally so the human reviews IN the page — pinned comments land in tracked comments.jsonl and BLOCK the features they cite until resolved with an answer. Use whenever someone says "visual plan", "/vplan", "plan this feature", "show me the plan", "make the plan reviewable", wants to review or comment on a plan, says "address my comments" / "/address-comments", or asks to see plan status rendered. Also use to structure a captured plan-mode plan (blocks tagged needs-structuring from the ExitPlanMode hook). The defining rule: the plan is a RENDERING of ground truth plus authored blocks — never a second source of truth; plan.html is generated and never hand-edited. Do NOT use for seeding a fresh repo's harness (that is conduc
grandfather
Makes your AI agent think like the maintainer who has never once broken a user without a deprecation path — every existing caller gets grandfathered in. Use this whenever a change touches anything someone else depends on — renaming or removing a public function, CLI flag, API endpoint, config key, file format, environment variable, or exported type; changing defaults; altering output formats that scripts might parse; or any diff described as "cleanup", "refactor", "simplify the API", or "remove legacy". Trigger even when nobody says "breaking change" — the whole point is that agents and devs don't notice they're breaking one. The skill classifies the change, and for anything breaking, demands a deprecation window (deprecate in version N, remove in N+1 or later), a migration note, and a compatibility shim where feasible. Ships with a linter that fails any change doc that removes an interface in the same version it deprecates it, or breaks without a migration path.
leftpad
Makes your AI agent think like the dev who remembers March 2016, when an 11-line npm package got unpublished and broke the internet. Every dependency is a stranger with commit access to your product. Use this whenever a new dependency is about to enter a project — any "npm install", "pip install", "cargo add", "add this package", "there's a library for that", import of something not yet in the lockfile, or an AI-generated plan that lists packages to install. Trigger especially on AI-recommended package lists, because hallucinated or abandoned packages survive unchallenged without live registry verification. The skill runs a 6-rung dependency ladder (do we need this at all → stdlib → already-installed deps → vendor the 20 lines → verify the package is real, alive, and maintained on the registry → add with an exit plan) and refuses ADD verdicts without live registry evidence. Ships with a linter that fails any decision doc approving a dependency without stdlib/existing-dep checks and registry proof.
popquiz
Makes your AI agent think like the reviewer who won't merge what you can't explain. Comprehension debt — code that ships without anyone understanding it — is a loan against every future incident. Use this whenever agent-generated or unfamiliar code is about to merge — before approving a PR, before merging loop-generated work, at the end of any autonomous build session, or whenever someone says "merge it", "ship it", "approve this PR", "LGTM", or accepts a large diff they didn't write line-by-line. Especially trigger for autonomous/headless agent output and multi-file diffs. The skill runs a 5-rung explain ladder ending in a written quiz the human (or authorizing agent) must answer before APPROVE is allowed. Ships with a linter that fails any review containing an APPROVE verdict without a completed quiz, unanswered questions, or rubber-stamp phrases. Do NOT use for trivial diffs the author wrote by hand and can already explain — the gate is for understanding gaps, not ceremony.
tinfoil
Makes your AI agent think like the security reviewer who assumes every input is hostile until the code proves otherwise. Not paranoid — just right often enough that it stopped being funny. Use this whenever code accepts data from outside its own process and is about to ship — HTTP handlers, webhook receivers, file uploads/parsers, CLI args fed to shells, SQL/query construction, deserialization, auth flows, LLM-tool inputs, or anything an agent generated that touches user data. Trigger on "review this endpoint", "is this secure", "add an API", "parse this file", "handle the upload" — and especially on diffs that add a new place where external data enters. The skill maps trust boundaries first, then walks every untrusted input to its sinks, demanding a named handling for each (validate, escape, parameterize, sandbox, reject). Ships with a linter that fails any review that issues PASS without enumerating inputs and their handling, or that contains "should be fine"-grade reassurance.
conductor-memory
Extract and build a complete memory pack from an agent conversation or session, synthesizing it into vault-ready artifacts so the next session resumes with full context. Produces a conversation summary, artifact index, communication-style and project-context notes, a machine-readable seed JSON and persona YAML, verification and maintenance checklists, and a generalized integration.py that copies the pack into an Obsidian vault and can update a session-memory pointer file (with an optional MCP/vector-store hook). Use this whenever the user says 'build conductor memory', 'extract memory from this conversation', 'capture this session', 'snapshot our progress', 'save this to memory', or 'update conductor memory' - and also when wrapping up a substantial working session whose context should persist as durable artifacts across agents, Obsidian, or MCP. A plain spoken wrap-up belongs to session-bookend; this skill creates durable artifacts when the handoff must outlive the conversation.
hemlock
Use BEFORE any new project, product, feature, or "I have an idea" moment — whenever someone is about to build something and the riskiest thing is the premise, not the code. Triggers include "I want to build X", "should I build X", "is this idea worth it", "validate this idea", "does this beat what already exists", "new project idea", "let's start on", "kick off", any plan that schedules construction before validation, and mid-build "should I keep going or kill it". Trigger even on enthusiasm ("I have a great idea for…"), not just doubt — enthusiasm is when this skill earns its keep. Makes your AI agent think like the skeptic who kills your project on day one so day fifty doesn't have to: the cheapest code is the project you never started. Runs a 6-rung kill ladder (incumbent → riskiest assumption → cheapest decisive test → pre-registered kill bar → run → verdict) and refuses to authorize building until every rung is climbed. Bundled linter fails any verdict with an unnamed incumbent, unranked assumptions, or
session-continuity
Pick up where a past conversation left off by retrieving real history instead of guessing. Use this whenever someone writes as if you already share context — "where were we," "that schema we designed last month," "continue the project," "what did we decide about X," "remember the thing I'm working on" — or resumes after a gap and expects you to know the prior state. Trigger on any reference to earlier sessions in the user's own words: "our previous chats," "the conversation we had last time," "that earlier session," "we talked about this before." Reach for it on possessives and definite articles that assume shared memory ("my project," "the bug we discussed," "our approach") even when they don't explicitly say "do you remember."
adaptive-communication
DEPRECATED — this skill was merged into `neurodivergent-comms` on 2026-06-16 because the two were competing for the same triggers. Do NOT trigger this skill. If you see this description matching a user request, use `neurodivergent-comms` instead — it now covers ADHD-leaning, autism-leaning, energy-aware, and general "format/pace this for me" requests, including the before/after example and the literal-clarity guidance that used to live here. This tombstone exists only because the source file could not be deleted in the build environment; treat it as a no-op redirect.
task-decomposition
DEPRECATED — this skill was merged into `overwhelm-breakdown` on 2026-06-16 because the two were competing for the same triggers. Do NOT trigger this skill. If you see this description matching a user request, use `overwhelm-breakdown` instead — it now covers "I'm overwhelmed, where do I start?" alongside "break this big thing down for me", with the worked reporting-system example, the size-by-time-AND-energy guidance, and the "use real tools only" caution that used to live here. This tombstone exists only because the source file could not be deleted in the build environment; treat it as a no-op redirect.
agent-workspace-compatibility
Set up or audit a portable agent-skills repository that uses .agents/skills as the canonical source, AGENTS.md as canonical persistent instructions, and generated provider packages. Use when migrating Claude, Codex, Gemini, or skills.sh skill layouts; do not use for ordinary application code changes.
assumption-grill
Surface and resolve the assumptions that would make a plan unsafe before implementation starts. Use when a request has consequential ambiguity, competing interpretations, unclear ownership, irreversible choices, missing success measures, or a person asks "what are we assuming?". It creates a compact decision card with evidence, reversibility, owner, and the smallest test or human decision that resolves each material unknown. Do NOT use for routine implementation details that can safely be decided while building.
conductor-doctor
Audit a repository's Conductor harness without changing it. Use when someone asks whether the loop is ready, why routing is blocked, whether state and policy agree, or to diagnose aliases, generated packages, criteria, evidence, queue transitions, and required tests. With `--library-root`, it also audits instruction aliases and the generated Marketplace package. It returns Conductor verdict PASS, FAIL, or BLOCKED with directly actionable repairs. Do NOT use it to silently repair a repository; it is read-only by design.
conductor-router
Route one Conductor queue item through Orient, Frame, Authorize, Execute, Verify, Review, and Learn without doing the item itself. Use when an agent needs to determine the next legal lifecycle phase, resume a loop, reconcile a queue state with verdicts, or decide whether to escalate. It enforces loop policy, explicit human gates, evidence requirements, and the three-failure stop. Do NOT use it to bypass a human decision or to implement a queue item.
next-step
Find the single safest next action when someone says "what now?", "I don't know what to do next", "where do I start", returns to a cold project, or has an unclear Conductor queue. Use it to orient from CONTEXT.md, MEMORY_BANK.md, LOOP_QUEUE.md, FEATURES.json, and loop policy before proposing work. It distinguishes a blocked human decision from actionable work and never invents missing acceptance criteria. Do NOT use for emotional overwhelm that needs a smaller activation-energy step; use overwhelm-breakdown instead.
idea-validator
DEPRECATED — this skill was superseded by `hemlock` on 2026-07-04 because the two were competing for the same triggers ("should I build X", "validate this idea", "is this worth building"). Do NOT trigger this skill. If you see this description matching a user request, use `hemlock` instead — it now covers everything that lived here: the incumbent-first gate, the risk ÷ cost-to-test assumption ranking, the real-vs-differentiated split (real-but-commodity is a NO), pre-registered kill criteria, the GO / NO-GO / CONDITIONAL-GO verdict with scorecard, the anti-pattern taxes, the honesty rules, and the worked examples (moved to hemlock/references/) — plus a bundled linter that mechanically enforces the honesty rules this skill only stated. This tombstone exists to preserve graph integrity; treat it as a no-op redirect.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.