task manager + workflow engine for coding agents

You don't need a smarter agent.
You need a way to run them in loops.

Local-first task tracking and code-defined workflows that drive your coding agents — Claude Code, pi, or your own — through a real pipeline you can watch, steer, and trust.

View on GitHub

macOS · Linux · iOS — open source, MIT

autosk across three front ends: the lazy TUI streaming a transcript, the desktop GUI detail pane, and the mobile web view

terminal

$ autosk create "Wire up the auth flow"
ask-3f9b2c
$ autosk enroll ask-3f9b2c --workflow feature-dev
# the daemon runs the agent pipeline and returns when done or parked

the problem

One chat window is not a process.

Coding agents are powerful but unmanaged. One context, no memory of what's next, no handoff from a coder to a reviewer, no record of why work parked. So you re-prompt, copy-paste context between tabs, and hope the agent transitions cleanly.

No handoffs

The coder and the reviewer are the same forgetful chat. Nothing carries from one role to the next.

No guardrails

Nothing stops an agent looping on the same failing step until it runs out of tokens — or your patience.

No memory

Context dies when the tab closes. Why work parked, what came next — none of it lands anywhere.

the model

Tasks → workflows (as code) → agents the daemon drives.

autosk gives agent work structure (tasks with dependencies), process (workflows written in TypeScript, versioned in your repo), and observability (live transcripts) — while everything stays local and file-based under .autosk/.

feature-dev: dev → review → docs → validator → accept → cleanup → done, with bounce-backs to dev

structure

Tasks with ids, statuses, blockers, and a free-form metadata bag — a real backlog the engine can pull a ready set from.

process

A workflow is a TypeScript graph of steps, each owned by an agent. It lives in your repo and evolves in code review.

observability

Every run streams a live transcript — text, thinking, tool calls — to disk and to any attached front end.

30 seconds

Create. Enroll. Watch.

Almost no ceremony. Three commands take a one-line task from your head to a running agent pipeline you can observe.

01
Create a taskautosk create
A task is a small local file with an id, a title, and a status. No project to set up — the first write creates .autosk/.
02
Enroll into a workflowautosk enroll
Hand the task to feature-dev (or your own workflow). The daemon picks it up and starts driving it through the graph.
03
Watch it runautosk lazy
Open the lazy TUI or the GUI and the agent's transcript streams live into the detail pane — text, thinking, tool calls. Steer or abort mid-turn.

create → enroll → watch

# 1. create a task
$ autosk create "Wire up the auth flow"
ask-3f9b2c

# 2. enroll it into a workflow
$ autosk enroll ask-3f9b2c --workflow feature-dev

# 3. watch the agents run, live
$ autosk lazy

Prefer the desktop app? The GUI shows the same live transcript.

why autosk

Depth where it counts.

The selling points lead with what is genuinely new: process as code, agents that hand off with guardrails, and a local file model with nothing to migrate.

Workflows as code, not config

A workflow is a TypeScript graph of steps, each owned by an agent, versioned in your repo. No database, no brittle JSON editor.

Multi-agent handoffs

Agents pass work through comments; every prior comment is injected at the top of the next step's prompt, so context carries between roles.

Guardrails that stop loops

step_visits caps how many times a task can bounce through a step. After N failed reviews it parks for a human — not forever.

Never lose work

Any run that can't transition cleanly is parked to human. Crash recovery seals interrupted sessions so work always lands somewhere a person can pick it up.

Agent-owned sandboxes

Run each task in its own git worktree (autosk/<task-id>) or a per-task Docker container, so parallel agents never clobber each other's files.

No database — just files

Tasks, comments, and transcripts are plain files under .autosk/. Hand-editable, git-diffable, no migrator, no engine.

Three front ends, one source of truth

A lazygit-style TUI, a native Tauri desktop GUI (+ iPhone/iPad), and the CLI — all pure JSON-RPC clients of one daemon, all streaming the same live transcript.

Bring your own agent

Ships an agent that drives pi and one that drives Claude Code headless. Swap them inline in a workflow, or write your own.

Extensions, no build step

Drop a .ts file in .autosk/extensions/ or run autosk ext add npm:@scope/pkg. A broken extension shows up in diagnostics instead of crashing the daemon.

up close

The flagship features, with room to breathe.

workflows as code

Workflows you can read in a diff.

A workflow is a TypeScript graph of steps. Each step is owned by an agent and declares its transitions. It lives in your repo, evolves in code review, and carries no hidden state.

Process is code — versioned, reviewable, testable.
The step key is the agent's name; no separate registry.
A statusStep is a human gate — the only non-agent step.

feature-dev.ts

export const featureDev = defineWorkflow({
  name: "feature-dev",
  steps: {
    dev: devAgent,
    review: reviewAgent,        // → dev | docs
    docs: docsAgent,
    validator: validatorAgent,  // → dev | accept
    accept: acceptAgent,
    cleanup: cleanupAgent,
    human: statusStep("human"), // escape hatch
  },
});

handoffs + guardrails

Handoffs with a human escape hatch.

Agents collaborate by leaving comments; every prior comment is injected at the top of the next step's prompt, so context carries from coder to reviewer. step_visits caps the loop — after N bounces a task parks for a person.

Comments are the shared, durable channel between steps.
step_visits stops an agent from looping forever.
When in doubt, work parks to human — never lost.

dev→ask-3f9b2c

Implemented the auth flow; tests pass locally. Handing to review.

review→ask-3f9b2c

Token refresh isn't covered. Bouncing back to dev for a test.

ask-3f9b2chuman

step_visits.dev = 3

agent-owned sandboxes

Isolation without orchestration glue.

Each task runs in its own git worktree (autosk/<task-id>) or a per-task Docker container. Parallel agents never clobber each other's files — and the engine knows nothing about sandboxes. Agents own them.

True parallelism: one worktree (or container) per task.
A final cleanup step tears the worktree down on the way to done.
Swap worktreeSandbox() for dockerSandbox() — same contract.

isolation

$ git worktree list
/repo                  [main]
/repo/.autosk/wt/...   [autosk/ask-3f9b2c]
/repo/.autosk/wt/...   [autosk/ask-77c1a0]

# two agents, two branches, zero collisions

live observability

Watch the work, not just the result.

The agent's pi-format transcript streams live into the detail pane of the TUI and the GUI — text, thinking, and tool calls — and persists to disk. Steer it mid-turn, or abort. It's observability you don't get from a headless one-shot.

One live transcript, three front ends, one daemon.
Thinking + tool calls are first-class, not hidden.
Steer or abort a running session without losing the record.

session 9b2cwork● streaming

dev reading src/auth/flow.ts

› thinking: the refresh path needs a guard…

tool edit src/auth/flow.ts +18 −2

tool bash go test ./... ok

Implemented. Transitioning → review.

why not just…

It's a runtime, not another chat or another board.

Why not just use an agent directly?

You get a pipeline — multi-step, multi-role, with handoffs and guardrails — instead of one ephemeral chat.
You get parallelism — a sandbox per task — instead of stepping on your own working tree.
You get observability — live and persistent transcripts — instead of a headless one-shot you can't watch.

Why not a task tracker (Jira / Linear)?

autosk isn't a ticket board — it's a runtime. Tasks aren't tickets; they're units the engine executes through agents.
Process lives in code, not a config UI, so it evolves with your repo in code review.
And you can still stop at step one and use it as a plain, file-based backlog.

yours to run

Local, file-based, and open.

No database

Everything is files in your repo — hand-editable and git-diffable.

Parks, never crashes

Interrupted work always lands in human, ready for a person to resume.

Open source, MIT

Yours to read, fork, and run. No telemetry, no lock-in.

Signed & notarized

macOS cask; Linux binaries + AppImage/.deb; iOS via TestFlight.

install

Run your agents in a loop.

One command installs the CLI, the TUI, and the daemon. Then point it at any repo and go.

macOSLinuxiOSFrom source

Homebrew cask

$ brew install --cask wierdbytes/autosk/autosk

Signed + notarized. Bundles the CLI/TUI/GUI and the daemon.

Latest GitHub Release

iOS App (beta)

Requires the TestFlight app. Companion to the daemon — watch and steer sessions on the go.

From source

$ make install

Any platform. Builds and installs both binaries.

$ autosk lazy

Docs GitHub Changelog

You don't need a smarter agent.
You need a way to run them in loops.

One chat window is not a process.

No handoffs

No guardrails

No memory

Tasks → workflows (as code) → agents the daemon drives.

structure

process

observability

Create. Enroll. Watch.

Create a task`autosk create`

Enroll into a workflow`autosk enroll`

Watch it run`autosk lazy`

Depth where it counts.

Workflows as code, not config

Multi-agent handoffs

Guardrails that stop loops

Never lose work

Agent-owned sandboxes

No database — just files

Three front ends, one source of truth

Bring your own agent

Extensions, no build step

The flagship features, with room to breathe.

Workflows you can read in a diff.

Handoffs with a human escape hatch.

Isolation without orchestration glue.

Watch the work, not just the result.

It's a runtime, not another chat or another board.

Why not just use an agent directly?

Why not a task tracker (Jira / Linear)?

Local, file-based, and open.

No database

Parks, never crashes

Open source, MIT

Signed & notarized

Run your agents in a loop.

You don't need a smarter agent. You need a way to run them in loops.

No handoffs

No guardrails

No memory

structure

process

observability

Create a taskautosk create

Enroll into a workflowautosk enroll

Watch it runautosk lazy

Workflows as code, not config

Multi-agent handoffs

Guardrails that stop loops

Never lose work

Agent-owned sandboxes

No database — just files

Three front ends, one source of truth

Bring your own agent

Extensions, no build step

Workflows you can read in a diff.

Handoffs with a human escape hatch.

Isolation without orchestration glue.

Watch the work, not just the result.

Why not just use an agent directly?

Why not a task tracker (Jira / Linear)?

No database

Parks, never crashes

Open source, MIT

Signed & notarized

Run your agents in a loop.

You don't need a smarter agent.
You need a way to run them in loops.

Create a task`autosk create`

Enroll into a workflow`autosk enroll`

Watch it run`autosk lazy`