Skip to main content
Glama

ddflow_task

Create, split, update, remove, and resolve tasks, phases, and research notes in the ddflow work queue by setting an action per call.

Instructions

Tasks, phases and research notes. Set action; required arguments in brackets: phase_add(id), split(id,into), add(id), research_add(question,verdict), update(id), remove(id), resolve(id,keep), phase_close(id,imported), batch, fold(dup,keep), rename(old,new).

Input Schema

NameRequiredDescriptionDefault
idNoStable id you choose. Referenced by `supersedes`, by commit messages and by the reconstruction; a generated id cannot be cited in advance.
dupNoThe duplicate to abandon.
newNoIts new id.
oldNoThe task to rename.
bodyNoNew detail / acceptance criteria. REPLACES the body.
intoNoComma-separated 'sub-id=title' pairs. At least two.
itemNoThe task this research is for.
keepNoEvent id (or a 6+ character prefix), agent, or lease holder to keep.
kindNoWork kind: task, doc, research or job (its gate pipeline).
lineNoRelease line this lands on (a name from [flow.lines], or the current line). Omit for the current line; tasks inherit a phase's line.
tagsNoComma-separated tags.
claimNoThe falsifiable claim.
editsNoJSON array of edit objects, each with an 'id'.
forceNoRemove although it still has open children or dependents. Both leave the queue inconsistent in a way the scheduler reports; read the refusal before overriding.
globsNoPath globs this item writes, comma-separated or a JSON array. REPLACES the list (a claimed item's lease too); the result names what it dropped. Empty: none, and a fix task then takes none from its bug.
linesNoRelease lines a FIX must reach, e.g. '1,2,3': written where [flow].port_strategy says, plus a port task `<id>@<line>` per other line.
needsNoComma-separated ids it depends on. Pass an EMPTY string to clear them — that is how you break a dependency cycle the loop detector found.
phaseNoOwning phase id. Give this OR `parent`.
probeNoThe command you ran.
queueNoQueue a refused request (FIFO per file).
readdNoFile a REMOVED item's id again with this definition. An id still in the queue is always refused -- change that item with ddflow_update.
titleNoOne-line description.
actionYesWhat to do; see the tool description for each action's arguments.
budgetNoWhat you allowed yourself, e.g. '30 min, no GPU'.
landedNoRecord work already on main: a commit, or <before>..<after>; verified as ancestors of the base touching the item's globs. For work merged outside `ddflow merge`.
parentNoMove the task under this phase (or task); empty makes it top level. Refused for a finished item, a missing parent, or a dependency cycle.
reasonNoWhy (recorded on the abandonment).
dry_runNoPlan and show the diff; record nothing.
port_ofNoEarlier fix this follows up: reuses the lines it reached.
sourcesNoComma-separated URLs/DOIs you actually opened.
verdictNoCONFIRMED | REFUTED | THEORETICAL
as_agentNoSubagent name, this call only.
importedNoRequired: closes an IMPORTED phase; its imported source is the evidence recorded.
priorityNoLower is offered first (default 100; a DX or bug-fix task: its band).
questionNoWhat was asked.
relationNoAnswer to a 'possible duplicate' refusal: new | extends:ID | duplicate_of:ID | related:ID | merge_into:ID. Omit at first.
worktreeNoRebind the item and your live lease to this linked worktree (absolute, or repo-relative) and its branch: the way out of a wrong-tree binding, since re-claiming keeps the recorded tree and merge lands that tree's branch.
falsifierNoThe single observation that would kill it.
mechanismNoWHY it would work in this repo. The middle field of the triple — claim, mechanism, falsifier — and the one most often skipped.
refile_asNoComma-separated new ids, one per definition NOT kept, in `show` order: each is re-added under its new id in the same transaction.
resourcesNoPhysical resources the work RUNS on, beside its files: 'gpu:4,vllm-fleet'. `next` withholds and `claim` refuses while live claims use up the capacity ([schedule] resources). Declare for a GPU job, model server or long run. Empty clears.
check_onlyNoDry run: write nothing, return the `candidates`.
append_bodyNoText to ADD after the item's current body (a blank line between); the original is kept. Use it for a note or a decision instead of re-sending the body.
probe_outputNoIts output, verbatim.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.9

TDQS

B3.2/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure, yet it says nothing about side effects, permissions, reversibility, or which actions are destructive (remove, fold, split) versus read-only. The rich behavioral notes live in the per-parameter schema text, not in the description itself, so the description adds almost no behavioral context.

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

Conciseness5/5

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

Two compact fragments: a domain statement followed by a dense but readable action/argument table. Nothing is redundant and the most decision-relevant information (the action list and its required args) is front-loaded.

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

Completeness3/5

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

For a 44-parameter, eleven-action tool with no annotations and no output schema, the description covers only the required-argument surface. It omits the lifecycle relationships between actions (add/claim/complete/close), caution around destructive actions, and any workflow guidance, leaving the agent to reconstruct intent from schema descriptions.

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

Parameters4/5

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

Schema coverage is 100%, which sets a baseline of 3, but the description earns an extra point by mapping each of the eleven actions to its required parameters — a relationship the schema does not encode, since the action property merely says 'see the tool description.' For a 44-parameter dispatcher this action-to-argument mapping is essential and genuinely additive.

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

Purpose3/5

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

The description names the resource domain ('Tasks, phases and research notes') and enumerates concrete operations through the action list, so an agent can infer this is a multi-action task management tool. However, there is no single clear verb framing and nothing distinguishes it from siblings such as ddflow_bug, ddflow_claim or ddflow_show, so the purpose is only implied rather than stated.

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

Usage Guidelines3/5

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

The description gives invocation-level guidance by mapping each action to its required arguments (e.g. phase_close(id,imported)), which is valuable for correct calling. It stops short of saying when to choose this tool over the many siblings or when a given action is appropriate, so usage context remains implicit.

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