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

workflow-composer

Write and debug workflow scripts for Claude Code's Workflow tool: single .js files in which deterministic JavaScript drives fleets of fresh-context subagents through agent(), parallel(), pipeline(), and phase(). Invoke for any request to build, generate, draft, repair, or restructure such a workflow ("I want a workflow that…", "turn this process into a workflow", "set up a multi-agent pipeline for X", editing files under .claude/workflows/), for questions about the script format — the meta literal, the orchestration primitives, structured-output schemas, the no-nondeterminism rules — and for diagnosing a workflow that launched with an error or produced wrong output. Fire it too when a request merely DESCRIBES a repeatable multi-stage or fan-out job that deserves packaging as a workflow, with or without the word. Teaches the bundled @workflow-toolbox TypeScript pattern toolkit as the standard library for workflows that will be kept and maintained. Out of scope: simply launching an already-written workflow, and