Skip to main content
Glama

Shift work: draft

shiftwork_draft

Turn settled tickets into a validated shift-work job checkpoint and one brief per ticket before clock-in, dry-run by default or write files.

Instructions

Shift-work draft: turn tickets into a new job — a checkpoint that validates against the checkpoint schema, plus one brief file per ticket — so step 1 of the shift-work loop is not typed by hand. Call it once, when a job's tickets are settled and before the first shiftwork_clock_in; it never edits a job in progress (that is the planner's edit, or shiftwork_clock_out's follow_ups), and work_plan is the read-only answer when all you want is the batches. Every ticket needs a non-empty id, title, role, verify, data_shape (the types, fields, files or messages the unit produces or consumes — a ticket without one is not ready to execute) and brief; the first missing one is refused by name. The graph is work_plan's: its refusals come back verbatim, batches and width are its answer, and cursor is the first ready unit, the one shiftwork_clock_out would pick. With job.roles declared, a ticket role it does not name is refused. Each ticket becomes a todo unit with brief_path <briefs_dir>/.md; any other ticket key (touches, reviews, irreversible, ...) is copied onto the unit, and the composed document must pass the checkpoint schema and shiftwork_plan's graph checks, or the schema's sentence is the refusal. write is false by default: the document and every brief's text come back and nothing is touched. With write: true the briefs and then the checkpoint are written by temp file + rename under .lock; an existing checkpoint, or an existing brief with other bytes, is refused before anything is written, and a failure part-way names what landed in written. It never runs git, never runs verify and never reads the working tree: repo is taken as given. Refusals are {"result": "error", "reason"}, never exceptions.

Input Schema

NameRequiredDescriptionDefault
jobYesThe checkpoint's `job` object, copied as given: id, goal, done_definition, constraints, and optional roles, budget or agreements.
repoYesstate.repo as given: {branch, head_sha, dirty}. Never read from git.
writeNotrue writes the briefs and the checkpoint; false or absent is a dry run that touches nothing.
handoffNoOptional do_not, open_questions and notes for the checkpoint's handoff; next_action is always written as `Read <cursor brief> and clock in <cursor>.`
ticketsYesOne per unit, in plan order. Keys other than the six required ones, depends_on and priority are copied onto the unit and judged by the checkpoint schema.
artifactsNo{path, role} entries (spec, plan) appended to state.artifacts after one brief entry per unit.
briefs_dirNoDirectory of the brief files, also the prefix of every brief_path; default .shiftwork/briefs.
checkpointNoWhere the checkpoint is written with write: true, absolute or relative to the server's working directory; default .shiftwork/checkpoint.json.

Output Schema

NameRequiredDescriptionDefault
widthNowork_plan's width: the widest batch.
briefsNoOne per unit: its id, its brief_path, and `bytes`, the file's full UTF-8 text.
cursorNoplan.cursor: the first unit of the first batch.
reasonNoThe refusal sentence, when result is `error`.
resultYes`draft` on success; `error` with `reason` for the first refusal.
batchesNowork_plan's batches over the tickets, priorities included.
writtenNoPaths written by this call, briefs first and the checkpoint last; [] on a dry run, and on a write-side refusal the paths that landed before it.
checkpointNoThe composed checkpoint document, valid against assets/schemas/shiftwork-checkpoint.json.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.38.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, closed-world write, and the description adds substantial detail beyond them. It explains the dry-run default, write:true temp-file-and-rename behavior under a lock, refusal on existing checkpoints or differing briefs, partial-failure reporting in `written`, and that it never runs git, verify, or reads the working tree. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and usage, and nearly every sentence carries behavioral or validation detail rather than filler. It is dense as one long paragraph; splitting write semantics and validation into short sections would improve scanability without adding length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an eight-parameter tool with nested ticket objects, an output schema, and write behavior, the description covers defaults, refusal shape, write atomicity, schema validation, and what the tool does not touch. An agent has enough information to invoke it correctly without opening the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds validation and relational meaning beyond the schema: every ticket needs non-empty id, title, role, verify, data_shape, and brief, with the first missing one refused by name. It also explains role checks against job.roles, brief_path composition, cursor derivation, and the dry-run default for `write`.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: turn tickets into a new job consisting of a schema-valid checkpoint plus one brief file per ticket. It names the exact stage of the shift-work loop and distinguishes itself from planner edits, clock_out follow_ups, and the read-only work_plan.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to call it once, when a job's tickets are settled and before the first shiftwork_clock_in. It also states when not to use it (a job in progress) and names the alternatives for those cases: the planner's edit, shiftwork_clock_out's follow_ups, and work_plan for read-only batches.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.