Local Workflows
AI quality is decided by the context you feed it.
A VS Code extension: a local pipeline runner and spec-driven
development, on one engine, declared in files you own.
📖 Full documentation →
Why this exists
Every long AI session decays: the failed tool calls, the dead ends, the
side questions all stay in the context, and the model reasons over all
of it. The fix is not a better model — it is cutting work into the
smallest unit that can stand alone, so the detours never travel forward.
The pipeline runner
Your daily commands in .local-workflows/tasks.yml, whole pipelines in
.local-workflows/workflows/*.yml. Run them from a native sidebar with
a live, GitHub Actions-style run panel and a dependency graph — no
commit, no push, no CI queue, no Docker. Nothing leaves your machine:
no server, no account, no telemetry of your runs.
Spec-driven development
A spec is a folder of Markdown next to your code — requirements.md,
design.md, tasks.md. AI drafts each phase, a human approves it, and
the next phase is prompted from the approved file alone — never the
chat that produced it. The prompts themselves are files in your
repository, versioned and reviewed like any other code.
Not every task needs AI
AI produces data, and a file you wrote and reviewed decides what
happens to it. Drafting release notes is a job for a model;
publishing is not:
- name: Draft the notes
uses: ai
args:
prompt: Draft release notes from the commits on this branch.
artifact: NOTES # a value, not a decision
- name: Publish
trigger: manual # a human reads the resolved args first
run: ./publish.ps1 -Body "${{ run.context.NOTES.summary }}"
You read what the model wrote in the run panel's Data tab — rendered
as markdown, not a wall of \n — before approving the gate.
Not for you if
- You need unattended or scheduled runs. No server; close the
laptop and nothing runs.
- You need hundreds of SaaS connectors. First-party plugins plus
your own JavaScript is the whole ecosystem, and it is not growing
into a marketplace.
- You want the model to decide what runs. Structurally refused.
- You want a no-code canvas. It is YAML, reviewed in pull requests.
- You only need aliases for three shell commands.
just is
lighter; this earns its keep at the graph, the AI steps, the specs.
- You are not in VS Code. The one not yet on this list.
⚠️ Caution
run: executes shell commands, unsandboxed — the same risk class
as npm run. Cloning an untrusted repo and clicking a task is a real
execution vector. workspaceFolder/cwd decide where a process
starts, not what it can reach. (Plugins you write are different:
they run confined under Node's permission model.)- AI tasks write to your working tree. Git is your safety net;
review what they change.
- Young project. ~3,200 unit tests on the engine, hand-verified VS
Code integration. Not intended for a mixed-OS team.
Requirements
- VS Code 1.103+ — run history is SQLite via Node's built-in
node:sqlite; on older builds history is in-memory only, and it says
so rather than losing it quietly.
- PowerShell for
shell: pwsh tasks and the pwsh@1 plugin.
- For AI and SDD only: a sign-in and the CLI of whichever provider
the task names. Default
ghcp: a GitHub Copilot sign-in and the
Copilot CLI — npm install -g @github/copilot, ~340 MB. The CLI,
not the Copilot editor extension. claude: a Claude sign-in and
npm install -g @anthropic-ai/claude-code. Kiro, Gemini CLI, Codex,
Cursor, OpenCode: that vendor's CLI, over the Agent Client Protocol.
Everything else works without any of them.
- Kiro, VSCodium, other Code-OSS builds: install from
Open VSX
— the same build, on the registry those editors search.
License
Free to use — for anything, personal or commercial, on as many
machines as you like. Not open source; the source is not distributed.
You may not copy, modify, redistribute, or build a derivative work from
the installed extension. Everything you author — tasks, workflows,
prompts, specs, plugins — is entirely yours. Provided as-is, with no
warranty; the Caution section is what that means in practice.
