Skip to main content
Glama
Sign In
delian

ddflow

by delian
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

ddflow_bug

Log bug findings, file fix tasks, and mark bugs fixed or invalid in the ddflow work queue. Link each record to tasks, tests, and evidence.

Instructions

Bug records. Set action; required arguments in brackets: fixed(id), invalid(id,reason), found(summary), file_tasks.

Input Schema

NameRequiredDescriptionDefault
idNoStable id, e.g. 'B1'. You will cite it when closing.
allNoFile a fix task for EVERY open bug that has none, other agents' too. Without it and without `id`, only a preview.
itemNoThe task it was found in or affects.
globsNoThe fix task's files; default: the item's globs.
scopeNoproject (default) or ddflow.
titleNoShort headline.
actionYesWhat to do; see the tool description for each action's arguments.
landedNoA commit already on the base that holds the fix (the fix task was claimed after it landed): the test must fail on its first parent and pass on it; the fix task is ended naming it.
lessonNoId of an existing lesson this bug belongs to.
reasonNoWhy the finding is false (with reopen: why reopen).
reopenNoReopen the closed bug instead.
dry_runNoList what would be filed; write nothing.
no_taskNoFile no fix task (fixed in the same commit).
summaryNoWhat is wrong, in one line.
as_agentNoSubagent name, this call only.
evidenceNoThe probe command or test node id that showed it false.
mutationNoTest-only fix: JSON {"file","old","new"} disabling it; the test must FAIL.
relationNoAnswer to a 'possible duplicate' refusal: new | extends:ID | duplicate_of:ID | related:ID | merge_into:ID. Omit at first.
severityNolow|medium|high|critical.
changelogNoOptional 'Fixed: text' (any category), or skip.
check_onlyNoDry run: write nothing, return the `candidates`.
lesson_ruleNoThe lesson in full: the transferable rule, not the incident.
lint_exemptNoFor a CI-filed LINT bug (a check that is not a test, e.g. ruff format --check): why it needs no regression test (what made the check green). Recorded as regression_verified=exempt-lint; instead of regression_test.
lesson_titleNoCapture a lesson at the same time.
verify_reasonNoWhy the pre-fix check is skipped (recorded); required with skip_regression_verify.
regression_testNoTest that now guards this. Several: separate with ',' or ';'.
regression_testsNoThe tests guarding this, one per element: the list form of regression_test.
skip_regression_verifyNoSkip the pre-fix check (the test must FAIL pre-fix, PASS fixed). Needs verify_reason.

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?

No annotations are provided, so the description carries the full behavioral burden. It says nothing about mutation semantics, side effects such as filing tasks, dry-run preview behavior, permissions, or what happens when closing a bug; the one-line description only lists actions and required arguments.

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 one tightly packed sentence with no wasted words, and the action mapping is front-loaded. It is efficient, though its extreme brevity pushes important workflow context out of the description.

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 28-parameter bug workflow tool with no annotations and no output schema, the description is very thin. The rich schema descriptions compensate significantly, but the description itself does not summarize the overall lifecycle or the meaning of the four actions beyond their required arguments.

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 description coverage is 100%, so the schema already documents all 28 parameters in detail. The description adds a useful action-to-required-arguments mapping that is not fully expressed in the schema, but it says nothing about the many optional parameters, so the baseline 3 is appropriate.

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 identifies the resource as 'Bug records' and lists the action verbs fixed, invalid, found, and file_tasks, so an agent can tell this is a bug-tracking workflow tool. It is clearer than a tautology but does not distinguish itself from sibling tools such as ddflow_task or ddflow_complete beyond the word 'Bug'.

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 maps each action to its required arguments, which implies how to call the tool, but gives no guidance on when to choose this tool over siblings, when to use one action versus another, or any prerequisites. The usage is inferred from the action list rather than explicitly 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