Integrations and repository workflows

Most decisions aren't made in an editor. They're made in a pull request thread, a Slack channel, or a Jira comment. Connecting those makes them searchable with everything else.

What connects

Connect from the dashboard. Each workspace connects to its own accounts.

GitHub

Use GitHub for two related jobs. Its connected knowledge makes repositories and issues searchable alongside your project history. Its repository connection also supports the operational detail an agent needs for pull requests: diffs, review comments, commits, checks, branches, and notifications.

The connected GitHub account remains the permission boundary. A private repository appears only when that account can read it, and writes such as reviews, comments, merges, or issue changes still use that account's access.

GitLab and Bitbucket are available through the repository connection layer, even though they are not values in the six-provider integration list.

Repository workflows

The repository connection goes beyond bringing code into search.

Repositories and indexing

List and inspect connected repositories, sync one, change its sync settings, link or import it into a ContextStream project, start repository ingest, and follow ingest status. Deleting a repository connection is different from removing a local project mapping; verify which boundary you intend to change.

Pull requests and reviews

Read the pull request, diff, comments, commits, and checks. Get or generate a summary, leave a comment, submit an approval or change request with inline comments, and merge with the provider's supported merge strategy when the user has authorized that write.

Reading a review is normal retrieval. Commenting, approving, requesting changes, or merging changes the external repository and should remain an explicit request.

Issues

List and read issues and their comments, create or update an issue, and add a comment. Labels and assignees follow the connected provider. A repository issue remains an external system-of-record even when ContextStream links it to a plan, document, decision, or project.

Commits, refs, and files

Inspect commit history and diffs, compare two refs, list branches and tags, walk a repository tree, read a file at a specific ref, and search code across linked repositories. This is useful when the relevant evidence is not in the current local checkout.

Activity, notifications, and automation

Read repository activity and notifications, mark one or all notifications read, create links between repository objects and ContextStream records, and manage supported automations and webhooks.

Links are indexed relationships, not arbitrary URLs pasted into a record. They let a pull request, issue, commit, plan, task, document, decision, or other supported record stay connected without copying its contents.

Slack

Slack contributes channels, threaded discussions, and user mappings. Connect the channels where decisions happen, not every conversational channel in a large workspace. Search can find matching messages; discussion retrieval keeps the thread and replies together so the answer does not quote one message without its context.

Private-channel visibility follows the connected Slack account. User sync keeps names and participants aligned when the workspace membership changes.

Notion

Notion supports pages and databases, including typed pages for tasks, meetings, wikis, bug reports, features, journals, and general notes. Your assistant can search and read pages, query databases, and — when you ask for a write — create or update pages and create databases.

For writes, name the intended parent page or database. Similar page titles are not a safe target-selection rule.

Linear and Jira

Both connect issue work without requiring you to recreate it as a native ContextStream ticket. Linear can narrow issues by team, state, priority, assignee, and whether a due date exists. Jira adds project key and issue type to the equivalent filters.

Use the native issue tracker when it is already your system of record. Use a ContextStream ticket for work born inside an agent session that needs a lightweight record and attached project context.

Figma

Figma brings design files into search and summaries. Results can be narrowed to a Figma project or addressed by file key. This connection supplies design knowledge; it does not turn ContextStream into a Figma file editor.

What it changes

The one that earns its keep is the first. Pull request review comments are where a lot of a codebase's reasoning lives, and they're effectively unsearchable in the normal course of things.

Follow one decision across the services where it happened

Suppose a cache was proposed, rejected, and then raised again six months later. Ask why it was rejected. A complete investigation may find:

• the pull request comment that identified stale authorization results;
• the Slack thread where support described the customer-visible failure;
• the Jira issue that measured the affected accounts;
• the Figma file showing that the interface needed immediate permission changes rather than delayed consistency;
• the current source and decision that implemented the alternative.

The answer should preserve those source boundaries and dates. A Jira issue can show impact; it does not prove the architecture. A Slack message can explain the concern; it may have been superseded by the merged pull request. A Figma file supplies design intent, not production behavior.

Once the evidence is confirmed, save a focused decision in ContextStream so the next person gets the reasoning without repeating the whole cross-provider investigation. Link the source records instead of copying their full contents.

Reading this history is different from acting on it. Leaving a review, requesting changes, commenting on an issue, merging a pull request, or updating a Notion page changes the connected service and should happen only when you ask for that write explicitly.

Keep using the services you already use

This doesn't replace GitHub or Jira. Keep working where you already work; the content becomes searchable alongside your code and decisions. Nobody has to change habits for it to pay off.

Choosing what to connect

Connect the noisy-but-valuable sources: pull requests, and the two or three channels where decisions actually get made. Connecting every channel in a large Slack adds more noise than signal.

For team accounts, cross-provider search and activity views combine only the records the caller can already access. Team mode changes scope; it does not override GitHub, Slack, Notion, Linear, Jira, or Figma permissions.

ChatGPT is a connected client, not one of these content providers. See ChatGPT and desktop apps.

Integration search and team views

The unified provider layer can check connection status, search, report statistics and activity, identify contributors, summarize provider knowledge, list channels or discussions, synchronize users, and show connected files or repositories. Team-wide search and activity still filter to what the caller is allowed to access.

If it doesn't work

Nothing appeared after connecting. The first sync takes a while for a large account. Check the integration's status in the dashboard.

Too much irrelevant content. Narrow which repositories or channels sync.

A private repository isn't listed. The connected account lacks access to it. Reconnect with the right permissions.

A write is rejected while reads work. The connected account may have read-only provider permission, the branch may be protected, or the requested review/merge action may require a different role.

Repository search and local search disagree. They may be looking at different refs or index times. Name the branch, tag, or commit you intend to inspect.

I need the exact provider/action matrix. See the integration action reference. It also explains when to use the repository-native surface instead.

Next

• Search
• Tickets and operational tracking
• Integration action reference