product-delivery
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 | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| workflow_detectA | Detect the product-delivery state of a project. Call this FIRST when entering a project. Returns the current state and what action to take next:
Args: project_dir: Project directory to check. Defaults to working directory. |
| workflow_projectsA | List all known projects managed by this server. Shows every project that has been detected, initialized, or set up, along with its current phase and last-seen timestamp. Args: refresh: If True, re-check each project's live state from disk. If False, return cached registry data (faster). |
| workflow_project_removeA | Remove a project from the registry. Does not delete any files — just removes the project from the cross-project tracking list. Args: project_dir: Project directory to remove. |
| workflow_initA | Initialize a new delivery workflow in the project directory. Args: project_type: "greenfield" or "evolution". Leave empty to determine during intake. Can be defaulted via PRODUCT_DELIVERY_PROJECT_TYPE in .env. from_migration: Detect existing BUILD_PLAN.md or ROADMAP.md and migrate. project_dir: Project directory. Defaults to working directory. |
| workflow_statusB | Get the current workflow state, work items, and recent events. Args: project_dir: Project directory. Defaults to working directory. |
| workflow_nextA | Show allowed transitions from the current state with guard status. Returns which states can be reached and whether each guard passes, so the agent can decide what to do next. Args: project_dir: Project directory. Defaults to working directory. |
| workflow_transitionA | Attempt a state transition. Guards are checked automatically. Args: target: Target state (e.g. "discover", "frame", "plan", "deliver"). evidence: Evidence keys to attach to this transition. force: Force past failed guards (logged as forced). reason: Human-readable reason for the transition. project_dir: Project directory. Defaults to working directory. |
| workflow_item_addA | Add a work item to the delivery plan. Only valid in plan or deliver phase. The item starts in "ready" state. Args: name: Work item name/description. acceptance_criteria: AC-NNN IDs this item satisfies. risks: RISK-NNN IDs associated with this item. project_dir: Project directory. Defaults to working directory. |
| workflow_item_listA | List all work items, optionally filtered by state. Args: state_filter: Only show items in this state (e.g. "ready", "implementing"). project_dir: Project directory. Defaults to working directory. |
| workflow_item_transitionB | Transition a work item to a new state. Valid transitions: ready->implementing, implementing->verifying, verifying->reviewing, verifying->rework, reviewing->accepted, reviewing->rework, rework->implementing. Any item can be cancelled. Args: item_id: Work item ID (WI-NNN). target: Target state. reason: Reason for the transition. project_dir: Project directory. Defaults to working directory. |
| workflow_item_waiveA | Waive a work item that is in reviewing state. Requires explicit approver and reason. The item moves to "waived" terminal state and counts toward the completion guard. Args: item_id: Work item ID (WI-NNN). approver: Who approved the waiver. reason: Why the item is being waived. project_dir: Project directory. Defaults to working directory. |
| workflow_checkA | Run guard checks for all available transitions from the current state. Returns which transitions are ready (all guards pass) and which are blocked, with per-guard status. Args: project_dir: Project directory. Defaults to working directory. |
| workflow_blockB | Block the workflow. Records the current phase as the resume target. Args: reason: Why the workflow is blocked. owner: Who is responsible for resolving the blocker. project_dir: Project directory. Defaults to working directory. |
| workflow_resumeC | Resume a blocked workflow back to its pre-blocked phase. Args: reason: Why the blocker is resolved. project_dir: Project directory. Defaults to working directory. |
| workflow_waive_guardA | Waive a transition guard so the transition can proceed. The waiver is recorded with the approver and reason. The guard will show as "waived" instead of "fail" on subsequent checks. Args: guard: Guard name to waive (from workflow_check results). approver: Who approved the waiver. reason: Why the guard is being waived (risk accepted). project_dir: Project directory. Defaults to working directory. |
| workflow_closeB | Close the workflow (normally from stabilize phase). Args: reason: Reason for closing. force: Close from a non-stabilize phase (logged as forced). project_dir: Project directory. Defaults to working directory. |
| workflow_renderB | Render a human-readable markdown summary of the workflow status. Args: project_dir: Project directory. Defaults to working directory. |
| workflow_configA | Show the active configuration from .env and environment variables. Returns all PRODUCT_DELIVERY_* settings and where they came from. Args: project_dir: Project directory. Defaults to working directory. |
| workflow_setupA | Set up product-delivery in a project. Creates or updates: .claude/settings.json, .cursor/mcp.json, AGENTS.md (workflow rule), .env.sample, .env, and .gitignore. Merges into existing files without clobbering other settings. Idempotent — safe to run multiple times. Call with dry_run=True first to preview changes, then with dry_run=False to apply them. Present the preview to the user before applying. Args: dry_run: If True, preview what would change without writing. If False, apply the changes. project_dir: Project directory. Defaults to working directory. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| product_delivery | Load the product-delivery conversational skill instructions. This prompt provides the agent with the full conversational skill: how to run discovery, when to push back, pacing rules, evidence types, and interaction style. Load it into context when starting or resuming a product delivery workflow. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| resource_state | Current workflow state (state.json contents). |
| resource_events | Workflow event log (events.jsonl contents). |
| resource_template_brief | Project brief template. |
| resource_template_plan | Delivery plan template (greenfield sequenced steps / evolution priority buckets). |
| resource_template_evidence | Evidence tracking template. |
| resource_ref_lifecycle | Full state machine specification and transition table. |
| resource_ref_guards | Guard catalog for every transition. |
| resource_ref_evidence | Evidence types and linking rules. |
| resource_ref_compat | Capability matrix across AI coding harnesses. |
| resource_ref_migration | Migration guide from BUILD_PLAN.md / ROADMAP.md. |
TDQS
Scored across 19 tools
Most tools map to distinct resources or actions, but workflow_check and workflow_next are nearly identical—both report available transitions and guard status. workflow_status and workflow_render also overlap in purpose, differing mainly in output format, which could cause an agent to select the wrong one.
All tools share a consistent workflow_ prefix, and subdomains are marked with item_ and project_ segments. However, the pattern is not uniformly verb-first: workflow_projects, workflow_status, and workflow_config are noun-style, while workflow_item_add and workflow_project_remove place the verb at the end.
19 tools is on the heavy side for a single server, though the breadth of workflow management—setup, state transitions, work items, guards, and project registry—partially justifies it. A few tools like workflow_check and workflow_next could be consolidated, which would tighten the surface.
The server covers the full delivery lifecycle: setup, detection, initialization, status, state transitions, blocking/resuming, closing, work item management, guard waiving, and configuration. Minor gaps exist, such as no way to edit or delete a work item, but these can be worked around without major agent failures.