What makes TaskOps notable?

1.1K downloads. Trust evidence available

How should TaskOps be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

TaskOps

Manage AI-agent work as an execution graph instead of a flat TODO list. Use TaskOps to structure objectives, task decomposition, run readiness, execution log... Skill: TaskOps Owner: jimmylegendary Summary: Manage AI-agent work as an execution graph instead of a flat TODO list. Use TaskOps to structure objectives, task decomposition, run readiness, execution log... Tags: latest:0.5.4 Version history: v0.5.4 | 2026-06-16T11:48:56.544Z | user Add taskops daemon supervisor with user-systemd install/start/status/logs/uninstall lifecycle. v0.5.3 | 2026-06-16T11:07:43.678Z | user

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.1k

Updated

Oct 11, 2026

Version

0.5.4

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.1K downloadsadoption · observed Oct 11, 2026
Latest release: 0.5.4release · observed Jun 16, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s175t2e2n8hr9v2jphatfs57ah83qsr1:taskops

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-jimmylegendary-taskops/snapshot"

Documentation

CLAWHUB

160,000 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: taskops
description: "Manage AI-agent work as an execution graph instead of a flat TODO list. Use TaskOps to structure objectives, task decomposition, run readiness, execution logs, exploration, delegation/waiting, EoW closure, validation, summaries, and runner-driven progress."
---

# TaskOps

TaskOps is a **work-truth protocol**, not just a task manager. It exists so that AI agents can be trusted with hours/days/weeks of work without pretending tasks are done, silently stopping, asking "what next?", or executing a wrong plan. Plans lie, logs drift, and TODO lists make agent work look simpler than it is; TaskOps separates task decomposition from execution reality and forces explicit, file-backed closure.

Use it when the user needs to know what should happen, what actually happened, what is blocked or delegated, and whether work is truly closed.

## Canonical rule

TaskOps v1 is **md-first**.

Canonical state lives in markdown files arranged around:
- `task-groups/`
- `snapshots/`
- `runs/<run-id>/`
- non-canonical `derived/`

Do **not** treat `.taskops/queue.sqlite`, `graph.json`, or generated canvases as durable semantic truth. SQLite is an execution projection/ledger, not the task graph source of truth.

## Read these first

- `references/core-model.md`
- `references/md-first-format.md`
- `references/decomposition-protocol.md`
- `references/run-readiness.md`
- `../examples/taskops-canonical-minimal-v1/`

## Current operating model

- Task graph = decomposition truth
- Run graph = execution truth
- Work = top-level objective container (`entityType: work`; legacy `project` can still be read)
- Task groups are versioned
- Snapshots materialize selected version paths
- EoW (End of Work) is an explicit terminal node, not just a status field
- Run graphs are independent under `runs/<run-id>/` and may reference external runs/tasks without being merged
- Task↔run traceability is bidirectional: task `runRefs` plus run-node `sourceTaskId` / `sourceTaskGroupVersionId`
- Delegation/waiting belongs in the run graph as `type: delegate` / `status: waiting` with delegatee, request, expected output, and optional timeout metadata
- Markdown is canonical; canvas/views are derived
- SQLite queue state is a rebuildable execution projection plus lease/report ledger
- Shared status vocabulary: `pending | active | done | blocked | waiting | cancelled`
- Before execution, classify task run readiness as `runnable | needs_decomposition | needs_exploration | blocked`
- Use `needs_exploration` when the objective is meaningful but the system does not yet know enough to decompose honestly; exploratory runs may search, try, debug, prototype, and reflect to learn constraints for the next graph update

## Decomposition discipline

- Start with a one-line objective.
- Decompose depth 1 by default.
- Do not turn decomposition into an activity checklist.
- A task can be large but not decomposable yet; if the missing knowledge blocks honest decomposition, create an expl

examples/md-first-minimal/README.md

# md-first minimal example

This example demonstrates the proposed vNext canonical layout where markdown files are the source of truth.

It intentionally stays tiny:
- 1 Project
- 1 Step
- 1 Phase
- 1 Node
- 1 Result
- log files at each structural level

Use it to pressure-test:
- folder naming rules
- YAML frontmatter shape
- append-only result handling
- Obsidian navigation
- future plugin parsing

README.md

# TaskOps skill

**AI agent work cannot be managed as a flat TODO list.**

TaskOps is a markdown-canonical execution control protocol for keeping human + AI work honest: separate the decomposition truth from execution reality, record blockers and delegation explicitly, and only close work when there is visible evidence.

## Canonical shape

TaskOps v1 separates:
- **work root** at `index.md` with `entityType: work`
- **task graph** under `task-groups/`
- **snapshot selection** under `snapshots/`
- **execution truth** under independent `runs/<run-id>/` graphs
- **EoW terminal nodes** under task-version `eow/` folders and run `nodes/`
- **derived views** under `derived/`

Markdown is canonical.
Derived canvas/views are not.

## Current surfaces

- `../cli/` — installable `taskops` CLI for `init / validate / summary / show / decompose / refactor / run` plus git-backed vault setup/sync
- `../obsidian-plugin/` — Obsidian explorer + derived canvas export for TaskOps v1 projects, with desktop git auto-sync support when configured
- `scripts/graph_task.py` — legacy graph-task prototype kept only as migration/source material

## Main working references

- `../docs/CORE_MODEL.md`
- `../docs/MD_FIRST_FORMAT.md`
- `../examples/taskops-canonical-minimal-v1/`
- `SKILL.md`

## Core operating loop

```bash
taskops init <work-dir> --id <id> --title <title> --objective <objective>
taskops validate <work-dir>
taskops summary <work-dir>
taskops classify-runnable <work-dir> <task-id> --json
taskops run <work-dir> --executor dry-run --max-steps 1 --json
```

Use `dry-run` for smoke tests and graph rehearsals. Use `--executor openclaw-agent --agent <agent-id>` when the user wants real agent execution.

## Good fit

TaskOps is strongest for complex agentic work such as refactors, migrations, research-to-implementation loops, and multi-step investigations where the user needs to know:

- what the goal is
- how it was decomposed
- what actually ran
- what got blocked, delegated, or explored
- why a branch is truly closed

## Validation stance

Prefer the CLI for current validation and summaries:

```bash
taskops validate <work-dir>
taskops summary <work-dir>
```

For a git-backed Obsidian vault workflow:

```bash
taskops vault-init <vault-dir> --repo-url <github-repo-url> --branch main --auto-sync true
taskops git-sync <vault-dir> --message "Sync vault changes"
```

Only use the legacy Python script when the work is explicitly about old graph-task compatibility or migration.

_meta.json

{
  "ownerId": "kn73mypx9fx9qehs8agyh3drs183bb1y",
  "slug": "taskops",
  "version": "0.5.4",
  "publishedAt": 1781610536544
}

references/cli.graph-task.md

# graph-task CLI surface

> Legacy prototype note: this CLI currently operates on `graph.json` runs.
> In the md-first direction, treat its outputs as legacy behavior, migration help, or derived snapshots/exports — not canonical markdown state.

Use the bundled CLI with:

```bash
python3 scripts/graph_task.py <command> ...
```

All commands accept either:
- a run directory (the CLI will use `graph.json` inside it), or
- a direct path to `graph.json`

## Shared status vocabulary

Use the same minimal status set everywhere:
- `pending`
- `active`
- `done`
- `blocked`
- `cancelled`

## Commands

### init
Create a new run directory with `graph.json` and `summary.md`.

```bash
python3 scripts/graph_task.py init ./runs/demo \
  --id demo-project \
  --title "Demo project" \
  --description "Test graph" \
  --goal "Reach a validated state"
```

To initialize inside a git-backed vault/work repo, point `path` at the desired local checkout directory and pass a repo URL. The CLI will clone or refresh the checkout, then create the run under `<checkout>/<project-id-slug>/`.

```bash
python3 scripts/graph_task.py init ./tmp/company-vault \
  --repo-url https://github.company.com/ORG/obsidian-vault.git \
  --repo-branch main \
  --id graph-task-demo \
  --title "Graph task demo" \
  --description "Repo-backed run" \
  --goal "Write into a project-specific folder"
```

### show
Render the current graph as a summary or raw JSON.

```bash
python3 scripts/graph_task.py show ./runs/demo
python3 scripts/graph_task.py show ./runs/demo --format json
```

### add-step
Add a Project-level Step.

```bash
python3 scripts/graph_task.py add-step ./runs/demo \
  --id step-1 \
  --step-type implementation \
  --description "Implement state handling"
```

### add-step-edge
Connect two Steps.

```bash
python3 scripts/graph_task.py add-step-edge ./runs/demo \
  --id step-edge-1 \
  --from-step step-1 \
  --to-step step-2
```

### add-phase
Add a Step-level Phase and automatically create its root node.

```bash
python3 scripts/graph_task.py add-phase ./runs/demo \
  --step-id step-1 \
  --id phase-diverge-1 \
  --phase-type diverge \
  --description "Explore implementation options"
```

### add-phase-edge
Connect two Phases inside a Step.

```bash
python3 scripts/graph_task.py add-phase-edge ./runs/demo \
  --step-id step-1 \
  --id phase-edge-1 \
  --from-phase phase-diverge-1 \
  --to-phase phase-verify-1
```

### add-node
Add a work node to a Phase.

```bash
python3 scripts/graph_task.py add-node ./runs/demo \
  --phase-id phase-diverge-1 \
  --id node-1 \
  --title "Compare libraries" \
  --description "Check Zustand and Redux"
```

### add-edge
Connect two Nodes inside a Phase.

```bash
python3 scripts/graph_task.py add-edge ./runs/demo \
  --phase-id phase-diverge-1 \
  --id edge-1 \
  --from-node phase-diverge-1-root \
  --to-node node-1 \
  --edge-type flow
```

### set-status
Set the status on a Project, Step, Phase, or Node.

```bash
python3 scripts/graph_task.py set-sta

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.