How to Engineer a Serious AI Delivery Framework with OpenSpec, Skills, Hooks, Rules, and Templates
Most AI agent frameworks look impressive in a demo and weak in a real delivery pipeline. They can generate code, draft plans, and even produce tests, but they often fail at the harder engineering problem: keeping implementation, intent, validation, and release evidence aligned over time.
That is the gap this article focuses on. Here, OpenSpec specifically means the Fission AI project at github.com/Fission-AI/OpenSpec, a spec-driven development framework for AI coding assistants. OpenSpec is not just “a place to write specs.” It is a structured workflow for managing change through artifacts, delta specs, lifecycle commands, and tool-aware integrations.
If you are trying to build an AI delivery framework that senior engineers can trust, OpenSpec can be a strong backbone. But it is only one layer. To make the whole system work, you still need skills, rules, hooks, templates, and a deliberate validation model.
Here is the architecture we actually care about:
governed-ai-delivery/
├─ openspec/
│ ├─ specs/ <-- current system behavior by domain
│ └─ changes/ <-- proposal, design, tasks, delta specs
├─ skills/ <-- role-specific execution guidance
├─ rules/ <-- persistent engineering constraints
├─ hooks/ <-- deterministic lifecycle automation
├─ templates/ <-- stable artifact shapes
├─ validations/
│ ├─ test-strategy/
│ ├─ policy-checks/
│ └─ release-evidence/
└─ ci/
└─ pipelines/ <-- reproducible validation and release gates