Skip to main content
Glama
README.md
# Product Delivery

A unified lifecycle skill for software products — from first idea through delivery and stabilization. Replaces the separate product-discovery and product-evolution skills with a single hierarchical state machine.

## What it does

Manages the full product lifecycle through ten states: **intake → discover → frame → plan → deliver → release → stabilize → closed**, plus **blocked** (resumable overlay) and **aborted** (terminal). A nested work-item submachine inside `deliver` tracks individual items through **ready → implementing → verifying → reviewing → accepted**.

Every transition is evidence-gated: guards check that required artifacts exist and conditions are met before allowing a state change. State lives in `.workflow/state.json` with an append-only event log in `.workflow/events.jsonl`.

## Installation

### MCP Server (recommended)

The MCP server gives any MCP-capable harness identical behavior — 19 tools, 10 resources, and a prompt for loading the skill instructions.

```bash
# Install and run via uvx (no clone needed)
uvx product-delivery

# Or install from source
pip install -e .
product-delivery

# With a specific project directory
product-delivery --project-dir /path/to/project
```

**Claude Code** — add to your MCP config:

```json
{
  "mcpServers": {
    "product-delivery": {
      "command": "uvx",
      "args": ["product-delivery"]
    }
  }
}
```

**Cursor / other MCP clients** — same pattern, point to the `product-delivery` command.

### Claude Plugin

```bash
# Install the .plugin file in Claude Code
claude plugin install product-delivery.plugin
```

### CLI Only

For environments without MCP, the CLI wrapper provides the same engine:

```bash
python scripts/workflow init
python scripts/workflow status
python scripts/workflow transition discover
```

### Manual (any harness)

Read `SKILL.md` and follow the instructions. The skill is harness-agnostic — no vendor tool names. Without MCP or CLI, state management is advisory.

## MCP Server Reference

### Tools (19)

| Tool | Purpose |
|------|---------|
| `workflow_detect` | Detect project state (not_setup / setup_no_workflow / active / legacy) |
| `workflow_projects` | List all registered projects across directories |
| `workflow_project_remove` | Remove a project from the registry |
| `workflow_init` | Initialize a new delivery workflow |
| `workflow_status` | Get current state, work items, events |
| `workflow_next` | Show allowed transitions with guard status |
| `workflow_transition` | Attempt a state transition (guard-checked) |
| `workflow_item_add` | Add a work item to the plan |
| `workflow_item_list` | List work items (filterable by state) |
| `workflow_item_transition` | Transition a work item |
| `workflow_item_waive` | Waive a work item in review |
| `workflow_check` | Run guard checks for all transitions |
| `workflow_block` | Block the workflow |
| `workflow_resume` | Resume from blocked |
| `workflow_waive_guard` | Waive a transition guard |
| `workflow_close` | Close the workflow |
| `workflow_render` | Render a markdown status summary |
| `workflow_config` | Show active configuration from .env |
| `workflow_setup` | Set up product-delivery in a project (dry_run preview + apply) |

### Resources (10)

| URI | Content |
|-----|---------|
| `workflow://state` | Current state.json |
| `workflow://events` | Event log |
| `workflow://template/brief` | Project brief template |
| `workflow://template/plan` | Delivery plan template |
| `workflow://template/evidence-ledger` | Evidence tracking template |
| `workflow://reference/lifecycle` | State machine specification |
| `workflow://reference/guards` | Guard catalog |
| `workflow://reference/evidence` | Evidence types and rules |
| `workflow://reference/harness-compatibility` | Harness capability matrix |
| `workflow://reference/migration` | Migration guide |

### Prompts (1)

| Prompt | Purpose |
|--------|---------|
| `product_delivery` | Load the full conversational skill instructions (SKILL.md) |

## Migration from legacy skills

Projects with existing BUILD_PLAN.md or ROADMAP.md can migrate:

```bash
# Via MCP
workflow_init(from_migration=True)

# Via CLI
python scripts/workflow init --from-migration
```

The engine detects which artifact exists, infers the current state from artifact content, creates `.workflow/state.json`, and logs a migration event. Legacy artifacts are preserved.

TDQS

A3.5/5.0

Scored across 19 tools

Disambiguation3/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness4/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues