ddflow
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ddflow_briefA | START HERE every session. Returns a budgeted pack: work recoverable after a crash, the current item, what is ready to start now, why everything else is blocked, and the past lessons ranked as relevant to this task. Use this INSTEAD of reading the project's lesson or rule files: the same information, ranked for the task at hand, at a fraction of the tokens. |
| ddflow_bugB | Bug records. Set |
| ddflow_claimA | Lease an item and create its isolated git worktree. Refuses (exit 3) if another agent holds it or an overlapping item, and names what you could take instead. NEVER steals an expired lease: a crashed agent's tree often holds finished work. |
| ddflow_completeA | 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'. |
| ddflow_gateB | Quality gates of a work item. Set |
| ddflow_heartbeatA | Renew the lease on an item. Call periodically during long work, or the lease expires and another agent may take the item. |
| ddflow_helpA | What ddflow IS, what it can do, and what the workflow is. Call this first if you have not used it before: the other descriptions explain one tool each and the connection instructions describe THIS repository; neither answers 'how am I meant to work here'. No argument: the loop from picking work to landing it, the exit codes, and every capability grouped by purpose. |
| ddflow_identifyA | Declare WHO you are on this connection before anything that writes. Call it first when 2+ agents or subagents work this repository at once: identity attributes every claim, gate outcome and review, and the tree-derived default merges several agents in one tree into one identity with no error (a review would pass independence against itself). Pick a short stable name (your role), distinct from the others'. Idempotent. A SUBAGENT sharing its parent's connection must NOT call this; it passes |
| ddflow_memoryB | Lessons, memories, recall and record links. Set |
| ddflow_mergeA | Land an item's branch without ever switching a checkout's branch. With [flow].integration = 'pr' it pushes and opens (or updates) a pull request instead, releases your lease and parks the item in REVIEW — take the next item; |
| ddflow_nextB | What may be started RIGHT NOW, and for everything that may not, the reason. Independent items in the ready set can be run in parallel worktrees by separate agents. Returns ready=[] when nothing is actionable — that is a result, not an error, and it never means 'pick something anyway'. |
| ddflow_ruleB | Project rules. Set |
| ddflow_sessionC | The session log. Set |
| ddflow_showA | Everything known about one phase, task, bug or research note: state, dependencies, globs, the lease holder, the worktree path, and every gate's outcome with evidence. Check your work with it before ddflow_complete. |
| ddflow_taskB | Tasks, phases and research notes. Set |
| ddflow_viewC | Read the queue, history and reports. Set |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| all-tests | Clean first, then run every configured suite (unit, integration, UI, e2e) in full, and fix failures under the bug-hunt rule. An unconfigured suite is absent, not passing. |
| bug-hunt | Bounded bug hunt under the empirical-repro rule: a finding may not change source unless a runnable probe demonstrates it and ships as the regression test, mutation-verified. |
| code-clean | Classify every worktree and branch, deal with dirty trees by hand, land the unmerged work through its gates, remove what is finished, then bug-hunt, deduplicate and commit. |
| code-deduplication | Mechanical clone report first, then grep by OPERATION. Second occurrence: reuse or extract. Third: extraction is mandatory. Prefer eliminating a duplicate over guarding it twice. |
| dedupe_sweep | The knowledge-dedupe cadence pass: run `ddflow dupes --open-only`, read each pair, and settle it with `ddflow link <a> --duplicate-of <b>` (a duplicate, and for two lessons a merge), `--related`, or `--distinct` when the pair is really different — a dismissed pair never returns. Record the pass with `ddflow cadence --ran dedupe_sweep`. |
| implement | The autonomous loop: one item per iteration — recover, pick, claim, every gate, merge, complete, capture, cadences — until nothing actionable is left. Carries what the per-item driver does not: the four cases in which the loop may stop, keeping it running across turns, when to ask the operator, and the termination checklist. Scope it to a phase or task id, or leave it empty for the whole queue. |
| import-existing-project | For a project that adopts ddflow mid-stream. Reads its todo checklists, lessons, ADRs, research log, engineering journal, memory store and unmerged branches, then walks the agent through the half that needs judgement — globs, dependencies, what is actually live — WITH the operator. A queue that starts empty tells the next agent nothing is in flight. Safe and useful to re-run at any time: it starts by checking what is already imported and switches to finishing and refreshing it rather than repeating it. |
| install-companions | Surveys the registry, sorts each companion into register / install / check / nothing, asks the operator per install with the exact command and what it executes, runs only what they approved, proves each by re-probing rather than trusting the installer's exit code, registers the MCP ones (dry run first), and records every decline so its gate is `unavailable`, never passed unaided. Scope it to companion ids, or leave it empty for the defaults. |
| onboard | The whole path from 'the MCP server is attached' to a workflow ddflow manages: preflight (leftover worktrees and branches: merged or holding work), setup from the durable place, a measured test gate, the history import, cutting the project's rulebook over from its old todo/lessons/journal files to ddflow, freezing those files, and an end-to-end verification before the commit. Asks the operator at each decision rather than in one list at the end. Scope it to one stage (`preflight`, `verify`, ...) or leave it empty for the whole path. |
| research-companions | The shipped registry covers the gates every project shares. It cannot know your stack. This walks the agent from the pipeline's UNCOVERED gates, through the repository's actual manifests, to candidate servers checked against their primary sources -- provenance, maintenance, what they execute and what credential they want -- and produces `[[companion]]` blocks the operator can read and delete. Proposes only; installs nothing. A decline is part of the report, so the next session does not re-research it. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Work queue | The full queue with the critical path. |
| Session brief | Budgeted session-start pack. |
| Lessons | Everything learned so far. |
| Lessons summary | Every live lesson in one paragraph, by tag. |
| Research log | Findings with verdicts and probes. |
| Bugs | Every bug with its item, its regression tests and its lesson. |
| Decisions | The architectural decisions in force. |
| Sessions | The sessions, when they ran and what they were for. |
| Assumption records | An assumption: something taken as true that the plan depends on. Newest first; ddflow://records/assumption/{id} reads one with its history. |
| Attention records | An attention item: something that needs a human until it is handled. Newest first; ddflow://records/attention/{id} reads one with its history. |
| Attestation records | An attestation: someone vouches that a claim holds, citing evidence. Newest first; ddflow://records/attestation/{id} reads one with its history. |
| Commlog records | A communication log entry: what was said or agreed, with whom, and when. Newest first; ddflow://records/commlog/{id} reads one with its history. |
| Contract records | A contract: terms agreed with a vendor, its dates and value. Newest first; ddflow://records/contract/{id} reads one with its history. |
| Evalfixture records | An evaluation fixture: an input with planted faults a workflow must catch. Newest first; ddflow://records/evalfixture/{id} reads one with its history. |
| Fitness records | A fitness function: a runnable check that an architectural property still holds. Newest first; ddflow://records/fitness/{id} reads one with its history. |
| Proposal records | A proposal: a suggested change of one type, decided later (accepted, rejected or expired). Newest first; ddflow://records/proposal/{id} reads one with its history. |
| Requirement records | A requirement: what the product must do or be, and where it came from. Newest first; ddflow://records/requirement/{id} reads one with its history. |
| Risk records | A risk: something that may go wrong, how likely and how bad. Newest first; ddflow://records/risk/{id} reads one with its history. |
| Stakeholder records | A stakeholder: a person or group with an interest in the project. Newest first; ddflow://records/stakeholder/{id} reads one with its history. |
| Vendor records | A vendor: an outside party the project buys from or depends on. Newest first; ddflow://records/vendor/{id} reads one with its history. |
TDQS
Scored across 16 tools
Most tools are distinct domain objects (bug, task, gate, memory, rule, claim, merge), but the read-side overlaps: ddflow_brief promises 'what is ready to start now' which is exactly ddflow_next's job, and ddflow_view, ddflow_show, ddflow_brief and ddflow_next all occupy the 'read state' niche. ddflow_help ('call this first') and ddflow_brief ('START HERE every session') also give competing first-call instructions, so an agent must read carefully to pick correctly.
All 16 tools share a consistent ddflow_<topic> prefix with single-token names and uniform action-dispatch arguments, which is highly predictable. The only deviation is mixing nouns (task, gate, rule) with verbs (claim, complete, show) and adjectives (brief, next), so the name alone doesn't tell you whether it reads or writes.
16 tools is slightly above the comfortable range but each maps to a real workflow concern (identity, lease, gates, merge, memory, rules, sessions, bugs, views). Consolidating the many action-dispatch tools further would just move complexity into argument lists, so the split is defensible.
The surface covers the full item lifecycle from identify/brief through claim, task/gate, heartbeat, merge and complete, plus supporting memory, rules, bugs and reporting. The gap is ddflow_merge's description pointing at a `ddflow_pr_sync` tool that is not in the set, leaving the PR-integration path a dead end, and there is no explicit release/abandon-lease operation.