Prior Art & Novelty

Several patterns share adjacent territory. Here is what came before, how SEW differs, and what appears to be genuinely new.

The closest prior art

CrewAI Task Guardrails (2024–2025) is the nearest existing pattern. It supports embedded validation criteria, natural-language checks checked by an LLM, and automatic retry up to 3 times on failure — the same default as SEW.

CrewAI Task Guardrails Self-Enforcing Workflows
Who calls the checker The framework, automatically The skill itself, explicitly
Where criteria live Passed by caller at task creation Inside the skill's own definition file
Universal auditor No — each task has its own guardrail Yes — one auditor reads any skill's DoD
Quality system audits itself No Yes — meta-skill has its own DoD
Repairs bad criteria No Yes — silently, via review-definition-of-done

The most important difference is who calls the checker. In CrewAI, the framework weaves in the guardrail automatically — the task author doesn't write the call. In SEW, the skill author explicitly includes the audit call in the skill body. This makes the quality contract visible and auditable by anyone reading the file, and it makes the skill's commitment to self-verification explicit rather than implicit.

Other adjacent patterns

AGILE

Definition of Done

In Scrum, a DoD is a shared checklist a team uses to determine when an item is truly complete. SEW borrows the term and concept directly. The key difference: in Agile, the DoD is external to the work item and checked by humans. In SEW, it is embedded inside the skill and checked automatically.

DbC

Design by Contract (Bertrand Meyer, 1986)

Software components specify preconditions, postconditions, and invariants as part of their interface. A skill's DoD is essentially a postcondition — the skill must satisfy it before completing. The difference: DbC postconditions are formal, machine-checkable assertions in code. Skill DoDs are natural-language criteria checked by an AI agent.

CI/CD

Quality Gates in CI/CD

A quality gate is a checkpoint in a pipeline that must pass before the build proceeds. audit-workflow-deliverables is functionally a quality gate. The difference: CI/CD gates are configured externally in the pipeline. SEW's gate criteria are internal to the skill itself.

AOP

Aspect-Oriented Programming

AOP separates cross-cutting concerns (logging, security) from business logic by weaving them in automatically. The audit call at the end of every skill is a cross-cutting concern — applied uniformly, regardless of what the skill does. The difference: AOP weaves concerns externally. In SEW, the skill author writes the audit call explicitly.

What appears to be new

No single feature here is novel in isolation. The combination is:

  1. DoD embedded in the skill itself — not external config, not constructor arguments, not a separate spec file. The skill owns its quality contract in its own definition file.
  2. Universal self-auditing via a single shared auditor — every skill calls the same auditor, which reads the skill's DoD dynamically rather than receiving criteria as parameters.
  3. The skill author calls the auditor explicitly — visible in the skill body, not hidden in framework plumbing. Anyone reading the skill sees the quality commitment.
  4. Recursive quality enforcement — the quality system applies to itself. The meta-skill that writes DoDs has its own DoD, audited by the same system it maintains.
  5. Silent automated repair of bad criteria — missing or vague DoDs are repaired without user intervention, before the audit proceeds.
  6. Explicit base case — one skill (the auditor) is exempt from self-auditing to terminate the recursion. Named and documented, not an accidental omission.

What a skill looks like

---
name: my-skill
description: Does one job well. Invoke when the user asks to...
allowed-tools: Read, Bash, Write, Edit
---

# Skill: my-skill

## 1. Do the work

... skill procedures ...

## Definition of Done

- [ ] Criterion one — specific, verifiable, pass/fail
- [ ] Criterion two — covers a distinct output or state
- [ ] Criterion three — atomic, one thing per criterion

[Final step: Call audit-workflow-deliverables with this skill's path]