The problem

A good implementation workflow tends to grow tangled inside one harness. The steps that make it work, interrogate the request before coding, plan, drive the change test-first in an isolated worktree, review it, then sweep the loose ends, end up spread across a particular tool's config and a particular machine's skill directory. The discipline is portable in principle and trapped in practice: hand it to a different agent and it falls apart, because half of what it depends on is somewhere else.

What I built

delegate-skill-pack is that workflow packed into one canonical tree that travels intact. It bundles the delegate skill, every skill it transitively calls, three role prompts and two shared workflow documents, so the whole dependency graph resolves inside a single checkout. The entrypoint is skills/delegate/SKILL.md; everything it references lives beside it under skills/, roles/ and docs/; and manifest.json records the graph in machine-readable form. Fifteen skills in total: six of mine and nine MIT-licensed Superpowers skills, with ship-gate deliberately left out.

There are two ways to use it.

  • Hand the repository to an agent. The whole integration is one instruction: clone the repo, read skills/delegate/SKILL.md, and follow it, resolving every named skill and role prompt from the same checkout. Nothing points outside the tree.
  • Install it into an explicit target. A bundled Node CLI copies the pack somewhere permanent. The target is always named, never guessed, and becomes a complete portable pack root with its entrypoint, roles, docs, manifest and licence files beside it. Install refuses to overwrite an existing skill folder unless replacement is made explicit, so nothing is clobbered by accident and no second copy is left to drift.
open ⤢
The pack is one tree: the delegate skill, its whole dependency graph, roles and docs, with a manifest. It runs nothing on its own; any capable agent reads it and drives the pipeline, from grill through to sweep, to a bounded PR. The agent is the runtime; the pack is the bill of materials.

What it is not

It is not a framework or a runtime. The pack does not execute anything on its own; it is a tree of instructions, a dependency manifest and a small installer. The agent is the runtime, and the pack is only the bill of materials it reads from. That is the point: the workflow is harness-agnostic, so the same law runs under different tools instead of being rewritten for each.

Harness-agnostic is not the same as capability-free. A full run still needs filesystem access, shell execution, Git worktrees and worker and reviewer agents, with gh on top for pull-request integration. A harness that has no notion of named roles simply hands the Markdown role prompt to a generic subagent.

Licence

The original pack material is MIT-licensed. The adapted Superpowers material and its full MIT notice are kept in THIRD_PARTY_NOTICES.md, and the installer copies both licence files into every installed pack, so provenance travels with the code.