Project Delivery Framework: An Operating System for the 'CEO of the Engagement'

If product managers, engineering leads, and operations teams now have opinionated, locally runnable, AI-assisted toolchains tailored to the way they actually work, what about the senior delivery manager?

The person who, on any given Thursday afternoon, is simultaneously responsible for a charter, a budget, a steering committee, a client relationship, a team of fifteen, a contract (and a roadmap that has moved twice since kickoff) gets, in our reading of the present landscape, almost nothing.

The AI tooling that has arrived under the banner of "AI for project management" is AI for product management. It generates user stories, refines backlogs, summarises retrospectives, drafts requirements, and clarifies acceptance criteria. It is good at what it does. But it is not aimed at the engagement manager. It does not write the steering pack that has to land before the Friday morning exec read. It does not draft the escalation memo that, badly written, gets the author quietly removed from the account. It does not produce the change order that captures three weeks of unbudgeted scope without breaking the commercial model. It does not prepare a one-to-one that remembers what was said in the previous five.

That gap is what the Project Delivery Framework (PDF) is built to close. It is open source, it ships today as an npm package, and it runs locally inside Claude Code or OpenCode.

npx @systima/project-delivery-framework

What it is, and what we mean by it

We use engagement in the consulting sense: a discrete, time-bounded, contractually defined piece of work, with a charter, a budget, a governance model, a team, and a client.

We use engagement manager (interchangeably with senior delivery manager and senior programme manager) for the accountable executive of that engagement; the person who, for the duration, is effectively its chief executive.

We use workflow for a structured procedure that produces a single, named, audit-ready artefact (a steering pack, a change order, a closure handover).

We use agent for a thin persona layer that owns a stage of the lifecycle and dispatches to workflows.

The framework itself is a Claude Code and OpenCode skill library. It contains ten stage-aligned agents and fifty-two workflows. Together, they cover the full lifecycle of an engagement from pre-sales shaping through closure. Each agent greets the operator, scans what has already been produced, presents a menu of available workflows, and dispatches.

Most workflows accept a dump intent for ingesting unstructured material (call transcripts, RFPs, scrappy status notes), and most produce a markdown artefact with structured frontmatter linking it back to the engagement charter, the input sources, the model used, and the prompt hash.

The ten agents and the stages they own are as follows.

The operator does not have to remember these names; there is a /pdf-help command that recommends the next required action based on the current state of the engagement. But agents can be addressed directly, and once an engagement is a few weeks in, most operators do find themselves saying "hey Ronan" out of habit.

Why six design choices matter more than the workflow count

There are plenty of template libraries in the world, but the thing that distinguishes PDF from those is its six opinionated design choices that, taken together, change what it is like to run an engagement with an AI in the loop.

1. The charter is the constitution

Every engagement begins with a charter. Not the one-page summary that gets stapled to the front of a SoW and then never opened, but a living constitution that captures scope, success criteria, governance model, RACI, commercial model, risk appetite, definition of done, and reporting cadence. Every artefact produced by every workflow links back, by frontmatter reference, to the charter revision it was generated against. Charter changes are append-only, with a visible change-log.

This is borrowed, with thanks, from GitHub's Spec Kit (which uses the same pattern for software development), and it is the single most consequential decision in PDF. It is what prevents the weekly status from disagreeing with the steering deck from disagreeing with the budget tracker; they all reconcile to the same authoritative text. Without that anchor, an LLM-generated artefact is a free-floating object, and one free-floating object tends, in our experience, to produce a second free-floating object that disagrees with the first.

2. Spec-driven, not template-driven

Every artefact has structured YAML frontmatter declaring its workflow ID, workflow version, source inputs, model, prompt hash, and the charter revision it reconciles to. Artefacts are inspectable, comparable, and machine-readable. They are not free-form blobs that an LLM generated and the operator pasted into a deck. This matters, downstream, because it means an artefact produced in week four can be meaningfully diffed against an artefact produced in week sixteen; and it means that when an artefact later has to be defended (to the client, to internal audit, to the partner running the practice), there is a chain of provenance behind it.

3. Stage-orchestrated, persona-mediated

"Agents route. Workflows do the work".

The persona layer exists because operators find it easier to talk to "Ronan" than to scroll through a list of forty-seven workflow IDs; that is the entire reason. Underneath the persona, the actual artefact generation happens in versioned skills with explicit inputs, outputs, and validation thresholds. The architecture is borrowed (again, with thanks) from BMAD-Method, which applies the same pattern to engineering work. PDF adapts it for delivery management.

4. Local-first

All engagement data lives in _pdf-output/engagements/<slug>/ on the operator's machine. It is gitignored by default. The 09-people/ folder, which contains one-to-one notes, attrition signals, and performance conversations, is excluded from version control even when the rest of the engagement folder is shared with a team. Nothing leaves the operator's disk unless they explicitly share an artefact.

This is not an aesthetic preference. The material an engagement manager handles (commercial terms, client politics, team performance, draft escalations) is among the most sensitive material in any consulting practice. The idea that this material should be uploaded to a SaaS product as part of routine workflow seems, to us, simply wrong; and the regulated-industry clients we work with would, in any event, not permit it.

5. Audit by default

Every workflow invocation writes a JSONL audit record. Timestamp, workflow ID, workflow version, model, prompt hash, input artefact references, output artefact path, operator-provided context. The audit log is local; nobody else sees it. But it is the artefact the operator reaches for when, six months later, a procurement function or an internal audit asks how a particular figure in a particular steering deck came to be there.

6. Adversarial before stakeholder

Every outward-facing artefact (steering pack, exec memo, change order, client-shareable retrospective, SoW, case study) passes through a pdf-red-team workflow before it goes out. The red-team gate critiques the artefact against the charter, against the client's stated success criteria, and against a configurable adversarial checklist. The operator sees the findings. They either resolve them or accept the risk, in writing, on the record.

This is, we think, the most behaviourally important property of the framework. The operator never sends an artefact that has not been pressure-tested against the engagement's own constitution. Not because they could not, but because the framework makes the gate the path of least resistance.

A short tour of the workflows

A handful of workflows convey the texture of the catalogue better than an exhaustive list:

• pdf-status-weekly produces a status report formatted for Teams or Slack paste, with sections for headline, RAG, accomplishments this week, planned next week, risks and issues moved this week, decisions needed, and a single ask. It reconciles against the charter's reporting cadence, the current RAID register, and the previous week's status; if any of those disagree, it surfaces the disagreement rather than hiding it.

• pdf-steering-pack produces a MARP-rendered steering deck with speaker notes, a strict one-page exec summary on the cover (cover page discipline is, in our experience, the single highest-leverage editorial choice in any steering pack), a risk and change appendix, and a decisions-required slide that links each decision to its supporting artefact.

• pdf-change-request uses a granular taxonomy (scope add, scope clarify, scope remove, schedule slip, schedule compress, cost increase, cost reallocation, resource swap, governance change, commercial-model change) and infers the classical scope/time/cost/quality axes from the taxonomy rather than the other way around. The reason for this inversion is that, in our experience, change requests written top-down from "scope/time/cost/quality" tend to obscure what actually happened; change requests written bottom-up from a granular taxonomy tend to surface it.

• pdf-onetoone-prep produces a per-person one-to-one prep that is cumulative across previous one-to-ones with the same person. Recurring frustrations, unmet asks, and growth themes that no single-session prep would catch are surfaced as patterns. This is, perhaps, the workflow that surprises operators most on first use.

• pdf-estimate-challenge runs a pre-mortem against a draft estimate, cone-of-uncertainty corrected, with an explicit red-team pass on the assumptions. It is, in effect, the workflow that the estimator wishes a sceptical colleague would always run before the estimate is committed.

• pdf-closure-handover produces an internal closure pack, a client-shareable retrospective, a lessons-learned record propagated to the cross-engagement practice library, and a case study in two versions (internal and public). The propagation step is the important one: lessons that stay inside a single engagement folder may as well not have been written down at all.

The full catalogue, with the inputs, outputs, validation thresholds, and dispatching agent for each workflow, lives in _pdf/_config/pdf-help.csv, which is also what drives the /pdf-help recommender.

Who it is for, and (just as importantly) who it is not for

The framework is built for the senior delivery, engagement, or programme manager who runs one or more multi-month, multi-stakeholder engagements as the accountable executive for those engagements; who is responsible for budget, delivery, people, client, and quality across the engagement; who wants a private, opinionated, audit-defensible AI toolchain that operates at their level rather than at the product-manager level below them; and who is comfortable working in Claude Code, OpenCode, or another agentic CLI that supports the .claude/skills/ or .agents/skills/ discovery patterns.

It is not, to be clear, for product managers (who should use Anthropic's product-management knowledge-work plugin, or BMAD). It is not for engineering leads in build mode (who should use BMAD-Method). It is not for team platforms with multi-user state (PDF is single-operator by design, and we think that is the right shape for the role; the engagement manager is, after all, accountable as an individual).

What it borrows, and from where

We are explicit about lineage. The skill anatomy, the agent-versus-workflow split, the central CSV index, and the per-stage orchestration pattern are taken from BMAD-Method. The living-constitution pattern is taken from GitHub Spec Kit. The file-based, locally runnable, permissively licensed design philosophy comes from Anthropic's Knowledge Work Plugins. The audit-ready artefact structure, the Orange Book risk taxonomy that informs Klaus, and the MADR pattern for architecture decision records come from ArcKit.

PDF is, in our view, the delivery-management-layer sibling these projects were missing. BMAD gave engineering teams an opinionated, locally runnable AI toolchain. Spec Kit gave specification-driven development its constitution. Anthropic's Knowledge Work Plugins covered product, operations, and productivity. None of them addressed the engagement-management layer; the work the senior delivery manager actually does week to week. PDF does.

Getting started, and what comes next

Installation is one command.

npx @systima/project-delivery-framework

The installer copies skills into three locations, so that whichever AI tool the operator prefers works out of the box: .claude/skills/pdf-*/ (discovered natively by Claude Code and OpenCode), .agents/skills/pdf-*/ (a tool-agnostic mirror for any agent that follows the .agents/skills/ convention), and .opencode/commands/pdf-*.md (slash-command wrappers for OpenCode's TUI). It does not touch any existing skills from other frameworks; PDF coexists by namespace.

Once installed, the operator can scaffold a new engagement and ask for the next required action:

/pdf-engagement-init
/pdf-help

Or, more usually, address an agent directly:

"hey Marcus"      # Mobiliser
"hey Ronan"       # Run-Lead
"hey Helena"      # Herald
"hey Klaus"       # Risk Officer
"hey Petra"       # Planner
"hey Theo"        # Treasurer
"hey Quinn"       # Quality Steward
"hey Iris"        # People Lead
"hey Sofia"       # Shaper
"hey Felix"       # Finisher

The v0.1 release is feature-complete: fifty-two workflows, ten agents, eleven development stages with explicit consultation gates per stage. The known future work, all out of scope for v0.1, is described in ARCHITECTURE.md: API sync providers (Jira, Azure DevOps, GitHub, Confluence, Calendar, Slack and Teams, time-tracking) for which the architecture is forward-compatible but the connectors are not yet built; a cross-engagement portfolio view (pdf-portfolio) for the partner or practice lead running several engagements at once; practice-library search during engagement init, so that lessons from previous engagements surface at the point a new one is scoped; and real-world hardening through dry-runs and feedback from first live uses.

The source code is on GitHub. The npm package is published. The framework is MIT-licensed.

If you run engagements at this level and want an opinionated AI toolchain that operates the way you actually work, the install is one command away. If you work in a regulated industry, where the audit-by-default and local-first properties matter more than usual, our AI Governance and Compliance practice works with delivery functions on adopting this kind of toolchain in ways that satisfy internal audit and external regulators alike.