Integrate GitHub with Spark

Spark has two distinct integrations with GitHub:

• The GitHub MCP connector lets you query live GitHub data (open pull requests, CI/CD status, issue queues, and more) directly in Spark chat. 
• The GitHub codebase integration connects one or more of your repositories to Spark so it can read your production code and answer questions about how your product actually behaves.

Each integration is activated separately and serves a different purpose. We recommend activating both to achieve the best synergy between Spark and GitHub. 

This article describes the setup and behaviors for both Spark-related GitHub integrations.

Note: There's a third GitHub integration that has nothing to do with Spark, called the GitHub Issues integration, which is specifically for pushing features from Productboard into GitHub as issues. This article is not about that integration. 

In this article:

• Choosing the right GitHub tool
• GitHub MCP connector
  • What it is
  • Connecting the GitHub MCP connector
  • Using the GitHub MCP connector
  • GitHub MCP behaviors
• Codebase analysis
  • What it is
  • Scope of access
  • Setup and permissions
  • How indexing works
  • What codebase analysis can answer
  • What it can't answer
  • Getting the best results
  • Security and data privacy
  • Known limitations
• FAQ
• See also

Differences between these GitHub tools

Both integrations involve GitHub, but they answer different questions. Here's how to tell them apart:

If you have both tools set up, Spark will decide whether to use one or both depending on how your questions are worded. 

If you only have one or the other integration set up, Spark may struggle to answer certain questions. For example, if you only have the codebase integration set up, and you ask Spark about an open PR, it won't give you a good answer (because that question is better handled by the MCP connector.

GitHub MCP connector

What it is

The GitHub MCP connector makes GitHub queryable in plain language, directly in Spark. Instead of switching to GitHub to piece together the state of a repository, you can ask questions like "What PRs are open in this repo?", "Did CI pass on the last commit?", or "Which issues are assigned to me?" and get a direct answer in chat.

The connector is read-only: it surfaces the current state of GitHub objects but never creates, edits, or deletes anything. 

Note: The GitHub MCP connector only works with GitHub.com. GitHub Enterprise (self-hosted) support is planned as part of a future Custom Connectors capability.

Each user connects their own GitHub account through Spark settings, so the connector reflects that user's individual permissions. It only accesses repositories the user already has permission to view in GitHub; no elevated access is granted.

Connecting the GitHub MCP connector

To connect your GitHub account to Spark:

1. From any Spark chat, click Integrations > Add integrations and connectors.
   
   
    
2. Find GitHub in the connector list and click Connect.
   
   
    
3. You'll be redirected to GitHub to authorize Spark. Review the permissions and grant access. When finished, you'll be redirected back to Productboard.

The connection is tied to your GitHub account and is active across all your Spark chats. Other workspace members connect their own accounts separately.

Using the GitHub MCP connector

Once connected, ask Spark about GitHub in natural language. For best results, name GitHub explicitly in your prompt so Spark knows where to look:

• "What PRs are open in the productboard/platform repo?"
• "Did CI pass on the last commit to main?"
• "Which issues are assigned to me this week?"
• "What's the current status of PR #1234?"
• "Show me open issues labeled bug in the api repo."

Spark queries GitHub on your behalf and returns a structured answer in chat. You stay in your workflow; no tab-switching required.

If GitHub is unreachable or returns an error, Spark surfaces a clear message and suggests checking GitHub directly.

GitHub MCP behaviors

• Read-only. The connector never writes to GitHub — no issues created, no PR comments posted, no branches modified.
• GitHub.com only. GitHub Enterprise Server (self-hosted) is not currently supported.
• Personal scope. The connector uses your individual GitHub credentials. It can only access repositories you already have permission to view.
• Questions about how your code actually works, like its architecture, business logic, or permissions, are better answered by codebase analysis instead. If your workspace doesn't have that set up, such questions will likely return unsatisfactory results. 

GitHub codebase integration

What it is

The GitHub codebase integration connects one or more GitHub repositories to your Productboard workspace. Spark indexes those repositories and uses them as context whenever you ask a question about product behavior, business rules, constraints, permissions, or configuration.

Once a repository is connected, Spark draws on it automatically. You don't need to explicitly ask Spark to check the code; it decides on its own when codebase context will make a response more accurate.

This codebase analysis is especially useful when writing specs, as Spark can use what's already in your codebase to write better specifications using the spec writing skill. See Spark: Turn ideas into specs for details.

Scope of access

Setting up this integration grants Productboard read-only access to your repositories. Spark can read and analyze your code, but it cannot create branches, open pull requests, commit changes, or modify anything in your repositories. Read-only access keeps your codebase safe while giving Spark everything it needs to be genuinely useful.

Setup and permissions

Role requirements in Productboard and GitHub

Setting up and managing GitHub codebase analysis requires permissions afforded by the following roles:

• Productboard: Admin or maker.
• GitHub: Organization admin.

If you're a Productboard admin but not a GitHub organization admin, that's alright; an org admin will be notified during the setup phase.

Note: Productboard contributors and viewers can't manage repositories, but they can still use Spark and benefit from codebase-grounded answers as long as an admin or maker has already connected a repository. See Member role definitions for details.

Connecting the integration

To set up the GitHub integration for Spark codebase analysis:

1. From the Main menu, click Settings > Integrations > Spark sources > GitHub.

   Note: There are two different Productboard integrations for GitHub. Make sure you select the one labeled "Spark" or you'll be very confused in a minute. (The other one is for syncing issues.)

   
    

2. Click Connect GitHub organization.
   
   
    
3. You'll be redirected to GitHub. Select the GitHub organization you want to connect. *
4. Choose which repositories Productboard can access: all repositories in the organization, or only specific ones using the searchable dropdown. You must select at least one.
5. Review the permissions. Productboard requests read-only access to code and metadata only.
6. Click Install. You'll be redirected back to Productboard to complete setup.

* Note: If you're not a GitHub organization admin, you'll be given the option to send an installation request to one when you arrive in GitHub from Productboard's integrations page. Do this, then go ask your admin to approve it. You won't get a notification when it's approved, so check the integrations page in Productboard to confirm.

Once you've set up at least one connection, the GitHub integrations page will show all authorized and pending connections. You can click on a connection to manage it and its repositories.

How indexing works

The indexing process

When you connect a repository, Spark indexes its default branch and prepares the content for search. As part of this process, Spark automatically detects and redacts secrets, such as API keys, tokens, and passwords, before anything is stored. Files over 1 MB and non-product directories, such as dependency folders and test fixtures, are excluded. All indexed content is stored in an isolated, workspace-specific container, so data from different workspaces is never mixed.

Note: We don't charge you for indexing operations. You can index and re-index as much as you like.

Automatic re-indexing

Spark automatically re-indexes all connected repositories on a daily schedule. Each run is smart and incremental:

• Spark compares the current commit on the default branch against the last indexed commit.
• If nothing has changed, the re-index is skipped entirely.
• If changes are detected, only the modified files are re-processed, not the entire repository (an "incremental" index).
• If more than 300 files changed since the last index, Spark falls back to a full re-index.

Manual index management

If you're an admin or maker, you can trigger a manual re-index or pause the indexing of any connected repository at any time from settings like so:

1. From the Main menu, click Settings > Integrations > Spark sources > GitHub.
2. Click on the connection you want to manage.
   
   
    
3. Beside each repository in the connection, you'll see a toggle and a Reindex button. The toggle controls whether that repo is automatically indexed every day. Clicking Reindex will immediately begin reindexing for that repo.
   
   

Note: Disabling a repository is non-destructive. You can safely disable a repo without losing its indexing history or needing to start from scratch when you re-enable it.

Disabling a repo does not block Spark from accessing the most recent index of that repo, however. This can potentially cause Spark to return stale information if it pulls from a repo that hasn't been indexed in a while.

Which branch is indexed?

Only the repository's default branch (typically "main" or "master") is indexed. Feature branches, pull requests, and other branches aren't included.

What codebase analysis can answer

Codebase analysis excels at questions about product behavior as it's actually implemented, making it useful for both product managers and product-adjacent stakeholders.

The following question categories consistently produce strong results:

What codebase analysis cannot answer

Codebase analysis shows what the code does, not why decisions were made, what users do, or how infrastructure is managed. It won't produce useful answers for:

• Historical design decisions. Code shows what's implemented, not why a particular approach was chosen.
• User behavior and analytics. How users actually use the product is captured in analytics and telemetry, not source code. An MCP connection to something like Amplitude would work better.
• Infrastructure and DevOps specifics. Deployment pipelines, containerization, load balancing, and similar operational concerns are not analyzed unless they directly affect user-visible behavior.
• Test coverage and quality metrics. Test files are filtered out during indexing.
• Unreleased or in-progress features. Only the default branch is indexed, so code in feature branches or unmerged pull requests isn't available.
• Performance benchmarks. Response times, throughput, and latency figures aren't captured in source code.
• Live GitHub object state. Open PRs, CI results, and issue queues are real-time data that lives in GitHub, not your codebase. If you need to ask such questions, make sure the GitHub MCP connector for is enabled.

Getting the best results

• Be specific about the feature or workflow. "How does the invite workflow work?" gets a better answer than "How does user management work?"
• Focus on user-visible behavior. Ask what the user sees or experiences, not how the underlying system is built.
• Ask about constraints and limits. Code explicitly encodes limits, maximums, and validation rules, so these are among the most reliable things to look up.
• Ask about error cases. "What happens when X fails?" or "What errors can occur during Y?" tend to produce highly specific, useful answers.
• Combine related aspects in one question. "How are webhooks authenticated, and what data do they send?" is more efficient than two separate questions.

Security and data privacy

Workspace isolation

All indexed code is stored in a workspace-specific, isolated container. Every search and retrieval operation is automatically scoped to your workspace. Code from one workspace can never appear in another workspace's search results.

Secret redaction

Before any code is stored, Spark scans for secrets using pattern-matching rules covering API keys, authentication tokens, passwords, and connection strings across common providers. Detected secrets are replaced with [REDACTED] and are never written to the index.

Access control

Every request to codebase analysis carries your authenticated workspace ID and role. Management operations (connect, enable, disable, re-index) are gated to admin and maker roles. The GitHub integration uses OAuth, so Productboard never stores raw repository credentials.

Data removal

You can remove indexed code data at multiple levels: individual files, an entire repository, or all data associated with a workspace. Deletion operations are logged. When a workspace is deleted, all associated code data is removed with it.

Known limitations

• Codebase analysis is workspace-wide. You can't restrict certain members or teamspaces from using codebase analysis with Spark.
• Only the default branch is indexed. Branches in active development or unmerged pull requests aren't reflected until they're merged into the default branch and the daily re-index runs.
• Files over 1 MB are excluded. Very large files are skipped during indexing to avoid processing issues.

FAQ

See also

• Productboard Spark
• Connect external tools to Productboard Spark
• Context management in Spark
• Spark: Turn ideas into specs
• Prompt library for common Spark use cases