The Ecosystem

Four roles, one quality contract, and a hook that enforces it at write time — before a skill ever runs.

Four roles

Every skill in the ecosystem fills one of four distinct roles. The roles are not about what a skill does — they are about where it sits in the quality chain.

Role Responsibility Example
Orchestrator Sequences sub-skills, owns the workflow, self-audits last skeleton-project
Sub-skill Does one job well, self-audits before returning to the orchestrator claude-project, gitlab-new-project
Quality gate Reads DoD, checks state, reports pass/fail — never re-runs work audit-workflow-deliverables
Meta-skill Audits the auditor's prerequisites — ensures DoDs are good before the audit runs review-definition-of-done

Sub-skills don't chain to each other — they're independent utilities. The orchestrator owns the sequence. If you need to add a step or change the order, you change one file.

graph LR
    subgraph Orchestrators
        SK[skeleton-project]
    end
    subgraph Sub-skills
        CP[claude-project]
        GL[gitlab-new-project]
    end
    subgraph Quality Layer
        AUD[audit-workflow-deliverables]
        REV[review-definition-of-done]
    end
    SK -->|calls| CP
    SK -->|calls| GL
    CP -->|self-audits via| AUD
    GL -->|self-audits via| AUD
    SK -->|self-audits via| AUD
    AUD -->|questionable DoD| REV
    REV -.->|has own DoD| REV
    AUD -.->|base case| AUD
Figure 1 — The four skill roles and their audit relationships within the ecosystem.

How orchestration works

1

Orchestrator calls sub-skills in order

Each sub-skill is an independent utility — it doesn't know who called it or what comes next. The orchestrator owns the sequence entirely.

2

Each sub-skill self-audits before returning

The sub-skill calls audit-workflow-deliverables on itself and returns pass/fail to the orchestrator. It does not escalate — that's the orchestrator's job.

3

On sub-skill failure, the orchestrator decides

The orchestrator retries the sub-skill or escalates to the user. Sub-skills don't retry themselves — the retry logic belongs to whoever owns the sequence.

4

Orchestrator self-audits last

After all sub-skills complete, the orchestrator calls audit-workflow-deliverables on itself. Its own DoD typically includes "all sub-skills completed successfully."

The integrity hook

A PostToolUse hook fires on every SKILL.md write — whether the file was written by Claude, copied from another project, or edited manually. It runs at the harness layer, below the skill invocation system. There is no path into the ecosystem that bypasses it.

1
Is ## Definition of Done present?

A skill without a DoD has no quality contract. The hook flags it before it can be used.

2
Is audit-workflow-deliverables called in the skill body?

A skill that doesn't call the auditor cannot self-verify. The hook flags it immediately.

If either check fails, a SKILL QUALITY NOTICE is injected into Claude's context, blocking other work until both requirements are met. Skills cannot validate themselves at creation time — the skill needs to exist before it can be called, which is a bootstrapping paradox the hook resolves by running at the harness layer instead.

Exempt skills

audit-workflow-deliverables and review-definition-of-done are explicitly exempt from the hook check. They are the base cases of the recursive system — they define and enforce the standard, so subjecting them to it would create a circularity the system cannot resolve.

The auditor's quality is maintained instead by: (1) review-definition-of-done can be called on its DoD section directly if ever questioned; (2) the skill is simple and narrow enough to verify by inspection; (3) any agent using the ecosystem can read its SKILL.md and judge it directly.