How I Coral: Analysing project progress across Linear and Slack

Most engineering managers I’ve worked with (myself included) ask themselves the same question once a week: how close are we to the finish line? Often it’s prompted by a Linear ticket that’s been hanging around longer than expected. More likely, the question pops up before a leadership meeting, when you have to take a more structured view. Roughly how close are we to done, and what’s actually left?

I took this question to Coral the other day. The project, fittingly, was the Coral launch. I asked Claude Code, via Coral, for a snapshot of the Linear project, and it duly gave me the breakdown.

coral - Run SQL (MCP)(sql: "SELECT i.identifier, i.title, i.state_name,
       p.number as pr_number, p.title as pr_title,
       p.state as pr_state, p.draft as pr_draft, p.merged_at,
       p.html_url as pr_url
FROM linear.issues i
LEFT JOIN linear.attachments a
  ON i.id = a.issue_id AND a.source_type = 'github'
LEFT JOIN github.pulls p
  ON p.html_url = a.url
  AND p.owner = 'withcoral' AND p.repo = 'coral' AND p.state = 'all'
WHERE i.project_id = 'f95eef97-b0fb-455d-bc19-30362c0c930b'
  AND i.completed_at IS NULL
  AND i.state_name NOT IN ('Canceled', 'Duplicate')
ORDER BY i.identifier")

{
  "rows": [
    { "identifier": "GROWTH-28",  "title": "Launch video",                                   "state_name": "Backlog" },
    { "identifier": "SOURCE-346", "title": "Add CLA",                                        "state_name": "In Progress" },
    { "identifier": "SOURCE-353", "title": "Coral is not chosen unless explicitly requested","state_name": "Todo" },
    { "identifier": "SOURCE-356", "title": "Handle oversized SQL introspection output better","state_name": "Backlog" },
    { "identifier": "SOURCE-358", "title": "GitHub: Improve handling of secondary rate limits",
      "state_name": "In Review", "pr_number": 91,
      "pr_title": "fix(spec): handle 403 rate limits & improve GitHub search table guides",
      "pr_state": "closed", "pr_draft": false,
      "merged_at": "2026-04-15T16:12:32Z",
      "pr_url": "https://github.com/withcoral/coral/pull/91" }
  ]
}

Coral returned a table joining 21 open issues against any GitHub PRs linked from Linear attachments:

Issue	Title	Linear State	PR	PR State
GROWTH-28	Launch video	Backlog	–	–
SOURCE-346	Add CLA	In Progress	–	–
SOURCE-353	Coral is not chosen unless explicitly requested	Todo	–	–
SOURCE-356	Handle oversized SQL introspection output better	Backlog	–	–
SOURCE-358	GitHub: Improve handling of secondary rate limits	In Review	#91	Merged (Apr 15)
SOURCE-398	Update pricing page with latest text and calculator	In Progress	–	–
SOURCE-402	Prepare menu of social comments for announcement	Todo	–	–
SOURCE-403	Get AWS Cloudwatch source live and tested	Todo	–	–
SOURCE-404	Write brief release notes post for launch	Todo	–	–
SOURCE-411	Update LinkedIn	Todo	–	–
SOURCE-412	Replace dummy blog posts with launch versions	Todo	–	–
SOURCE-417	Benchmarks page on withcoral.com returns 404	Todo	–	–
SOURCE-418	Add a custom 404 & 500 page	Todo	–	–
SOURCE-419	Fix company logos in carousel	Todo	–	–
SOURCE-421	Fine tune responsiveness of the website	Todo	–	–
SOURCE-422	Support querying Linear project milestones in Coral	Backlog	–	–
SOURCE-423	Support one-click MCP installation for Coral	Backlog	–	–

Notable: SOURCE-358 is still marked “In Review” in Linear but its PR was actually merged on April 15 — looks like it needs to be closed out.

Useful stats, but to be honest I was more interested in where the issues were coming from as we sprinted towards launch, so that was my follow up question. I asked: which of the open issues originated in Slack, and in which channels? Coral joined linear.issues against linear.attachments (Linear stores external links — Slack URLs, GitHub PRs — as attachments on an issue), matched the Slack channel names, and came back with a grouped breakdown. 12 of our 21 open issues originated from Slack, the bulk of them from a single #coral-website planning thread a teammate ran.

Got the channel names. Here are all the open issues that originated from Slack:

#coral (3 issues)
 - Handle oversized SQL introspection output better      (Backlog)
 - Support one-click MCP installation for Coral          (Backlog)
 - GitHub: Improve handling of secondary rate limits     (In Review)
 - Coral is not chosen unless explicitly requested       (Todo)

#coral-feedback (2 issues)
 - Support querying Linear project milestones in Coral   (Backlog)
 - Benchmarks page on withcoral.com returns 404          (Todo)

#coral-website (6 issues)
 - Update pricing page with latest text and calculator   (In Progress)
 - Prepare menu of social comments for announcement      (Todo)
 - Replace dummy blog posts with launch versions         (Todo)
 - Review video script and clips                         (Todo)
 - Get AWS CloudWatch source live and tested             (Todo)
 - Write brief release notes post for launch             (Todo)

12 of the 21 open issues came from Slack — the bulk from #coral-website,
likely from a single planning thread by matt.

Last question, and the one that was the most insightful: of those 21 open issues, how many had a pull request attached? I’d have guessed about half — a rough proxy for work already in flight. The answer was one. The 47% still to go wasn’t half-written code waiting to be reviewed. It was mostly still on paper, important context when staring at a progress bar and wondering what the cost to complete is.

> How many of the open issues have PRs attached? Show me the current status of those attached PRs.

Called coral (ctrl+o to expand)

● Only one open issue has a PR attached. Let me pull its current status from GitHub.

Called coral 10 times (ctrl+o to expand)

● That's the full picture. Only 1 open issue has a PR attached — and it tells an interesting story:

  "GitHub: Improve handling of secondary rate limits"  (Linear status: In Review)
  - PR #91: fix(spec): handle 403 rate limits & improve GitHub search table guides
  - Author: iaptsiauri
  - PR is already merged — closed on April 15th

  The Linear issue is still marked "In Review" but the PR has been merged. It looks
  like the issue just needs to be moved to Done. The other 20 open issues have no
  PRs attached at all.

✻ Sautéed for 1m 4s

Why SQL beat three MCPs here

The query that pulled this together was a three-way join across linear.issues, linear.attachments, and github.pulls. You can’t really join Linear and GitHub given they are two different data sources (obviously). Without Coral, if I’d wired up a Linear MCP and a GitHub MCP side by side, Claude would have pulled loads of rows from Linear, loads from GitHub, and correlated them in its own context, burning tokens on data it was going to throw away after one comparison. Coral does the join outside the context window. What Claude actually sees is the SQL and the rows that came back.

Honest caveat: you could have gotten to the same answer without Coral. Any stack with access to those three sources could. The difference is efficiency, and it matters more than you’d think even now that context windows are a million tokens wide. Having a bigger window doesn’t mean it’s a good idea to fill it. Models still get overwhelmed and wander off when you pack them with data they don’t need. Keeping context small is still a virtue.

More broadly I like that SQL is familiar, the query is readable, and you can see exactly what the agent did and didn’t pull into context.

What using Coral taught me about building it

One thing I’ve noticed using Coral as a user rather than building it: sources with very large API surfaces are a context problem of their own. When the agent asks Coral “what can I do with GitHub?”, the answer is hundreds of tables — which is the opposite of the efficiency we just celebrated. For sources like this, we’re leaning towards breaking them up (e.g. allowing opt-in to tables you care about rather than everything GitHub exposes). We’re working on this — more to come soon!