home-dev-lab

toolkit-scaffold

Scaffold a new Claude Code Workflow as a build-clean `.workflow.ts` skeleton from the @workflow-toolbox pattern toolkit, so you never hand-roll the `defineWorkflow` boilerplate. Invoke when the user describes a workflow they want and asks to "scaffold a workflow", "start a new workflow", "generate a workflow skeleton", "set up a .workflow.ts", "wire these patterns together", or "use the toolkit to build a workflow". Given a plain job description, pick the patterns (from the L1 use/don't-use table), write a small JSON spec, run `workflow-toolbox scaffold`, then fill in the placeholder prompts/data and build + check. Out of scope: deep one-off authoring guidance (that is the broader workflow-composer skill), diagnosing a failed RUN (workflow-debugger), and re-verifying the runtime after a Claude Code upgrade (upgrade-canary).

upgrade-canary

Re-verify that Claude Code's Workflow-tool runtime still behaves the way the @workflow-toolbox toolkit depends on, after a Claude Code upgrade — and report what changed. Invoke when the user upgraded (or might have upgraded) Claude Code and asks whether the workflow toolkit / committed artifacts still work, when they say "run the upgrade canary", "did the update break the workflows", "re-check the runtime surface", "what changed in the runtime", or before cutting a plugin release. The canary is version-triggered: the full check runs only when the `claude` CLI or the Agent SDK version changed since it last passed (or when forced), so it is cheap to invoke often. It tests TWO runtimes — the user's interactive `claude` binary AND the SDK-bundled one — and reports their version delta + any behavior drift, which can drive fixes or feature work. This is a MAINTAINER tool — it runs against this repo's `toolkit/` dev tree and needs local Claude Code subscription auth; it is not meant for end users who only installed

workflow-debugger

Diagnose why a Claude Code Workflow-tool RUN failed or behaved oddly, from its on-disk run journal, and decide whether a `resumeFromRunId` re-launch will actually help. Invoke when a workflow launched but errored, returned a wrong or partial result, seems stuck, or the user asks "why did my workflow fail", "debug my workflow run", "the workflow errored / died", "can I resume this run", "what happened in run wf_…", or wants a run's journal read and explained. It reads the structured journal Claude Code writes for every run (the per-agent `agent-*.jsonl` transcripts are only a fallback), classifies the failure mode, and recommends — honestly — when resuming replays cached work and when it would save nothing. Out of scope: AUTHORING or restructuring a workflow script (that is the workflow-composer skill) and checking whether a Claude Code upgrade changed the runtime surface (that is the upgrade-canary skill).

what-next

Propose the logical next step given the project's task backlog — a Planka board (via .claude/planka.json, when the `planka` MCP is reachable) or, failing that, a .claude/progress.md file — plus the current conversation and, if the project keeps one, a knowledge index such as `MEMORY.md`. Use when the user types /what-next or asks "what's next", "what should I tackle now", "what comes after this", or has just finished a chunk of work and wants a recommendation grounded in their tracked backlog. Works even with none of the above present, falling back to conversation + memory and saying so plainly. Read-only — proposes, never mutates the board, progress.md, or task state. Pairs with the `planka-tracking` skill, which sets up the board this skill reads.

adopt-rules

Invoke ONLY when the user explicitly asks to install / adopt editable copies from workflow-toolbox into their config, or to check adopted copies for updates. Two managed sets — the cross-cutting RULE files (the delegation ladder) and the pilot AGENT-definition copies (pilot / pilot-watchdog / pilot-orchestrator, whose project copies enable the watchdog observer pairing that plugin-installed agents can't). E.g. "adopt the delegation rules", "install the workflow-toolbox rules as editable files", "install project copies of the pilot agents", "adopt the pilot watchdog into this project", "check my adopted workflow-toolbox rules/agents for updates". Writes versioned, fingerprinted, editable files ONLY on explicit request — never automatically. Re-invoke to detect stale copies (installed version behind the plugin) and refresh them. Not for authoring workflows (workflow-composer) or composing a pilot wave (pilot-wave).

deep-grounding

Run a deep-grounding pass BEFORE asserting or analyzing — do not answer from priors on the first source or angle that comes to mind. Ask "where could the evidence for this be?", gather the relevant available sources (project memory, READMEs/docs, the actual code/config, tests, logs/telemetry, tickets, git history, the web — whatever fits the question), and follow the leads they reveal RECURSIVELY, even low-odds ones, until the trail runs dry; THEN reason, grounded, tagging each conclusion with its evidence tier and stating what could not be verified. Use this PROACTIVELY whenever you are about to assert a checkable claim, start a non-trivial analysis / design / diagnosis / recommendation, or answer from "what you already know" — ESPECIALLY when you notice yourself reaching for a conclusion from a single source or a single angle, or when a result BEATS your expectation (favorable surprises are the ones that silently skip verification). Evidence, not more reasoning, is what escapes a wrong prior.

independent-analysis

Run a bias-free, multi-lens adversarial analysis of any non-trivial subject — a design, plan, decision, claim, architecture, root-cause theory, or change set — via the bundled independent-analysis workflow. Fresh agents, each pinned to a distinct lens and blind to the conversation, surface what the driving model overlooked, then refute-first verifiers kill the plausible-but-wrong ones. Use this PROACTIVELY before committing to a non-trivial design or decision, and whenever the user asks to stress-test or red-team thinking, get a second opinion, sanity-check a conclusion, audit docs or a plan for accuracy, or "make sure no angle is forgotten" — even if they never say the words "workflow" or "analysis". Reach for it ESPECIALLY when you suspect your own reasoning may be biased by going fast or by confirming a prior assumption: independent agents are the cheapest way to catch that.

pilot-wave

Invoke when you want a WAVE of task-tracker cards (or a single card) driven end-to-end through the dev loop by delegation — "run these cards", "pilot this wave", "spawn a pilot for this ticket", "set up the orchestrator for these". Composes the environment brief (knowledge-base index, task tracker, executor lane, worktree + report dirs, quota posture) and the orchestrator/pilot spawn prompt with model elevation, so your main session stays a thin relay. Not for a single mechanical edit — spawn a plain sub-agent for that.

workflow-composer

Invoke when the user asks to build, generate, repair, or restructure a workflow for Claude Code's Workflow tool ("I want a workflow that…", "turn this process into a workflow", "set up a multi-agent pipeline"), to pick orchestration patterns, or to tune model/effort/agentType routing. Covers writing and debugging the single .js scripts where deterministic JavaScript drives fleets of fresh-context subagents (agent/parallel/pipeline/phase), via the @workflow-toolbox toolkit or the raw single-file path.

planka-tracking

Onboard the CURRENT project onto a Planka kanban board for task tracking — create a project/board/lists/labels via the `planka` MCP, migrate an existing .claude/progress.md into reformulated, classified cards (zero-loss), and write the .claude/planka.json pointer that this skill's companion, `what-next`, reads. Requires the `planka` MCP server to be installed and reachable in the session — this skill cannot run without it. Use when a project has no .claude/planka.json and the user wants to start board-based task tracking, or says things like "onboard this project to Planka", "set up the board here", "start tracking tasks on Planka", "track my tasks on a kanban board".