Uma Claude Skill que extrai o pipeline aberto de um único rep, compara commit / best-case / upside com o snapshot da semana anterior, aprofunda os três principais commits com atividade recente e lista perguntas específicas que o gestor deve fazer na 1:1 semanal de forecast — extraídas de uma biblioteca de perguntas indexada por padrão de movimento, não inventadas a cada execução. O output é um briefing Markdown de uma página que o gestor lê nos cinco a dez minutos antes da chamada. A Skill nunca produz um número de forecast, nunca compartilha o briefing automaticamente e nunca compara reps entre si.
Quando usar
Você é um gestor de vendas com três a dez subordinados diretos que realiza uma 1:1 semanal de forecast com cada um. Você quer que cada chamada comece com a mesma profundidade de contexto de dados — não apenas os reps barulhentos com negociações bagunçadas — e não tem noventa minutos por semana por rep para revisar manualmente o pipeline antes de cada chamada. A Skill reduz o loop de “snapshot-diff mais pull-atividade-recente mais rascunho-de-perguntas” de aproximadamente 45 a 90 minutos por rep para cerca de 10 minutos de revisão de um briefing em formato fixo. Para uma equipe de seis reps, isso é a diferença entre realmente fazer o prep de forecast na manhã de segunda-feira e pular três semanas de cada quatro.
Use semanalmente, no mesmo dia, antes do mesmo conjunto de 1:1s. Prep diário é exagero (snapshots de forecast não mudam tão rápido e você vai se condicionar a reagir a ruído). Prep mensal é raro demais (a atividade recente fica defasada e você está lendo o movimento da semana cinco em um negócio que já fechou ou já morreu). Domingo à noite ou segunda de manhã, antes da primeira 1:1 da semana, é a janela para a qual a biblioteca de perguntas e a lógica de snapshot-diff foram ajustadas.
Quando NÃO usar
Produzir o número de forecast que você comunica para cima. Esta Skill prepara você para uma conversa sobre o número do rep. O rep é dono do número, você o calibra, e um LLM não o gera. Números de commit gerados automaticamente são como a cultura de forecast é jogada — quando o rep sabe que um modelo está produzindo a chamada, ele começa a encaixar as notas de pipeline no que o modelo recompensa.
Prep para board, roll-ups de QBR ou qualquer output que saia da sua mesa sem você ler e editar primeiro. O briefing é um documento privado de preparação. Encaminhar o output bruto da Skill para o rep, para o VP ou para cima transforma correspondências de padrões incompletas em um veredicto que o gestor na verdade não emitiu. O bundle não inclui hook de auto-compartilhamento de propósito.
Reps que você não gerencia diretamente. A Skill verifica o gerente-de-registro antes de carregar qualquer dado de pipeline e recusa em caso de incompatibilidade. Briefings de forecast de gestor errado expõem contexto negócio a negócio que o invocador não deveria ver — o modo de falha de vazamento de dados de maior impacto que esta Skill poderia causar se desprotegida.
Reps em rampa nos primeiros 30 dias. O movimento semana a semana no pipeline de um rep em rampa é majoritariamente ruído — eles estão aprendendo o que cada estágio realmente significa, não sinalizando saúde do negócio. Um briefing de segunda sinalizando “thrashing” em um rep que está apenas descobrindo as definições de estágio é o tipo de falso positivo que erode a confiança em todo o loop. Aguarde até que eles tenham três semanas limpas de atividade de pipeline.
Pipelines puramente de renovação ou customer-success. O rubric aqui é construído para o movimento de commit / best-case / upside de novos negócios. O forecast de renovação tem sinais diferentes — tendências de uso, NPS, cláusulas plurianuais, mudanças de sponsor executivo — que esta Skill não analisa. Use uma ferramenta ou workflow específico de renovação para pipelines de CS.
Configuração
Adicione o bundle. A Skill, o formato do briefing, a biblioteca de perguntas e o template de deep-dive por negócio estão em apps/web/public/artifacts/forecast-meeting-prep-skill/SKILL.md e nos três arquivos em apps/web/public/artifacts/forecast-meeting-prep-skill/references/. Copie o diretório para ~/.claude/skills/forecast-meeting-prep/ ou para o .claude/skills/ do seu projeto de equipe para que o Claude Code o reconheça.
Conecte o Salesforce (ou seu CRM). Service user com acesso de leitura a Opportunity, OpportunityHistory, OpportunityFieldHistory, Task, Event e ForecastingItem. Escopos api e refresh_token. A Skill armazena em cache o token OAuth por uma hora para que briefings seguidos para vários reps não precisem de re-autenticação. A Skill respeita as permissões por usuário no CRM; se você não consegue ver os negócios de um rep na UI, a Skill também não consegue — esse é o comportamento correto.
Configure o job de snapshot. O diff no passo 2 da Skill precisa do snapshot do pipeline da semana passada no mesmo formato de colunas do snapshot desta semana. Qualquer coisa que gere pipeline_<rep_id>_YYYY-MM-DD.csv em S3 ou Drive toda sexta às 18h funciona. A Skill recusa se houver drift de schema entre snapshots, portanto não mude as colunas no meio do trimestre sem re-executar o job de snapshot para as semanas anteriores.
Substitua os templates pelos seus artefatos reais. O bundle inclui três arquivos de referência placeholder. Cada um é genérico até você preenchê-lo com o conteúdo da sua equipe:
references/01-briefing-format.md — o formato Markdown literal que cada briefing semanal usa. O formato fixo é o ponto; não o regenere por execução.
references/02-question-library.md — seu catálogo de perguntas para chamadas de forecast, indexado por padrão de movimento. O piloto vem com sete padrões (commit adicionado sem aparição prévia em best-case, commit caído, avanço de estágio sem atividade, drift de data de fechamento, paralisado, thrashing, flag repetida). Adicione padrões que correspondam às definições de estágio e ao vocabulário da sua equipe.
references/03-deal-deepdive-template.md — o bloco por negócio que a Skill renderiza para cada top commit. Mesmo formato por negócio para que o gestor faça um scan dos três principais de relance.
Decida sua cadência semanal e sequência de 1:1. O briefing foi projetado para ser lido uma vez, nos cinco a dez minutos antes de cada 1:1. Execute a Skill em lote na manhã de segunda para cada rep, arquive cada briefing em suas notas de gestor e, em seguida, leia cada um ao entrar na 1:1 correspondente. Não pré-compartilhe o briefing com o rep — as perguntas no briefing são do gestor, não um prompt de preparação do rep.
O que a skill realmente faz
Seis passos, em ordem, sem paralelização:
Verifica o gerente-de-registro no CRM. Recusa total se o usuário invocador não for o gestor direto do rep. Sem briefing parcial, sem sugestão de contorno.
Calcula o delta commit-vs-real primeiro — commit total, best-case e upside semana a semana, mais movimentos por oportunidade entre categorias. O delta é calculado antes de qualquer pull de atividade porque cada passo posterior (quais negócios aprofundar, quais perguntas surfacear) é indexado pelo que se moveu. Drift de schema entre snapshots também resulta em recusa total aqui.
Classifica os principais commits por um composto de tamanho do negócio, dias até o fechamento, qualquer movimento semana a semana e “nenhuma atividade nos últimos 14 dias.” Pega os três primeiros (padrão; configurável até cinco). O limite existe porque briefings que tentam aprofundar doze negócios são folheados; briefings em três são usados.
Extrai atividade recente por top commit — últimos 14 dias de e-mails, reuniões, chamadas (apenas títulos, nunca transcrições), conclusões de tarefas, histórico de estágio. Ruído auto-registrado (e-mails de sistema, recusas de calendário, sequências de BCC em massa) é filtrado antes da contagem. Negócios com zero atividade significativa são sinalizados como paralisados; negócios com mais de cinco mudanças de estágio na janela são sinalizados como thrashing.
Combina padrões de perguntas de 02-question-library.md com os movimentos detectados nos passos 2 e 4. A biblioteca é indexada por padrão, não por tamanho do negócio ou por rep. Se um padrão de movimento não corresponder a nenhuma entrada da biblioteca, a Skill surfacea o movimento abertamente e escreve “nenhuma pergunta da biblioteca corresponde; gestor deve redigir” — nunca inventa uma pergunta genérica para preencher o slot.
Renderiza o briefing no formato fixo de 01-briefing-format.md. A ordem das seções não muda entre as semanas; a escolha de engenharia é deliberada para que o gestor faça um scan do mesmo layout toda segunda e perceba o que mudou.
A seção de perguntas é o output mais importante. “Como está o negócio?” é inútil. “Me leve pelo que mudou na Acme entre a última sexta e hoje que a colocou direto em commit” é uma pergunta que o rep pode responder especificamente, que o gestor pode verificar no snapshot da próxima semana, e que a biblioteca de perguntas é construída para produzir perguntas dessa forma específica por padrão detectado.
Realidade de custos
Por briefing (um rep, três commits de deep-dive, ~14 dias de atividade filtrada, Claude Sonnet 4.5):
Aproximadamente 40k tokens de input — ambos os snapshots, metadados das oportunidades top-N, log de atividade filtrado por top commit, os três arquivos de referência. Cerca de US$0,12 pelo preço atual do Sonnet.
Aproximadamente 1,5k tokens de output para o briefing em si. Cerca de US$0,02.
Em torno de US$0,15 por rep por semana, US$0,60 por rep por mês.
Para um gestor de seis reps, isso é cerca de US$4 por mês em custo de tokens. O acesso à API do CRM está incluído se você já tem Salesforce; o armazenamento de snapshot no S3 ou Drive é essencialmente gratuito neste volume.
Tempo economizado por gestor por semana: aproximadamente 60 minutos de prep manual de forecast por rep se reduzem a cerca de 10 minutos de revisão do briefing. Para seis reps, isso é aproximadamente cinco horas de volta por semana. O piso realista é mais próximo de três horas de volta quando você considera que as conversas de 1:1 duram um pouco mais porque as perguntas são mais precisas — o que é exatamente o ponto.
Métrica de sucesso
Observe um número por um trimestre: percentual de 1:1s semanais de forecast onde o rep referencia o padrão sinalizado pelo briefing sem ser provocado. Se acima de 50% até a semana 6, a biblioteca de perguntas está calibrada para os padrões de negócio reais da sua equipe e o briefing está funcionando como iniciador de conversa em vez de veredicto. Se abaixo desse limite, as perguntas são genéricas demais ou o rep não as vê como relevantes — atualize a biblioteca de perguntas contra os post-mortems de negócios reais do último trimestre.
Sinais secundários (mais lentos, mais ruidosos): acurácia de commit semana a semana, taxa de slip de forecast no final do trimestre, qualidade de 1:1 avaliada pelo gestor, percentual de 1:1s em que o rep sinaliza um risco de negócio antes do gestor.
vs alternativas
Prep manual de forecast do zero. Melhor fidelidade se o gestor realmente o fizer semanalmente. O problema é consistência: sob carga, o prep manual pula os reps estáveis para focar no bagunçado, a profundidade do prep varia semana a semana e as perguntas derivam para o genérico (“como está a Acme?”) porque não há biblioteca fixa. A Skill não produz um prep melhor do que um ótimo gestor com tempo infinito; ela produz um prep consistente para o mesmo gestor sob carga realista.
Features de forecast do Clari. Clari é construído para o número de forecast em si — o roll-up, a calibração do commit, a pontuação negócio a negócio. É excelente em “qual é o número da equipe” e em sinalizar negócios em risco contra padrões históricos. O que ele não faz é gerar um briefing de conversa de 1:1 por rep com perguntas específicas extraídas de uma biblioteca que o gestor possui. Você pode combinar: Clari para o número e a detecção de padrões no nível da equipe, esta Skill para o prep de conversa semanal por rep.
Gong Forecast. Mais forte quando o sinal que você quer é “o que o cliente realmente disse nas chamadas recentes” — a camada de transcrição do Gong alimenta sua pontuação de negócios de forecast diretamente. Esta Skill deliberadamente não extrai transcrições (apenas títulos) para manter o briefing escaneável em 10 minutos e para manter a superfície de privacidade pequena. Se você quiser sinal de forecast no nível do conteúdo de chamada, Gong é a ferramenta certa; para “o que devo perguntar ao rep sobre o diff de snapshot,” esta Skill é.
Status quo. “Vou fazer o prep de forecast logo após a limpeza do pipeline.” A limpeza do pipeline nunca está feita. A 1:1 começa com “então, como está tudo?” e termina com o rep saindo sem se sentir visto. O status quo é a alternativa que a maioria dos gestores está na verdade escolhendo.
Pontos de atenção
Surfacear reps como bons ou ruins com base em dados defasados. Um rep cujo commit caiu esta semana pode ter feito a coisa certa (tirou um negócio honestamente paralisado do commit antes que ele escorregasse) e um rep cujo commit cresceu pode estar sandbagando um slip. Proteção: o briefing reporta movimento e padrões e nunca pontua o rep, nunca classifica reps entre si, e a biblioteca de perguntas é construída em torno do enquadramento de “me ajude a entender” em vez de “se explique.” Veja apps/web/public/artifacts/forecast-meeting-prep-skill/references/02-question-library.md para as regras de enquadramento de perguntas. O gestor aplica o contexto fora dos dados (histórico de 1:1, nuances do negócio que o snapshot não mostra) antes de tirar qualquer conclusão.
Drift de qualidade de perguntas específicas. Com o tempo, a biblioteca de perguntas pode colapsar nas mesmas três perguntas para cada padrão de movimento, e o rep para de se engajar porque toda segunda soa igual. Proteção: cada entrada na biblioteca de perguntas carrega uma data last_used que a Skill incrementa quando seleciona a pergunta para um rep; a Skill prepende um aviso quando a pergunta correspondida foi usada neste rep mais de três semanas no último trimestre; o plano de rollout prevê uma atualização trimestral da biblioteca de perguntas contra os post-mortems de negócios reais do último trimestre. Veja apps/web/public/artifacts/forecast-meeting-prep-skill/references/02-question-library.md.
Contexto faltante que o gestor tem das 1:1s anteriores. A Skill vê dados de pipeline e logs de atividade. Ela não vê o que o rep disse ao gestor sobre o negócio na última 1:1, o que o champion mencionou no corredor ou o que o procurement está fazendo no lado do cliente. Proteção: o briefing é explicitamente enquadrado como “o que os dados mostram,” a biblioteca de perguntas é construída no enquadramento de “me ajude a entender a lacuna,” e o gestor sempre edita antes da chamada. O output da Skill sem revisão do gestor é uma correspondência de padrão incompleta, não um veredicto.
Higiene de snapshot. Se o snapshot semanal perder uma semana, o diff no passo 2 vai alucinar movimento em escala (cada negócio parece ter se movido). Proteção: a Skill compara timestamps de snapshot e recusa se a lacuna exceder 10 dias, e recusa em caso de drift de schema entre snapshots. Melhor retornar “lacuna de snapshot, sem briefing” do que renderizar um briefing incorreto com confiança.
Auto-compartilhamento intencionalmente não está no bundle. O briefing é prep privado. Conectá-lo a um canal do Slack, enviá-lo ao rep ou alimentá-lo no roll-up ascendente quebra o modelo de confiança — o rep começa a escrever notas de pipeline para o briefing, não para o cliente, e o briefing colapsa de “o que os dados mostram” para “o que o modelo recompensa.”
Stack
Salesforce (ou seu CRM) — fonte de verdade para o conjunto de oportunidades, verificação do gerente-de-registro, log de atividade
S3 ou Google Drive — armazenamento de snapshot semanal para o diff semana a semana
Claude (Sonnet 4.5 ou superior) — narração do diff de snapshot, detecção de padrões, seleção de perguntas, renderização em formato fixo
Formato do briefing, biblioteca de perguntas, template de deep-dive — os três arquivos de referência em apps/web/public/artifacts/forecast-meeting-prep-skill/references/ que transformam um prompt genérico de “resuma este pipeline” em um loop de prep de forecast semanal que sua equipe possui
---
name: forecast-meeting-prep
description: Generate a one-page briefing for a sales manager's weekly forecast call. Pulls the rep's open pipeline, diffs commit / best-case / upside against last week's snapshot, deep-dives the top three commits, and lists specific questions the manager should ask the rep — based on actual movement patterns, not generic forecast hygiene. Output is a Markdown document the manager reads on the way to the call. Never produces forecast numbers; never auto-shares with the rep.
---
# Forecast meeting prep
## When to invoke
Invoke when a sales manager is preparing for a weekly one-on-one forecast call with a single rep. Take a rep ID, the current week's forecast snapshot, and last week's snapshot as input. Produce a Markdown briefing the manager reads in the five to ten minutes before the call.
Do NOT invoke for:
- **Producing the actual forecast number to commit upward.** This Skill prepares the manager for a conversation about the rep's number; the rep owns the number, the manager calibrates it, the Skill does not generate it. Auto-generated commit numbers are how forecast culture gets gamed.
- **Board prep, QBR roll-ups, or any output that leaves the manager's desk without manager review.** The briefing is a private prep doc. Surfacing it to the rep, the VP, or the board without the manager reading and editing first turns half-formed pattern matching into a verdict.
- **Reps the invoking user does not directly manage.** The Skill checks the requesting user's manager-of-record status against the rep ID and refuses on mismatch. Wrong-manager forecast briefings expose deal-by-deal context the invoker should not see.
- **A new rep in their first 30 days.** Week-over-week movement on a ramping rep's pipeline is mostly noise — they are learning the stages, not signaling deal health. Wait until the rep has three clean weeks of pipeline activity before relying on this Skill.
- **Renewal-only books or pure CS pipelines.** The rubric here is built for new-business commit / best-case / upside motion. Renewal forecasting has different signal (usage, NPS, multi-year clauses) that this Skill does not look at.
## Inputs
- Required: `rep_id` — the CRM user ID for the AE being prepped.
- Required: `manager_id` — the CRM user ID of the invoking manager. Used to verify manager-of-record before any pipeline data loads.
- Required: `current_snapshot` — path or ID of this week's pipeline snapshot CSV (commit, best-case, upside flagged per opportunity).
- Required: `prior_snapshot` — path or ID of last week's snapshot in the same shape. The Skill expects identical column structure week-over-week and refuses on schema drift.
- Optional: `top_n_commits` — how many top commits to deep-dive on. Default 3. The cap exists because four-plus deep-dives turn the briefing into a deck the manager will not read in five minutes.
- Optional: `activity_window_days` — how far back to pull recent activity per top commit. Default 14. Older activity is too stale to be a current-quarter signal.
- Optional: `prior_briefing` — path to last week's prep briefing for this same rep, if it exists. Used to flag patterns repeating week-over-week ("third week in a row this deal slipped a stage").
## Reference files
Read all of the following from `references/` before generating the briefing. Without them, the output reads like a generic forecast-call checklist that any sales blog could produce.
- `references/01-briefing-format.md` — the literal Markdown shape every weekly briefing uses. Fixed format is deliberate so the manager scans the same sections in the same order every week.
- `references/02-question-library.md` — the manager's catalog of forecast-call questions, indexed by deal pattern (slipped close date, stage advance with no activity, commit added with no prior best-case appearance, etc.). The Skill picks from this library rather than inventing questions.
- `references/03-deal-deepdive-template.md` — the per-deal block the Skill fills in for each of the top commits. Same shape per deal so the manager can compare across the top three at a glance.
## Method
Run these steps in order. Do not parallelize — later steps depend on data from earlier steps, and the manager-of-record check must run before any pipeline content is loaded.
### 1. Verify manager-of-record
Query the CRM for the rep's manager-of-record. If it does not match `manager_id`, refuse the request and return:
```
Refused: <manager_id> is not the manager of record for <rep_id>. Forecast prep briefings are written for the direct manager only.
```
This is a hard refusal. Do not produce a partial briefing, do not suggest workarounds. Wrong-manager forecast content is the highest-impact data-leakage failure mode this Skill could enable.
### 2. Diff commit-vs-actual delta first
Before pulling activity, compute the week-over-week delta on the forecast categories themselves: total commit, total best-case, total upside, plus per-opportunity moves between categories. Pull this first because the delta frames every other section — a $400k commit that lost $120k overnight changes which deals the deep-dive prioritizes, and the question library indexes by movement pattern (category change, amount change, close-date drift) rather than by deal size.
If schema drift is detected (column added, removed, or renamed between snapshots), stop and return:
```
Schema drift detected between snapshots. Columns differ: <list>. Re-run after the snapshot job is reconciled.
```
Hallucinating diffs across mismatched schemas is the failure mode this guard rules out.
### 3. Rank top commits for deep-dive
Take the current week's commit set and rank by a composite of: deal size, days-to-close, week-over-week movement (any move = higher rank), and "no activity in last 14 days" (any silence = higher rank). Take the top `top_n_commits` (default 3).
The engineering choice to focus the deep-dive on three deals (not all of them) is bounded by what the manager can actually talk through in a 30-minute one-on-one. Briefings that try to cover twelve commits get skimmed; briefings on three get used.
### 4. Pull recent activity per top commit
For each of the top commits, pull the last `activity_window_days` of activity: emails logged, meetings, call recordings (titles only — not transcripts), task completions, stage history. Filter out auto-logged noise (system emails, calendar declines, BCC-blast sequences) before counting.
Surface the deal as "stalled" if there are zero meaningful activities in the window. Surface as "thrashing" if there are more than five stage changes in the window (real deals do not move that much; the rep is gaming the pipeline view).
### 5. Match question patterns from the library
For each top commit and each notable category-level movement, look up the relevant question pattern in `02-question-library.md`. Engineering choice: the question library is per-pattern, not per-deal-size or per-rep, because the same patterns repeat across deals — "commit added this week with no prior best-case appearance" calls for the same conversation regardless of whether it is a $50k deal or a $500k one.
If `prior_briefing` is provided, cross-check: is this the same pattern flagged on this deal last week? If yes, escalate the question ("Third week in a row we are flagging this — what changed in the deal that did not change in the data?").
If no library question matches a movement pattern (rare, but possible), surface the movement openly and write "no library question matches; manager to draft." Never invent a generic question to fill the slot — generic questions are the failure mode this guard rules out.
### 6. Render the briefing
Use the format in `01-briefing-format.md` exactly. Engineering choice: the format is fixed so the manager scans the same sections in the same order every week and notices what changed week over week.
## Output format
```markdown
# Forecast prep — {Rep name}, week of {YYYY-MM-DD}
Manager: {Manager name}
Snapshots: this week ({date}) vs last week ({date})
Pipeline rolled up: ${commit total} commit / ${best-case total} best-case / ${upside total} upside
## Week-over-week movement
- Commit: ${last_week} → ${this_week} ({+/- $delta}, {+/- %})
- Best-case: ${last_week} → ${this_week} ({+/- $delta}, {+/- %})
- Upside: ${last_week} → ${this_week} ({+/- $delta}, {+/- %})
Notable category moves:
- {Deal name} — moved from {prior category} to {current category} ({reason if visible from activity})
- {Deal name} — close date slipped from {prior date} to {current date}
- {Deal name} — added to commit this week, no prior appearance in best-case
## Top {N} commits — deep dive
### 1. {Deal name} — ${amount}, close {date}
- Stage: {current} (was {prior, if changed})
- Activity in last {window} days: {meaningful_count} touches ({email/meeting/call counts})
- Last meaningful activity: {date} — {one-line summary}
- Movement this week: {category move | amount change | close-date drift | none}
- Pattern flag: {stalled | thrashing | repeat-flag-from-prior-week | clean}
### 2. {Deal name} — ${amount}, close {date}
(same shape)
### 3. {Deal name} — ${amount}, close {date}
(same shape)
## Questions for the rep this week
(Specific, sourced from the question library against the patterns above. Two to five questions, never generic.)
1. **{Pattern}.** "{question pulled from 02-question-library.md, deal name substituted}"
2. **{Pattern}.** "{question}"
3. **{Pattern}.** "{question}"
## Other deals worth a sentence
(One line each — deals that moved but did not make the top three. Not deep-dived.)
- {Deal name} — {one-sentence movement summary}
- {Deal name} — {one-sentence movement summary}
---
Draft by forecast-meeting-prep skill. Manager reviews and edits
before the 1:1; this briefing is private prep, not auto-shared with
the rep or rolled up.
```
## Watch-outs
- **Surfacing reps as good or bad based on lagging data.** A rep whose commit dropped this week may have done the right thing (pulled an honestly-stalled deal out of commit) and a rep whose commit grew may be sandbagging a slip. Guard: the briefing reports movement and patterns; it never scores the rep, never ranks reps against each other, and the question library is built around "help me understand" framing rather than "explain yourself" framing. The manager applies the off-data context (1:1 history, deal nuance the data does not show) before drawing any conclusion.
- **Specific-question quality drift.** Over time, the question library can collapse into the same three questions for every movement pattern, and the briefing becomes background noise the rep stops engaging with. Guard: every question in `02-question-library.md` carries a `last_used` date; the Skill prepends a warning when the matched question has been used on this rep more than three weeks in the last quarter, and the rollout plan includes a quarterly question-library refresh.
- **Missing context that the manager has from prior 1:1s.** The Skill sees pipeline data and activity logs. It does not see what the rep told the manager about the deal in the last 1:1, what the champion mentioned in a hallway, or what the customer's procurement team is doing. Guard: the briefing is explicitly framed as "what the data shows," the question library is built on "help me understand the gap" framing rather than "the data says X therefore Y," and the manager always edits before the call. The Skill output without manager review is a half-formed pattern match, not a verdict.
- **Snapshot hygiene.** If the weekly snapshot misses a week, the diff in step 2 will hallucinate movement at scale (every deal looks like it moved). Guard: the Skill compares snapshot timestamps and refuses if the gap exceeds 10 days. Better to return "snapshot gap, no briefing" than render a confident wrong briefing.
- **Auto-share is out of scope.** The briefing is a manager prep document. Never wire this into a Slack channel, never send it to the rep, never feed it into the upward roll-up. The bundle ships no auto-send hook; adding one breaks the trust model.
# Briefing format — TEMPLATE
> Replace this template's contents with your team's actual briefing
> shape. Keep the section order fixed across weeks so the manager
> scans the same layout every Monday and notices what changed.
## Why a fixed format
The manager reads this in the five to ten minutes before a 1:1. Layout-shopping is friction. Every section appears in the same place every week so eye-line goes straight to "what changed."
## Section order (do not reorder)
1. **Header** — rep name, week, manager, snapshot dates, top-line roll-up of commit / best-case / upside totals. One block.
2. **Week-over-week movement** — three lines for the category totals plus a bulleted list of notable category-level moves (not deal deep-dives — those come later).
3. **Top N commits — deep dive** — one block per deal in the format defined in `03-deal-deepdive-template.md`. Default N = 3.
4. **Questions for the rep this week** — two to five specific questions pulled from `02-question-library.md`. Each question carries the pattern that triggered it, in bold, before the question text.
5. **Other deals worth a sentence** — one line per deal that moved but did not make the top three deep-dive list. Cap at ten lines total; longer is briefing-as-list and gets skimmed.
6. **Footer** — one-line provenance line stating the briefing was drafted by the Skill, the manager reviews before the 1:1, and the briefing is not auto-shared.
## Tone
- Reporter, not judge. "Commit dropped $120k week-over-week" not "rep sandbagged commit."
- Specific, not generic. "Deal X moved from best-case to commit this week with no prior best-case appearance" not "some movement in the commit category."
- Question framing in the questions section is "help me understand" not "explain yourself." Forecast calls go badly when reps feel cornered; this briefing primes the manager toward curiosity.
## What the format does not include
- Rep score / grade / ranking against other reps. The Skill is per rep and never aggregates across reps.
- A recommended commit number. The rep owns the number; the Skill does not produce one.
- Any prediction about whether the deal closes. The Skill describes movement; the manager and rep judge probability.
## Last edited
{YYYY-MM-DD}
# Forecast question library — TEMPLATE
> Replace this template with your team's actual question catalog.
> The Skill picks questions from this library by matching the deal
> movement pattern, rather than inventing a question per run.
> Every entry carries a `last_used` date the Skill bumps when it
> picks the question for a given rep, so over-use is visible and the
> question library can be refreshed quarterly.
## How questions are indexed
Each question is filed under one or more **movement patterns**. The Skill detects the pattern from the snapshot diff and pulls one question per pattern triggered for the top-N commits. Patterns are mutually compatible — a deal can fire two patterns and pull two questions.
If you add or rename a pattern here, update the pattern detection logic in the Skill so detection and question retrieval stay in sync.
## Pattern: commit added with no prior best-case appearance
**What it means.** A deal showed up in the commit column this week that was not in best-case last week. The rep skipped the normal escalation path (upside → best-case → commit). Either the deal genuinely moved that fast (rare) or the rep is filling a commit gap.
Questions:
- "Walk me through what changed on {deal} between last Friday and today that took it straight to commit."
- "Who at {customer} confirmed verbally that they are committing this quarter, and when did that conversation happen?"
- "If we were doing this same call two weeks ago, would {deal} have been in upside, best-case, or not on the list at all?"
## Pattern: commit dropped, deal moved to best-case or upside
**What it means.** A deal in commit last week moved down a category this week. Could be honest (deal genuinely slipped) or could be a late tell that the deal was never really committed.
Questions:
- "What specifically did the customer say or do that moved {deal} out of commit?"
- "Was anything new in the deal last week that we missed, or did the signal we already had finally land?"
- "What would have to be true for {deal} to come back into commit by end of quarter?"
## Pattern: stage advance with no corresponding activity
**What it means.** Deal moved from one stage to a later stage this week, but the activity log shows no meaningful customer touch (meetings, emails, calls) tied to that move. Often the rep is hygiene-cleaning the pipeline and the move is administrative, not substantive.
Questions:
- "{Deal} advanced from {prior stage} to {current stage} this week. What conversation triggered that move?"
- "Is there a meeting, an email, or a verbal commitment we should log against this stage change so the next person reading the account understands?"
## Pattern: close-date drift (slipped > 7 days)
**What it means.** Close date moved out by more than a week. Once-off slips are normal; repeat slips on the same deal are a tell.
Questions:
- "What is the customer-side reason {deal} slipped from {prior date} to {current date}?"
- "How many times has the close date on {deal} moved this quarter, and what was the reason each time?"
- "Are we at a point where the close date is the customer's ask, or are we still telling the customer when we want to close?"
## Pattern: stalled (zero meaningful activity in window)
**What it means.** No customer-side touch in the last 14 days on a deal that is still in commit.
Questions:
- "When was the last time you heard from anyone at {customer} on {deal}, and what did they say?"
- "Who is owning the next step on the customer side, and what is their stated timeline?"
- "Should {deal} still be in commit if we have not heard from them in two weeks?"
## Pattern: thrashing (more than five stage changes in window)
**What it means.** Deal stage moved more than five times in two weeks. Real deals do not move that much; either the stage definitions are unclear or the rep is gaming pipeline hygiene reports.
Questions:
- "{Deal} has moved stage five-plus times in the last two weeks. What is actually happening on the customer side?"
- "Are our stage definitions clear enough on this one, or do we need to talk through what {current stage} means for this deal?"
## Pattern: repeat flag from prior week
**What it means.** Same pattern flagged on the same deal in the prior briefing. Either the issue did not get addressed, or the underlying signal is real and ongoing.
Questions:
- "We flagged {pattern} on {deal} last week as well. What changed this week, if anything?"
- "Is this turning into a deal where the data is telling us something the rep narrative is not?"
## Last edited
{YYYY-MM-DD}
# Deal deep-dive block — TEMPLATE
> Replace this template with your team's actual per-deal block. Keep
> the field order fixed across deals and across weeks so the manager
> can scan the top three deep-dives at a glance and compare like for
> like.
## The block
```markdown
### {Rank}. {Deal name} — ${amount}, close {date}
- Stage: {current stage} (was {prior stage, if changed in window})
- Forecast category: {commit | best-case | upside} (was {prior, if changed})
- Activity in last {window} days: {count} meaningful touches
({email count} emails, {meeting count} meetings, {call count} calls)
- Last meaningful activity: {date} — {one-line summary, no transcripts}
- Movement this week: {category move | amount change | close-date drift | stage change | none}
- Pattern flag: {stalled | thrashing | repeat-flag-from-prior-week | clean | other}
- Notes from prior briefing (if any): {one line, only if same deal flagged last week}
```
## Field rules
- **Amount and close date** come straight from the snapshot. No derivation, no rounding, no projection.
- **Activity counts** are post-filter. Auto-logged emails, calendar declines, BCC-sequence sends, and bounce notifications are excluded before counting. The Skill never inflates activity by counting noise.
- **Last meaningful activity** is one line. Title or subject line of the activity, plus date. Never a transcript, never a quote — those belong in the source system, not in a prep briefing.
- **Movement** lists every dimension that changed week-over-week. If multiple changed, list all of them; the manager decides which matters most for the conversation.
- **Pattern flag** is the worst-case flag fired by the deal across the patterns in `02-question-library.md`. If multiple patterns fired, the flag is "multiple" and the questions section will surface one question per pattern.
- **Notes from prior briefing** appear only when `prior_briefing` was passed as input and the same deal was flagged. Otherwise omit the line — do not pad with "no prior context."
## What goes here vs what goes in the questions section
This block is reporting (what the data shows). The questions section is conversation (what the manager asks). Do not collapse them — a manager scanning the deep-dive on the way to a 1:1 needs to hold the data in their head before they get to the questions.
## Last edited
{YYYY-MM-DD}