Klyr integrations: how evidence reaches the tools you already build in

Most of what people call an integration is really a handoff. Klyr is opinionated about that handoff: every theme links to a verified source quote, themes under two citations auto-drop, and the ranked Feature Bet you act on carries its evidence with it. When you generate a Build Pack (PRD summary, acceptance criteria, implementation tasks, the evidence citations, and a coding-agent prompt), that context is what flows out to your stack.

Two directions matter. On the way in, imports bring product data and existing tasks into the evidence graph. On the way out, Build Packs produce payloads formatted per destination so the citation chain (quote to theme to Feature Bet to Build Pack) survives the trip. The point of view is simple: your coding agent forgets, and Klyr is the memory it loses. See the full loop on proof.

For coding agents, the integration is the Build Pack itself. Each Build Pack includes a coding-agent prompt and a copyable Klyr context pack: the problem, acceptance criteria, suggested files, edge cases, a test plan, and the evidence behind the bet. You copy it into Cursor or Claude Code and the agent starts from cited intent instead of a one-line ticket.

This is copy-ready today, and deliberately so. A prompt you paste works in any agent and any editor with zero credentials and nothing to break. The deeper play is the read-only agent-context API below, which lets an agent pull the same state continuously rather than from a single paste.

From a Build Pack or a task, Klyr produces issue payloads formatted for GitHub, Linear, Jira, and Notion, each carrying the evidence-backed brief and acceptance criteria. Be clear on the line between native creation and copy-ready payloads, because it is exactly as the product behaves today.

Native issue creation runs for GitHub and Linear when server-side credentials are configured (a GitHub token plus owner and repo, or a Linear API key plus team). With those set, Klyr creates the issue and returns the live URL. Without them, the same push returns a prepared payload instead of failing, so you copy it across by hand. Jira and Notion are payload-only today: Klyr formats the issue for them, but native creation waits on OAuth. Treat anything beyond GitHub and Linear as copy-ready until that connection exists.

Slack and email are copy-ready payload targets, not automated senders. Klyr formats a clean, evidence-backed summary you can drop into a channel or a message: the bet, the acceptance criteria, and the citations that justify it. Nothing posts on your behalf, which keeps the human in the loop where a recommendation is being socialized.

This fits how decisions actually move. The Decision Room and Spec Quality Gate keep weak specs in draft inside Klyr; Slack and email are how the approved version travels to the people who were not in the workspace.

Imports are the inbound half of Klyr integrations, and they are native today. Product data comes in as CSV: usage exports, support tickets, survey results, anything that can support or refute a bet, with a summary and column mapping captured so it lives in the evidence graph rather than a side spreadsheet.

Task imports run through the Migration Center with editable field mapping and a preview before anything is created. CSV is the universal path, and the importer also recognizes exports from Jira, Linear, Trello, Asana, and ClickUp so existing work lands as tasks you can tie back to evidence. Details and field-mapping notes live in the docs.

Every project exposes a read-only, machine-readable context endpoint. An authenticated agent can GET the project's Feature Bets, Build Packs, current tasks, PRDs, opportunity plans, and the evidence graph (memory links, outcome reviews, data imports) as structured JSON, with explicit guardrails: treat it as planning context, keep citations attached, and ask for human review before mutating anything.

Read-only is intentional. The endpoint cannot change tasks, docs, or production data, which makes it safe to point an agent at. The direction is MCP: wrapping this same endpoint as a Model Context Protocol server so Cursor and Claude Code can pull live, evidence-backed product context as a native tool instead of a paste. The endpoint and the persistent graph behind it are the real moat. Cited synthesis is table stakes; the loop and the memory it leaves are not.