By fcms14
Agnostic delivery process: role agents, the work/ kanban workflow, deterministic review/board/docs gates, the /init scaffolder, and the engineering principles. Stack-agnostic — pair with an opinionated stack plugin.
Run task(s) through the full agent pipeline — implement → qa ∥ docs → review — dispatching the right agents in the correct sequence
Deterministically apply a reviewer's verdict — tick Acceptance Criteria, stamp the Verdict section, move the task to its new state
Refresh living documentation to match the code — dispatch the docs agent at a scope, following the project's documentation model (as defined by the applicable docs rules)
Bootstrap a repository to use the delivery foundation — scaffold the work/ kanban and docs/ tree, materialize the rules, wire the commit-time gates, and write a starter CLAUDE.md
Specify a new task — delegate to the planner agent to produce a task file in work/ready/
Produces and maintains living documentation that matches the code. Follows the project's documentation model as defined by the applicable docs rules (e.g. a stack's C4 model + ERDs). Use when a feature needs docs, a schema changed, or existing docs drifted.
Turns a goal or feature request into a well-formed task file (Spec + Plan + Todo + Verdict + Log) in work/ready/. Use when a new piece of work needs to be specified before execution. Does not write production code.
The delivery orchestrator. Owns the end-to-end product workflow — reads the work/ kanban, builds the dependency graph, dispatches worker subagents (planner, backend, frontend, infra, qa, docs, reviewer) in parallel isolated git worktrees when independent and serially when dependent, integrates their results, applies verdicts deterministically, and ships reviewed tasks to done. Replenishes the backlog with the /delivery-team:task-promote skill. Optimizes token/model usage (workers on Sonnet, reviewer/judgment on Opus). Does NOT write feature code itself.
Writes and runs tests — unit, e2e, and Artillery load tests — and verifies resilience/degradation. Use to raise coverage, add load scenarios, or validate a feature before it moves to done. Executes a single task file from work/active/.
Reviews a completed task / diff for correctness and adherence to the project rules before it moves to done. Use after a worker finishes, especially for tasks in work/review/. Read-only on production code — reports findings, does not silently rewrite features.
Executes bash commands
Hook triggers when Bash tool is used
Modifies files
Hook triggers on file write and edit operations
Own this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimOwn this plugin?
Verify ownership to unlock analytics, metadata editing, and a verified badge. GitHub access is read-only (username + org membership).
Sign in to claimBased on adoption, maintenance, documentation, and repository signals. Not a security audit or endorsement.
Uses power tools
Uses power tools
Uses Bash, Write, or Edit tools
Uses Bash, Write, or Edit tools
A reusable delivery foundation for Claude Code, packaged as a plugin marketplace. Install it into any project to get a team of role agents, a work/ markdown kanban, and deterministic gates that keep the board honest.
📄 Design article: Agents create and judge. Code enforces. — the rationale, architecture, and how it compares to prompt-canvas methods like SPDD. (GitHub Pages, served from
/docs.)
It ships two plugins — install one or both:
delivery-team — the agnostic process: role agents (planner, reviewer, docs, qa, product-delivery-manager), the work/ kanban, the deterministic board/docs/verdict gates, and the /delivery-team:init scaffolder. Carries how work flows, not which stack you use.stack-turbo-nest-react — an opinionated stack layer (v0, as-built): NestJS + React/Turborepo implementer agents and their conventions. Depends on delivery-team. The stack-* prefix is the convention for future stacks.Agents create and judge; deterministic steps apply state; hooks enforce it. The reviewer returns a structured verdict → /delivery-team:apply-verdict ticks the Acceptance Criteria and moves the task → a board gate refuses done/ without a verdict + ticked criteria → a docs gate refuses a migration without an ERD/docs update. Bookkeeping is code, not an agent's memory.
Gates run in two layers: agent-time PreToolUse hooks ship in the plugin (resolved via ${CLAUDE_PLUGIN_ROOT}); the commit-time git gate is wired by /delivery-team:init, which copies the validators into the consumer repo because git hooks can't see ${CLAUDE_PLUGIN_ROOT}.
The team splits into a process layer (delivery-team, agnostic) and a stack layer (stack-turbo-nest-react, opinionated). The Delivery Manager orchestrates: the planner specifies, implementers build, docs and QA run alongside when warranted, and the reviewer is the gate.
flowchart TD
DM["Delivery Manager<br/>(orchestrator)"]
PL["Planner<br/>PO + Tech Lead"]
RV["Reviewer<br/>Quality Gate"]
subgraph ENG["Engineering — stack layer"]
BE["Backend"]
FE["Frontend"]
IN["Platform / DevOps"]
end
DOC["Technical Writer"]
QA["QA<br/>(specialist)"]
DM --> PL
DM --> ENG
DM --> DOC
DM --> QA
DM --> RV
PL -. specifies tasks .-> ENG
ENG -. implements + unit/e2e .-> RV
QA -. load / journeys / resilience .-> RV
DOC -. living docs .-> RV
RV -. "approve / changes-requested" .-> DM
| Agent | Persona | Layer | Role |
|---|---|---|---|
| planner | Product Owner + Tech Lead | delivery-team | turns a goal into a well-formed task (Spec + Plan + Todo + Verdict + Log) |
| reviewer | Quality Gate | delivery-team | judges the diff vs the contract; its verdict drives apply-verdict + the gate |
| docs | Technical Writer | delivery-team | living C4 docs and ERDs |
| qa | QA Engineer (specialist) | delivery-team | load / journeys / resilience / coverage — not the per-feature path |
| product-delivery-manager | Delivery Manager | delivery-team | reads the board, dispatches, integrates, ships |
| backend | Software Engineer | stack-turbo-nest-react | server-side feature work + its own tests |
| frontend | Software Engineer | stack-turbo-nest-react | UI/app feature work + its own tests |
| infra | Platform / DevOps | stack-turbo-nest-react | platform / CI / deploy tasks |
Backlog replenishment (
/delivery-team:task-promote) and verdict application (/delivery-team:apply-verdict) are deterministic skills, not agents — bookkeeping is code, not an agent's discretion.
agents-foundation/
├── .claude-plugin/marketplace.json # marketplace manifest (lists the plugins)
└── plugins/
├── delivery-team/ # Plugin A — agnostic process
│ ├── .claude-plugin/plugin.json
│ ├── agents/ commands/ hooks/ scripts/ rules/ templates/
│ └── README.md
└── stack-turbo-nest-react/ # Plugin B — opinionated stack (v0)
├── .claude-plugin/plugin.json
├── agents/ rules/
└── README.md
npx claudepluginhub fcms14/agents-foundation --plugin delivery-teamOpinionated stack layer (v0, as-built from poc-delivery-watch-tower): NestJS + React/Turborepo implementer agents and their architecture/backend/frontend/delivery/docs rules. Depends on delivery-team. To be refined into your design conventions + a structure-lint.
Harness-native ECC operator layer - 67 agents, 271 skills, 92 legacy command shims, reusable hooks, rules, selective install profiles, and production-ready workflows for Claude Code, Codex, OpenCode, Cursor, and related agent harnesses
Upstash Context7 MCP server for up-to-date documentation lookup. Pull version-specific documentation and code examples directly from source repositories into your LLM context.
Comprehensive feature development workflow with specialized agents for codebase exploration, architecture design, and quality review
Comprehensive C4 architecture documentation workflow with bottom-up code analysis, component synthesis, container mapping, and context diagram generation
Comprehensive PR review agents specializing in comments, tests, error handling, type design, code quality, and code simplification
Real-time statusline HUD for Claude Code - context health, tool activity, agent tracking, and todo progress