Developer Tool Workflows

Initialize a repo for the Conductor Method loop: write init.sh, seed FEATURES.json from the spec, create CONTEXT.md and MEMORYBANK.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.

Extract and build a complete memory pack from a Claude 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 updates a Claude Code resume pointer (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 that should persist for continuity across Claude Code, Obsidian, or MCP, even if they don't say the word 'memory'. Built for the Conductor Method continuity system; works for any project needing durable cross-session memory.

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.

Turn a vague intent into a correct, transcript-verifiable Claude Code /goal condition through a short question-and-answer interview, then (when the pattern recurs) crystallize it into a reusable .claude/commands/ slash command. Use whenever the user wants to write, fix, or improve a /goal command, set a completion condition, "keep Claude working until X", run an unattended/until-it-passes Claude Code session, or says their /goal "just keeps looping" or "stops too early". Trigger even if they don't say "goal" but describe wanting Claude Code to loop on its own until a measurable end state holds. The point is to stop them writing a PROMPT ("clean up my code") when /goal needs a CONDITION ("npm test exits 0, without editing the test file"), and to refuse any goal whose finish line a transcript-reading evaluator can't check. For crafting the single /goal line; to build a full builder/verifier loop package (spec, prompts, harness, CI) use loop-creator.

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.

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. Use this 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. 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 a kill bar written after the result. Supersedes idea-validator. Distinct from reality-check (verifies an existing plan for hallucinations), experiment-designer (designs one test), and derisk-sequencer (orders many tests) — hemlock decides whether the project deserves any tests at all.

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.

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. Do NOT treat it as a fixed template to stamp on every reply — read the cues and adapt, because ADHD and autistic needs sometimes pull in different directions.

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.

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.

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.

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.

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".

Open and close work sessions with clean, grounded continuity. Use at the START of a session when someone returns to ongoing work — "where were we", "pick up where we left off", "what's the status of X", "back to the project" — to produce a recap of what's done, where things stand, decisions made and why, and the next step. Use at the END of a session — "let's wrap up", "good place to stop", "save where we are" — to produce a clean handoff for next time. 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. Do NOT fabricate a "where we left off" from nothing — if you can't retrieve it, say so and ask.

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.

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.