Pipeline Review

Connected Mode (Salesforce available)

Dispatch salesforce-researcher with the Extended SOQL query from pipeline-data.md (includes LastActivityDate, LastModifiedDate, CreatedDate). After SF data is parsed, run Multi-Source Enrichment (Step 2) to cross-reference Obsidian, Gmail, and Slack for each account.

Named Sub-Agents

Workflow

Step 1: Detect Mode and Parse Input

Determine which input mode the user is providing:

1. If user attached a file or pasted CSV-formatted data: CSV mode
2. If user pasted deal descriptions (one per line, informal): Paste mode
3. If user described their pipeline in prose: Describe mode
4. If user asks to "pull from Salesforce", provides no data, or invokes /pipeline-review without specifying a source: Connected mode (dispatch salesforce-researcher). This is the default when no input is provided.

Parse the input using the corresponding rules from pipeline-data.md. Extract for each deal:

• Deal name (required)
• Amount (required; flag as hygiene issue if missing)
• Stage (required; normalize using the Stage Name Normalization table from pipeline-data.md)
• Last activity date (if available; needed for Engagement Quality scoring)
• Created date (if available; helpful for stuck-deal detection)
• Account name (if available)

If any required field is missing across multiple deals, ask the user once for the pattern rather than per-deal.

Step 2: Multi-Source Enrichment (Two-Wave Architecture)

Connected mode only. Cross-reference Salesforce data against Obsidian, Gmail, Slack, meeting transcripts, and external sources. Enrichment findings are NOT optional supplementary data. They are co-equal with SF data and feed directly into all four health score dimensions (Step 3), dead weight detection (Section 10), Opp Velocity (Step 4), and recommended SF updates (Section 11).

Pre-dispatch setup: Run rm -rf /tmp/pipeline-review/ && mkdir -p /tmp/pipeline-review/ before dispatching any agents.

Dispatch prompt rubrics for each agent are in references/enrichment-rubrics.md. Reference that file for the full prompt templates; the summaries below describe each agent's role and key outputs.

Wave 1: Locate + Pull (sequential: SF first, then obsidian-locator)

Dispatch salesforce-researcher first. Once it returns and you have account names, dispatch obsidian-locator. obsidian-locator requires the top account names from SF data to search — it cannot run in parallel with salesforce-researcher.

1. salesforce-researcher: Pull pipeline data with the Extended SOQL query from pipeline-data.md, THEN run the Account Contacts query (also in pipeline-data.md) to get all Contacts on pipeline Accounts. Returns deal data including Type field for renewal filtering, plus per-account contact lists for multi-threading baseline. Write to /tmp/pipeline-review/salesforce-data.md.

2. obsidian-locator: Search Regal/Accounts/<Account Name>/ for account files (briefs, deal docs) matching the top 10-15 account names by deal value. Return file paths and dates only. Do NOT read file contents. Write to /tmp/pipeline-review/obsidian-paths.md.

3. transcript-locator: Search transcript-pipeline SQLite, vault-search, and Regal/Granola/ for transcript files matching the top 10-15 account names by deal value. Return file paths, meeting IDs, and source types only. Do NOT read transcript contents. Write to /tmp/pipeline-review/transcript-locator.md.

Wait for Wave 1 to complete before dispatching Wave 2. Read /tmp/pipeline-review/transcript-locator.md to get transcript locations for transcript-analyzer. Apply three-state locator failure handling:

• Success (transcript-locator output file exists and contains 1+ entries): dispatch transcript-analyzer with the locator output path.
• Empty (output file exists but Total: 0): skip transcript-analyzer. Note [NO TRANSCRIPT DATA] and proceed with other Wave 2 agents.
• Crash (locator Task call errors, output file missing, or tool_uses: 0): note [TRANSCRIPT LOCATOR FAILED] and proceed without transcript data. Do NOT retry.

Wave 2a: Extract (parallel dispatch, 4 agents)

Dispatch exactly 4 agents in parallel (max concurrent agent limit). Each agent includes the WRITE EARLY persistence instruction from enrichment-rubrics.md.

1. transcript-analyzer: Provide the transcript-locator output path from Wave 1 (/tmp/pipeline-review/transcript-locator.md). Extract intent signals using the 6-signal-type rubric (verbal buying language, budget/timeline, champion ID, competitive eval, multi-stakeholder, deal progression). Also extract negative signals. Output: per-account structured format with signal type, quote, date, speaker. Write to /tmp/pipeline-review/transcript-enrichment.md. Gated: only dispatch if transcript-locator returned 1+ entries (see three-state handling above).

2. google-workspace-researcher: Search Gmail for the top account names. Track email direction (buyer-initiated vs seller-initiated), extract contacts ([email protected]), flag substantive buyer content. Write to /tmp/pipeline-review/gmail-enrichment.md.

3. slack-researcher: Search Slack for the top account names. Classify momentum signals (positive/negative/neutral), flag internal urgency. Write to /tmp/pipeline-review/slack-enrichment.md.

4. obsidian-analyzer: Read Regal/Accounts/<Account Name>/ for the top accounts. Extract contacts with roles, deal sizing references, competitive intel, qualification data. Write to /tmp/pipeline-review/obsidian-enrichment.md.

Wave 2b: Extract (dispatch after Wave 2a starts, 1 agent)

Dispatch separately because Wave 2a already uses 4 concurrent agent slots.

5. company-researcher: Research external triggers for the top 5-10 accounts by deal value. Search for funding events (90 days), executive hiring, expansion signals, contraction signals. This is the ONLY enrichment agent that uses web search (brave/tavily). Write to /tmp/pipeline-review/external-triggers.md.

6. deep-research-agent: Conditional. Dispatch alongside company-researcher ONLY when the user explicitly requests competitive analysis, industry context, or market intelligence beyond standard external triggers. This is the narrowest dispatch condition in the toolkit. Read tools/references/deep-research-dispatch.md for query construction. Write findings to /tmp/pipeline-review/deep-research-agent.md.

Post-Wave 2 Synthesis

Truncation detection: After all agents return, check each result. If any agent returns <500 chars but reported tool_uses >5, its output was truncated by the 32K cap. Read the file it wrote to /tmp/pipeline-review/ instead. If neither the return nor the file has data, log "ENRICHMENT GAP: [agent] output lost" and note which accounts lack enrichment.

After all agents return, read each enrichment file from /tmp/pipeline-review/. Build a per-deal enrichment record that includes:

• Cross-source contact count (unique contacts from transcripts + Gmail + SF Account Contacts)
• Most recent activity date across all sources
• Buyer-initiated activity count and two-way ratio
• Intent signal inventory (which of the 6 signal types are present per deal)
• External trigger inventory per account
• Discrepancy list across 5 categories:

• Recommended SF updates (for Section 11): specific CRM corrections derived from discrepancies

Store the enrichment record for use in Step 3 (health scoring), Step 4 (Opp Velocity justification), and Step 5 Section 11 (recommended SF updates).

Standalone mode: Skip this step. Intent Signals and Deal Quality dimensions score as "N/A (external sources unavailable)". Opp Velocity relies solely on SF data patterns.

Step 3: Calculate Health Score

Compute a composite health score across four equally-weighted dimensions (25 points each = 100 total). See references/health-score-methodology.md for the detailed scoring rubrics, deduction formulas, and edge case rules for each dimension.

Stage Progression (25 pts)

Measures deal momentum using velocity ratios against org-specific benchmarks from pipeline-data.md and cross-source multi-threading signals.

• Compare each deal's days_in_current_stage against the Stale Threshold from the Stage Velocity Benchmarks table in pipeline-data.md. Deduct based on the velocity ratio (see methodology file for tier thresholds).
• Count unique contacts per deal from ALL sources (SF Account Contacts, transcripts, Gmail). Flag single-threaded deals above $50K. Note: OpportunityContactRoles are unused in this org; use Account Contacts as the SF baseline.
• Exclude Type = 'Renewal' deals from velocity scoring. Do NOT penalize stage skipping.

Engagement Quality (25 pts)

Measures depth and recency of two-way engagement with step-function decay weighting.

• Apply time decay to all activities: 100% (0-30 days), 75% (31-60 days), 50% (61-90 days), 0% (90+ days). <!-- keep in sync with health-score-methodology.md -->
• Buyer-initiated activities receive 2x weight when direction can be determined from enrichment data.
• Calculate two-way ratio per deal. Flag deals with ratio < 0.2 and > 5 total activities as "seller-dominated."
• Full deduction for deals with zero activities in the last 30 days; half deduction for 31-60 day window only.
• Standalone mode: Score using SF LastActivityDate only with the same decay thresholds.

Intent Signals (25 pts)

Measures prospect buying intent from transcript analysis, email content, and external triggers. Connected mode only.

• Check for 6 signal types in recent transcripts: verbal buying language, budget/timeline mentions, champion identification, competitive evaluation, multi-stakeholder involvement, deal progression indicators. <!-- keep in sync with health-score-methodology.md -->
• Score based on signal presence: 4+ types = no deduction, 2-3 = minor, 0-1 = moderate, negative signals = full deduction.
• Bonus reductions for substantive buyer emails and external triggers (funding, executive hires). See methodology file for caps.
• Deals with no transcripts available are scored as neutral (no deduction, no penalty).
• Standalone mode: Mark as "N/A" and score out of 75.

Deal Quality (25 pts)

Cross-source data integrity. Requires Step 2 enrichment data.

• Check 5 discrepancy categories: Sizing, Timeline, Stage, Stakeholder, Activity. <!-- keep in sync with health-score-methodology.md -->
• Deduct based on discrepancy count per deal (1 category = half deduction, 2+ = full deduction).
• Standalone mode: Skip and score out of 75 (or 50 if Intent Signals also N/A).

When a dimension is unavailable, adjust the denominator accordingly. A pipeline scored out of 50 (standalone) with 42 points reports as "42/50 (84%)".

Step 4: Prioritize Deals

Rank all deals using a 5-factor weighted framework:

Opp Velocity Score Rubric

Score each deal 0-100 based on observable momentum signals, then provide a 1-2 sentence Opp Velocity Justification explaining the score.

Quantitative signals (from SF data):

• Stage advanced in the last 30 days: +30
• Activity in the last 7 days: +20
• Activity in the last 14 days (but not last 7): +10
• Amount increased since creation: +10
• Multiple activities in the last 30 days (3+): +10

Cross-source signals (from Step 2 enrichment, connected mode only):

• Buyer-initiated communication found (they emailed/called you, not just replies): +10
• Verbal timeline commitment in transcript ("we want to sign by X"): +10
• New stakeholder engaged since last review (found in transcript/email but not prior SF data): +10
• Internal Slack discussion indicates positive momentum: +5
• Negative signals found (ghosting, "not a priority right now", budget freeze): -20

Cap at 100, floor at 0. Deals with no data default to 30 (neutral).

Opp Velocity Justification: For each deal, write 1-2 sentences citing the specific signals that drove the score. Example: "Score 75: Stage advanced from Scoping to Tech Validation on Feb 20. Gmail shows buyer sent integration docs unprompted on Feb 25. 4 activities in last 30 days."

User overrides: If the user says "focus on big deals" or "I need quick wins," adjust the weights:

• "Big deals" / "largest": Deal Size 40%, Opp Velocity 20%
• "Quick wins" / "high velocity": Opp Velocity 45%, Deal Size 15%
• "At risk" / "save deals": Risk 30%, Activity 25%, Opp Velocity 20%, Deal Size 15%, Stage 10%

Sort deals by composite score descending.

Step 5: Generate Report

Produce the report with all sections below. Every section is required.

Section 1: Header

Pipeline Review: [Date]
Data Source: [CSV upload / Manual input / Salesforce]
Deals Analyzed: [X]
Total Pipeline Value: $[X]

Section 2: Health Score Breakdown

If a dimension is N/A, show "N/A" in Score and explain why in Key Signals.

Section 3: Priority Actions This Week

The top 3 deals by priority score. For each:

• Why: One sentence explaining why this deal is the priority (large amount, high velocity, at risk, etc.)
• Velocity: The Opp Velocity Score and 1-sentence justification
• Action: Specific next step (not generic, e.g., "Send revised proposal addressing the pricing objection from Jan 15 call" not "Follow up")
• Impact: Dollar amount at stake

Section 4: Deal Prioritization Matrix

Group deals into three buckets based on priority score and velocity:

High Velocity (Focus Time Here): Deals with Opp Velocity Score 60+ and in Stage 2+. Active (Keep Warm): Deals with Opp Velocity Score 30-59 or in earlier stages with recent activity. Stalled (Intervention Needed): Deals with Opp Velocity Score below 30 or no activity in 14+ days.

Each bucket as a table: Deal, Amount, Stage, Velocity Score, Velocity Justification, Next Action.

Section 5: Deal Quality Findings

Only in connected mode (when Step 2 enrichment ran). For each deal where cross-source discrepancies were found, show:

Example rows:

• Acme Corp | Sizing | 100 agents | 1,000 agents | Obsidian research doc | Update SF Opp Agent Seats
• TechStart | Timeline | Close 6/30 | "Want to sign in 2 weeks" | Feb 25 transcript | Move close date to mid-March
• HealthCo | Stakeholder | No Account Contact for "Fernando" | VP Eng "Fernando" on Feb 9 call | Transcript | Add Fernando as Contact on Account

If no discrepancies found, state "Deal Quality: All deals aligned across sources" and move on.

See Section 11 (Recommended Salesforce Updates) for specific CRM actions derived from these findings.

Section 6: Risk Flags

Five risk categories, each as its own table. "Last Activity" must reflect the most recent touchpoint from ANY source (SF, Gmail, Slack, transcripts), not just SF LastActivityDate.

Cooling (15-30 Days No Activity Across Any Source): Deal, Amount, Last Activity (Source), Days Silent, Engagement Score, Recommendation (send check-in / schedule call).

Stale (31-60 Days No Activity Across Any Source): Deal, Amount, Last Activity (Source), Days Silent, Engagement Score, Recommendation (escalate outreach / involve manager).

At Risk of Loss (60+ Days No Activity Across Any Source): Deal, Amount, Last Activity (Source), Days Silent, Engagement Score, Recommendation (qualify out / one-last-try executive outreach).

Stuck Deals (Same Stage 30+ Days): Deal, Amount, Stage, Days in Stage, Recommendation (Push / Multi-thread / Qualify out).

Negative Intent Detected: Deal, Amount, Signal, Source, Quote, Recommendation (address objection / re-qualify). Only populated when enrichment found negative signals (budget freeze, competitor selected, "not a priority"). Connected mode only.

If a category has no flagged deals, omit that table.

Section 7: Hygiene Issues

Only include rows where count > 0.

Section 8: Pipeline Shape

Two views of pipeline distribution:

By Stage: Stage, # Deals, Value, % of Pipeline

By Deal Size: Bucket ($100K+, $50K-100K, $25K-50K, <$25K), # Deals, Value

Section 9: Recommendations

This Week: 3 specific action items (checklist format) tied to named deals.

This Month: 2 strategic actions (pipeline building, hygiene cleanup, etc.)

Section 10: Deals to Consider Removing

Flag deals that may be dead weight. In connected mode, "activity" includes ALL sources from Step 2 enrichment (Gmail, Slack, transcripts, Obsidian), not just SF LastActivityDate. A deal with a stale SF record but active Gmail threads or Slack discussions is NOT dead weight. NEVER recommend removing a deal based solely on SF activity dates.

Criteria (ALL must be checked against cross-source data when available):

• No activity across ANY source (SF, Gmail, Slack, transcripts) in 60+ days
• Amount $0 with no clear path to sizing
• No buyer-initiated contact found in any source

Table: Deal, Amount, Reason, Sources Checked, Recommendation (Mark closed-lost / Qualify out)

If no deals qualify, state "No dead weight detected" and move on.

Section 11: Recommended Salesforce Updates

Connected mode only. Convert cross-source discrepancies and enrichment discoveries into specific, actionable SF update recommendations. This section turns the data quality findings from Section 5 into a concrete CRM maintenance checklist.

Five sub-categories, each as a sub-table. Omit any sub-table with no recommendations.

Missing Contacts: Contacts found in enrichment sources (transcripts, Gmail, Obsidian) that do NOT exist as Account Contacts in Salesforce. Compare enrichment contact names against the Account Contacts query results. Only flag contacts with no match on the Account.

ContactRole Coverage (positive signal): Deals where OpportunityContactRoles are linked. This is uncommon in this org and indicates above-average deal management hygiene. List these deals as a positive note, not a remediation item.

Amount Updates: Deal sizing found in external sources that differs from SF Amount.

Stage Updates: Signals suggesting deal is further along (or behind) than SF Stage.

Missing Activities: Recent meetings or emails found externally but not logged in SF.

If no recommendations across all categories, state "Salesforce data aligned with external sources" and move on. Omit this section entirely in standalone mode.

Step 6: Save to Obsidian

ALWAYS save the full pipeline review to Obsidian after generating the report. No confirmation needed.

Obsidian MCP unavailable fallback: If obsidian_list_files_in_dir fails with "Connection refused", write directly to the filesystem. Vault root: /Users/nick.yebra/Library/Mobile Documents/iCloud~md~obsidian/Documents/Core Vault. Full path: $VAULT_ROOT/Regal/Pipeline/MM.DD-MM.DD/Pipeline Review.md.

• Directory: Regal/Pipeline/MM.DD-MM.DD/ where MM.DD-MM.DD is the Monday-Friday range of the current work week (e.g., Regal/Pipeline/02.23-02.27/)
• Filename: Pipeline Review.md
• Include all sections from Step 5 in the saved document

Check-before-write (mandatory): obsidian_append_content silently appends to existing files instead of creating new ones. You MUST check for conflicts before writing.

1. List files in Regal/Pipeline/MM.DD-MM.DD/ using obsidian_list_files_in_dir (if the directory doesn't exist yet, proceed directly to write)
2. Check if Pipeline Review.md already exists in the listing
3. If it exists, increment the suffix: Pipeline Review (2).md, Pipeline Review (3).md, etc. until a filename is available
4. Only then call obsidian_append_content with the final unique filepath

Post-enrichment addendums: When adding supplementary data to an existing review document (e.g., after re-running a failed enrichment agent post-OAuth-refresh), ALWAYS use obsidian_append_content to append a labeled ## ADDENDUM: [Agent] (post-[reason]) section. Do NOT use obsidian_patch_content to update specific sections — heading target matching is fragile and fails silently when headings don't exactly match the stored document text.

Step 7: Present and Offer Iteration

After presenting and saving the review, offer these options:

• Adjust prioritization weights ("focus on big deals" / "I need quick wins")
• Drill into a specific deal for deeper analysis
• Generate follow-up tasks for priority deals
• Re-run with updated data (add/remove deals, update stages)
• Compare against a previous review (if one exists)

Critical Rules

• Health score has EXACTLY 4 dimensions (Stage Progression 25 + Engagement Quality 25 + Intent Signals 25 + Deal Quality 25 = 100). NEVER add, remove, or substitute dimensions. NEVER use Close Date as a health dimension.
• Each dimension score has a floor of 0. Apply max(0, 25 - total_deductions) after summing all deductions for a dimension. This prevents negative scores when multiple deduction categories overlap on small pipelines.
• Intent Signals and Deal Quality require Step 2 enrichment data. In standalone mode, skip these dimensions and score out of 50 (Stage Progression 25 + Engagement Quality 25). If only one enrichment-dependent dimension is available, score out of 75.
• When data for a dimension is unavailable, note "N/A" and adjust the scoring denominator accordingly.
• Stage velocity benchmarks are in pipeline-data.md. Use the Stale Threshold column for deduction thresholds. Do NOT hardcode day counts in the skill itself.
• Engagement Quality uses step-function decay: 100% (0-30d), 75% (31-60d), 50% (61-90d), 0% (90d+). These thresholds are fixed.
• Buyer-initiated activities receive 2x weight in Engagement Quality scoring. If direction cannot be determined from enrichment data, do not apply the multiplier.
• Intent Signals scores the PRESENCE of buying signals, not their absence in early-stage deals. Deals with no transcripts available are scored as neutral (no deduction), not penalized.
• Multi-threading signal comes from cross-source contact count (SF Account Contacts + transcripts + emails). OpportunityContactRoles are unused in this org; use the Account Contacts query from pipeline-data.md as the SF baseline. When a deal DOES have ContactRoles linked, note it as a positive CRM hygiene signal.
• "Activity" means the most recent touchpoint across ALL sources (SF, Gmail, Slack, transcripts, Obsidian). NEVER use SF LastActivityDate as the sole activity signal when enrichment data is available.
• Per-dimension failure degradation: If an enrichment agent fails or returns incomplete data, carry forward the ENRICHMENT GAP rule for the affected dimension:
  • Stage Progression: If SF data unavailable, skip velocity scoring. Score multi-threading from available sources only.
  • Engagement Quality: If only SF available, use LastActivityDate with decay thresholds. Note "ENRICHMENT GAP: engagement scoring limited to SF activity dates."
  • Intent Signals: If transcript researcher fails, mark "ENRICHMENT GAP: no transcript data" and score intent as neutral (no deduction). If company-researcher fails, omit external triggers only.
  • Deal Quality: If any enrichment source fails, note which cross-source comparisons are unavailable. Score only available comparisons.
• Opp Velocity Score MUST include a 1-2 sentence justification citing specific signals. Never assign a score without evidence.
• Opp Velocity cross-source signals are only available in connected mode (when Step 2 enrichment ran). In standalone mode, score using quantitative SF signals only.
• NEVER fabricate deal details from vague descriptions; ask for specifics.
• NEVER characterize deals as "fictitious," "dead," or recommend removal based solely on SF activity dates. Cross-source confirmation is required.
• Dead weight detection requires checking ALL available sources. 60+ days no activity across ANY source is the threshold.
• If an enrichment agent returns <500 chars but reported tool_uses >5, its output was truncated. Read the file it wrote to /tmp/pipeline-review/ instead. If no file exists either, note the enrichment gap and do NOT penalize those deals in scoring.
• run_in_background: true is banned for sub-agents (MCP tools unavailable in background).
• Sub-agents write findings to /tmp/pipeline-review/ to prevent context pollution. Max 4 concurrent agents per dispatch wave.
• Pre-create /tmp/pipeline-review/ with mkdir -p before dispatching any agents.

References

• pipeline-data.md: Stage probabilities, SOQL queries, input parsing rules, stage normalization, velocity benchmarks
• health-score-methodology.md: 4-dimension scoring rubrics, decay thresholds, deduction formulas
• enrichment-rubrics.md: Dispatch prompt rubrics for all 7 enrichment agents with signal extraction instructions
• deep-research-dispatch.md: Shared dispatch guidance for deep-research-agent: query construction, when to dispatch, failure handling