Analyze your codebase with Spark

Codebase analysis connects your code repositories to Spark so it can read your production code and answer questions about how your product behaves. It works with repositories on GitHub, GitLab, Bitbucket, and Azure DevOps.

This article covers setup, indexing, security, and what codebase analysis can and can't answer.

Note: To query live GitHub data such as open pull requests or CI status, use the separate GitHub MCP connector instead.

In this article:

• What codebase analysis is
• Scope of access
• Setup and permissions
  • Role requirements
  • Connecting the codebase
• How indexing works
• What codebase analysis can answer
• What codebase analysis cannot answer
• Getting the best results
• Security and data privacy
• Known limitations
• FAQ
• See also

What codebase analysis is

Codebase analysis connects one or more 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.

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

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

• Productboard: Admin or maker.
• Codebase: Organization admin (or equivalent).

If you lack the proper codebase permissions when you attempt to set up the integration, that's alright; a user with the proper permissions will be notified and can complete the process for you.

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 codebase

To set up the codebase integration:

1. From the Main menu, click Settings > Integrations > Spark sources and select the codebase you wish to integrate with.

   Note: Some codebase platforms (Like GitHub and ADO) have multiple different integrations with Productboard. Make sure you select the one labeled "Spark" or you'll be very confused in a minute. 

   
    

2. Click Connect.
   
   
    
3. You'll be redirected to the chosen codebase. Select which organization you want to connect to, if applicable. 
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.

Once you've set up at least one connection, the integration 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 and select your integration.
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 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. Codebase integrations use 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