Tuesdays: features buyers asked for on calls for open deals, the pipeline riding on each, and whether Linear or Jira has a date for it.
Reads
You get
The card on the right is a sample. Yours shows your own numbers and updates in place every run.
What lands on your board
8 open deals worth $120,000 asked for one of 4 features on Gong calls or in CRM notes. Audit log and Salesforce sync ($53,000 between them) have no cycle or date in Linear.
A rep hears "we need SSO before we can sign" on a call, writes "waiting on SSO" in the deal, and product hears about it at the quarterly review, if at all. Meanwhile the roadmap gets planned from ticket counts and opinions, not from the open pipeline waiting on each item.
Every Tuesday the agent reads the Gong transcripts and CRM notes of open deals, pulls out the features buyers asked for, adds up the deal amounts behind each, and looks each one up in Linear or Jira: in a cycle, with a target date, or nowhere. Sales leads see which promises have no date behind them; product managers see the dollars before they plan the next cycle.
POST /crm/v3/objects/deals/search with hs_is_closed EQ false, properties dealname, amount, dealstage and closedate. For each deal, GET /crm/v4/objects/deals/{dealId}/associations/notes, then POST /crm/v3/objects/notes/batch/read for hs_note_body and hs_timestamp, keeping notes from the last 90 days.
POST /v2/calls/extensive for the last 90 days with contentSelector.context: "Extended" and exposedFields: { parties: true, content: { trackers: true } }. Keep calls whose context holds an object with objectType: "Opportunity" and an objectId equal to an open deal's ID, then POST /v2/calls/transcript with those callIds and keep only monologues whose speakerId belongs to a party with affiliation: External.
Match buyer sentences and notes against the feature list the person keeps, with synonyms (SSO: SAML, Okta, single sign-on); a Gong tracker named after a feature confirms the hit. Requirement-like lines that match nothing ("we need", "before we can sign", "does it support") become proposed new features, shown apart and added to the list only on a yes. Keep deal, feature, call date and a quote of at most 20 words.
Linear: issues(filter: { labels: { name: { eq: "<feature label>" } } }), else searchIssues(term: "<feature name>"), reading identifier, state { name type }, cycle { number endsAt }, dueDate and project { name targetDate }. Jira: GET /rest/api/3/search/jql with labels = "<label>" OR summary ~ "<name>", fields status, statusCategory, fixVersions, duedate and the sprint field (a custom field such as customfield_10020).
Join asks to deals on the CRM deal ID and to issues on the feature name or label. Per feature: the deals and their summed amount, each deal counted once in the overall total even when it asks for two features. Scheduled means a started issue, a current or upcoming cycle or sprint, or a due or target date; anything else is not scheduled, including features with no issue. Flag a scheduled date later than the deal's closedate: that deal closes on a promise.
With BRIEFKIN_TOKEN set, the agent sends the result as one card that updates in place every run. Without it, you get the report in the chat.
Pick your agent, where the data comes from and how to schedule it; the commands below follow.
One command. It puts the SKILL.md in ~/.claude/skills and in ~/.agents/skills, which Codex, Cursor, Gemini CLI, Copilot CLI and OpenCode read too.
shellcurl -fsSL https://briefkin.dev/skills/gong-promised-features-vs-roadmap/install | shAsk Claude Code:
promptRun the gong-promised-features-vs-roadmap skillOr paste the prompt instead of installing:
promptUsing HubSpot (read only), list open deals with amount, stage and close date, and their notes from the last 90 days. Using the Gong API, get calls from the last 90 days linked to those deals (calls/extensive with Extended context and parties), and read their transcripts, keeping only what external speakers said. Find where buyers asked for features on my list: <feature: synonyms; ...>. Propose any other requirement you hear as a new feature, separately. For each feature, sum the amounts of the deals that asked (count each deal once in the total) and look it up in Linear or Jira by label or name: state, cycle or sprint, due or target date. Mark it scheduled if it is started, in a cycle or sprint, or has a date; otherwise not scheduled. Flag deals whose close date is before the feature lands. Give me the total, a table per feature, the proposed new features with one short quote each, and the unscheduled feature with the most pipeline.Tuesdays at 9:00, from cron on any machine where Claude Code is signed in:
crontab0 9 * * 2 claude -p "Run the gong-promised-features-vs-roadmap skill"Add it with crontab -e. A laptop asleep at that time runs it when it wakes if you use launchd or Task Scheduler instead; GitHub Actions works for the API route.
Connect Briefkin once with curl -fsSL https://briefkin.dev/install | sh and every run lands on your board as a report card. How setup works
SKILL.md---
name: gong-promised-features-vs-roadmap
description: "Tuesdays: features buyers asked for on calls for open deals, the pipeline riding on each, and whether Linear or Jira has a date for it. Use when the user asks for this, or when it runs on a schedule."
---
# Features promised in sales calls vs the roadmap: Gong, CRM and Linear
Tuesdays: features buyers asked for on calls for open deals, the pipeline riding on each, and whether Linear or Jira has a date for it.
A rep hears "we need SSO before we can sign" on a call, writes "waiting on SSO" in the deal, and product hears about it at the quarterly review, if at all. Meanwhile the roadmap gets planned from ticket counts and opinions, not from the open pipeline waiting on each item.
Every Tuesday the agent reads the Gong transcripts and CRM notes of open deals, pulls out the features buyers asked for, adds up the deal amounts behind each, and looks each one up in Linear or Jira: in a cycle, with a target date, or nowhere. Sales leads see which promises have no date behind them; product managers see the dollars before they plan the next cycle.
## Two ways to get the data
Use the API or MCP route when you have an MCP server, a CLI or an API token for the app. Otherwise, if you can drive a browser the user is signed in to (Claude in Chrome, a Playwright or Chrome DevTools MCP server), use the browser route. Say which one you used.
## Route A: API or MCP server
### What you need
- Read access to open deals and notes in HubSpot, with Gong connected to HubSpot so calls carry the deal ID in their CRM context.
- A Gong API access key (`GONG_ACCESS_KEY`, `GONG_ACCESS_KEY_SECRET`, `GONG_BASE_URL`) that can read calls and transcripts; the Gong MCP server returns summaries rather than transcripts.
- A feature list with synonyms and the Linear or Jira label each feature uses, plus read access to Linear or Jira.
If something is missing, say what and stop; do not invent numbers.
### Steps
1. **List open deals and their notes** (HubSpot): `POST /crm/v3/objects/deals/search` with `hs_is_closed EQ false`, properties `dealname`, `amount`, `dealstage` and `closedate`. For each deal, `GET /crm/v4/objects/deals/{dealId}/associations/notes`, then `POST /crm/v3/objects/notes/batch/read` for `hs_note_body` and `hs_timestamp`, keeping notes from the last 90 days.
2. **Pull the calls on those deals** (Gong): `POST /v2/calls/extensive` for the last 90 days with `contentSelector.context: "Extended"` and `exposedFields: { parties: true, content: { trackers: true } }`. Keep calls whose `context` holds an object with `objectType: "Opportunity"` and an `objectId` equal to an open deal's ID, then `POST /v2/calls/transcript` with those `callIds` and keep only monologues whose `speakerId` belongs to a party with `affiliation: External`.
3. **Extract the feature asks**: Match buyer sentences and notes against the feature list the person keeps, with synonyms (`SSO: SAML, Okta, single sign-on`); a Gong tracker named after a feature confirms the hit. Requirement-like lines that match nothing ("we need", "before we can sign", "does it support") become proposed new features, shown apart and added to the list only on a yes. Keep deal, feature, call date and a quote of at most 20 words.
4. **Find each feature on the roadmap** (Linear): Linear: `issues(filter: { labels: { name: { eq: "<feature label>" } } })`, else `searchIssues(term: "<feature name>")`, reading `identifier`, `state { name type }`, `cycle { number endsAt }`, `dueDate` and `project { name targetDate }`. Jira: `GET /rest/api/3/search/jql` with `labels = "<label>" OR summary ~ "<name>"`, fields `status`, `statusCategory`, `fixVersions`, `duedate` and the sprint field (a custom field such as `customfield_10020`).
5. **Join pipeline to roadmap**: Join asks to deals on the CRM deal ID and to issues on the feature name or label. Per feature: the deals and their summed amount, each deal counted once in the overall total even when it asks for two features. **Scheduled** means a started issue, a current or upcoming cycle or sprint, or a due or target date; anything else is **not scheduled**, including features with no issue. Flag a scheduled date later than the deal's `closedate`: that deal closes on a promise.
## Route B: the browser
### What you need
- Signed in to Gong with access to the deals' calls, to HubSpot with view access to open deals, and to Linear or Jira with view access to the projects concerned.
If something is missing, say what and stop; do not invent numbers.
### Steps
Start at https://app.gong.io/. The user is signed in already; never type passwords or codes, and ask if a sign-in page appears.
1. **List the open deals**: In `https://app.hubspot.com/contacts/` open **CRM > Deals** in list view, filter to the open stages and sort by **Amount**. For the 20 largest, note amount, close date and anything in the notes on the deal's activity timeline from the last 90 days that names a feature.
2. **Search the calls on each deal**: In Gong, find the deal or account and open its calls from the last 90 days. On each call, open the transcript and search it for each feature name and synonym; keep only lines spoken by the buyer, with the call date and a short quote.
3. **Look up each feature in Linear or Jira**: In `https://linear.app/` open the feature's label or search its name and read the issue's status, cycle, due date and project target date. In Jira, run the JQL `labels = "<label>" OR summary ~ "<name>"` in the issue search and read status, sprint, fix version and due date.
4. **Add up and write the report**: Per feature, sum the deals that asked, counting each deal once in the overall total. Scheduled means started, in a cycle or sprint, or dated; otherwise not scheduled. Report the total, the table, deals closing before their feature lands, new asks heard on calls, and the unscheduled feature with the most pipeline.
Note: Searching transcripts by hand takes about a minute per call, so this route suits 20 deals or fewer; the API reads every transcript in one pass. Private calls appear only for people allowed to see them, so run it as someone who can see the team's calls.
## The report
- **Pipeline waiting on features**: how many open deals and how much, across how many features.
- **Per feature**: deals, pipeline, the issue and its state, and when it lands or "not scheduled".
- **Promises past the close date**: deals expected to close before their feature ships.
- **Proposed new features** heard on calls, with one quote each.
- What to do first: the unscheduled feature with the most pipeline, with the deal and quote behind it.
## Post it to Briefkin
When `BRIEFKIN_TOKEN` is set, or `~/.config/briefkin/env` exists (the installer from https://briefkin.dev/docs writes it), also send the result to the user's Briefkin board as one card. Keep the `item_key` the same on every run so the card updates in place, use a new `event_id` per run, and put today's real numbers in place of the example ones. If the request fails, say so once and carry on.
```bash
[ -n "${BRIEFKIN_TOKEN:-}" ] || . ~/.config/briefkin/env
curl -sS -X POST "${BRIEFKIN_URL:-https://briefkin.dev}/v1/events" \
-H "authorization: Bearer $BRIEFKIN_TOKEN" \
-H "content-type: application/json" \
-d @- <<'JSON'
{
"v": 1,
"event_id": "gong-promised-features-vs-roadmap/<date of this run, e.g. 2026-10-16>",
"item_key": "gong-promised-features-vs-roadmap",
"project": "Acme",
"source": "Features promised in sales calls vs the roadmap: Gong, CRM and Linear skill",
"kind": "update",
"title": "$120k of pipeline waits on 4 features, 2 unscheduled",
"summary": "**8 open deals worth $120,000** asked for one of 4 features on Gong calls or in CRM notes. **Audit log** and **Salesforce sync** ($53,000 between them) have no cycle or date in Linear.",
"widget": [
{
"type": "Table",
"props": {
"columns": [
"Feature",
"Deals",
"Pipeline",
"Roadmap",
"Lands"
],
"align": [
"left",
"right",
"right",
"left",
"left"
],
"rows": [
[
"SSO (SAML)",
3,
"$52,000",
"ENG-412, In Progress, Cycle 24",
"Nov 6"
],
[
"Audit log",
2,
"$31,000",
"ENG-388, Backlog",
"Not scheduled"
],
[
"Salesforce sync",
2,
"$22,000",
"No issue found",
"Not scheduled"
],
[
"Custom roles",
1,
"$15,000",
"Permissions v2 project",
"Dec 15"
]
]
}
},
{
"type": "Badges",
"props": {
"items": [
{
"label": "Custom roles lands after close date",
"tone": "warn"
},
{
"label": "New ask: HIPAA BAA, 1 call",
"tone": "info"
}
]
}
},
{
"type": "Callout",
"props": {
"text": "Biggest gap: Audit log. Relecloud ($19,000, Negotiation) said on the Oct 21 call: \"we cannot sign without an audit trail for our SOC 2 review.\"",
"tone": "warn"
}
}
]
}
JSON
```
Widgets come from the Briefkin catalog (https://briefkin.dev/v1/catalog). Without a token, just give the user the report.
## Run it on a schedule
Suggested: Tuesdays at 9:00 (`0 9 * * 2`). From cron, with the agent signed in on that machine:
```bash
0 9 * * 2 claude -p "Run the gong-promised-features-vs-roadmap skill"
# Codex: codex exec, Gemini CLI: gemini -p, Copilot CLI: copilot -p, OpenCode: opencode run
```
Or use the agent's own scheduler (Claude Code routines, Codex automations, Claude or ChatGPT scheduled tasks): https://briefkin.dev/skills/gong-promised-features-vs-roadmap#schedule
Source: https://briefkin.dev/skills/gong-promised-features-vs-roadmap
Read access to open deals and notes in HubSpot, with Gong connected to HubSpot so calls carry the deal ID in their CRM context.
A Gong API access key (GONG_ACCESS_KEY, GONG_ACCESS_KEY_SECRET, GONG_BASE_URL) that can read calls and transcripts; the Gong MCP server returns summaries rather than transcripts.
A feature list with synonyms and the Linear or Jira label each feature uses, plus read access to Linear or Jira.
https://mcp.gong.io/mcp, read-only. A technical administrator creates an MCP integration in Gong with Personal access, so each person sees only the calls they already can, adds the client's redirect URI, and shares the client ID and secret; in Claude you add it as a custom connector with those values. Its tools (ask_account, ask_deal, generate_brief) return Gong's AI-generated insights about accounts and deals, not raw transcripts, and leave private calls out. Users need a paid Gong seat (docs).GONG_ACCESS_KEY, GONG_ACCESS_KEY_SECRET and GONG_BASE_URL and uses basic auth.The API key reads every call in the company, transcripts included, so keep it in a secret store and point the skill at the deals in the report; for per-person access, use the MCP server with Personal access.
https://mcp.hubspot.com. HubSpot also offers a Claude connector built on the same server; you sign in with your HubSpot user and it sees what that user can see (docs).crm.objects.deals.read, crm.objects.contacts.read, crm.objects.companies.read, crm.objects.owners.read), and store its token in HUBSPOT_ACCESS_TOKEN.The MCP server and connector can create and update records, so for unattended reports a private app with only .read scopes is the safer credential.
https://mcp.linear.app/mcp. Add Linear from Claude's connector directory, or run claude mcp add --transport http linear https://mcp.linear.app/mcp in Claude Code, and sign in with OAuth.LINEAR_API_KEY, and send it as the Authorization header with no Bearer prefix. For a workspace bot, an OAuth app with the read scope does the same job.When you create the key, give it Read access and only the teams in the report; it then can't create or edit issues.
https://mcp.atlassian.com/v2/mcp. In Claude, add the Atlassian connector from the directory; in Claude Code, run claude mcp add --transport http atlassian https://mcp.atlassian.com/v2/mcp and authenticate with /mcp. It signs in with OAuth 2.1 or an API token and respects your Jira permissions (getting started).acli jira auth login, acli jira workitem search --jql "sprint in openSprints()" --json returns the same issues from a terminal.JIRA_EMAIL, JIRA_API_TOKEN and JIRA_BASE_URL (https://acme.atlassian.net) and uses basic auth. A scoped token limited to read:jira-work and read:jira-user is narrower; scoped tokens call https://api.atlassian.com/ex/jira/{cloudId} instead of your site URL.A classic token can do anything your account can, so prefer a scoped token with read scopes only, or an account that just has Browse permission on the projects in the report.
Gong links a call to a deal through its CRM integration, usually by matching the participants to the deal's contacts. Calls with no Opportunity in their context are left out, so their asks are never counted against the wrong deal. If many calls come back unlinked, check the Gong to HubSpot integration and that buyers are contacts on their deals.
Each feature row sums every deal that asked for it, so a deal asking for SSO and an audit log shows in both rows. The headline total adds each deal once. That is why the per-feature pipeline can add up to more than the total on the card.
No. The skill runs with your own agent and gives you the report in the chat. With a Briefkin token set, each run also posts it to your board as a report card, so you can glance at it instead of asking again.
Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot CLI, OpenCode, Windsurf and Amp all read SKILL.md files. The install command puts it in ~/.claude/skills and ~/.agents/skills, where they look. ChatGPT, the Claude app and Grok take the prompt instead. Pick your agent under "Install and run it" and the commands change to match.
Yes. Switch the data source to "Your browser" and the steps change to the Gong, HubSpot, Linear and Jira pages themselves: the agent opens app.gong.io in a browser you are signed in to and reads the numbers off the page. Claude Code, Codex, Cursor, Claude app and ChatGPT can drive a browser out of the box; Gemini CLI, Copilot CLI and OpenCode need a Playwright or Chrome DevTools MCP server first. It is slower than the API and needs you signed in, so it suits a report you run by hand or from a scheduler on your own computer.
Skills are free to use with any agent. Briefkin is where their results land: one board for every report, number and question your agents send, with a ping when something needs you.
Free during the open beta. No card.