brawblan/ai-workflow

Cornerstone: a framework for agent-assisted software delivery, where checks decide that work is
done.
Version 1.2.0. All 10 profiles are supported, and each generated check blocks.
This repo holds Cornerstone, its stone CLI, the cornerstone plugin skills, my personal agent
rules, and tips. Read the docs at brawblan.github.io/ai-workflow.
## What Cornerstone is
Cornerstone says how a human and an agent deliver software together. It is a set of written rules
and a CLI that turns the rules into files for your repo.
Stages and roles. The work moves through Intake, Shape, Plan, Build, Test, Verify, Review,
Deliver, and Learn. A shaper, a planner, an implementer, a tester, a reviewer, and an
investigator do the work.
Gates. A human approves the ticket, the plan, and the change. Only CI passes the checks gate.
Profiles. Ten profiles set the plan form and the gates for each type of work, from a spike to
a full project.
A neutral core. The core never names a tool. An adapter turns it into files for one harness.
stone render writes those files into your repo.
## Why use it
| Problem | What Cornerstone does |
| An agent stops when the work looks done, and it can claim a check that it did not run. | Check output from CI, outside the agent session, shows that work is done (P1). |
| An agent that writes the code and its tests proves only that the code agrees with itself. | A different role writes the tests and reviews, each in a fresh session. A hook and a CI check stop the implementer from changing tests (P2). |
| A vague ticket gives a drifting result, and a long prompt does not fix it. | A human makes the ticket ready first: acceptance criteria, non-goals, a test oracle, and the users it serves (P3). |
| The same heavy process for a one-line fix and for a new product wastes time. | The profile sets how much plan and how many gates the work needs (P7). |
| A rule that helps one model can hurt the next model. | Each rule, skill, and role has an eval and a review date. When the evidence goes, the part goes (P5). |
| A framework tied to one tool breaks when the tool changes. | Only the adapter changes. The core stays the same (P12). |
Each rule cites its evidence in the research dossier.
## Who it is for
A developer who uses a coding agent on real repos and wants the result checked, not trusted.
A team that wants one process for many types of work, with the heavy gates only where the risk is
high.
A person who already uses Spec Kit, OpenSpec, or BMAD and wants a layer that does not depend on
one tool. See the migration guide.
It is not for you if you want a prompt library or an IDE. It is also not for you if you need a
harness other than Claude Code today. The only adapter at this time is for Claude Code.
## How it compares
Many tools cover one part of this: a gated flow, role agents, or a file generator. In the sources
that we read, none joins a neutral core, harness adapters, gates by profile, and an eval and review
date for each part. The prior art section has the table and
its limits.
## Status
Draft v0. The framework is complete enough to use on one profile. Other parts are design only.
| Part | State |
| Framework: principles, workflow model, gates, checks, modes, 10 profiles | Draft v0 |