delivery-loop

delivery-chain

A Claude Code plugin that turns a feature request into production-ready code through a continuous delivery loop. Instead of a single pass, an orchestrator skill drives a team of specialist subagents through a test → diagnose → fix → review → re-test cycle until every quality gate is green and the work is ship-ready.

The plugin ships three delivery loops (frontend, backend, fullstack), a spec-driven planning workflow, a large library of context-optimized skills the agents preload, 18 specialist subagents with per-role memory, and four bundled MCP servers. The whole thing is designed for long, autonomous development flows: plan a feature end-to-end, then let the loops build it until tests and reviews pass.

Deliverable is prompt engineering. With one exception (the Python agent-memory sidecar under scripts/), this plugin is Markdown — skill definitions and agent personas. There is no build step and no pip/npm dependencies.

---

Table of contents

• Requirements
• Install
• The 18 subagents
• The skill library (64 skills)
• Agent memory
• Bundled MCP servers & API keys
• Example workflows (the daily flow)
• Disclaimers & recommendations

---

Requirements

• Claude Code — the plugin runs inside the Claude Code harness.
• Python 3 — already required by Claude Code; runs the stdlib-only agent-memory sidecar. This plugin adds no pip dependencies.
• Node / npx — used by the bundled MCP servers (playwright, cypress-cloud, postman), which launch on demand via npx. No global install needed, but Node must be available.

---

Install

There is no build step. Install the plugin and the harness auto-discovers everything.

From GitHub (recommended) — this repo is its own marketplace:

# 1. Register the marketplace (once)
/plugin marketplace add jgamaraalv/delivery-loop

# 2. Install the plugin
/plugin install delivery-chain@delivery-loop

Update later with /plugin marketplace update delivery-loop.

From a local checkout (for development):

# Add the marketplace from a local path, then install:
/plugin marketplace add /path/to/delivery-loop
/plugin install delivery-chain@delivery-loop

# Or load it directly for a single session without installing:
claude --plugin-dir /path/to/delivery-loop

On install: skills are auto-discovered from ./.claude/skills/, hooks/hooks.json (agent memory) and .mcp.json (MCP servers) are auto-loaded, and agents are registered from the manifest (.claude-plugin/plugin.json). No host-side configuration is required to get started.

---

The 18 subagents

Agents are thin personas — a role, grounding rules, the skills they preload, and a "what you return" contract. The delivery loops dispatch them with the Agent tool. They split into three teams:

Frontend team (7)

Agent	Role
frontend-architect	Turns a feature spec into a ready-to-dev frontend architecture plan — mermaid flows, state machines, design tokens, component tree, screen-state matrix.
cypress-expert	Behaviour driver (when Cypress is installed) — authors/fixes/runs the E2E suite, root-causes failures, reports a product-bug-vs-test-defect verdict. Diagnose-only.
playwright-expert	Behaviour driver (Playwright variant) — same pass/fail ownership as above, picked by detection when Cypress isn't present. Diagnose-only.
frontend-reviewer	Code-quality gate — static audit of changed .tsx/.ts/.js (quality, performance, UI/UX & a11y, business logic), findings tagged Urgent vs suggestion. Never edits.
ui-ux-reviewer	Visual-fidelity gate — judges the rendered pixels (alignment, spacing, data density, overflow, hierarchy, responsive, design-reference drift) from screenshots. Never edits.
frontend-engineer	Fixes the logic layer — hooks, state machines, data fetching, FE↔BE integration, performance.
ui-ux-specialist	Fixes the presentational layer — markup, styling, layout, a11y, design fidelity, states.

Backend team (8)

Agent	Role
backend-architect	Turns a spec into a backend architecture plan — API contracts, data models/ERDs, service boundaries, sequence flows, auth, scaling decisions.
backend-behaviour-driver	Behaviour driver — drives the running service (real HTTP, /verify) and runs the engineer-authored suite; root-causes failures, verifies behaviour + a latency baseline. Diagnose-only.
postman-expert	Behaviour driver (Postman variant) — authors/runs collection tests, mocks, and spec sync via the Postman MCP. Diagnose-only.
backend-reviewer	Code-quality gate for backend .ts/.js — quality, security, performance, business-logic defects. Never edits.
security-auditor	Security gate — audits against the OWASP Top 10:2025 and hunts race-condition / TOCTOU vulns. Diagnose-only, never edits.
backend-engineer	Fixes routes, services, business logic, validation, auth — the application logic layer behind the API.
database-engineer	Fixes the data layer — schema design, migrations, queries, indexing, transactions, query performance (SQL/NoSQL + ORM).
websocket-engineer	Fixes real-time systems — WebSocket/Socket.IO servers, rooms/presence, Redis pub/sub scaling, WS channel security.

Cross-cutting quality reviewers (3)

Used by the review-panel skill (and routed in by the loops):

Agent	Role
sr-reviewer	Clean-code quality — cyclomatic complexity, DRY, naming, error paths, abstraction boundaries, maintainability against the codebase standard.
sa-reviewer	Architecture reviewer — system-design coherence & layering, race conditions/ordering/atomicity, caching & invalidation, performance characteristics.
qa-reviewer	Pre-merge defect hunter — unhandled edge cases, butterfly-effect breakage in callers of changed files, regressions in existing behaviour.

The rule that holds the loop together: the behaviour driver owns pass/fail, the reviewers own the quality/security verdict, and none of them ever edit. Only the engineers/specialists edit; the orchestrator routes between them.

---

The skill library (64 skills)

The plugin ships 64 skills — each a context-optimized capability the agents preload on demand (tuned to carry only the instructions that earn their token cost). Most are curated best-practice references for a specific stack; a handful are the plugin's own authorial orchestrators. By category:

Category	Count	Examples
Frontend & UI/UX	14	react-best-practices, nextjs-best-practices, accessibility-a11y, css-architecture, impeccable, ui-ux-pro-max, vite
Backend & APIs	9	backend-design, nestjs-best-practices, fastify-best-practices, nodejs-backend-patterns, system-design, websocket-patterns
Orchestration & meta (authorial)	9	frontend-delivery-loop, backend-delivery-loop, fullstack-delivery-loop, spec-driven, review-panel, delivery-loop-retro, skill-evolution-factory
Testing & QA	8	cypress-author, playwright-best-practices, testing-strategy, webapp-testing, postman
Database	7	postgresql-optimization, prisma-postgres, redis-core, sql-optimization
Code quality & workflow	7	refactor, code-patterns, conventional-commit, diagnose, mermaid-diagrams
Performance	4	core-web-vitals, react-performance, nextjs-performance, performance-hunter
Security	4	owasp-security-review, hunt-race-condition, race-condition, websocket-security
Design / visual assets	2	canvas-design, create-svg
Total	64

The authorial skills

Most skills are curated stack references. These four are the ones built for this plugin — the core of the workflow:

• frontend-delivery-loop — the continuous frontend loop. Cycles the frontend team through test → diagnose → fix → review → visual-review → re-test until the E2E suite passes, the code-quality review is clean, the visual-fidelity review is clean, and the work is production-ready. Runs inline in the main thread so it can dispatch agents and reach you on judgment calls.

• backend-delivery-loop — the same shape for the backend team, with a security gate added: test → diagnose → fix → review → secure → re-test until the suite, the code-quality review, and the OWASP/race-condition audit are all clean.

• spec-driven — an end-to-end change-planning workflow inspired by the OpenSpec CLI. It scaffolds a feature through proposal.md (WHY) → specs/ (WHAT) → design.<side>.md (HOW) → tasks.<side>.md (work breakdown), tracks status (draft → in-progress → in-review → archived), and — once the change ships — archives it by folding the delta specs into the shipped specs. The delivery loops act as its apply phase, checking off tasks.<side>.md as their gates pass.

• review-panel — a multi-reviewer code-review orchestrator. Dispatches the three quality reviewers (sr / sa / qa) over a diff/branch/PR and routes in domain specialists based on what the diff touches. Handy as a final pass over the fixes the delivery loops made at their quality gates.

---

Agent memory

Every persona gets per-role memory — auto-injected at SubagentStart and persisted at SubagentStop/Stop by the Python sidecar (scripts/agent_memory_hook.py, wired in hooks/hooks.json). This is what lets an agent get better at your codebase over time: it remembers what it learned in prior runs.

The four memory types

Memory loads wrapped in an === AGENT MEMORY === envelope of labeled blocks. Each block is a distinct memory type:

Block	Memory type	What it holds & why
[known_facts]	Semantic / long-term facts	Deterministic (subject, predicate) facts distilled from past runs (e.g. "the auth token lives in useSession"). Update-not-duplicate, newer facts win on contradiction, gated on evidence. This is the agent's stable knowledge base.
[prior_experience]	Episodic memory	Raw records of what happened in previous runs — the objective, files touched, gates run, outcome. Lets the agent recall "last time I touched this, X broke."
[relevant_knowledge]	Patterns	Recurring (situation → lesson) patterns detected after the same lesson shows up K≥3 times. The agent's generalized playbook.
[relevant_lessons]	Reflection lessons	Individual gated lessons extracted from a run ("this test was flaky because of a missing await").

How persistence works

Each persona ends its turn with a fenced ```status block (a canonical shape: taskId, status, plus optional objective, filesTouched[], gatesRun[], specDrift, notes). On SubagentStop the sidecar runs five best-effort phases, each wrapped to never raise:

1. Persist the episode — extracted from the live transcript, with every secret redacted in place (never dropped), paths made repo-relative, written atomically.
2. Gated lesson — extract a reflection lesson (needs OPENAI_API_KEY).
3. Embedding reindex — refresh the retrieval index (needs OPENAI_API_KEY).
4. Curation — distil the deterministic long-tier fact KB.
5. Pattern detection — write K≥3 recurrences.

Stores are written into the host repo at $CLAUDE_PROJECT_DIR/.claude/agent-memory/<agent>/ and .claude/reflection_store/. These are runtime artefacts of your repo — the plugin never commits them, and they're gitignored on the host.

Enabling the OpenAI phases (OPENAI_API_KEY)

Phases 1, 4, and 5 run keyless — the file store, the fact KB, and pattern detection all work with no key at all. Phases 2–3 (OpenAI lesson extraction + embedding retrieval) need an OPENAI_API_KEY. Without one, they skip silently.

Set the key in the host repo's .claude/settings.json (not this plugin's, and never in the committed hooks/hooks.json — that ships with the plugin and would leak the key):

// <your-project>/.claude/settings.json
{
  "env": {
    "OPENAI_API_KEY": "sk-..."
  }
}

Or export it in your shell before launching Claude Code:

export OPENAI_API_KEY=sk-...

Memory caps are host-tunable via .claude/settings.json → agentMemory.caps.

---

Bundled MCP servers & API keys

.mcp.json ships four MCP servers, auto-loaded on install:

Server	Transport	Purpose	Needs a key?
context7	http	Live, up-to-date library/framework documentation.	CONTEXT7_API_KEY
playwright	stdio (npx)	Live browser driving for E2E and visual review.	No
cypress-cloud	http	Cypress Cloud run/flake data.	No (OAuth on first use)
postman	stdio (npx)	Postman API lifecycle — collections, mocks, spec sync.	POSTMAN_API_KEY

Setting the MCP API keys

Provide MCP keys the same way as the OpenAI key — through the host repo's .claude/settings.json env block (or your shell), and reference them in .mcp.json via ${VAR} interpolation so the key value never lands in a committed file:

// <your-project>/.claude/settings.json
{
  "env": {
    "CONTEXT7_API_KEY": "ctx7sk-...",
    "POSTMAN_API_KEY": "PMAK-..."
  }
}

// .mcp.json — reference env vars, never inline the value
{
  "mcpServers": {
    "context7": {
      "type": "http",
      "url": "https://mcp.context7.com/mcp",
      "headers": { "CONTEXT7_API_KEY": "${CONTEXT7_API_KEY}" }
    },
    "postman": {
      "command": "npx",
      "args": ["@postman/postman-mcp-server", "--full"],
      "env": { "POSTMAN_API_KEY": "${POSTMAN_API_KEY}" }
    }
  }
}

context7 and postman are the only servers that need keys; playwright needs none and cypress-cloud authenticates via OAuth on first use. Get keys from context7.com and the Postman dashboard respectively.

---

Example workflows (the daily flow)

The plugin is built to be driven skill by skill across a whole feature. This is the flow it was designed around:

1. Plan the feature end-to-end with spec-driven

/spec-driven a new "CSV export" feature — let users export their report as CSV

spec-driven scaffolds the change (proposal → specs → design → tasks) for whichever surface the feature touches — backend, frontend, or fullstack — and produces the tasks.<side>.md breakdown the loops will execute.

2. Build the backend (if the feature has one) with backend-delivery-loop

/backend-delivery-loop path/to/the/spec

The loop reads the spec as its source of truth, drives the backend team through test → diagnose → fix → review → secure → re-test, and checks off tasks.backend.md as its gates pass.

3. Build the frontend with frontend-delivery-loop

/frontend-delivery-loop path/to/the/spec

Same idea for the UI — test → diagnose → fix → review → visual-review → re-test until the E2E suite, code-quality review, and visual-fidelity review are all clean.

Fullstack alternative: for a feature that spans API and UI together, use /fullstack-delivery-loop path/to/the/spec instead of running the two loops back-to-back — it builds both sides in coordinated cross-side vertical slices.

4. (Optional but recommended) final pass with review-panel

/review-panel

When the loops finish, running review-panel once more gives an independent review of the fixes made at each loop's final quality gates. It's not required — the loops already gate on their own reviewers — but it's a cheap extra sanity check before you ship.

5. Close out the change with spec-driven archive

Once the feature is 100% done (and the MR/PR is merged), archive the change so the shipped specs describe merged code only:

/spec-driven archive path/to/the/spec

Boundary: the loops stop at "tests green + review clean + production-ready." No skill opens, pushes, or merges a PR — that is always your action.

---

Disclaimers & recommendations

• Built for long development flows. This plugin shines on long, multi-step feature work — plan a whole feature, then let the loops build it across many cycles. That is exactly where the test → fix → review structure pays off. For a quick one-line change, a single loop is overkill.

• Use it on a Claude Code subscription plan. The plugin's priority is quality delivery while economizing tokens where it can (context-optimized skills, thin personas, keyless memory phases). But quality vs. token spend is a genuine trade-off — driving a full test → diagnose → fix → review → re-test cycle with a team of subagents consumes a large amount of tokens. Running it on a Claude Code subscription plan (rather than metered API billing) is strongly recommended so a long flow doesn't become expensive.

• Memory improves results over time but writes runtime data into your repo under .claude/agent-memory/ and .claude/reflection_store/. Both are gitignored by the plugin; keep them gitignored on your host repo too.

• Never commit keys. MCP and OpenAI keys belong in your host .claude/settings.json env block, referenced via ${VAR} — not inlined in any committed file.

---

License & authorship

Authored by João Vequiato. See plugin.json for the manifest and for version history.