Skip to content

Repository files navigation

Task-Spec — define one task, seal the authority, prove the work

Task-Spec

Agents can write code. Task-Spec makes them earn done.

One open contract for bounded scope, executable proof, sealed authority,
portable handoff, and independent acceptance.

versionformatbashrelease gatelicense

Works with Codex · Claude Code · Kimi · Grok Build · any conformant executor

Prove it · Highlights · Features · Install · Use it · Architecture · Trust · Docs


The missing contract between intent and execution

A prompt tells an agent what you want. A Task-Spec also records what the agent may change, what observable behavior counts as success, what evidence must exist, who authorized that exact contract, and what an independent gate must verify afterward.

Without Task-SpecWith Task-Spec
“Implement search and test it.”One atomic leaf with explicit paths, behavior, evals, budget, and owner
The agent decides what “done” means while workingHumans review the contract; runnable evals decide the technical result
Scope changes disappear into the conversationHMAC v2 breaks when authority-bearing fields change after sign-off
Every harness receives a different interpretationEvery harness receives the same credential-free handoff and task digest
“Tests pass” is the final claimAcceptance reruns proof, checks the blast radius, verifies the seal, and binds required receipts

Task-Spec deliberately stops at this boundary. It does not host models, schedule a fleet, store credentials, create a sandbox, or turn a weak eval into a wise oracle. It makes one unit of work portable, tamper-evident, and independently checkable.

Prove it in one command

After installation, run a complete lifecycle in a disposable repository:

$ taskspec demoTask-Spec isolated lifecycle PLAN=VALID DOD=COMPLETE VERDICT=DELEGATE TIER=1 HANDOFF=TaskHandoff/v1 EVAL=PASS ACCEPTED=1DEMO=READY

taskspec demo creates an isolated Git repository, writes and validates a real TaskPlan/v1, generates one atomic leaf, seals it, emits a portable handoff, runs its eval, accepts the result, and removes the repository. It does not touch the repository from which you invoke it.

That command is exercised by make check; tagged releases also have a separate remote-install workflow that runs the curl and npm/GitHub distribution doors on both Ubuntu and macOS before those doors are called verified.

What shipped in 3.7

Version 3.7 keeps format v3 as the stable default and adds format v4 as an explicit evidence-policy layer. The executor still receives a bounded task; independent evaluators issue receipts that acceptance binds back to the exact authorized task.

HighlightWhat it addsWhy it matters
Evaluation policydeterministic, hidden holdout, graded, or human acceptance modesEvidence requirements become part of the contract instead of harness folklore
Hidden holdoutssealed evaluator bundles and redacted public descriptorsThe executor can know what evidence is required without receiving the private oracle
Typed receiptsevaluation, environment, engine, graded, human, and authorization receiptsEvidence becomes machine-checkable and digest-bound
Environment contractslocal or portable runtime commitments plus observed receipts“It passed on my machine” gets an explicit environment boundary
Signer identityoptional Ed25519 signing, verification, and revocation above HMACTeams can attribute evidence without pretending shared-key HMAC is identity
Eval discrimination auditcurrent change must pass; baseline and declared mutations must failAn eval must distinguish the work from the unpatched state
Author doctorflags vague goals, existence-only evals, open decisions, and unsafe scopeWeak authoring becomes visible before delegation
Multi-engine evidenceisolated, receipt-producing runs across nine declared model familiesMissing engines are recorded as unavailable, never fabricated as passes
A2A and MCP bridgesdigest-preserving envelopes plus a read-only MCP serverThe atomic contract can cross modern agent protocols without changing meaning
Installation proofself-verifying installer, isolated demo, and tagged-release smoke CIA user can test the lifecycle before trusting it with real work

The nine-family matrix is a harness, not a claim that nine real providers have passed. Checked-in entries remain disabled until an operator supplies exact models, adapters, credentials, and retained results.

Five reasons to use Task-Spec

  1. Bound the work.touches_paths, creates_paths, Do-Not-Touch, effort, dependencies, and budgets define the executor's authorized surface.
  2. Make proof executable. Every behavior maps to at least one eval, every eval maps back to behavior, and the Exit Check is the terminal condition.
  3. Seal authority. Only the PRE-gate writes signed_off*; changing the approved body or authority breaks the HMAC v2 seal.
  4. Change the player, not the contract. Codex, Claude Code, Kimi, Grok, or a conformant custom executor receives the same handoff.
  5. Accept independently. Only the POST-gate writes accepted*, after evals, scope, seal integrity, and any v4 evidence policy pass.

Feature matrix

SurfaceCapabilityDeterministic proof
Atomic authoringv3/v4 scaffolds, approved TaskPlan/v1, batch generationtaskspec plan, batch, validate
Behavior contractGiven/When/Then IDs with bidirectional eval traceabilitytaskspec dodDOD=COMPLETE
Scope controlbounded read/write surfaces and Do-Not-Touch rulesPRE-gate validation + POST-gate blast-radius check
AuthorizationHMAC v2 over body, paths, dependencies, backend, agent, and budgetstaskspec gate --stampTIER=1
Portable handoffcredential-free TaskHandoff/v1 for v3 and v2 for v4taskspec handoff --backend …
Independent acceptanceeval rerun, scope audit, seal verification, receipt policytaskspec accept --stampACCEPTED=1
Eval qualityauthor warnings, baseline checks, mutation discriminationauthor-doctor, eval-audit, --gold-sanity
Independent evidenceholdouts, typed receipts, environment and human evidenceholdout, receipt, v4 Gate F
Identityoptional Ed25519 evidence attribution and revocationtaskspec identity verify
DecompositionXS/S/M/L leaves; XL/XXL composition nodes; dependency DAGtaskspec lint, ready --all
Multi-engine experimentsisolated worktrees, exact model IDs, retained run receipts`taskspec evidence validate
InteroperabilityA2A/MCP envelope round trips and read-only MCP toolstaskspec bridge, taskspec mcp
Agent ergonomicsone installed skill across four harness destinationsinstaller equivalence checks
AutomationJSON envelope, dry-run, stable tokens, shell completion--json, --dry-run, agent-context
PortabilityBash 3.2 core, standard-library Python, offline by defaultmake check, conformance L0–L2

Installation

Source checkout — available now

This is the honest installation door while the v3.7.0 release tag remains unpublished:

git clone --depth 1 https://github.com/luanmorenommaciel/task-spec.git \
"$HOME/.local/share/task-spec-src"cd /path/to/your/repository
bash "$HOME/.local/share/task-spec-src/install.sh" --target "$PWD" --copy
export PATH="$HOME/.local/bin:$PATH"
taskspec doctor
taskspec demo

The installer ends with INSTALL=OK only after the installed engine reports the expected version, all harness skill copies match the canonical skill, and the CLI launcher resolves to that same engine.

Pinned release doors — activate when v3.7.0 is published

curl -fsSL \
https://raw.githubusercontent.com/luanmorenommaciel/task-spec/v3.7.0/install.sh \
| bash -s -- --target "$PWD"
npm install -g github:luanmorenommaciel/task-spec#v3.7.0
taskspec-install --target "$PWD"

Claude marketplace

/plugin marketplace add luanmorenommaciel/task-spec
/plugin install task-spec@taskspec

One installation gives each supported harness the same contract:

HarnessSkill destinationInstalled surface
Codex.agents/skills/task-spec/Task-Spec skill and CLI
Kimi.agents/skills/task-spec/Same skill and CLI
Claude Code.claude/skills/task-spec/Same skill, CLI, and compatibility agent
Grok Build.grok/skills/task-spec/Same skill and CLI

Installation guarantees

GuaranteeBehavior
Non-clobberingExisting unmanaged destinations are refused by default
IdempotentReinstalling the same managed version keeps valid destinations
Recoverable upgrade--force backs up replaced managed paths with a UTC suffix
Pinned engineVersions install side by side under ~/.local/share/task-spec/
Harness parityInstalled skill content is compared with the canonical source
Credential safetyNo model or provider credential is installed, copied, or requested
VerifiableEngine and launcher version checks run before INSTALL=OK
Prove-before-usetaskspec demo exercises the complete lifecycle in isolation
Installer controls and requirements
--target DIR repository receiving harness skills
--copy pinned, non-clobbering copy installation (default)
--symlink local checkout-development mode
--bin-dir DIR CLI launcher directory (default: ~/.local/bin)
--no-bin install skills only
--force back up and replace managed destinations

Requirements

  • Bash 3.2+
  • Git
  • Python 3
  • shellcheck for the PRE-gate and taskspec demo
  • OpenSSL, shasum, or sha256sum for Tier-1 HMAC
  • Node 18+ only for the npm installation door

Step-by-step usage

Everything below happens inside the repository you want to change. The first task should be XS or S and supervised; calibrate eval quality before increasing autonomy.

Eight explicit steps from an empty repository to one independently accepted atomic task

1. Prepare the repository

taskspec init
taskspec setup signing
taskspec doctor

init creates only missing Task-Spec workspace files. The signing key lives in the repository's private Git common directory and never enters a handoff.

2. Ask for a plan, not files

Use the installed skill from chat:

Turn “add repository search” into atomic Task-Specs. Inspect the repository,
show me the TaskPlan first, and do not generate files until I approve it.

The expected boundary is a complete TaskPlan/v1: atomic units, dependencies, write surfaces, behaviors, evals, budgets, and open questions. Approval of the plan is separate from authorization to execute a leaf.

3. Preview, approve, and generate

taskspec plan --manifest tasks/.plans/add-search.yaml
taskspec batch --plan tasks/.plans/add-search.yaml

plan is read-only. batch refuses an unapproved, malformed, cyclic, or credential-bearing manifest.

4. Inspect the contract and its proof graph

taskspec validate tasks/T-…-add-search.md
taskspec dod tasks/T-…-add-search.md
taskspec author-doctor tasks/T-…-add-search.md

Do not continue until structure is valid, DOD=COMPLETE, and every unresolved semantic decision has an accountable owner or a blocked status.

5. Authorize exactly one ready leaf

taskspec gate --stamp tasks/T-…-add-search.md
taskspec handoff tasks/T-…-add-search.md --backend codex --json

The gate writes the HMAC seal. The handoff is read-only, digest-bound, and credential-free. A v4 leaf includes public evidence and environment commitments without revealing private holdout commands.

6. Execute with the chosen harness

Give the handoff to Codex, Claude Code, Kimi, Grok Build, or a conformant custom executor. The player may change; the authorized paths, budgets, behaviors, and eval commands do not.

7. Accept independently

taskspec run tasks/T-…-add-search.md
taskspec accept --stamp --gold-sanity tasks/T-…-add-search.md
taskspec transition T-…-add-search done

Acceptance reruns the Exit Check, rejects out-of-scope changes, verifies the sign-off envelope, applies v4 receipt policy when present, and only then writes accepted: true. A task cannot transition to done before acceptance.

8. Expose the next safe frontier

taskspec ready --all
taskspec lint

The backlog layer reports dependency-unblocked leaves, collisions, cycles, dangling edges, and write-disjoint concurrency groups. Task-Spec does not choose or schedule that frontier for you.

Choose the evidence level

NeedUseAcceptance boundary
Normal repository change with strong runnable evalsFormat v3 (default)evals + blast radius + HMAC integrity
Hidden evaluator or benchmarkv4 · holdoutsealed holdout receipt bound to task and handoff
Subjective quality with a rubricv4 · gradedgraded receipt from the declared evaluator
Accountable semantic approvalv4 · humannamed human acceptance receipt
Portable environment claimv4 · environment contractobserved environment receipt matches the commitment
taskspec new add-search S codex
taskspec new --format 4 benchmark-search S codex

Use v4 because the evidence source must be independent—not because a task looks important. Structural validity never replaces semantic human review.

Inside one atomic task

One Task-Spec aligns four layers:

LayerFields and sectionsWhat it controls
Bounded workspacetouches_paths, creates_paths, Do-Not-TouchWhere the executor may write and what acceptance must reject
Execution contractgoal, context, dependencies, effort, backend, agent contract, budgetsWhat the unit means and how much autonomy it receives
Executable proofbehaviors, success criteria, runnable evals, Exit CheckWhat observable outcome counts as success
Authorization envelopesigned_off*, hmac-sha256-v2Whether body and authority still match human sign-off

The strongest invariant is bidirectional traceability: every B-N behavior is verified by at least one eval, and every eval points back to at least one behavior. Neither side may dangle.

How it works

The Task-Spec flow from evidence and planning through authorization, portable execution, and independent acceptance

flowchart LR
Human["Human intent + decisions"] --> Plan["TaskPlan/v1"]
Repo["Repository evidence"] --> Plan
Plan --> Spec["Atomic Task-Spec"]
Spec --> Pre{"PRE-gate<br/>validate + seal"}
Pre --> Handoff["TaskHandoff v1/v2"]
Handoff --> Executor["Any conformant executor"]
Executor --> Change["Repository change"]
Change --> Post{"POST-gate<br/>eval + scope + seal + policy"}
Evaluators["Independent evaluators"] -. "typed receipts" .-> Post
Post -->|pass| Accepted["accepted: true"]
Post -->|fail closed| Repair["repair · block · park"]
Loading
MomentOwnerOutputWhat is actually proven
Composeauthor + humanplan and atomic specsdeclared work, dependencies, and proof are explicit
PRE-gatedeterministic gatesign-off seal and tierthe exact contract is structurally ready and tamper-evident
Handoffdispatcherv1/v2 JSON contracteach executor receives the same digest, scope, budget, and commands
Executionselected harnessrepository changean authorized attempt occurred; success is not implied
Evidenceindependent surfacestyped receiptsnamed evaluators reported results bound to the task
POST-gateacceptance gateacceptance verdictconfigured proof, scope, integrity, and policy passed or failed

Atomic leaves and composition nodes

flowchart TD
XXL["XXL node<br/>3+ children"] --> XL["XL node<br/>2+ children"]
XXL --> L["L leaf"]
XXL --> M["M leaf"]
XL --> S["S leaf"]
XL --> XS["XS leaf"]
classDef node fill:#1b2630,stroke:#ffb454,color:#ffffff,stroke-width:2px;
classDef leaf fill:#10251e,stroke:#3ddc97,color:#ffffff,stroke-width:2px;
class XXL,XL node;
class L,M,S,XS leaf;
Loading
SizeKindWrite-surface guidanceDispatch rule
XSLeaf≤1 pathRunnable
SLeaf≤2 pathsRunnable
MLeaf≤3 pathsRunnable
LLeaf≤5 pathsLong-horizon backend; one coherent done-condition
XLNodeNo writesAt least 2 children; never delegated
XXLNodeNo writesAt least 3 children; never delegated

Nodes compose; leaves execute. If a leaf exceeds its coherent write surface or done-condition, decompose it instead of hiding more autonomy inside the prompt.

Trust boundaries

ClaimHonest boundary
HMAC v2Tamper-evident shared-key authorization; not identity, non-repudiation, or isolation
Runnable evalsDeterministic evidence when well designed; no validator can make a weak oracle wise
TaskHandoff/v1/v2Portable transfer contract; it does not invoke a model or schedule workers
v4 receiptsBound reports from named evidence surfaces; not universal correctness
Ed25519 receiptOptional signer attribution and revocation; not authorization policy by itself
accepted: trueThe configured POST-gate passed; not proof of deployment or production health
Conformance L0–L2An adapter honors format and lifecycle behavior in the suite; not fleet reliability
Release smoke CIPublished curl and npm/GitHub doors install and pass the isolated demo; it does not test provider credentials

Legacy HMAC v1 seals remain authentic on their original terms but are narrowed to supervised Tier 2 until re-stamped with v2. Read Trust and security before using unsupervised Tier 1.

CLI map

StageCommandsMutation boundary
Prove the installdoctor, demo, conformance --self-testdemo/conformance use disposable fixtures only
Prepareinit, setup, setup signingnon-clobbering workspace and private key setup
Composeplan, batch --plan, new, migratepreview is read-only; generation is explicit
Prove before workvalidate, dod, author-doctor, gate --stamponly the gate writes signed_off*
Transferhandoff --backend …, agent-contextread-only machine contracts; never credentials
Executerun, any conformant harnessevals run relative to the task workspace
Prove after workaccept --stamp, transition … doneonly acceptance writes accepted*; done requires it
Strengthen evidenceholdout, receipt, eval-audit, identityexplicit evidence paths; v4 fails closed when required proof is missing
Interoperatebridge, mcp, evidenceread-only by default; matrix runs retain receipts
Operateready, lint, rebuild-state, metricsdeterministic derived state and backlog analysis

Global --json wraps results in TaskSpecCLIResult/v1; global --dry-run prevents supported mutations and reports intent. NO_COLOR or TASKSPEC_COLOR=0 disables ANSI. taskspec agent-context exposes the complete machine-readable command and token contract.

Verified status

SurfaceRepository evidenceStatus
EngineBash 3.2 portability, schemas, compatibility, HMAC v1/v2, sizing, backlog, DoD, conformancePass — make checkCHECK=READY
v4 evidencePolicy validation, hidden holdout, receipt binding, mutation audit, identity/revocation, A2A/MCP round tripEvidence suite 28/28_local
ExperienceCopy/symlink installs, isolated demo, and init → sign → plan → generate → gate → handoff → execute → acceptPass; experience suite 30/30
Packagenpm pack --dry-run and local global npm installPass; GitHub install pending release tag
ResearchOffline fake Firecrawl/Tavily/Exa adapters and named failure statesPass; live providers not advertised
Converge consumptionDeterministic generated mirror plus per-file SHA-256 lockNot updated
External enginesNine-family matrix contract and honest unavailable stateNot run; no real-engine result claimed
PublicationCanonical source commit, main branch, v3.7.0 tag, and remote curl/npm doorsImplemented locally; unpublished; tag-dependent installs pending v3.7.0 release tag

The canonical status source is release/evidence.json. make check is the single local and normal-CI boundary. It ends with CHECK=READY only when doctor, documentation lint, every self-test, the isolated demo, and conformance are green.

Hosted status is reported separately from local evidence. A workflow that fails before receiving a runner has not executed the repository gate and must not be described as a test failure or a pass.

Documentation

Start hereBest for
Getting Startedinstallation, signing, and the first accepted task
Guidesrepository scans, research evidence, multi-engine execution, and recovery
ReferenceCLI, contracts, schemas, TaskPlan, TaskHandoff, and AuthoringEvidence
TrustHMAC limits, eval gaming, supervision tiers, blast radius, and conformance
Examplesleaves, composition nodes, evidence bundles, and portable handoffs
Format v3stable standalone Task-Spec contract
Format v4opt-in evidence, identity, and environment policy
Conformancewhat an adapter must prove at L0, L1, and L2
Changelogcompatibility and engine history

FAQ

Does my coding agent need native Task-Spec support?

No. The installed skill is markdown plus scripts. Any harness that can discover the skill and invoke shell commands can drive the lifecycle. The deterministic CLI remains the referee.

Why sign a task instead of relying only on Git history?

Git records that bytes changed. HMAC v2 records that the exact body and fields granting authority still match what a human reviewed at delegation time.

Does Task-Spec run many agents or schedule a fleet?

No. It defines, authorizes, hands off, and accepts one atomic leaf. ready can expose a safe frontier and lint can find write-disjoint groups; orchestration remains outside this contract.

Can I add it to an existing repository?

Yes. The installer and taskspec init are non-clobbering by default. Start with one supervised XS or S task, inspect every artifact, and calibrate eval quality before granting more autonomy.

Does accepted mean deployed?

No. It means the configured acceptance contract passed in the observed environment. Deployment and production verification need their own tasks, evidence, and owners.

Provenance

Task-Spec was extracted from Converge and owns the canonical format, schemas, engine, CLI, skill, installer, examples, and conformance suite. The immutable donor baseline is converge@f78f077; the portable mapping is recorded in the donor map. Converge remains the higher-level methodology and runtime for intent shaping, coordination, loops, receipts, and future management.

Contributing

make check

Format changes are triple-locked: schema, conformance fixture, and changelog. The core gate path stays compatible with macOS Bash 3.2. See AGENTS.md for repository conventions.

License

MIT — one open contract, any conformant executor.

About

Task-Spec

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages