OpenAURA
§ 00 — Thesis
Agentic updates, reviews & accountability —
weekly project briefs generated from the work you already did.
A small, repeatable method that reads your repo — PRs, issues, commits, releases, sprint items, metrics — and writes a structured markdown brief every week. Committed back to your project. Reviewable. Diffable. Owned by the repo.
Four steps, then boom.
Python 3.11 → 3.14 · CI-nativepip install, drop a config, push.
First brief lands Friday 17:00 UTC.
1. pip install open-aura
2. Create aura.config.yml at your repo root — declare project, trigger, model, signals.
3. Copy the bundled GitHub Actions workflow into .github/workflows/aura.yml and set ANTHROPIC_API_KEY (or OPENAI_API_KEY) as a repo secret.
4. Commit & push. A structured markdown brief lands in aura-docs/ on the next cadence tick.
aura runFull pipeline: gather → score → summarize → write markdownaura run --dry-runPrint the JSON brief instead of writing to diskaura validateCheck config + env vars; no API or LLM callsaura manifestoPrint the bundled AURA Protocol manifestoThe manifesto.
10 rules for accurate repo updates10 rules for accurate
repo updates.
OpenAURA is not a framework in the heavy sense. It is an update protocol — a small, repeatable way for any repo to turn delivery signals into accurate project briefs. These ten rules keep the claims grounded and the ritual small enough to survive every week.
The repo is the source of truth.
Every update should start from the systems where work actually happened. Prefer PRs, issues, commits, releases, work items, pipeline runs, and declared metrics over memory, meetings, or vibes.
Evidence beats narrative.
Every meaningful claim needs a source. If a brief says something shipped, slipped, blocked, improved, or regressed, it should point back to the signal that proves it.
Missing data is not zero.
No signal means "unknown", not "nothing happened". OpenAURA distinguishes a measured zero from missing coverage so readers know whether the project is quiet or the instrumentation is thin.
Updates must be repeatable.
The same repo, same configuration, and same time window should produce the same kind of brief every run. It works because the ritual is small enough to survive every week.
Keep the brief human-sized.
A good update is short enough to read and specific enough to act on. It should tell people what changed, what matters, what is blocked, and what needs a decision without burying the reader in raw logs.
Separate facts from recommendations.
Findings describe what the signals show. Next focus describes what the team should do about it. Mixing the two makes updates sound confident while hiding the reasoning.
Risks stay visible.
Blockers, failed pipelines, stale PRs, and unresolved decisions belong in the brief even when they are uncomfortable. OpenAURA is accountable to delivery reality, not optics.
Shared metrics need local context.
Every project can track common delivery measures, but each repo should declare what "healthy" means for its own domain. A KPI without a local target is just decoration.
Markdown is the artifact.
The update should live beside the work, in version control, as a durable project history. Dashboards can help, but the canonical brief should be reviewable, diffable, and owned by the repo.
Humans decide.
OpenAURA gathers, scores, summarizes, and recommends. It does not pretend to be the team. The brief should make decisions easier by making the evidence clearer.
Open method. Real signals.
Weekly clarity.