agentleFS
icarloscornejoicarloscornejo/doer/skills/doer/SKILL.md

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
  1. Very specific:

    Every /doer ... invocation, in order:

    line 54
  2. Very specific:

    Test command unknown: ask once, persist as metadata.test_command via a single metadata.sh write.

    line 78

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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)

ConcernFile
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

StageFile
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:

  1. Resolve locale (first action): LOCALE="$("${CLAUDE_PLUGIN_ROOT}/lib/helpers/preferences.sh" get-locale)". All chat output binds to it (persistent state stays English; see lib/narration.md).
  2. Route by command:
    • /doer list, /doer status <ID>, /doer cleanup-history <ID> → read _commands.md, execute, end turn.
    • /doer <ID> [--no-pr] → strip --no-pr from the arguments first (it is not part of the ID), then check ./.doer/tickets/<ID>/metadata.json:
      • Exists → read _resume.md and ONLY that file. Do NOT re-ask intake questions. A --no-pr typed here is ignored with a one-line narration: the mode is fixed when the ticket is created and lives in metadata.no_pr.
      • Missing → read 01-ac.md and ONLY that file (intake lives there); hold whether --no-pr was given for its Step 3.
  3. 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_command via a single metadata.sh write.
  • Halt signal: narrate current position and stop. Resume later with /doer <ID>.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.