GitHub Value Stream

The GitHub Value Stream page builds a per-issue timeline of work — branches, commits, pull requests, reviews, and merges — and computes cycle-time metrics for each issue.

The spine of the analysis is a GitHub issue (owner/repo#N). Every Git activity whose payload references that issue (via Fixes #42, Closes owner/repo#42, or the implicit branch-name convention) is attached to the spine, sorted chronologically, and used to derive cycle metrics.

When to use it

You want a per-issue dev time / review wait / merge time breakdown for a focused set of issues.
You want to spot bottlenecks — long review-wait windows, gaps between commit and PR open, or PRs that linger after approval.
You’re producing a value-stream report for a slice of work (an epic, a release, a milestone) and need an LLM-friendly Markdown summary.

If most of your team’s work is tracked in Jira, prefer the Jira value-stream page — it already correlates GitHub activity (commits, PRs) back to Jira keys when they appear in branch names or PR titles.

Getting started

Navigate to Value Stream → GitHub in the sidebar. The GitHub data source must be configured.

Pick a repository from the dropdown. (If the configured token cannot list repositories, the dropdown becomes a free-text box so you can type an owner/repo slug by hand.)
Enter either issue numbers or a search query (see below).
Click Load to run the report, or Analyze with AI to run it and immediately generate a written analysis.

What you can type in the issue box

The box accepts two different kinds of input and decides which one you meant from what you typed — the same way the Issue Hierarchy search box does. There is no mode switch.

Mode 1 — issue numbers and keys

Used when every token you typed is a number or a repository-qualified key.

You type	Analyzes	Needs a repository selected?
`42`	issue 42 in the selected repository	yes
`#42`	same — the `#` is optional	yes
`42, 43`	issues 42 and 43	yes
`42 43`	same — spaces, commas, and newlines all separate	yes
`42 OR 43`	same — `OR` (any capitalization) is a separator too	yes
`group/proj#7`	issue 7 in `group/proj`, whatever is selected	no
`42 other/repo#7`	one issue from each — cross-repository in one report	yes, for the bare `42`

Duplicates are removed. Bare numbers are qualified with the selected repository, which is why they need one; a full owner/repo#N key carries its own. These are the same forms the Issue Hierarchy search box accepts.

Number mode applies no state filter — an issue you name explicitly is analyzed whatever state it is in.

Mode 2 — search qualifiers

Used for anything else. The text is run as a GitHub issue search against the selected repository, and every matching issue is analyzed. This is how you filter by state.

You type	Analyzes
`is:closed`	every closed issue in the repository
`is:open label:bug`	open issues labeled `bug`
`milestone:"Q2 hardening"`	everything in that milestone
`assignee:@me is:closed`	your closed issues
`author:some-user`	issues opened by that account

Full syntax and the complete qualifier list: GitHub’s issue search syntax. The same qualifiers are rejected here as on the hierarchy page — repo:, org:, user:, archived:, fork: — because they would move the search outside the repository you selected.

A repository must be selected in qualifier mode. Unlike a numeric key, a query has nothing to scope itself to; until you pick one, the box shows “Select a repository to search with qualifiers.” and Load stays disabled.

Rules that apply to both modes

Do not mix the two. 42 is:closed is rejected with an inline hint rather than guessed at. In a search query a bare 42 is a full-text term, and GitHub’s search indexes comment bodies — so it would silently match unrelated issues that merely mention “42”.
Qualifiers filter the matched set, not the context rows. Parents and sub-issues of a matched issue are added to the report regardless of their own state, so is:closed can still show an open parent. This is the same behavior as the Jira value stream, where JQL selects the issues and ancestor context is added on top.
Query results are capped at 100 issues, the most recently updated ones. When the cap is hit, an amber notice says so — narrow the query rather than trusting a partial analysis, especially before running Analyze with AI. The page also shows how many issues the query matched.

What you’ll see

The GitHub value stream now uses the unified value-stream UI shared by every source. The header bar, the summary cards (aggregate metrics and longest cycle times), the issue table (Key, Title, Type, Status, Progress, Assignee, Events, Cycle Time), the expandable per-issue cycle-time bar and timeline, and the AI analysis with export and email sharing all behave exactly as described in Value Stream Analytics. The shared Show / Hide parents toggle is active for GitHub.

A few things are specific to the GitHub source:

Issue key column — shows the compact #N label; the link still points at the full owner/repo#N issue on GitHub.
Type and Status — resolved from the per-(org, repo, issue) cache populated by Issue Hierarchy and Goal Contributions. They read Issue / Unknown until another page has hydrated that issue.
Events — the count of correlated Git activities (see How issue correlation works).
Ancestor context — with Show parents on, the page also pulls in the parent (epic / parent issue) of each entered issue, giving cross-repo work the same hierarchy context the Jira value stream includes by default. Sub-issues of an entered issue continue to be expanded downward.
Share by email — GitHub analyses can now be emailed to a colleague through the same share dialog as the other sources (previously export-only).

Cycle metrics

The metrics are computed from the correlated event stream — the same heuristics as the Jira value stream, applied to GitHub events:

Metric	Definition
Total cycle time	First “in progress” or first commit → merge (or close).
Dev time	First commit (or “in progress”) → PR opened (or marked ready).
Review wait	PR opened / ready → first review comment or approval.
Review time	First review → approved or merged.
Merge time	Approved → merged.
QA time	Merged → closed. Only counted when greater than zero.

A phase is None when it cannot be determined (for example, an issue with commits but no PR has no review-wait time).

How issue correlation works

ActivityPulse extracts GitHub issue references from every synced commit, PR, and branch using these patterns:

Close keywords: Fixes #42, Closes owner/repo#42, Resolves #42.
Bare references: #42 in commit messages and PR bodies.
Cross-repo references: owner/repo#42.
Branch-name conventions: a branch like feature/owner/repo#42-fix-x contributes the reference.

The extracted references are stored on the activity row as data->'github_issue_refs'. The value-stream analyzer reads that array — no live GitHub API calls are made during analysis (the page works fully offline once activities are synced).

LLM analysis

The page can render the analysis as LLM-ready Markdown and submit it to your configured LLM for a narrative summary — useful for status updates and retrospectives. Configure the LLM in Settings → LLM first.

The LLM output is downloadable as PDF, HTML, or Markdown, or shareable via email using the standard Value Stream share dialog. The export pipeline is provider-agnostic — it does not care whether the underlying analysis came from Jira, ADO, or GitHub.

Limitations

No GitHub-side issue history in v1. The timeline shows only Git events (commits, PR events, reviews). GitHub issue events (status changes, label changes, issue comments) are not fetched. Cycle metrics that depend on a “Done” status transition fall back to the merge timestamp as a proxy.
Issue metadata depends on cache warmth. The Type, Status, and parent_key columns hydrate from the per-(org, repo, issue) cache populated by Goal Contributions and Issue Hierarchy. Visit one of those pages first if you want the richest analysis for a brand-new repository.
Branch-name references must include the #. A branch like feature/PROJ-123 is treated as a Jira reference, not a GitHub reference — its activity will appear in the Jira value stream, not here.

Issue Hierarchy — populate the issue cache so this page renders richer metadata.
Worklog — the same activity stream from a per-day, per-repo angle.