Blueprint

Turn any Slack discussion into an approved, cited PRD and real tickets — without leaving Slack. Grounded by Real-Time Search + GitHub MCP; nothing ships without a human.

Comment

Inspiration

Every software team knows the gap between "we discussed it" and "it's in the tracker." After a good feature discussion, someone re-reads the whole thread, writes the PRD, chases sign-off, files the tickets, and links everything back. It's hours of glue work per feature — and the details that made the discussion valuable (the exact decision, the constraint someone mentioned, the question nobody answered) are the first things lost. Blueprint closes that gap where the discussion already happens: in Slack.

What it does

Blueprint turns a real team discussion into shipped, accountable work — in one thread:

  1. Invoke it on a discussion — an @Blueprint mention in the thread (also: a "Draft PRD from thread" message shortcut, /prd, or DM).
  2. It reads the whole thread and streams its progress as it works.
  3. Structured requirements, honestly extracted — every requirement carries a verbatim evidence quote from the discussion and a priority the team actually agreed on. Critically, Open Questions are surfaced, not invented: if the team didn't decide something, Blueprint says so instead of guessing.
  4. A dual-grounded PRD with clickable citations — two kinds of truth:
    • Your workspace's memory, via Slack's Real-Time Search API (assistant.search.context): related past decisions, cited with permalinks — e.g. [S1] #eng-decisions — the SendGrid decision. Permission-aware, real-time; this grounding simply cannot be built without it.
    • Your actual codebase, via the GitHub MCP server: real files by name — e.g. [G2] api/src/services/metering.ts — retrieved over the open MCP standard. Citation labels are reconciled against the source that actually served them; a "via Real-Time Search" label can't be hallucinated.
  5. The PRD lives on a Slack canvas in the channel — a native, versioned document, not an export to another tool.
  6. A durable human approval gate — Approve / Request changes buttons on the PRD. Feedback regenerates it (v2, v3…); the decision is recorded — who, when, what changed. The pipeline pauses durably (a LangGraph interrupt() behind a checkpointer): it survives restarts and waits days if it has to. Nothing is created until a human signs off.
  7. Approved means done — Blueprint decomposes the PRD into an epic + stories with acceptance criteria, creates them as real GitHub Issues (a Jira adapter ships behind the same tracker interface), posts the links back to the thread, and adds a live ticket table to the canvas.
  8. A full audit trail in App Home — for every run: what was searched, which sources were cited, every PRD version, who approved, which tickets were created. Quote → requirement → PRD → ticket: everything traces.

How we built it

  • Slack surfaces: Bolt for Python (async) over Socket Mode; the agent Messages tab with suggested prompts; streamed status; Block Kit everywhere (requirements card, approval card + feedback modal, App Home dashboard); the Canvas API for the PRD.
  • Real-Time Search: grounding queries are fired with the action_token captured from the triggering mention — results are used ephemerally and cited by permalink.
  • MCP: the agent is an MCP client to GitHub's remote MCP server — search_code + get_file_contents for grounding, issue_write for output. One open standard covers read and write, with a REST fallback behind the same interface.
  • Pipeline: LangGraph with a durable checkpointer — human review is a first-class interrupt(); the Approve button resumes the paused graph, and "request changes" loops back to regeneration with the reviewer's feedback.
  • LLM: Claude with schema-validated structured outputs at every step (requirements, PRD, decomposition are Pydantic contracts), and anti-hallucination prompts: "if a detail is not grounded, put it under Open Questions."

Challenges we ran into

Offline tests were green the whole time. Live verification kept catching things that would have failed on camera:

  • The RTS action_token is picky. We empirically mapped which triggers carry one (the @mention and DM do; the message shortcut and slash command don't) and found it expires within minutes. That shaped the architecture: grounding runs as the third pipeline node — seconds after the trigger — and the regenerate loop never needs to re-search.
  • Anthropic's constrained decoding rejected our PRD schema ("Schema is too complex") — the nested requirements/citations structure exceeded the grammar compiler. Fix: a permanent JSON-mode fallback — schema-in-prompt, parse, validate by hand, retry once.
  • The MCP server's get_file_contents returns a status line plus an embedded resource — naïvely reading the first text block feeds the model "successfully downloaded text file" instead of code. Caught live, parsed properly.
  • GitHub code search can't see a freshly pushed repo (index lag), so we added curated grounding paths — hand-picked citation targets that are fetched directly and always survive the ranking cap.
  • Slack's canvas API 400s on angle-bracket autolinks with query strings — which every Slack permalink has. One markdown-link change away from the demo's centerpiece silently not rendering.

Accomplishments we're proud of

  • The full governed chain live, end-to-end, in one thread: discussion → evidence-quoted requirements → cited PRD → human gate → real GitHub issues → links back.
  • Citations you can click — [S1] opens the actual past decision in Slack; [G2] opens the actual file on GitHub — with via labels that reflect the source that really served them.
  • Honesty as a feature: the question the team never answered is flagged, never answered for them.
  • An approval gate with memory: the run pauses durably and resumes from a button click, even across process restarts.

What we learned

  • Platform truth beats docs: the RTS trigger matrix, the MCP content shape, and the canvas markdown dialect were all discoverable only by running against the real APIs. Smoke-test the live path early; offline green means little.
  • Trust is a product feature, not a model feature. Evidence quotes, clickable citations, honest open questions, and a human gate did more for credibility than any prompt tuning.

What's next for Blueprint

  • Role-aware review chains: per-channel BA/eng-lead/QA config, approvals routed to the right person, role-based App Home queues.
  • More trackers over MCP (Jira/Linear MCP servers) — same open standard, zero bespoke integrations.
  • Handoff to coding agents: an approved, grounded, cited ticket is exactly the input a coding agent needs — "from conversation to shipped work" ends with code.

Testing instructions (for judges)

Sandbox: https://e0bgjs10w6a-14d60t93.slack.com — [email protected] and [email protected] are invited as Members.

60-second happy path:

  1. Open #feat-billing-alerts — a real feature discussion is seeded there.
  2. In the thread, reply @Blueprint draft a PRD from this thread.
  3. Watch the streamed status → the requirements card (note the evidence quotes and the flagged open question) → the canvas PRD (open the Sources section: [S1] links to the original #eng-decisions message, [G*] to real files on GitHub).
  4. Click Request changes, type any instruction (e.g. "make forecast alerts out of scope"), watch v2 regenerate — then Approve.
  5. The epic + stories appear as real GitHub issues, links post back to the thread, and the canvas gains a ticket table.
  6. Open the app's Home tab for the run's full audit trail.

Try it cold: DM the app "hi" — it orients you and points to the seeded thread. It never creates anything without your approval.

Required technologies used

  • Real-Time Search API — workspace-memory grounding with citations (core; irreplaceable)
  • MCP server integration — GitHub MCP for code grounding and ticket creation (open standard, read + write)
  • Slack AI / agent surfaces — agent Messages tab, streamed status, Block Kit + Canvas UX

Built With

Share this project:

Updates

Submission history