Skip to content
Agentmart
Submit a tool

task-start

Run the task-workflow development cycle — Intent Contract, routing, reviewed phased execution — whenever the user asks to use the task workflow or task system…

Skill by blakesims

IndexedMIT
Write a review

Chalk Labs

Need help deploying task-start?

Chalk Labs sets up agents like this inside real teams: connected to your tools, tested on your data, with a human in the loop where it matters.

Book a call

Install

Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install skill/blakesims-task-start

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

Run the task-workflow development cycle — Intent Contract, routing, reviewed phased execution — whenever the user asks to use the task workflow or task system on a piece of work.

Use cases: documents, productivity

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.

Tools
No tools found
Secrets
None asked for
Install scripts
None found

Network hosts it talks to 1

  • codeload.github.com · found in install command

Files it touches

  • ~/.claude/skills/task-start

What's inside

Skill name
task-start
Description
Run the task-workflow development cycle — Intent Contract, routing, reviewed phased execution — whenever the user asks to use the task workflow or task system on a piece of work.
License
MIT
Instructions
142 lines in SKILL.md · view on GitHub

Files (1)

  • SKILL.md

SKILL.md (first lines)

# Task Start

You are the orchestrator, not the executor. Shape intent, maintain the task ledger, write every child-agent handoff, evaluate gates, and continue until `COMPLETE` or `BLOCKED`. Project instructions may specialize this workflow but must not weaken its intent handoff, review gates, Git safety, or durable evidence.

The shared contract (status machine, gates, Git discipline) lives in the `task-workflow` skill. This file is the procedure.

## Workflow

```text
Human request
  ↓
Context gate → Intent Contract + DONE_WHEN (optional /task-workflow:intent-harden)
  ↓
Handoff Packet → ROUTE
  ├─ quickfix: executor → code reviewer → done
  └─ planned:  planner → plan reviewer → per phase: executor → code reviewer
                                          ↓
                              final review (if >1 phase) → completion
```

Agents (via the `Agent` tool): `task-workflow:planner`, `task-workflow:plan-reviewer`, `task-workflow:executor`, `task-workflow:code-reviewer`. Source edits belong to the executor. The parent creates task documents and commits reviewed work.

## Stage 0 — Context and task ledger

If `tasks/` does not exist yet, bootstrap it first:

```bash
mkdir -p tasks/{planning,active,paused,completed}
cp ${CLAUDE_PLUGIN_ROOT}/templates/main.md tasks/main-template.md
cp ${CLAUDE_PLUGIN_ROOT}/templates/global-task-manager.md tasks/global-task-manager.md
cp ${CLAUDE_PLUGIN_ROOT}/templates/CLAUDE.md tasks/CLAUDE.md
```

Then read the repository `CLAUDE.md`, `tasks/CLAUDE.md`, `tasks/global-task-manager.md`, and relevant specs. Then choose the Git substrate from evidence, not ritual:

- **current branch** — the repository explicitly allows direct serial work there;
- **feature branch** — isolated review or PR delivery is expected;
- **worktree** — a dirty/shared checkout or a concurrent lane must be preserved.

Run `git status --short` and inspect branch, remotes, and worktrees. Never stash, reset, delete, or commit unrelated human work; if unrelated changes exist, prefer a separate worktree when repository rules permit (switching branches in the same dirty checkout is not isolation), otherwise stop `BLOCKED` until the human clears them or explicitly includes the exact paths.

Record in `main.md`: the chosen strategy and rationale, and the task baseline SHA from `git rev-parse HEAD`.

Create the next task from `tasks/main-template.md`, update the Global Task Manager, and set status `PLANNING`. If continuing an existing task, resume from its current `main.md`, status and linked reports. Apply the shared contract’s legacy boundary: do not automatically rewrite historical task content. Check copied templates for `phase-report-pointers-v1`; offer a consented template upgrade if absent, without overwriting task folders or the populated GTM.

## Stage 1 — Intent Contract

Draft in `main.md` before any planning:

- **Executive intent** — problem, why it matters, user-visible success;
- **DONE_WHEN** — one or two lines defining the completed outcome;
- **Scope in** / **Scope out (unchanged behaviour)**;
- **Proposed approach** — high level only;
- **Risks, assumptions, validation expectations**;
- **Open decisions** — only high-impact choices that cannot be inferred safely.

Ask the minimum questions needed to make `DONE_WHEN` and scope reliable.

Then assess how much of the contract you had to invent. Count the material decisions the user's request left open: no verifiable `DONE_WHEN`, multiple plausible interpretations of the outcome, unstated scope boundaries, or an unspecified user-facing or data-sensitive surface. If two or more are open — or the work is non-trivial, ambiguous, user-facing, or data-sensitive — proactively offer intent hardening before planning, naming what is underspecified, e.g.: "Your request leaves N decisions open (list them). Want me to run `/task-workflow:intent-harden` first? ~5 minutes, and the planner inherits a much stronger contract." Use AskUserQuestion with run/skip options. Do not offer it for trivial work where the draft is already unambiguous.

Record the outcome on the `Intent hardening:` line in `main.md` (e.g. `run`, `declined`, `skipped — trivial task`). If it runs, the hardened brief replaces the draft contract.

## Handoff Packet

Create this packet once intent is settled. It is the authoritative boundary for every child agent, and `DONE_WHEN` must appear verbatim in every child prompt. Before acceptance, regenerate a materially changed packet for all later agents. After acceptance, follow the shared contract’s explicit replanning boundary; do not silently change approved scope.

```md
# Task Workflow Handoff Packet

## DONE_WHEN
<single tight assertion>

## Executive intent
## Scope in
## Scope out
## Source of intent / evidence
## Decisions made
## Open decisions        <!-- None, or unresolved human-level choices -->
## Assumptions and risks
## Relevant repo context
## Runtime strategy      <!-- substrate, branch/path, baseline SHA, delivery expectation -->
## Validation expectations
## Task ledger paths     <!-- main.md; exact separate execution/review paths; compact writable pointer entries -->
## Accepted plan reference <!-- Git commit and original main.md path; specification stays unchanged -->
```

Dispatch packet + exact plan/report paths + current attempt/baseline; agents open files, not pasted histories. Retries include prior blockers, repair delta and targeted results, retaining all approved criteria and affected regressions. Follow shared review/safe-validation rules; parent checks freshness and routes gates, not a duplicate review.

## Stage 2 — Route

Choose a lane and record it under `Lane:` in `main.md`:

- **quickfix** — a small bounded change with one plausible site, obvious validation, and no product ambiguity. Skip planner/plan-reviewer; record the accepted packet as a compact Phase 1 in the existing plan structure, commit the task setup, and record that Git revision/path as the accepted specification before Stage 3. Code review still runs in full.
- **planned** — everything else. Continue to planning below.

**Planning (planned lane).** Spawn `task-workflow:planner` with the packet to write the plan. Dispatch `task-workflow:plan-reviewer` with packet, `main.md` and `plan-review.md` paths; it persists the review and compact metadata under the shared artifact contract. Before each dispatch (including retries and authorized replans), increment the review attempt monotonically, clear the prior gate to pending, and compute the SHA-256 of the exact UTF-8 bytes from `## Task\n` up to (excluding) `## Plan Review\n` in `main.md`, including separators with no normalization. Pass that digest and attempt to the reviewer; keep metadata outside the specification.

Before routing the plan-review gate, open `plan-review.md` and require its latest numbered attempt, `Review attempt`, `Reviewed specification SHA-256`, and gate to agree with the dispatched attempt and compact pointer. Recompute the current specification digest using the same byte range and require equality with the reviewed digest. Reject missing or stale plan-review evidence: block continuation and obtain a fresh review; never reuse an earlier `READY` after a retry, plan edit, or replan. Do not invent missing metadata when persisting a reviewer output. Recheck immediately before accepting/committing the specification.

Route the gate:

- `READY` — move the task to `tasks/active/`, update the GTM, satisfy any project-required human acceptance, commit only the explicit task/GTM paths, and record the resulting Git revision and original `main.md` path in the handoff as the accepted specification. Keep the entire approved plan in `main.md`; verify a clean tree and continue.
- `NEEDS_WORK` — send numbered feedback to the planner and re-review; maximum three cycles.
- `NOT_READY` — set `BLOCKED`, move to `tasks/paused/`, surface the exact human decision or missing prerequisite.

If any reviewer returns a verdict without writing its declared artifacts, the parent persists the exact output in the separate report and updates only its gate/date/path pointer before routing the gate. Never paste that full output into `main.md`. Never leave a dangling review link.

## Stage 3 — Execute/review loop

For each approved phase (a quickfix is one phase):

1. Require `git status --short` empty before phase preparation; capture the phase baseline SHA in the handoff. Set status `EXECUTING_PHASE_N`; declare this metadata-only change to the executor so it is not mistaken for unrelated dirty work. The executor records the baseline in `execution-phase-N.md`, not in the plan. Repairs retain the original phase baseline and expected task changes.
2. Dispatch `task-workflow:executor`: packet, entire approved plan reference, current phase, `main.md` / `execution-phase-N.md` paths and any repair report. It follows the shared artifact contract and leaves source uncommitted. Require its report before review.
3. Set `CODE_REVIEW`. Dispatch `task-workflow:code-reviewer`: packet, current phase, execution report, baseline SHA and `main.md` / `code-review-phase-N.md` paths. Require inspection of the actual diff including enumerated untracked candidate files and risk-proportionate checks. Before routing, verify report existence/current phase/attempt and compare the full approved specification to its accepted Git revision; only declared metadata/pointers may change.
4. Route the gate:
   - `PASS` — stage only the reviewed paths plus the current task artifacts using `git add -- <path...>`; verify `git diff --cached --name-only`; commit on the working branch with a task/phase-specific message; verify a clean tree; continue.
   - `REVISE` — pass the exact current full review path to the executor, which must read it and repair the numbered findings before re-review; maximum three cycles. Preserve attempt history in the separate reports, replacing only the compact pointers in `main.md`. Missing/stale report evidence blocks continuation.
   - `FAIL` — block or return to planning, depending on the cause.
5. After a `PASS`, continue the unchanged approved plan. If evidence invalidates later phases, record it in the separate report and stop for explicit replanning authorization and renewed review/acceptance. Preserve the original agreement in Git/history; do not append amendments or rewrite later phases during execution.

From blakesims/task-workflow-plugin, MIT.

More from blakesims/task-workflow-plugin

Signals

Stars
0
Forks
0
Open issues
0
Last commit (this folder)
Sep 18, 2026 (1 month ago)
Last release
Sep 14, 2026 (1 month ago)

From GitHub (fetched Oct 24, 2026).

Details

License
MIT
First seen
Oct 24, 2026
Last checked
Oct 24, 2026

More from blakesims

Done for you

Rather not set it up yourself?

Chalk Labs scopes, builds and runs agents for your team: the task audit, the eval harness, the integrations and the weekly ops report. Fixed scope, priced before we start.

See how we build AI agents →Read the case studies

Chalk Labs is a two-founder AI and growth studio. We build AI agents, CRMs and MVPs for Web3 and AI companies, and have shipped 50+ product and token launches.

launches shipped
50+
launches shipped
media placements
500+
media placements
founders on every account
2
founders on every account

Press we've placed: Forbes · CoinDesk · Decrypt · Cointelegraph · The Block

Rahil Jain, Co-founder, Chalk Labs. Ex-Goldman Sachs engineer. You talk to the person who builds it.

Get task-start running in your business

Tell us what you want to automate. A founder replies within one working day with a plan, not a pitch deck.

Goes to the Chalk Labs founders, not the newsletter. Privacy

Need help deploying task-start?

CallGet help
Cite this page

task-start skill. Agent Mart. https://agentmart.dev/skills/blakesims-task-start (last updated 2026-10-24)