Integrate Spark with GitHub repositories to enable codebase analysis

Codebase analysis lets you ask Spark plain-language questions about how your product actually works, with answers sourced directly from your production code via GitHub integration. It also lets Spark read your codebase on its own, which helps it generate high-quality product specifications based on your current implementation.

Instead of waiting on an engineer to explain a feature's behavior, you can ask Spark something like "What are the file upload limits?" and get an accurate, code-grounded answer in seconds. And when writing a spec, Spark no longer has to ask you about your current product; it just goes and looks for itself.

This article covers how to connect and manage the integration, how indexing and question answering work behind the scenes, what codebase analysis can and can't help with, and how Productboard handles security for your code.

Note: Only GitHub is supported at this time. GitLab, Bitbucket, and other repository hosts are not currently supported.

In this article:

• What is codebase analysis?
  • Scope of access
• Setup and permissions
  • Role requirements in Productboard and GitHub
  • Connecting the integration
• How indexing works
  • The indexing process
  • Automatic re-indexing
  • Manual index management
  • Which branch is indexed?
• What codebase analysis can answer
• What codebase analysis cannot answer
• Getting the best results
• Security and data privacy
  • Workspace isolation
  • Secret redaction
  • Access control
  • Data removal
• Known limitations
• FAQ
• See also

What is codebase analysis?

Codebase analysis 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 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.

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
• Write product specifications with Spark
• Prompt library for common Spark use cases