Rebuild the sales pipeline that lives in your head. Trigger on 'what deals do I have open', 'rebuild my pipeline', 'my CRM is empty', 'who am I about to lose', 'which deals went cold', 'what did I quote and to whom', 'build my deal board', 'who hasn't replied to my proposal'. Reconstructs deals from captured DMs, discovery calls, proposals seen on screen, quotes sent and calendar holds into a stage-by-stage board with last-touch recency, a ranked going-cold list, and one next action per deal. Every stage is an inference and shows its evidence. Internal artifact only. Never contacts a prospect.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
deal-pipeline-reconstructor
description
Rebuild the sales pipeline that lives in your head. Trigger on 'what deals do I have open', 'rebuild my pipeline', 'my CRM is empty', 'who am I about to lose', 'which deals went cold', 'what did I quote and to whom', 'build my deal board', 'who hasn't replied to my proposal'. Reconstructs deals from captured DMs, discovery calls, proposals seen on screen, quotes sent and calendar holds into a stage-by-stage board with last-touch recency, a ranked going-cold list, and one next action per deal. Every stage is an inference and shows its evidence. Internal artifact only. Never contacts a prospect.
license
SEE LICENSE IN LICENSE.md
compatibility
Claude Cowork, Claude Code 2.1 or newer, Cursor 2.4 or newer, Codex
metadata
{"version":"1.0.0","author":"Mario Aldayuz / Littlebird","requires":"Littlebird MCP (Power or Pro plan)"}
Deal Pipeline Reconstructor
You sell. You do not maintain a CRM. The CRM is empty, or it has four deals in it from
March and one of them closed.
But the activity is all there. The DM from someone asking if you have capacity. The
discovery call you took on Tuesday. The quote you built in a spreadsheet and pasted into
WhatsApp. The calendar hold with a name you half recognise. The follow-up you meant to
send eleven days ago.
This skill assembles that into the board you never built: every deal placed at a stage,
with the evidence that put it there, how long each one has been silent, and which ones are
dying.
Every stage on this board is an inference. The skill shows its reasoning for each
placement and asks you to confirm before the board is treated as real. That is not
timidity. The forecasting literature's consistent finding is that human judgment combined
with mechanical method beats either alone
(references/research/distilled-b2b-pipeline-management.md, section 3).
The board is internal. Nothing here goes to a prospect.
Purpose
Turn captured sales activity into a stage-by-stage deal board with last-touch recency, a
ranked going-cold list, and one next action per deal, for an operator whose pipeline
currently exists only in their memory.
Capability gate
This skill requires the Littlebird MCP on a Power or Pro plan.
LIST the tools actually available in this session. Do not assume tool names. Use the
real names you find.
If no Littlebird tools are present, stop and tell the user the skill needs the
Littlebird MCP connected, with a link to https://support.littlebird.ai/docs/mcp/. Do
not proceed on memory or guesswork.
If the tools are present but return plan errors, call the subscription status tool and
report the plan gate.
Tool surface, parameters, and return shapes are in
references/littlebird-mcp-reference.md. Read it before writing any query.
Littlebird MCP calls used
Tool
Used for
LB_INTERNAL_LIST_MEETINGS
Sales, discovery and demo calls across the window. Also run with a FUTURE end_date to get upcoming prospect holds. There is no separate calendar tool.
LB_INTERNAL_SEARCH_MEETINGS
Topic search across transcripts and summaries for pricing, scope, proposal and contract discussion
LB_INTERNAL_GET_MEETING
The structured summary per call: Decisions, Action Items with owners, Risks and Open Questions, For You
LB_INTERNAL_GET_MEETING_TRANSCRIPT
Only where exact wording matters and the summary is insufficient. Expensive, and weakly diarized.
search_user_context with data_source: messages
Prospect threads, inbound enquiries, quotes pasted into chat
search_user_context with data_source: snapshots
Proposals, quotes, contracts, e-signature screens, and any CRM screen on display
search_user_context with data_source: summaries
Cheap compressed day view, for filling gaps in the timeline
LB_INTERNAL_GET_SUBSCRIPTION_STATUS
The capability gate above, and the routine limit check
LB_INTERNAL_CREATE_ROUTINE
The weekly pipeline watcher, offered with approval. See Routine cadence.
LB_INTERNAL_GET_ROUTINE_REPORTS
Read the watcher's own past reports before building a board
Check whether the watcher already exists and amend it rather than duplicating
Anything outside this table is a different MCP server. Gmail, HubSpot, Salesforce,
Pipedrive, GoHighLevel and the rest are separate connectors that may or may not be present.
See references/board-output-and-export.md, section 5.
Trigger
Run this when the user says any of: "what deals do I have open", "rebuild my pipeline", "my
CRM is empty", "who am I about to lose", "which deals went cold", "what did I quote and to
whom", "build my deal board", "who hasn't replied to my proposal", "I've lost track of my
deals", "what's in my pipeline".
Also run it on the Monday after the weekly watcher routine posts a report.
Routine cadence
Weekly, plus on demand. The routine observes and reports. The Cowork session builds the
board. Offer to create the routine per the Routine wiring section below.
Process
Step 1: Frame the pipeline. Do not guess.
Ask with AskUserQuestion, in one batch:
What do you sell. One line. It drives every query in step 2.
Typical deal size and typical time from first conversation to signed. Used to
calibrate going-cold thresholds. "I don't know" is an acceptable answer and switches the
skill to the published defaults.
The window. Default 90 days. Offer 60 and 90, and a custom range. 60 days for a fast
transactional cycle, 90 for anything with a proposal step.
Any deals you already know about. Names only. These become seeds that get looked up
directly, and any deal the retrieval MISSES that the user named is a coverage finding
worth reporting.
Where the board should be written. Default: the working directory.
Step 2: Retrieval brief
Run MULTIPLE NARROW queries, not one broad one. Parallel narrow beats one broad: it scores
better and avoids the oversized-result file dump
(references/littlebird-mcp-reference.md, retrieval patterns). Every query is bounded by
the window from step 1. Substitute what the user actually sells.
A. Calls.LB_INTERNAL_LIST_MEETINGS across the full window, then
LB_INTERNAL_SEARCH_MEETINGS for:
"discovery call with a prospective client about scope and pricing"
"sales call or demo where I described what I do and what it costs"
"conversation about budget, timeline, or who else needs to approve"
"call where a client asked for a proposal or a quote"
"conversation about contract terms, start date, or a discount"
For every meeting that comes back relevant, call LB_INTERNAL_GET_MEETING and work from
the structured summary blocks (Decisions, Action Items, Risks and Open Questions, For You).
That summary is the richest and cheapest stage evidence on the whole MCP surface
(references/littlebird-mcp-reference.md). Only pull the transcript where exact wording
matters.
B. Upcoming holds.LB_INTERNAL_LIST_MEETINGS with a FUTURE end_date, out 21 days.
These suppress cold flags (references/recency-and-going-cold.md, section 4). They carry no
id and no summary and are not searchable, so match them by attendee name and title text and
mark the match as an inference.
C. Prospect threads.search_user_context, search_queries_messages populated,
filters.data_source: messages:
"message asking whether I have availability or capacity"
"message asking how much something costs or what my rates are"
"message where I sent a price, a quote, or a scope"
"message about a proposal, an estimate, or a contract"
"message about scheduling a call to discuss working together"
"message where someone said they would get back to me"
D. Documents and screens.search_user_context,
filters.data_source: snapshots:
"proposal or statement of work document with a client name on it"
"quote or estimate with line items and a total"
"contract or agreement or e-signature screen"
"invoice or deposit request for a new engagement"
"CRM or spreadsheet screen showing a list of deals or leads"
Query D5 matters twice over: it finds any stale CRM the user forgot they had, and a CRM
screen on display is itself capture-visible evidence.
E. Seeds. For each name the user gave in step 1, one targeted
search_user_context query plus one LB_INTERNAL_LIST_MEETINGS call with name. A meeting
lookup by NAME uses LIST_MEETINGS with name; a lookup by TOPIC uses SEARCH_MEETINGS
with query. Using the wrong one is the most common retrieval mistake against this server
(references/littlebird-mcp-reference.md).
F. Terminal signals.search_user_context, both message and snapshot sources:
"message saying we decided to go in a different direction"
"message confirming we are moving forward, send the contract"
"kickoff or onboarding scheduling for a new client"
Read the relevance scores. Items scored 3 are maybes and do not carry a claim alone
(references/littlebird-mcp-reference.md).
Step 3: Build deal records
Follow references/deal-identity-and-dedupe.md exactly. In short:
A deal is a PERSON plus a COMPANY plus an OPPORTUNITY, not a contact.
Merge fragments using the matching ladder. Tiers 1 and 2 merge automatically. Tiers 3 and
below need corroboration or a question.
Never merge silently below tier 2. A bad merge is invisible in the output; a duplicate
is fixed in five seconds. Bias toward not merging.
Deduplicate identical OCR lines before counting anything. Sort evidence by EVENT time.
Record contacts observed as a FLOOR ("at least 2"), never as a total.
Do not fabricate deal amounts. Unknown is a valid and frequent answer. Do not compute
a weighted pipeline value.
Step 4: The "is this even a deal" pass
Capture surfaces names, and most of them are not prospects. Classify every candidate as
Prospect, Partner or referrer, Vendor or supplier, Existing client, or Ambiguous, using the
direction-of-sell test: who is being asked to pay whom
(references/deal-identity-and-dedupe.md, section 5).
If the evidence does not answer that question, the candidate is Ambiguous and goes to the
confirmation gate. Every exclusion is recorded with its reason. Never silently drop a
candidate.
Step 5: Infer stage, and show the reasoning
Follow references/stage-inference.md. Six live stages plus a Won and Lost tail: Lead,
Qualified, Proposal, Negotiation, Closing, Won, Lost.
Every placement carries a four-part reasoning line: the stage marked as inferred with a
confidence, the evidence with receipts, the competing reading that was rejected and why, and
what would change the placement.
Bias toward the LOWER stage where evidence is ambiguous. A deal placed too high makes the
user stop working it and count revenue that is not coming. A deal placed too low costs a
moment of correction.
Early-stage placements get lower confidence by default: early-stage outcomes are documented
as harder to predict than later ones
(references/research/distilled-b2b-pipeline-management.md, section 3).
Step 6: Recency and the going-cold list
Follow references/recency-and-going-cold.md.
Last touch is the most recent observed INTERACTION with the prospect, in event time, with
its direction recorded. A note the user typed to themselves is not a touch. This is the
skill's edge over a CRM last-modified date, which measures when the seller typed something
rather than when the buyer was contacted.
Thresholds vary BY STAGE, because typical time in stage varies by stage and the two shortest
expected windows are discovery response and proposal reply
(references/research/distilled-b2b-pipeline-management.md, section 5). Suppress the cold
flag for any deal with an upcoming hold. Rank by severity, not raw days.
Step 7: One next action per deal
One line, concrete, executable today, pulled from the meeting summary's Action Items and
For You blocks where one exists. Do not phrase it as a complaint about being ignored: the
"I never heard back" framing is claimed to reduce meetings booked
(references/research/distilled-b2b-pipeline-management.md, section 6).
Do not encode a follow-up cadence. The archive carries a direct, unresolved, order-of-
magnitude conflict on tempo between two vendor sources
(references/research/distilled-b2b-pipeline-management.md, section 6). Present both
readings if asked and let the user choose.
Step 8: The confirmation gate
The board is a DRAFT until the user confirms it (references/evidence-standards.md, rule
6). Run AskUserQuestion in batches, in this order: ambiguous "is this even a deal"
candidates, ambiguous merges, ambiguous stage placements, Low-confidence placements at
Proposal or later, then the thresholds.
Do not ask about High-confidence placements with clean evidence. Asking about everything
trains the user to click through, which destroys the gate.
Step 9: Write the board
Follow references/board-output-and-export.md.
Output
One file: pipeline-board-YYYY-MM-DD.md, in the user's working directory unless they
name another location. Optionally a companion pipeline-board-YYYY-MM-DD.csv if they
ask for an export.
Sections, in order:
Header. Date, window, deal count, and the statement that stages are inferred.
Confirmation status. Confirmed on DATE with the counts of what changed, or NOT
CONFIRMED in full.
The board. Lead, Qualified, Proposal, Negotiation, Closing, Won, Lost. Per stage: deal
count, sum of KNOWN amounts, count of unknown amounts. Never a weighted value. Per deal:
opportunity, amount with status, contacts observed, first and last touch, days silent,
threshold in force, status, four-part stage reasoning, next action, full evidence trail
sorted by event time, and the merge basis.
Going-cold list. Ranked across all stages by severity. Columns: rank, deal, stage, days
silent, threshold, ratio, direction of last touch, next action. Headed by one sentence
saying this is a work queue, not a write-off list.
Ambiguous stage placements. Both readings, both evidence sets, resolution if any.
Ambiguous merges. Both fragments, both receipts, resolution if any.
Excluded candidates. Every name that did not become a deal, with its bucket and reason.
Waiting. Deals with an upcoming hold, with the caveat that the hold match is an
inference.
Method and gaps. Queries run, window, filters, what came back empty, where the
thresholds came from, and the statement that the stage-inference mapping is the skill's
own reasoning with no external validation.
What this board is not. No win probability, no weighted value, no conversion rates,
unknown amounts are unknown rather than zero, and "no contact observed" is a statement
about the capture rather than proof no contact happened.
Raw retrieved capture does not go in the file. Process it in temp space and let it go
(references/evidence-standards.md, rule 7).
Empty retrieval
If the searches return nothing for the window, stop and report the gap. Do not fabricate a
pipeline.
Say exactly which queries ran, over which window, with which filters, and that they came
back empty. Then give the user the three things that could fix it:
Check the window. A 60-day window on a business with a 90-day cycle finds the tail of
nothing.
Check where the selling happens. If deals are worked on a phone, in person, or in an
app Littlebird does not see, capture has nothing to reconstruct from. Ask which apps and
surfaces the sales conversations actually live in, and re-run scoped to those.
Seed it. Give three prospect names and the skill will look each one up directly, which
frequently surfaces the rest of the thread.
A partial result is reported as partial with its coverage gap named. An empty result ends the
run (references/evidence-standards.md, rule 9).
Where the user named seed deals in step 1 that retrieval did not find, report that
specifically. It is a measurement of what the capture is missing, and it is more useful to
them than a padded board.
Routine wiring: the weekly pipeline watcher
Offer this whenever the user runs the skill and has more than two live deals. Routines can
be created from an interactive session. Show the user the exact prompt text and the
schedule, get approval through AskUserQuestion, then call the routine creation tool. Do not
tell them to go set it up by hand.
Check LB_INTERNAL_LIST_ROUTINES first so an existing watcher gets amended through
LB_INTERNAL_UPDATE_ROUTINE rather than duplicated. Note that UPDATE_ROUTINE REPLACES the
whole prompt, so read the current config first
(references/littlebird-mcp-reference.md).
Schedule: {"frequency": "weekly", "time": "08:00", "week_days": ["MO"]}, in the user's
local timezone. Monday morning, before the week gets away from them.
Routine prompt text to pass, with bracketed values substituted from step 1:
Read your own previous reports first before writing anything. If a deal you already
flagged is still silent, escalate it rather than restating it: say how many weeks running
it has appeared, how many days it has now been silent in total, and raise it above the
newly flagged items in this report.
Search my captured context from the last 7 days for activity on my sales conversations. I
sell [WHAT THEY SELL]. Run several narrow searches rather than one broad one. Cover:
discovery, sales and demo calls held this week; messages where someone asked about
availability, scope or price; messages where I sent a price, a quote or a scope; proposal,
quote, contract or e-signature documents that appeared on my screen; and any message where
a prospect said they would get back to me.
Also list my upcoming calendar events for the next 14 days that look like prospect calls.
Write a short report with five parts.
First, NEW deal signals this week: a named person or company that did not appear in your
previous reports, with what they did, when, and the receipt in the form
[Day, Month DD, YYYY HH:MM TZ | app]. Say plainly that you are not sure whether each one is
a prospect, a partner, a vendor or a friend, and do not assert that it is a deal.
Second, MOVEMENT: any existing deal where something happened this week that suggests it
advanced, for example a proposal document appearing on screen, a price being sent, or a
contract or signature screen. Describe the evidence and the receipt. Mark the stage as an
inference every time. Never state a stage as fact.
Third, GOING QUIET: deals where the last thing you can observe is more than 10 days old.
For each, give the days since the last observed contact, whether that last contact was from
me or from them, and what the last thing observed was. Put deals where THEY messaged ME and
got no reply at the top. Exclude any deal that has a call already on my calendar in the next
14 days, and list those separately as waiting.
Fourth, UPCOMING: prospect calls on my calendar in the next 14 days, with the date and who
is on them.
Fifth, the action line: tell me to open Cowork and run the deal-pipeline-reconstructor
skill to rebuild the full board with stage reasoning and a ranked going-cold list.
Never invent a deal, a company, an amount or a stage. If you observe no sales activity this
week, say exactly that and stop. Do not repeat last week's list as if it were new.
Set notifications on so the Monday nudge actually lands.
Handoff. When the user opens Cowork and runs this skill, read the watcher's past reports
with LB_INTERNAL_GET_ROUTINE_REPORTS BEFORE running step 2. The reports give a week-by-week
movement history that a single retrieval at the end cannot reconstruct, and they show which
deals have been silent across multiple weeks, which is exactly the going-cold signal
(references/littlebird-mcp-reference.md, the Routines-observe Cowork-acts pattern).
Evidence standards
Every claim in the board follows references/evidence-standards.md. The rules that bite
hardest here:
Rule 2, observed and inferred. "A document titled 'Northwind retainer v2' was on screen
on Jul 22" is observed. "Northwind is at Proposal stage" is inferred. The board marks every
stage as an inference, every time, without exception.
Rule 1, receipts. Every piece of evidence carries one. For messages the send time and
the collection time are different values and both appear.
Rule 3, confidence. Every stage placement is rated. A Low-rated placement never drives
an irreversible action, and at Proposal stage or later it goes to the confirmation gate.
Rule 4, attribution. Capture shows what the user was VIEWING. A proposal document on
the user's own screen does not prove it was sent. Flag that ambiguity rather than resolving
it silently.
Rule 5, partial rosters. Contacts per deal are reported as "at least N", never as a
total. App UIs collapse lists.
Rule 6, confirmation. The board is a draft until the user confirms it. Confirm before
encoding, and confirm the actual text before anything is ever sent.
Rule 9, empty retrieval. An empty result ends the run.
Rule 10, reporting on people. Purpose-bound to the pipeline. Provenance on every line.
Sensitive categories stay out even when the capture contains them, and the board contains
candid notes about people who have not replied, so it stays internal.
Guardrail
The specific risk this skill carries is a confidently wrong stage. A deal shown at
Negotiation that is actually at Lead makes the user stop selling to a prospect who has not
been sold to, and count revenue that is not coming. That is the failure mode, and it is
worse than the empty CRM the skill replaces, because an empty CRM does not tell you anything
false.
Five controls, all mandatory:
Every stage is marked as an inference and shows its evidence, its rejected alternative,
and what would change it. No placement is ever asserted bare.
Ambiguity resolves DOWN. Where two stages fit the evidence equally, the deal goes in
the lower one and gets flagged.
The user confirms before the board is real. Nothing is treated as a pipeline until it
passes the gate.
No amount is ever invented, and no weighted pipeline value is ever computed. On a
reconstructed board both inputs would be manufactured, and multiplying two guesses
produces a number that looks like revenue and is not.
No contact observed is not proof of no contact. The user may have called them from a
phone Littlebird never saw. Every cold flag is worded as an observation about the capture
and invites the correction.
Second-order risk: the going-cold list reads as a list of people who rejected you, which is
demoralising and wrong. Every documented cause of a prospect going quiet is about the buyer's
own bandwidth and internal situation, not a decision against the seller
(references/research/distilled-b2b-pipeline-management.md, section 6). Present the list as
a work queue and say so in the file.
Ship Gate
Ship Gate removed, research-only skill, produces no committable code.
Related skills
Skill
Relationship
lead-harvester
Runs UPSTREAM. It turns a campaign's hand-raisers into a ranked roster; this skill turns the ones that became conversations into deals.
pre-call-prep
Runs on a single deal before a call. Feed it a row from this board.
commitment-tracker
Overlaps on the promises inside a deal. Where that skill tracks what was promised, this one tracks where the deal stands.
comment-to-crm-piper
Pipes new hand-raisers into a CRM daily. If that skill is in use, some of this board's Lead-stage rows will already exist there. Reconcile rather than duplicate.
client-health-radar
Picks up after Won. This skill ends at the close; that one watches the relationship after it.
invoice-chaser
Picks up after Won on the money side. A deal marked Won here with no payment observed is that skill's problem, not this one's.
routine-architect
If the user wants the weekly watcher tuned, or has hit their routine limit, hand off there.
A personal voice skill
Not used here. This board is internal and nothing in it is written as the user. If the user asks to draft an actual follow-up message, that is a separate act needing approval of the final text.
References
File
What it covers
references/deal-identity-and-dedupe.md
What a deal is, the matching ladder, company matching, the "is this even a deal" pass, contacts per deal, and why amounts are never invented
references/stage-inference.md
The six stages, the evidence-to-stage table, meeting-summary mining, confidence, the four-part reasoning format, and what this skill refuses to compute
references/recency-and-going-cold.md
Last touch, per-stage thresholds, upcoming-hold suppression, severity ranking, what silence means, and the next-action line
references/board-output-and-export.md
The artifact shape, the confirmation gate, listing connectors before offering an export, the CSV fallback, and the re-run delta
references/littlebird-mcp-reference.md
Tool inventory, parameters, return shapes, retrieval patterns, known limitations
references/evidence-standards.md
Receipts, observed versus inferred, confidence, attribution, partial rosters, confirmation gates
