doer
Skill0 starsChanged 6 days agoMITView on GitHub
Ticket execution orchestrator. Takes a pre-defined ticket (feature, bug, refactor) from acceptance criteria to implementation-ready code on a feature branch, in 5 stages. Invoke with "/doer <TICKET-ID>" to start a new ticket or resume an existing one (auto-detected). Other entry points: "/doer status <ID>", "/doer list", "/doer cleanup-history <ID>". Also activates implicitly when the user references an active /doer ticket in natural language ("continue", "pause", "keep going with ABC-123"). Stops before PR and deploy. Pass --no-pr at start ("/doer <ID> --no-pr") for a branch that merges straight to its base branch: no PR description, and the closing line says merge and push. For bug triage from a Jira ticket use /wk:bugfix instead. For locale or Jira config use /wk:setup, /wk:locale, or /wk:jira instead.
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 54
Every /doer ... invocation, in order:
- Very specific: line 78
Test command unknown: ask once, persist as metadata.test_command via a single metadata.sh write.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Doer. Ticket Execution Orchestrator
Executes a single ticket end-to-end on a feature branch: 5 sequential stages, a bounded doer/reviewer loop on the build stage, on-device runtime verification via wk:protologs, lessons that accumulate across projects. State persists on disk; closing the session is pausing. BDD-style throughout: ACs are captured as Given/When/Then scenarios and tests derive from them (Stage 1, Stage 3), unless the change is trivial/cosmetic.
Scope: one ticket, one branch, up to (but not including) PR and deploy.
Protocols (read once, refer as needed)
| Concern | File |
| Core principles | ${CLAUDE_PLUGIN_ROOT}/lib/principles.md |
| Transition Sync (unconditional re-hydration per stage transition / resume) | ${CLAUDE_PLUGIN_ROOT}/lib/sync.md |
| Narration, turn boundaries, AskUserQuestion vs chat, locale | ${CLAUDE_PLUGIN_ROOT}/lib/narration.md |
Workspace Guard + per-ticket lock (lib/helpers/workspace-guard.sh, run at every entry) | ${CLAUDE_PLUGIN_ROOT}/lib/workspace-guard.md |
| Doer/Reviewer loop (severity buckets, iteration shapes, read budgets) | ${CLAUDE_PLUGIN_ROOT}/lib/loop.md |
metadata.json / bugfix.json schemas, .doer/ layout, required fields, write discipline | ${CLAUDE_PLUGIN_ROOT}/lib/state.md |
| Root-cause discipline for any fix | ${CLAUDE_PLUGIN_ROOT}/lib/debugging.md |
Stages
| Stage | File |
| 1. AC + Intake | ${CLAUDE_PLUGIN_ROOT}/skills/doer/stages/01-ac.md |
| 2. Plan | ${CLAUDE_PLUGIN_ROOT}/skills/doer/stages/02-plan.md |
| 3. Build (tests + code + review loop) | ${CLAUDE_PLUGIN_ROOT}/skills/doer/stages/03-build.md |
| 4. Verify (on device, via wk:protologs) | ${CLAUDE_PLUGIN_ROOT}/skills/doer/stages/04-verify.md |
| 5. Wrapup | ${CLAUDE_PLUGIN_ROOT}/skills/doer/stages/05-wrapup.md |
| Resume flow | ${CLAUDE_PLUGIN_ROOT}/skills/doer/stages/_resume.md |
Aux commands (status, list, cleanup-history) | ${CLAUDE_PLUGIN_ROOT}/skills/doer/stages/_commands.md |
Stage transition rule. Every stage transition and every resume runs the Transition Sync (lib/sync.md) as its first action, unconditionally: re-read metadata.json, then read ONLY the file for the current stage. One stage file resident at a time; this keeps peak context bounded and re-hydrates instructions after any compaction. A finished stage auto-proceeds to N+1 in the same turn; stopping between stages without an explicit pause is a sync violation, not a resting point.
Entry-point dispatch
Every /doer ... invocation, in order:
- Resolve locale (first action):
LOCALE="$("${CLAUDE_PLUGIN_ROOT}/lib/helpers/preferences.sh" get-locale)". All chat output binds to it (persistent state stays English; seelib/narration.md). - Route by command:
/doer list,/doer status <ID>,/doer cleanup-history <ID>→ read_commands.md, execute, end turn./doer <ID> [--no-pr]→ strip--no-prfrom the arguments first (it is not part of the ID), then check./.doer/tickets/<ID>/metadata.json:- Exists → read
_resume.mdand ONLY that file. Do NOT re-ask intake questions. A--no-prtyped here is ignored with a one-line narration: the mode is fixed when the ticket is created and lives inmetadata.no_pr. - Missing → read
01-ac.mdand ONLY that file (intake lives there); hold whether--no-prwas given for its Step 3.
- Exists → read
- Workspace Guard + lock (ticket-scoped commands only, not
list/status): run"${CLAUDE_PLUGIN_ROOT}/lib/helpers/workspace-guard.sh" acquire "<TICKET-ID>" doer(contract:lib/workspace-guard.md) before touching metadata.
Version stamp. New tickets record skill_version from this frontmatter. On resume, "${CLAUDE_PLUGIN_ROOT}/lib/helpers/metadata.sh" version-check "<TICKET-ID>" "<this frontmatter's version>" compares the ticket's MAJOR against the current MAJOR; on incompatible <old> vs <current> (exit 1), stop and narrate: the ticket was created with an incompatible schema; finish it by hand or recreate it. No auto-migration machinery exists; if a future 7.x change ever needs one, it will be written then.
Implicit activation: natural language ("keep going", "pause here") with an active ticket (status == "in_progress" under ./.doer/tickets/*/metadata.json) is a directive to the orchestrator, not a new query. There is no pause command: state persists after every Agent return; stop / wait / hold on halts, anything else resumes.
Stages cannot be skipped manually. The only skip path is Stage 1's pre-existing-work detection; the orchestrator decides.
Agent invocation contract
Sub-agents receive the relevant metadata.json slices inlined in their prompt (no sidecar reads), write real artifacts directly to the working tree, and return JSON with a changelog_appendix plus stage-specific output. Doer agents also return {"status": "success" | "failed", "summary": "<one line>"}. Sub-agents never call AskUserQuestion; the orchestrator is the sole user-facing voice. Heavy artifact work (planning happens in plan mode; test/code writing, reviewing, log analysis go through Agent) is delegated; the orchestrator itself only does state reads/writes (via lib/helpers/metadata.sh, never a direct Edit/Write on metadata.json), deterministic validation, narration, and transitions.
Error handling
- Agent error: narrate it, end turn; the user decides (retry max 3, or pause).
- Git failure: narrate, present options (resolve manually, pause, abort stage).
- Test command unknown: ask once, persist as
metadata.test_commandvia a singlemetadata.sh write. - Halt signal: narrate current position and stop. Resume later with
/doer <ID>.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

