I built a release intelligence agent in 4 days with Coral, Groq, and Claude Code. Here's the exact route

jitendra bhati — Sun, 31 May 2026 19:11:44 +0000

5 days. Solo. First hackathon. One dashboard that tells you whether to ship.

This is not a polished retrospective. This is the actual route I took — wrong turns, late debugging sessions, and the one query that made the whole thing feel real.

The problem I kept hitting

Before every release I open four tabs.

GitHub to check if the PRs are actually merged. Linear to check which sprint items are done. Sentry to check if anything is actively broken. Slack to scroll through #releases and see if anyone mentioned a concern.

Then I try to hold all of that in my head at once and make a decision.

It takes about 40 minutes. And I've still shipped things I shouldn't have — because a PR merged, an error appeared six hours later in Sentry, and I didn't connect the two. The error was sitting right there. I just wasn't looking at both at the same time.

That's not a process problem. That's a missing JOIN.

What Coral actually does

I was going into this hackathon looking for an excuse to use Coral. The short version: Coral is a local CLI that turns developer APIs into SQL tables.

You run coral source add github, hand it a token, and now github.pulls is a real table you can SELECT from. Same for linear.issues, sentry.issues, slack.channels. You can JOIN across them. You can do date arithmetic. You can pipe the result straight to an LLM without writing a single API client.

That last part is what I kept coming back to. It's not "you can query GitHub in SQL" — there are GraphQL proxies that do that. It's that the JOIN works across sources. Completely different APIs, completely different auth, one result set.

The agent: ShipMind

I built ShipMind — a release intelligence agent that answers five questions before every deploy:

🔴 Release blockers — unresolved Sentry errors that would break production
🟡 Readiness check — Linear tickets marked done vs PRs actually merged in GitHub
🟠 Risk assessment — GitHub PRs cross-joined with Sentry errors introduced after each merge
💬 Team signals — Slack messages from #releases surfaced and analyzed automatically
📈 Sprint velocity — Linear cycle completion rate against planned scope

All five run together. An LLM (Llama 3.3 70B via Groq, or Claude if you prefer) reads the combined results and outputs a score from 0 to 100 with a verdict: SHIP, SHIP WITH CAUTION, or HOLD.

🔗 GitHub: github.com/Jeetubhati/shipmind

The architecture

Browser  →  Flask (web/app.py)
                  ↓
     Groq · Llama 3.3 70B  (or Anthropic Claude)
                  ↓
          Coral CLI  (coral sql ...)
                  ↓
   github · linear · sentry · slack · slack_messages · devto
   bundled  bundled  bundled  bundled     custom        custom

The agent detects which LLM you have at startup — GROQ_API_KEY set means Groq, ANTHROPIC_API_KEY means Anthropic, neither means a deterministic stub that still renders the dashboard correctly so you can demo without any credits. The header shows a coloured pill — "Groq · Llama 3.3 70B" or "Anthropic · Claude Sonnet" — so you always know which model answered.

The web layer is Flask plus a single HTML file. No CDN. No build step. No framework. The whole dashboard — HTML, CSS, JavaScript, the SVG score gauge — is one file you can grep. In a 4-day solo project that was the right call and I'd make it again.

The key SQL queries

Release blockers:

SELECT s.title, s.level, s.count, s.first_seen, s.project
FROM sentry.issues s
WHERE s.status = 'unresolved'
  AND s.level IN ('fatal', 'error')
ORDER BY
  CASE s.level WHEN 'fatal' THEN 0 WHEN 'error' THEN 1 END,
  s.count DESC
LIMIT 20;

Release readiness — Linear vs GitHub:

SELECT
  l.identifier,
  l.title,
  l.state_name,
  p.number    AS pr,
  p.state     AS pr_state,
  p.merged_at
FROM linear.issues l
LEFT JOIN github.pulls p
  ON p.owner = 'your-org'
  AND p.repo  = 'your-repo'
  AND lower(p.title) LIKE '%' || lower(l.identifier) || '%'
WHERE l.state_name IN ('In Progress', 'In Review', 'Done', 'Todo')
ORDER BY l.priority, l.state_name
LIMIT 25;

A LEFT JOIN from Linear into GitHub is exactly the right shape for "is everything that's planned actually shipped?" If the PR column is null on a Done ticket, that's a risk worth surfacing before you press deploy.

Team signals from Slack:

SELECT m.text, m.ts, m.user
FROM slack_messages.messages m
WHERE m.channel = 'YOUR_CHANNEL_ID'
  AND (
    lower(m.text) LIKE '%release%'
    OR lower(m.text) LIKE '%deploy%'
    OR lower(m.text) LIKE '%blocker%'
    OR lower(m.text) LIKE '%broken%'
  )
ORDER BY m.ts DESC
LIMIT 25;

I'll come back to why this query needed a custom source spec.

The cross-source JOIN that made it feel real

This is the risk assessment query. The one that made me think the project was actually worth something.

SELECT
  p.title       AS pr,
  p.merged_at,
  p.user__login AS author,
  s.title       AS error_after_merge,
  s.level,
  s.count
FROM github.pulls p
JOIN sentry.issues s
  ON CAST(s.first_seen AS TIMESTAMP) >= CAST(p.merged_at AS TIMESTAMP)
  AND CAST(s.first_seen AS TIMESTAMP) <=
      CAST(p.merged_at AS TIMESTAMP) + INTERVAL '7 days'
  AND s.level IN ('fatal', 'error')
WHERE p.owner = 'withcoral'
  AND p.repo   = 'coral'
  AND p.state  = 'closed'
  AND p.merged_at IS NOT NULL
  AND CAST(p.merged_at AS TIMESTAMP) >= current_timestamp - INTERVAL '30 days'
ORDER BY p.merged_at DESC
LIMIT 20;

This returned 20 real rows on the first run against the withcoral/coral repo. Every recent PR, cross-referenced with the Sentry errors that first appeared within seven days of that PR merging.

When I saw a community source PR correlated with an AttributeError that appeared one day later, I realised: this isn't ShipMind-specific. This is a pattern every team can run against their own repo tomorrow. The query is completely generic. The JOIN is the feature.

In normal Python this would be 30+ lines of pagination, timestamp parsing, and rate-limit handling across two separate API clients. Here it's 18 lines of SQL.

Three things I learned about Coral the hard way

1. Table functions are not tables

The bundled Slack source has slack.channels and slack.users as plain tables — but messages live in a table function: slack.messages(channel => 'C0...'). I checked coral.tables on day one, saw no messages table, and nearly dropped Slack from the project entirely.

The fix was running SELECT * FROM coral.table_functions too. The deeper fix was writing a slack_messages custom source spec so I could write WHERE channel = '...' like any other table. Much cleaner SQL and the LLM generates it correctly on the first attempt.

2. Column names don't match the API docs

Linear's GraphQL returns state.name. Coral exposes it as state_name (single underscore). GitHub's REST returns user.login. Coral exposes it as user__login (double underscore — nested field separator). Every query I wrote on day two failed on the first run because I used the API field names.

The fix every time was:

SELECT column_name, data_type
FROM coral.columns
WHERE schema_name = 'linear'
  AND table_name  = 'issues';

After the third time I created a CORAL_CONTEXT constant in agent/config.py listing the canonical column names for every source and injected it into every LLM system prompt. Claude and Llama now generate correct Coral SQL on the first try.

3. LIMIT is not pushed down to the API

When I queried devto.articles WHERE username = 'ben' LIMIT 5, Coral fetched every article Ben has published — over 3,000 — and then took the first five locally. My source spec had max_pages: 50 set, which was not enough and the query failed hard.

The fix was bumping per_page from 30 to 1000 so a typical user's full feed fits in a single fetch. Every source author needs to think about this tradeoff when choosing between page-mode and cursor-mode pagination. Cursor-mode with a first parameter handles large datasets much more cleanly and should be the default for anything that could have hundreds of pages.

Writing the custom sources

I wrote two source specs as part of this project.

slack_messages — wraps Slack's conversations.history endpoint so messages become a regular filterable table instead of a table function call. Purely internal to ShipMind but it makes the SQL uniform across all five queries.

devto — exposes the dev.to (Forem) public API as two tables: devto.articles and devto.tags. Auth is a single api-key header, no OAuth. Submitted as a community contribution:

🔗 PR: withcoral/coral #1067 — feat(sources/community/devto): add dev.to source

Writing a source spec taught me something useful: it's just a YAML file that names a table, points at an HTTP path, declares auth, and maps response fields to typed columns. The hardest part isn't the YAML syntax — Coral's linter is friendly and tells you exactly what's wrong. The hardest part is discovering the actual field shapes. I ended up reading the source manifest JSON schema directly and everything clicked after that.

How to run it yourself

Clone and install

git clone https://github.com/Jeetubhati/shipmind
cd shipmind
python -m venv venv

Activate the virtualenv

On Windows PowerShell:

.\venv\Scripts\Activate.ps1

On macOS or Linux:

source venv/bin/activate

Then install dependencies:

pip install -r requirements.txt

Connect the four Coral sources

export GITHUB_TOKEN=ghp_...
export LINEAR_API_KEY=lin_api_...
export SENTRY_AUTH_TOKEN=sntryu_...
export SENTRY_ORG_SLUG=your-org-slug
export SLACK_TOKEN=xoxb-...

coral source add github
coral source add linear
coral source add --interactive sentry
coral source add --interactive slack
coral source add --file sources/slack_messages/slack_messages.yaml

Configure the agent

cp .env.example .env

Open .env and add one LLM key:

GROQ_API_KEY=gsk_...        # free at console.groq.com — recommended for speed
ANTHROPIC_API_KEY=sk-...    # alternative if you have Claude credits

Add your project identifiers too:

GITHUB_ORG=your-org
GITHUB_REPO=your-repo
SENTRY_ORG_SLUG=your-org-slug
SLACK_CHANNEL_ID=C0XXXXXXXXX

Start the dashboard

python web/app.py

Open http://localhost:5000 and click Run Full Release Check.

The README has a complete walkthrough including how to seed demo data if you're setting up fresh accounts.

What I'd build next

PagerDuty integration. Sentry tells you what's broken. PagerDuty tells you what's actively paging right now. That's a different urgency signal and the same JOIN pattern applies directly.

Push-down filter contribution upstream. Coral's GitHub source doesn't currently push WHERE state = 'closed' down to the GitHub API, so on a repo with 500+ PRs it fetches everything before filtering locally. Fixing that on the bundled source would speed up the readiness query for every Coral user, not just ShipMind.

Slack digest on cron. Run the full check on a schedule, post the verdict as a Slack thread 30 minutes before every planned deploy window. That's roughly 20 extra lines of Python.

The thing I'll actually remember

I spent day one worrying about the LLM prompts. Day two worrying about the dashboard layout. The thing that made the demo land was a single SQL query where GitHub and Sentry answered one question together — "show me the PRs and the errors they caused" — and returned real rows in 30 seconds without me writing a single API client.

Everything else in ShipMind is in service of that query.

The JOIN is the feature.

Links

🚢 GitHub: github.com/Jeetubhati/shipmind
🪸 Coral: withcoral.com
🏴‍☠️ Hackathon: Pirates of the Coral-bean — WeMakeDevs
🐠 dev.to source spec PR: withcoral/coral #1067

Jitendra Bhati · Built solo for Pirates of the Coral-bean · Track 1: Enterprise Agent · May 2026

DEV Community: jitendra bhati