{"id":"eecc0368-6f47-4ade-b325-bf79d8ef35e2","slug":"danielhanold-docket","kind":"skill","name":"docket","summary":"docket is a portable, harness-neutral skill set that adds a change-lifecycle and project-management layer on top of the superpowers skills.","owner":"danielhanold","repoUrl":"https://github.com/danielhanold/docket","license":"Apache-2.0","licenseTier":"permissive","trust":"community","stars":3,"match":null,"fewStars":true,"format":"skill","createdAt":"2026-05-30T15:24:17.000Z","addedAt":"2026-10-22T01:12:00.680Z","logoUrl":"https://avatars.githubusercontent.com/u/580920?u=dcae138dd71425bdb4a7c8c0662c25882cc64da8&v=4","linkOnly":false,"collection":null,"skillPath":null,"categories":["writing"],"tags":[],"runtime":"go","local":true,"cloudCapable":false,"cloudCapability":"unknown","cloudReadyOnPlatform":false,"needsApiKey":false,"reviewed":false,"syncedAt":"2026-10-25T20:55:09.568Z","sample":false,"url":"https://conduits.dev/tools/danielhanold-docket","language":"Go","transports":["stdio"],"install":{},"requirements":{"env":[],"upstreamMayCharge":false},"tools":null,"readme":"# docket\n\ndocket keeps a backlog of planned work as plain markdown files inside your repo and ships\nagent skills that drain that backlog to open pull requests. It is a repository-level\nimplementation of the Plan, Design, Build, Test, and Deploy stages of Anthropic's\n[AI-Native SDLC Playbook](https://claude.com/blog/the-ai-native-sdlc-playbook)\n([stage-by-stage comparison](docs/comparison/ai-native-sdlc-playbook.md)) — git-native,\nharness-neutral, with the human at the merge. Each unit of work is a **change**: one markdown\nfile, roughly one pull request's worth of work, that moves through a fixed lifecycle from idea\nto archived record — coordinated entirely through git, with no service and no database. A\nsingle `docket` binary, installed by `install.sh`, does the bookkeeping the skills ask for.\n\n## What you get\n\n- **A durable backlog that outlives the session.** Planned work is tracked in-repo as\n  markdown, so a change you brainstorm today is still there, with its full context, when an\n  agent picks it up next week.\n- **Hands-off implementation.** An autonomous skill claims the next ready change, refreshes it\n  against the current state of the code, builds it with test-driven development, and opens a\n  PR — with no supervision in between.\n- **You own the PR handoff.** Agents never merge on their own authority. Your review of\n  the pull request is the one required human checkpoint on the way to `done` for any change that\n  delivers code.\n- **No new infrastructure.** Markdown files, git, and skills any supported harness can run —\n  Claude Code and Cursor are supported and tested; opencode installs but is untested; Codex is\n  unsupported.\n- **The right model for each step.** Every autonomous skill is pinned to its own model and\n  effort, so a status check runs at a cheap tier while a build runs at a top one — see\n  [Models: tuning model and effort per task](docs/install/models-and-effort.md).\n\n## The committed artifact chain\n\nEvery stage ends in an artifact committed to git before the next stage reads it. The chain is\nthe audit trail — and the whole interface between you and the autonomous skills.\n\n| Stage | What docket commits | Where it lives |\n|---|---|---|\n| Plan | The change file: why, what changes, out of scope, dependencies, priority, type | `docs/changes/active/` on the `docket` metadata branch; rendered on `BOARD.md` |\n| Design | The spec, linked from the change | `docs/superpowers/specs/` on the metadata branch |\n| Build | A dated reconcile log, the implementation plan, one verified commit per task | The change body and `docs/superpowers/plans/` on the metadata branch; the commits on the feature branch |\n| Test | The build-evidence record — suite command, result, head SHA — plus the results file and the review's disposition table | The change body's `## Build evidence` section and `docs/results/` on the metadata branch; the table in the PR body |\n| Deploy | The merge (proven reachable), the archived change record, a cleaned branch and worktree, a re-rendered board | `docs/changes/archive/`; `BOARD.md` |\n\n## Why docket: plans rot\n\nA change is drafted against a snapshot — the codebase, the decision ledger, and the other\nin-flight changes as they stood the day you designed it. In an async backlog the implementer\nmay not pick it up for weeks. By then another change has shipped half of it, an architecture\ndecision has settled an open question the other way, or an interface it assumed has moved.\nMost backlog systems build the ticket as written and let the implementer discover the\nmismatch halfway through.\n\ndocket instead **reconciles at the last responsible moment**: after a change is claimed but\nbefore any build work starts, the implementer re-reads it against related and archived\nchanges, recent decisions, and the current code — then rewrites its scope to what is true\nnow, records a dated reconcile log entry, kills it if it has become obsolete, or stops and\nescalates if the design itself no longer holds.\n\nThe stance: plans rot, so refresh them just-in-time and never trust a stale backlog. The\n`reconciled` flag on every built change is the visible proof it happened.\n\n## Where you decide\n\n- **Creating and grooming changes.** Capturing an idea and designing it to build-ready are\n  interactive; autonomous grooming is opt-in per stub, and killing or deferring a change is\n  never autonomous.\n- **Merging the PR.** The one required checkpoint — the implementer stops at an open pull\n  request every time.\n- **Finalize's confirmations.** Close-out merges only with your authorization.\n- **Promoting a learning.** Findings graduate into the always-loaded instructions file only by\n  your hand.\n- **Filing discovered work.** Runs report follow-up work; a human decides what enters the\n  backlog.\n\nPlan approval is deliberately **not** a human point: your checkpoint is the PR, where the plan,\nthe diff, and the evidence arrive together. And docket ends at the merge — it does not deploy to production,\nmonitor production, or feed incidents back into the backlog.\n\n## Install and the five steps\n\nInstall from a release: download `install.sh` and `checksums.txt` from the release, verify the\nscript, then run it.\n\n```bash\nbase=https://github.com/danielhanold/docket/releases/download/v1.0.0-rc.2\ncurl -fsSLO \"$base/install.sh\" -O \"$base/checksums.txt\"\nsh install.sh --version v1.0.0-rc.2 --harness claude --harness cursor\n```\n\nClaude Code and Cursor are supported and tested; opencode installs but is untested; Codex is\nunsupported. To run from source instead, clone the repository and install from the checkout:\n\n```bash\ncd ~/dev/docket\ngit fetch --tags && git pull\nbash install.sh\n```\n\nRe-run the installer after every update — it is idempotent and machine-global. Full\nprerequisites and what an install run does: [Installing docket](docs/install/install.md). To adopt\ndocket in a repository, run `docket repository init` from inside it; `docket repository migrate`\nis only for converting a repository that still uses the legacy single-branch layout\n([Where the metadata lives](docs/guide/where-the-metadata-lives.md)). Upgrading from the Bash\nversion of docket? Follow [Upgrading from Bash docket](docs/release/upgrading-from-bash.md).\n\nThe five steps, one skill per step\n([Quickstart](docs/guide/five-steps.md)):\n\n1. **Capture** an idea into the backlog — `docket-new-change`.\n2. **Groom** rough stubs to build-ready — `docket-groom-next` (or `docket-auto-groom`).\n3. **Drain** the backlog to open PRs: ask in plain words (\"implement the next change\"), or\n   `/loop docket-implement-next` hands-free, so the [run tracker](docs/concepts/run-tracker.md)\n   follows it. In Claude Code the command runs forked.\n   A typed `/docket-implement-next` runs untracked.\n4. **Review and merge** the PR — you.\n5. **Close out** merged work — `docket-finalize-change`; `docket-status` keeps the board\n   honest in between.\n\n## Documentation map\n\nStart at **[the documentation index](docs/README.md)** — it lays out every section below and a\nstart-here path through them.\n\n- **[Install and configure](docs/install/README.md)** — get docket onto your machine, decide where\n  each setting lives, and set up your harness (one page each for Claude Code, Cursor, Codex, and\n  opencode).\n- **[Guide](docs/guide/README.md)** — how do I do the thing: one goal per page, end to end, each\n  titled by the docket component it is about.\n- **[Concepts](docs/concepts/README.md)** — what each piece is and why it is shaped the way it is,\n  linking the decisions behind it.\n- **[Reference](docs/reference/README.md)** — exact fields, keys, verbs, and outcomes, each\n  pointing at the surface that owns the current value; includes the\n  [harness validation checklist](docs/reference/harness/README.md) (the live Cursor checklist).\n\n## Status\n\ndocket keeps its planning records on their own orphan `docket` branch, checked out at `.docket/`\nnext to your code; that is the one supported layout. Everything this README and the linked\ndocumentation describe is what the `docket` binary and its skills do today. Run\n`docket capabilities --json` for the exact list of operations your installed binary supports.\n\n## License\n\ndocket is open source under the [Apache License 2.0](LICENSE). The\n[NOTICE](NOTICE) file carries the attribution that section 4(d) of the license\nasks redistributors to preserve.\n\n- **Files docket generates in your repository are yours.** Change documents,\n  specs, plans, results, decision records, and configuration belong to you; the\n  license places no condition on them.\n- **The license grants no rights in the docket name.** Use the software freely;\n  do not present a modified version as docket itself.\n- **Contributions** are accepted under the Developer Certificate of Origin; see\n  [CONTRIBUTING.md](CONTRIBUTING.md).\n\nThe license applies to the whole history of this repository, including every\ncommit made before it was added.\n"}