Enni

Context for coding agents

Your AI agents can write code.
Enni checks they know what to build.

Before your agent starts, Enni checks what's known, what's missing and what might block the work — across your issues, pull requests and team conversations.

See how Enni works

Try a public issue without an account. Read-only.

enni.vibana.com / acme/billing

Is acme/billing#1427 ready to start?

Needs careBILLING #1427Partial refunds post twice on retry

Before you start: add the steps that make it post twice, and link PR #1402. Then this becomes Ready.

What's in the way

  1. Add the steps that make it post twice. It reports a bug, but not how to make it happen. Quoted: sometimes posts the refund twice [1]
  2. Link PR #1402, or say why it's separate. PR #1402 changes the same refund handler, and the issue doesn't mention it. Quoted: the retry in refunds/handler.rb [2]

Who knows

@mayaAssigned to this, so the first person to ask.
Suggested rewrite

The sections this issue is missing, as Markdown. Copy them into the issue and fill in what is in italics. Lines marked Proposed: are drafted from the issue — check them before you paste.

## Steps to reproduce

1. Proposed: Refund $20 of an $80 payment.
2. Proposed: Make the ledger write time out once.
3. Proposed: See two refund rows in the ledger.

## Dependencies

- PR #1402 — _who provides it, and is it in place?_
Answer for:
Where this comes from · 2 sources
  1. [1] Issue #1427, description
  2. [2] PR #1402, changes to refunds/handler.rb
Details

Nothing is hidden, just ordered.

Needs care2

  • It can be reproducedfailedIt reports a bug, but not how to make it happen.
  • What it depends on is in placea caveatPR #1402 changes the same handler and isn't linked.

Couldn't check2

  • Whoever approves it is involvedcouldn't be checkedNothing remembered says who approves this.
  • Written rules are metcouldn't be checkedNo written rule is remembered for this.

Passed10

  • It says how to tell it's donepassed
  • The problem is statedpassed
  • Nothing is left openpassed
  • It's one bounded piece of workpassed
  • It says where in the codepassed
  • It shows what it should look likepassed
  • It's open and nobody else is on itpassed
  • The thread agrees with itpassed
  • The owner still owns itpassed
  • It hasn't been tried and undone beforepassed

An answer is advice. A person still decides.

Example answer · illustrative repo

The problem

Fast execution doesn't help when the task is missing critical context.

A coding agent starts on whatever it's handed. If the issue leaves out how to reproduce the bug, which pull request it builds on, or what the thread already settled, the agent fills the gap with a guess, and the gap shows up in review. Open source maintainers see the same with every new contributor.

Without Enni

  1. The agent is handed “Partial refunds post twice on retry” and reads the text it was given.
  2. Nothing tells it the steps to reproduce were never written, or that PR #1402 changes the same handler.
  3. It guesses, opens a pull request, and the missing context is found in review.

With Enni

  1. Before writing code, the agent asks Enni about the issue.
  2. Enni reads the issue, its comments, the linked pull requests and the team's thread, and finds what's missing: no steps to reproduce, and PR #1402 isn't linked.
  3. The agent asks @maya for the steps and builds on #1402. The gap is closed before the work starts.

A representative example, not a measurement.

How it works

Take context away. Watch the answer, and the agent, change.

Switch off something the issue has and follow it through all 14 checks: the finding, the step that fixes it, the verdict and what your coding agent decides. The worst finding decides: clear every one to make it Ready.

  1. Missing context
  2. Finding
  3. Fix
  4. Updated verdict
  5. The agent's decision

What the issue has

acme/billing · issue #1427Partial refunds post twice on retryopened by @dev-ana · 3 comments · assigned to @maya
Partial refunds post twice on retry

What Enni says

Switch one off to see what it costs, then on again to fix it.

Needs care

Before you start: add the steps that make it post twice and link PR #1402. Then this becomes Ready.

10 of 14 passed · 2 couldn't be checked · 2 need care

  • It says how to tell it's donepassed
  • The problem is statedpassed
  • It can be reproducedfailed
  • Nothing is left openpassed
  • It's one bounded piece of workpassed
  • It says where in the codepassed
  • What it depends on is in placea caveat
  • It shows what it should look likepassed
  • It's open and nobody else is on itpassed
  • The thread agrees with itpassed
  • The owner still owns itpassed
  • Whoever approves it is involvedcouldn't be checked
  • Written rules are metcouldn't be checked
  • It hasn't been tried and undone beforepassed

What the agent does

> enni.check_readiness(#1427) Needs care · 10/14 Asking @maya first: add the steps that make it post twice and link PR #1402. Then starting.
Where this comes from: issue #1427, team history

Product

What you and your agent get before the work starts

Enni answers one question about a task: is it ready to start? The answer is made of three parts.

01

Find what's missing

Enni reads the issue with its comments and linked pull requests, plus Linear and Slack when you connect them, and names what isn't there: the steps to reproduce, a definition of done, a decision still open.

  1. Add the steps that make it post twice. It reports a bug, but not how to make it happen. Quoted: sometimes posts the refund twice [1]
  2. Link PR #1402, or say why it's separate. PR #1402 changes the same refund handler, and the issue doesn't mention it. Quoted: the retry in refunds/handler.rb [2]

02

Know what to do next

Ready, Needs care or Not ready yet, decided by the worst finding. Each finding comes with a step to fix it, the line it quotes, and the person to ask.

Needs care

Before you start: add the steps that make it post twice, and link PR #1402. Then this becomes Ready.

Who knows

@mayaAssigned to this, so the first person to ask.

03

Give agents a better start

Claude Code and Cursor ask Enni over MCP before they write code, and act on the answer: start, ask first or hold off.

> Fix issue #1427 in acme/billing● enni.check_readiness(subject_url: "github.com/acme/billing/issues/1427")  Needs care · 10 of 14 passed · 2 couldn't be checkedEnni says: before you start, add the steps that make it posttwice; PR #1402 changes the same handler. I'll ask @maya forthe steps and build on top of #1402.
The 14 checks behind every answer

Rules first, then one model pass. Each finding is minor, serious or blocking, and a check with nothing to read says it couldn't be checked.

  • It says how to tell it's done
  • The problem is stated
  • It can be reproduced
  • Nothing is left open
  • It's one bounded piece of work
  • It says where in the code
  • What it depends on is in place
  • It shows what it should look like
  • It's open and nobody else is on it
  • The thread agrees with it
  • The owner still owns it
  • Whoever approves it is involved
  • Written rules are met
  • It hasn't been tried and undone before

Why not just ask Claude?

A chat sees what you paste. Enni gathers the rest.

A general model reads an issue you paste into it well. Enni does the gathering first, then runs the same checks on what it found, every time.

  • Context it gathers itself

    A chat only sees what you paste. Enni gathers the issue's comments, linked pull requests, who holds which role and the issue's state, plus Linear and Slack when you connect them.

  • Exact findings, with their source

    A finding comes from what Enni read, not from a guess, and quotes the line it rests on with the issue, comment or pull request it came from.

  • Unknowns said out loud

    When there is nothing to read for a check, the answer says it couldn't be checked, rather than filling the gap.

  • The same criteria, where you work

    The same 14 checks on every issue, in your coding agent over MCP, on every pull request through the GitHub Action, and in the app.

What the comparison measured

  • 0 of 39open pull requests a model caught from the pasted issue alone39 of the issues already had one. Enni flagged all 39. 100 open issues in public repositories, Claude Sonnet 4.5 for every side.
  • 1 in 4of its open pull request flags were wrong when the model got the same contextIt also called 29 open issues closed. Every Enni flag was right and cites its source. 100 open issues in public repositories, Claude Sonnet 4.5 for every side.
  • 20 of 20same decision when Enni checked an issue againA rerun on a sample of 20. The model alone gave the same decision on 97 to 98 of 100.

Developers

Works where you work

The same answer in your coding agent, in CI and in the app. Create a free account, connect GitHub with a read-only token, then add Enni to the tools you already use.

Claude Code · Cursor · live

In your coding agent, over MCP

The agent asks Enni before it writes code, and learns what's missing while there is still someone to ask.

One command:claude mcp add --transport http enni https://enni.vibana.com/api/mcp

GitHub Actions · live

In CI, on every pull request

One workflow step. The check fails until the work behind the pull request is ready, so reviewers see the gap before they read the diff.

Read-onlyThe Action reads the PR and its issue. It never comments, labels or merges.

The Enni app · live

In the app, for the whole team

Ask in plain words, or open Today: your open issues, checked in the background and sorted by what can start now.

  • #1431 Add refund reason to receiptready
  • #1427 Partial refunds post twice on retryneeds care
  • #1388 Migrate ledger exportsnot ready yet
Next upHand the green ones straight to your agent.

Set it up

Run this line in a terminal where you use Claude Code. Then ask: "Check with Enni if issue 1427 is ready before you start."

claude mcp add --transport http enni https://enni.vibana.com/api/mcp

The whole setup, step by step, with the exact token permissions: Get started

Trust

Read-only by design. Traceable by default.

Enni only reads, and only what you allow. To judge an issue, Enni sends it to an AI model through OpenRouter with zero data retention: it is not stored and not used for training.

Every finding cites its source

Each finding quotes the line it rests on and links where that line came from: the issue, a comment, a pull request or a thread. Check Enni's work before you act on it.

Rolling Enni out to a team? We'll walk your security lead through scopes, storage and deletion: support@enni.vibana.com

Access to your apps
Read-only
Scope
Repos, teams, channels you pick
Keys
Encrypted, never shown again
Issues sent to an AI model
Zero data retention, never trained on
Keys sent to an AI model
Never
Answers and evidence
Deleted after 30 days
Conversations
Deleted after 90 days
Disconnect an app
Key deleted at once

Questions

What developers ask first

Something else? Write to us and a founder will answer: support@enni.vibana.com

Does my code go to an AI model?

Not your code: Enni doesn't read it. To judge an issue, Enni sends it to an AI model through OpenRouter with zero data retention: it is not stored and not used for training. What goes is the issue's text, labels, state and comments, never your keys.

Is it only for coding agents?

No. People ask the same question before they pick up an issue, and open source maintainers check contributors' issues before labelling them.

What access does it need?

A read-only GitHub token scoped to the repos you choose. Slack and Linear are optional. Enni never writes to any of them.

What if an answer is wrong?

Nothing is hidden, just ordered. Every answer lists what passed, what needs care and what couldn't be checked, worst first, quoting the line each finding rests on. Tell us where it was wrong and we'll fix the check.

What does it cost?

Nothing while Enni is in beta. A free tier stays after the beta.

For developers

Give your next coding task a better start.

Get started freeSee the setup guide
  • Free while in beta, no credit card
  • First answer in about 5 minutes
  • Works in Claude Code, Cursor and GitHub Actions

For engineering teams and open source maintainers. Works for people and for coding agents alike. Only ever reads. Built by Angel Ramirez and Eduardo Silva (creator of Fluent Bit).