Software that breathes.

Both. The methodology, with the manifesto of principles behind it, stands on its own. The skills and the factory are the tooling that puts it into practice. The methodology works without the tooling, but the tooling is where it pays off.

It depends on the scale and the stakes. INSPIRE is built for complex software in enterprise and regulated settings: large teams, long-lived products, ISO-style certifications, and audit and compliance requirements. If you are a single developer on an isolated project, a lighter framework such as GitHub’s Spec Kit will probably fit better. See who it’s for.

A document gets read once and then drifts. A graph of small, linked plain-text files can be traversed: an agent working on one endpoint can follow the links to the use case, schema, screen and decision behind it, and pick up only the context that applies. That traceability is what lets agents emanate the code again and again without losing the reasons it was written.

In your own repository, as Markdown under inspire_kb/, versioned with git next to the code. There is no external service or database. You can edit it by hand or through a skill, and both are first-class.

No. INSPIRE is designed to work across agent harnesses and LLMs. The knowledge base is plain Markdown, the skills are plain-text instructions, and the validators are Bash with yq and jq that run, and run in CI, with no agent present. The deterministic gates don’t care which model wrote a change, only whether it passes. Today the runtime ships packaged as a Claude Code plugin, and that is the install path the how-to documents.

Through mechanisms that are built in rather than bolted on. Tooling stamps every knowledge-base artifact with its provenance: the skill that wrote it, the exact bytes that skill ran against, and the runtime version. A person can record an explicit endorsement with a name and a date. Every architectural decision lives as an ADR. Every test cites the acceptance criterion it verifies. Commits and PRs pass deterministic gates that cannot be skipped with --no-verify, and git history is the audit trail of everything that changed since. INSPIRE does not certify you, but it produces the evidence an audit asks for.

The checks that decide whether a change can land are ordinary programs, not language models. Validators enforce the structural rules of the knowledge graph, git hooks refuse commits and PRs while hard errors remain, and the factory promotes a unit only once the tests citing its acceptance criteria are green. Agents generate the code; deterministic checks rule on it. The same input always gets the same verdict.

No. It moves the engineer to where judgment counts: deciding what should exist and whether the result is right. The factory takes care of the exhale, turning a specification that is already understood into code. The inhale, understanding the problem, stays with a person.

Yes. /inspire-extract runs four parallel scanners over an existing codebase (stack and infrastructure, UI screens, logic/API/DB, and styles), consolidates their findings into cross-linked knowledge-base candidates, and hands them to the authoring skills. It never writes to your source.

It is stack-agnostic by design. Optional stack profiles add a framework's conventions on top of the generic checks. The template ships react, angular, nestjs, ios and android profiles plus a typescript language profile, and a fork can add its own.

Scrum addresses coordination between people over weeks. INSPIRE addresses people who each direct many agents, one context at a time. The unit of work is a Breath, sized by context and impact rather than by time, and skills, guardrails and QA take the place of ceremonies.

Install the runtime, run /inspire:init in your repository, and invoke your first skill. The how-to page covers each step.