Skip to content

Engineering Athena

Engineering intelligence on demand.

Engineering intelligence on demand, in the form the work needs it:

  • —the rules that bind a change
  • —a guide for building something new
  • —a flow when the job has steps
  • —research when the question is wider than the task

Curated, kept current. Connect once — nothing is added to your repositories.

coding agent · svc-billing
>

what Athena returns

agents · run in order

claude codecodexcursor— or any agent that speaks MCP

waiting for the plan…


The problem

You wrote the standards. Nothing reads them.

The knowledge never arrives

The standards exist — a 40-page PDF, a Notion space, a handful of ADRs. None of it is open in the editor at the moment the code actually gets written.

Copies drift apart

So the rules get copied into every repo. Eleven handbooks drift in eleven directions, and nobody can say which one is current anymore.

Docs rot quietly

No owner, no review date, no way to tell a living standard from a fossil. Engineers stop trusting all of it — and they are right to.

Agents default to generic

Coding agents generate from their training data — the average of GitHub — not from your layering, your error contract, your migration policy. The output looks right, and is wrong in exactly the places your house style differs.

The fixes pile up

The usual answer is to install more: a skill per framework, a server per vendor, a rules file per repo. Each one eats context on every request, and each one needs an owner. The team ends up maintaining tooling instead of shipping.

All five have the same root cause. The knowledge lives somewhere that is not where the work happens, so it has to be carried there by a human who remembers. Under deadline, nobody remembers — which is exactly when the rules mattered.

A CLAUDE.md per repo fixes maybe 60% of this for free and you should do it today. Athena exists for the part that does not fit in 100 lines and must not be copied eleven times.

How it works

Knowledge on demand, in four pillars.

Athena serves what the task needs, in the shape the task needs it: graded rules, working guides, multi-step flows, or deep research. The agent asks for what it's trying to get done; the pillar decides what comes back.

Rules

06-api-design.md

MUSTplural, lowercase routes — /api/v1/orders

MUSTPATCH for partial updates, never PUT

SHOULDidentifiers opaque to the client

Guides

auth-in-django.md

one working recipe — steps + code that runs

01 install djoser + simplejwt

02 settings: auth classes · token lifetimes

03 urls: /auth/jwt/ create · refresh · verify

04 code: serializer snippet, ready to paste

Flows

Setup FullStack App

01 fastapi cookiecutter template

02 react vite template

03 gcp + pulumi cli

04 rules: terraform · guide: cloud run

05 rules: gh actions · guide: ci/cd

Knowledge

> SQS or Kafka for this queue?

> what does a checkout flow need?

> how to design multi-tenancy?

The mechanism

Watch an agent do the reading.

The agent describes its task. Athena tells it which pillar and which call, returns exactly what that step needs, and the agent comes back citing the standard it used — by name, so you can open it and argue with it. A small toolbox, not forty tools.

An agent cannot create or alter a rule. It can ask, and it can report that something was missing. It cannot promote its own opinion into the standard it will be judged against next week. The standards change through reviewed pull requests.

one real session · three tool calls · four agents in sequence
>
the work, in sequence
the task
01 plan
queued
02 implement
queued
03 test
queued
04 review
queued
ToolCategoryWhat it is for
athena_route—Describe the task; get told which pillar and which call
athena_rulesRulesWhat binds the change being made
athena_guideGuidesHow to build one thing, with code
athena_flowFlowsMulti-step work, and the instruction to fan out
athena_briefFlowsOne agent's payload, for one step
athena_knowledgeKnowledgeDeep research on a topic
athena_get—Redeem a reference the agent was already given
athena_feedback—Report what was missing — the one write

Categories are the four pillars above. Route, get and feedback serve all of them.

Context economy

Ask for the rules, not the library.

Context is the budget you are actually spending. A 200 KB handbook in every session is worse retrieval than three relevant pages, and it crowds out the code the agent is supposed to be reading.

So the rules are served separately from the prose. athena_rules("python") returns the graded assertions — about 2 KB — with no rationale, no examples, no diagrams. That is what an agent needs to enforce a standard. The why is still one athena_get away, for the human who wants to argue.

Same reason the toolbox is small instead of forty tools. Every tool schema is injected into context on every request. A large toolbox makes an agent worse, not better.

one 200,000-token context window

0 tokens

whole handbook pasted into CLAUDE.md

0%

room left for your code

Planning

Don’t replace your AI’s planning tools. Make them smarter.

Cursor, Claude Code and the other coding agents already ship strong planning. Athena doesn’t add another planning skill, and it doesn’t force a new workflow on top of them.

It hands those native tools the right engineering knowledge at the right moment — your architecture, standards, conventions, guardrails and proven practices — so the agent plans with your context instead of generic knowledge, or rediscovering how your codebase works one session at a time.

native plan mode · grounded by Athena — no new skill, no new workflow

claude code · plan mode

01
Scaffold the order service
↳from the service template — routers thin, logic in services
architecture
02
Add the create-order endpoint
↳response model declared · errors on the shared contract
standards
03
Wire up persistence
↳DB access through repositories · migration ships a downgrade path
guardrails
04
Write the tests
↳contract tests, named and placed the way this team places them
conventions
05
Ship it
↳one image, built once, promoted dev → staging → prod
proven practice

athena · engineering context

←
architecture
how services are layered here
←
standards
graded MUST / SHOULD / MAY
←
conventions
naming, placement, shape
←
guardrails
what must never ship
←
proven practices
what already worked here
built-in planning+athena knowledge=plans grounded in how your team actually builds software
Fewer custom skillsLess prompt complexityBetter plansStronger guardrails

Breadth

The build is one stage out of twelve.

Teams adopt AI at the point where code gets typed and wonder why throughput barely moves. The expensive parts are upstream and downstream: deciding what to build, breaking it down honestly, and finding out why it broke in production.

Athena carries the standard for every stage, and the gate between each one. Agents draft. Humans decide. The artifacts — a spec, a plan, a reviewed diff — are what make the next stage cheap.

07 · Scaffold

agent asks

“Start a FastAPI service, our way”

the call

athena_guide("start a fastapi service")

returns
↳

the generator + its answers, prompt by prompt

↳

the post-generation delta · the day-zero checklist

Scaffolding

A new service, to your standard, in 30 minutes on prod.

The agent reads the setup pages, asks you the four questions it is not allowed to decide, runs the generator, applies the post-generation delta, and then verifies the day-zero checklist item by item with evidence.

It does not create the repo, the cloud resources or the secrets. It writes the infrastructure and the commands; you run them. An agent that provisions unattended is an unreviewed deploy.

Step 1

Four questions

agenthumanShould this exist?—✓Owner—✓Data ownership—✓Tier—✓

Step 2

Generate

$ uvx cookiecutter gh:cookiecutter/cookiecutter-django
project_name · use_docker: y · postgresql_version · cloud_provider: GCP …
answers come from the handbook's answer table, prompt by prompt

Step 3

Apply the delta

+ uv.lock   + Dockerfile.prod   + justfile
+ app/{api,services,repositories}/   + .import-linter — the layer contract

Step 4

Verify

✓ CI green on first push · workflow run✓ container builds & runs · image digest✓ Sentry receiving events · test event id✓ layer contract enforced · import-linter pass✓ staging reachable · health check 200✓ structured logging wired · sample line● branch protection · needs a human● runbook owner named · needs a human

24 items on the full checklist. Two stay amber until a human signs them — deliberately.

Step 5

Gated

⌖ repo settings · you run this⌖ cloud apply · you run this⌖ secrets · you run this⌖ Sentry project · you run this

Time to live

Minutes to a deployed skeleton. Thirty to your first feature PR on prod.

What takes minutes: a service that builds, runs in a container, passes CI, reports errors to Sentry and reaches staging. Not because anything was skipped — because the generator, the multi-stage image, the compose files, the CI workflow and the error tracking are standards Athena hands the agent, not decisions you make at 16:40 on a Thursday.

What takes the rest of the 30 minutes: the day-zero checklist. Owner, tier, data ownership, branch protection, secrets, infrastructure, the layer contract, the runbook. We will not tell you that part is instant. We will tell you it gets done, item by item with evidence, instead of becoming a ticket nobody picks up.

one image, built once, promoted

localCIstagingproductionnever re-rendered between stages

drawn to scale

minutes — skeleton deployed, CI green, Sentry live

minute 30 — day-zero checklist done with evidence, first feature PR on prod

Measured: “minutes” from uvx cookiecutter to a green pipeline, a container in staging and Sentry receiving events. “Thirty minutes” from the same start to the first reviewed feature PR on prod with the checklist complete. Both are handbook pages, linked from this one — not marketing claims.

Four environments from the first commit — one image, built once and promoted. Parity is the shape the service starts in, not a later project. And the same shape three times: FastAPI, Django, React. One handbook, one layering, one delivery path.

Standards as code

Every rule is graded. Most are enforced.

MUST

A PR that breaks it does not merge. Exceptions need a waiver ADR.

“Every endpoint declares a response_model” — CI fails the build on a bare dict return.

SHOULD

The default. Deviating is allowed and must be justified in the PR description.

“Use httpx, not requests” — fine to deviate for a legacy SDK, if the PR says why.

MAY

Genuinely a choice, written down so you do not re-derive the trade-off.

“Celery or Cloud Tasks for background jobs” — both supported; the page holds the trade-off so you pick in minutes, not meetings.

The grade is not decoration. CI keys off it, code review keys off it, and so does the agent. A MUST costs an ADR to create and an ADR to change — rules that cannot be challenged get routed around instead.

Every page carries a status and a review date. Anything in draft for more than 90 days is deleted or finished. That is how you tell a live standard from a fossil.

checks queued — rules lint, layer contract, review pass
rules-lint: POST /orders returns a bare dict (no response_model)
MUST · api-design standard
all checks passed — OrderOut declared as the response model

The gate behind the grade: same rule, carried by the agent, the linter and the review.

Knowledge that writes itself

Figured it out yourself? Feed it back.

When Athena has no answer and you work the thing out manually — a setup, a fix, a piece of functionality — one call sends what you learned back: athena_feedback. It gets reviewed, graded and merged as working knowledge.

Next time, your agent gets it served in two kilobytes — and so does everyone else’s. One person’s afternoon becomes the community’s answer, globally.

one gap, start to finish

> configure Cloud SQL IAM auth

→ athena_route("cloud sql iam auth")

no guide found · logged as a gap

you solve it by hand — 40 minutes, three dead ends

> send it back

→ athena_feedback("cloud sql iam auth")

your notes + the config that worked

one call · the only write in the toolbox

> review

+ guide: "Cloud SQL IAM auth" · merged by PR

graded SHOULD · tested · status: live

credited to you

> anyone, next time

→ athena_guide("cloud sql iam auth")

served in 2 KB · 40 minutes → 40 seconds

the gap no longer exists

Hit a gap

Athena says so honestly — no guide, logged.

Send what you learned

One call: athena_feedback — notes and working config.

Reviewed, graded, merged

A human reviews the PR. It becomes a real page, with a grade and a status.

Served to everyone

Working knowledge, on demand, globally — the community makes Athena better.

Examples

Watch Athena do the work.

example 01 / 06setup

What is Athena — and how to set it up

What Athena is, where it sits next to your coding agent, and the full setup — connect once, and every rule, guide and flow your team has curated is on call. Nothing is added to your repositories.

SetupMCPFirst run