Skip to main content
Glama
Sign In
delian

ddflow

by delian
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

ddflow_complete

Finish a work item only when required gates pass, open tasks are closed, and a reviewer from a different model family approves; pass the author's model to enforce checks.

Instructions

Finish an item. Refuses (exit 3) when a required gate has not passed, a phase has open tasks, or no reviewer came from a different model family than the author. Pass your own 'model'.

Input Schema

NameRequiredDescriptionDefault
idYesItem id.
shaNoCommit sha this shipped as.
forceNoComplete over unmet conditions, each recorded as overridden forever. Prefer `ddflow_gate_skip` with a reason.
modelNoThe AUTHOR's model.
approvalNoAn agent's way past unmet conditions: 'request' asks the operator, then the approval id they answered.
as_agentNoSubagent name, this call only.
mutationNoTest-only fix: JSON {"file","old","new"} disabling it; the test must FAIL.
changelogNoOptional 'Added|Changed|Deprecated|Removed|Fixed|Security: text', or skip.
regression_testNoFix task: the test guarding its bug(s); closes them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.9
    • addedInput schema / properties / approval
      Added value: +{
+  "description": "An agent's way past unmet conditions: 'request' asks the operator, then the approval id they answered.",
+  "type": "string"
+}
  2. Changed1 schema field changedv0.2.7
    • changedInput schema / properties / as_agent / description
      Previous value: -"A subagent's own name, this call only."New value: +"Subagent name, this call only."
  3. Changed3 schema fields changedv0.2.3
    • changedInput schema / properties / force / description
      Previous value: -"Complete over unmet conditions; each is recorded as overridden, forever. Prefer `ddflow_gate_skip` with a reason: it drops one named step."New value: +"Complete over unmet conditions, each recorded as overridden forever. Prefer `ddflow_gate_skip` with a reason."
    • addedInput schema / properties / mutation
      Added value: +{
+  "description": "Test-only fix: JSON {\"file\",\"old\",\"new\"} disabling it; the test must FAIL.",
+  "type": "string"
+}
    • changedInput schema / properties / regression_test / description
      Previous value: -"For a fix task: the test that now guards its bug(s); closes them."New value: +"Fix task: the test guarding its bug(s); closes them."
  4. Changed4 schema fields changedv0.1.12
    • changedInput schema / properties / as_agent / description
      Previous value: -"Subagent sharing the parent's connection: your own stable name, for this call only (see ddflow_identify)."New value: +"A subagent's own name, this call only."
    • addedInput schema / properties / changelog
      Added value: +{
+  "description": "Optional 'Added|Changed|Deprecated|Removed|Fixed|Security: text', or skip.",
+  "type": "string"
+}
    • changedInput schema / properties / force / description
      Previous value: -"Complete over unmet conditions. Every one is recorded in the event log as overridden, so this is visible forever rather than being the quiet way past a gate. Prefer `ddflow_gate_skip` with a reason: it names the single step you are dropping instead of all of them."New value: +"Complete over unmet conditions; each is recorded as overridden, forever. Prefer `ddflow_gate_skip` with a reason: it drops one named step."
    • addedInput schema / properties / regression_test
      Added value: +{
+  "description": "For a fix task: the test that now guards its bug(s); closes them.",
+  "type": "string"
+}
  5. Changed1 schema field changedv0.1.10
    • addedInput schema / properties / as_agent
      Added value: +{
+  "description": "Subagent sharing the parent's connection: your own stable name, for this call only (see ddflow_identify).",
+  "type": "string"
+}
  6. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does real work: it discloses the exact refusal contract (exit 3) and the three independent conditions that trigger it, plus the caveat that `model` must reflect the caller's own family. Gaps remain around what state is written on success (sha recording, changelog precedence, whether tasks are closed) and idempotency/re-call behavior.

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?

Three short sentences, front-loaded with the verb and the refusal contract, with no filler. The failure conditions and the `model` instruction each earn their place and are stated in the order an agent needs them.

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

Completeness4/5

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

For a 9-param mutation tool with 100% schema coverage and no annotations or output schema, the definition covers the hardest thing to infer: why the call fails. It leaves success-side behavior (what completion records, whether it is idempotent, how approved conditions are cleared) to be inferred, which keeps it short of fully complete.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3; the schema already documents `force`, `approval`, `as_agent`, and the rest in detail. The only description-level addition is 'Pass your own model', which clarifies the `model` parameter's intent (the author's family, not the reviewer's) but is a marginal increment over what the field description provides.

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

Purpose4/5

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

The description opens with a specific verb and resource ('Finish an item') and immediately frames the operation as a gated completion rather than a generic update, which separates it in spirit from ddflow_gate/ddflow_merge. It stops short of naming any sibling explicitly, so the boundary with ddflow_gate_skip (referenced only inside the schema's `force` field) is left implicit.

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?

It usefully enumerates the three preconditions that must already hold (gate passed, no open tasks in phase, cross-family reviewer), which tells an agent when the call will be rejected. However, it gives no routing guidance such as 'use ddflow_gate to close gates first' or 'prefer ddflow_gate_skip over force' in the description itself, so the alternatives are implied rather than stated.

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

Deploy Server

Other Tools