claude-skill

Weekly pipeline review report from HubSpot with Claude

Difficulty

intermediate

Setup time

30min

For

revops

RevOps

Stack

A Claude Skill that takes two HubSpot pipeline snapshots — this Monday’s and last Monday’s — slices them by segment, and writes the one-page brief the sales VP reads before the Monday pipeline review. Every metric carries a movement-direction word. Every claim is flat — there is a hedge-removal pass. The output sits at the top of #pipeline-review at six on Monday morning and the leadership thread is already arguing about the right thing by the time the call starts.

When to use

You are a RevOps lead or sales operations manager and your sales VP runs a Monday pipeline review. You have a HubSpot pipeline that you can extract via the deals API. You want the standing brief at the top of the thread on Monday morning to be written, not skipped, and you do not want to write it yourself every week.

The skill assumes the team is segment-aware — Enterprise / Mid-Market / SMB, or some equivalent slice — and that the VP wants to see segment-level deltas, not just one aggregate pipeline number. It assumes you have a snapshot of last week’s pipeline saved somewhere accessible. The first run produces a baseline brief; the second run onward produces a real WoW story.

The bundle is at apps/web/public/artifacts/weekly-pipeline-report-skill/. The skill body is SKILL.md; the templates the skill reads on every run are references/1-report-format-template.md, references/2-segment-mapping.md, and references/3-hedge-words-blocklist.md.

When NOT to use

Do not use this skill for board materials. The brief is operational — it uses last-week deltas and one-week-stale assumptions about what is real in the pipe. Board reporting needs reconciled, audited numbers from the finance system, not from a Monday morning Markdown file.

Do not use it for customer-facing reports. The brief names deals, owners, and risks in language that reads fine in an internal Slack channel and is unsafe to share externally. There is no anonymization pass; building one is out of scope.

Do not let anyone cite the headline number as the actual forecast. The brief summarizes pipeline composition and movement; it is not a forecast model. The forecast comes from the Friday forecast call, owned by the sales VP and the RevOps lead. The brief footer carries this disclaimer on every run — the disclaimer is in references/1-report-format-template.md and removing it defeats the guard.

If your team does not segment its pipeline, do not start by adopting this skill — start by writing references/2-segment-mapping.md for the team. The brief works without segments only as an aggregate-only baseline run, which is less useful than the same data in HubSpot’s own dashboard.

Setup

Drop the bundle into your Skills folder. Copy apps/web/public/artifacts/weekly-pipeline-report-skill/ into your Claude project under .claude/skills/weekly-pipeline-report/. Claude Code (or Claude.ai with a project-mounted MCP) discovers it on next launch.
Replace the three reference files. references/1-report-format-template.md is the literal layout the brief follows — edit it to change the report shape, do not edit SKILL.md. references/2-segment-mapping.md declares your segment rules; the placeholders ship as Enterprise/Mid-Market/SMB and you almost certainly want to change them. references/3-hedge-words-blocklist.md is a starting list; extend it whenever a hedge lands in production.
Configure the snapshot extractor. The skill consumes two snapshot files; it does not call the HubSpot API itself. Stand up a small extractor (cron job, n8n flow, scheduled GitHub Action) that hits /crm/v3/objects/deals with the columns the skill expects (deal_id, deal_name, owner_id, stage, amount, close_date, last_modified, plus whatever your segment rules reference) and writes one CSV or JSON file per Monday into a known directory. The extractor is the part of this stack that is HubSpot-specific.
Run the skill on Monday at 06:00. Invoke with two paths (pipeline_snapshot, previous_snapshot) and the segments file. Pipe the output to #pipeline-review or to the leadership distribution list. The first run sets comparison_mode = none and emits a baseline brief instead of fabricating zero-deltas.
Run the hedge-removal pass review weekly. Read the brief that landed. If a hedge slipped through (“appears to suggest”, “looks like it might”), add it to references/3-hedge-words-blocklist.md so the next week’s pass catches it. The blocklist is meant to evolve.

What the skill actually does

The method is in SKILL.md step-by-step. The engineering choices worth knowing about before you adopt it:

Segment-aware, not aggregate. A flat “pipeline up 4 percent” hides the case where Enterprise is down 12 and SMB is up 30 — opposite stories that demand opposite responses. The brief slices every metric by segment and rolls up to a headline only after. If a deal cannot be assigned to a segment it goes into a visible unsegmented bucket; never silently dropped.

Movement-direction stamped on every metric. Not just the headline. The VP scans the page in one pass — if only the top number carries a direction word, the rest reads as data and the eye skips it. Every cell in the segment table, every bullet in the headline list, is up +Z% or down -Z% or flat.

Top deals moving the number, not top deals by size. This section is about motion since last Monday — stage transitions, new adds, scope changes, slipped close dates. A static $500k deal that did nothing this week is not in the section. The deals that move the number this week are the ones the VP needs to ask about.

Top risks are the quietly-slipping deals. The loud risks (CFO email, “we lost”) get escalated through other channels. The brief surfaces deals that look fine in the board view but have been pushed twice, regressed a stage, had their amount cut by more than 25 percent, or sat dormant for 14+ days while still flagged as closing this quarter.

One pattern, one ask. The brief names a single biggest pattern and a single ask. Not five patterns and a five-bullet recommendations list. The brief is read in three minutes; one ask is a point of view, five is a list, and the difference is whether the VP walks into the room with a stance or with a survey.

Hedge-removal pass at the end. The model drafts the brief, then re-reads it against references/3-hedge-words-blocklist.md and rewrites any sentence that contains a blocked term. Hedging drifts in because the model is being polite about uncertain data; the brief is more useful when it states the observed pattern flatly and the reader pushes back than when every claim is pre-hedged. The pass is mechanical and it refuses to ship a brief that violates the blocklist.

Cost reality

Token cost per weekly brief is small. A 1,000-deal pipeline serializes to roughly 80-120k input tokens once both snapshots and the references are loaded. Output is around 600-900 tokens — the brief is one page on purpose. At Claude Sonnet pricing, the per-run cost lands in the single-digit-cents range. At Opus pricing, low double digits. Across a year of Mondays, this is a rounding error against the cost of any other pipeline-tooling line item.

Time saved per RevOps lead is the larger number. The Monday brief is typically 30-60 minutes of manual work — pulling the report, eyeballing the deltas, writing the narrative, posting it to Slack. Skill-authored, the cycle drops to under 5 minutes (read the draft, accept or rewrite the pattern paragraph, post). Across 50 Mondays a year that is roughly 25 hours back, which is real time even if the dollar value is hard to pin.

The hidden cost is the snapshot extractor. Standing up the cron job that writes two consistent CSVs is roughly half a day of one-time work. If your team does not already have an extract pipeline, count that work before claiming the skill is “free to adopt”.

Success metric

The metric that matters is whether the Monday brief gets read and referenced in the pipeline review. Two leading indicators that work in practice:

Did the VP cite the brief’s pattern paragraph in the meeting? Track this qualitatively for the first six weeks. If the VP is naming the pattern back during the review, the brief is doing its job. If the VP is reading from HubSpot dashboards and ignoring the Slack thread, the brief is not landing and the pattern paragraph needs work.
Time-to-first-question in the pipeline review. Before the skill, leaders spent the first 10 minutes orienting on what changed. After, they should walk in already arguing about the pattern the brief named. If orientation time has not dropped, either the brief is not being read or the pattern is not naming the right thing.

The lagging metric — pipeline accuracy or forecast accuracy — does not move because of this skill. The brief does not change what is in the pipe; it changes what the team talks about on Monday morning.

vs alternatives

HubSpot’s built-in dashboards. The HubSpot Sales Hub has a deals dashboard that shows pipeline by stage and owner, with WoW deltas if you build the report carefully. It does not produce a narrative — there is no top-3-moving, no top-3-risk, no pattern paragraph, no recommended ask. A team can run on dashboards alone and many do. The brief earns its keep when leadership wants the narrative pre-written rather than constructed live in the meeting.

Clari weekly briefings. Clari (or Gong Forecast, or BoostUp) ships a forecast tool with weekly summary capabilities. The briefings are credible and the underlying data layer is more reliable than a hand-rolled extractor. The trade-off: Clari’s seat license is in the four-figures-per-rep-per-year range, the briefings follow Clari’s opinionated shape rather than your VP’s, and you do not control the wording. The skill is the right answer when budget rules out a Clari and your team already has HubSpot.

Manual RevOps-written summary. The status quo for most teams. Quality is high when the RevOps lead has time to write it, low when they do not. The brief is consistent week to week — same shape, same metrics, same pattern-and-ask structure — which makes it easier for the VP to read. A senior RevOps lead can out-write the skill on any given Monday; the skill wins on consistency and on giving that lead 25 hours back per year for higher-leverage work.

Watch-outs

Confident-but-stale data. The HubSpot snapshot is only as fresh as the extractor’s last run. If last_modified on the snapshot file is more than 24 hours old, the brief prepends a one-line warning (“Snapshot is N hours stale — figures may not reflect Friday’s late-week activity”). Guard: the freshness check runs before any computation; the skill refuses to ship the brief without it.
Hedging language drifting in despite removal. The hedge-removal pass uses a fixed blocklist; new hedge phrasings the model invents will slip through. Guard: the blocklist at references/3-hedge-words-blocklist.md is meant to be extended weekly. The first month of running the skill will surface 5-10 new hedge phrasings; add them as you see them.
Downstream readers citing this as the forecast. The brief headlines an open-pipeline number, which a casual reader will round to “the forecast.” Guard: the brief footer always reads “Operational summary, not a forecast. Forecast is owned by <VP name> and produced in the Friday call.” The line is in references/1-report-format-template.md and removing it defeats the guard. Do not remove it.
Owner reassignments break WoW math. If a deal changed owner mid-week, both the old and new owners’ deltas fire — double-counting motion. Guard: the skill emits a “deals reassigned this week: N” footnote and excludes reassigned deals from the top-deals-moving section, so the move is not attributed to either owner. Pick a side (follow-the-deal or follow-the-owner) and document it in your team’s playbook.
Custom HubSpot stages not in the segment file. If your team renamed default stages, the segment-mapping rules that reference stage names break silently. Guard: the snapshot validator confirms every distinct stage value in the snapshot is referenced by at least one segment rule, and surfaces unmatched stages in the report footer. If a new stage shows up there, update references/2-segment-mapping.md.

Stack

HubSpot — pipeline source of truth and snapshot extractor input
Claude Skill — drafts the brief from the two snapshots and the references
Snapshot extractor (cron / n8n / GitHub Action) — writes the weekly CSV the skill consumes; the part of the stack that is HubSpot-specific
Slack — distribution channel for the rendered brief

Edit this page on GitHub

Files in this artifact

Download all (.zip)

---
name: weekly-pipeline-report
description: Produce the Monday-morning weekly pipeline brief for a sales VP from a HubSpot pipeline snapshot and last week's snapshot. Outputs a one-page markdown report with headline metrics, top deals moving the number, top risks, the single biggest pattern, and a recommended ask. Segment-aware. Stamps every metric with movement direction.
---

# Weekly pipeline report

## When to invoke

Invoke every Monday morning, before the sales VP's pipeline review, to produce the weekly brief that goes into Slack `#pipeline-review` or the Monday leadership thread. Input is a current HubSpot pipeline snapshot, last week's snapshot from the same extractor, and a segment-definitions file. Output is a single markdown report sized to fit on one screen — the VP reads it in under three minutes and walks into the review with a point of view.

Do NOT invoke this skill for:

- **Board materials.** The brief is operational. It uses last-week deltas and one-week-stale assumptions about what is real. Board reporting needs reconciled, audited numbers — pull those from the finance system, not from this skill.
- **Customer-facing reports.** The brief names deals, owners, and risks in language that is fine for an internal Slack channel and unsafe to share externally.
- **The actual forecast number.** This skill summarizes pipeline composition and movement. It is not a forecast model. Anyone citing the headline number as "the forecast" is misusing it. The forecast comes from the forecast call, owned by the sales VP and RevOps lead.

## Inputs

Required:

- `pipeline_snapshot` — path to the current HubSpot pipeline export (CSV or JSON), one row per open deal, with columns: `deal_id`, `deal_name`, `owner_id`, `stage`, `amount`, `close_date`, `last_modified`, `segment` (or a column the segment map can join on).
- `previous_snapshot` — path to last Monday's snapshot, same shape. Used for week-over-week deltas. If absent, the skill emits a "no comparison available" header instead of guessing direction.
- `segments` — path to `references/segment-mapping.md` (or a YAML/CSV of the same shape). Defines the segment slices the report uses.

Optional:

- `report_format` — path to `references/report-format-template.md`. If absent, the skill uses the embedded default in the Output format section below.
- `hedge_blocklist` — path to `references/hedge-words-blocklist.md`. The hedge-removal pass refuses to ship the brief while any blocked term appears in the draft.
- `top_n` — integer for "top N deals" and "top N risks" sections. Default `3`.

## Reference files

Read these from `references/` on every run. They are the levers the user adapts to their team — without them, the report is generic.

- `references/report-format-template.md` — the literal layout the brief follows, with placeholder blocks for headline metrics, top deals, top risks, the pattern, and the ask. The user edits this file to change the report shape; the skill does not invent its own layout.
- `references/segment-mapping.md` — defines the segments the report slices by (Enterprise / Mid-Market / SMB, or whatever the team uses) and the rule for assigning each deal to a segment when the snapshot does not carry one.
- `references/hedge-words-blocklist.md` — the wording rules. The hedge-removal pass rejects a draft if any of these appear. Replace as your team's vocabulary evolves.

## Method

Run these steps in order. Do not parallelize — later steps depend on earlier ones.

### 1. Load and validate both snapshots

Read `pipeline_snapshot` and `previous_snapshot`. Confirm that both share the same column shape and that `deal_id` is unique within each. If `previous_snapshot` is missing or the schema does not match, set `comparison_mode = none` and proceed — the brief will skip every WoW figure and label the header as a baseline run rather than fabricating zero-deltas.

### 2. Join to segment definitions

Apply `references/segment-mapping.md` to assign every deal to a segment. Engineering choice: segment-aware rather than aggregate. An aggregate "pipeline is up four percent" hides the case where Enterprise is down twelve and SMB is up thirty — opposite stories that the VP must respond to differently. The segment slice keeps the call honest. If a deal cannot be assigned to a segment, route it to a visible `unsegmented` bucket and surface the count in the report — never silently drop deals.

### 3. Compute headline metrics, segment-by-segment

For each segment compute: total open pipeline (sum of `amount`), deal count, average deal size, weighted pipeline (if probability data is present), pipeline by stage. For each metric: compute the WoW delta (absolute and percent) and a movement-direction label (`up`, `down`, `flat`). Engineering choice: include movement-direction on every metric, not just the headline. The VP scans the page in one pass. If only the top number carries direction, the rest reads as "data" instead of "story" and the eye skips it.

### 4. Identify the top deals moving the number

For each segment, rank deals by absolute change in `amount` or `stage` since `previous_snapshot`. Take the top `top_n` (default 3). For each: name, owner, amount, what changed (stage transition, amount adjustment, new add, slipped close date), and a one-line plain-English description of the move. Deals with no change do not appear here — this section is about motion, not size.

### 5. Identify the top risks

Rank deals by risk signal: stage regression, close date pushed for the second consecutive week, amount cut by more than 25 percent, or no activity for 14+ days on a deal forecast to close this quarter. Take the top `top_n`. For each: name, owner, the risk signal, and a one-line description. Engineering choice: surfaces deals that are *quietly* slipping. The loud risks (CFO email, "we lost") get escalated through other channels; this section is for the deals that look fine in the board view but smell off.

### 6. Find the single biggest pattern

Look across the segment metrics, the moving deals, and the risks. Name one pattern — e.g. "Enterprise pipeline is up but stage-1 dominates the add; the quarter is being filled with deals that will not close in it" or "Three of five top-risk deals are owned by the same AE." Engineering choice: one pattern, not five. The brief is read in three minutes. Five patterns is a list; one pattern is a point of view, which is what the VP needs to walk into the room with.

### 7. Recommend a single ask

Translate the pattern into one ask the VP can make of the room — "have the Enterprise lead defend the stage-1 quality of the new adds" or "review the pushed-twice deals owner-by-owner with the named AE." One ask. If the skill cannot produce one, it writes "no clear ask this week — pattern was diffuse" rather than padding.

### 8. Hedge-removal pass

Re-read the draft. If any term from `references/hedge-words-blocklist.md` appears (e.g. "may", "might", "could potentially", "appears to suggest"), rewrite the offending sentence. Engineering choice: hedging language drifts in because the model is being polite about uncertain data. The brief is more useful when it states the observed pattern flatly and lets the reader push back, than when it pre-hedges every claim. The hedge-removal pass is the guard against that drift — it is mechanical, run after the draft, and refuses to ship a brief that violates the blocklist.

## Output format

The brief follows this literal structure (also stored at `references/report-format-template.md` for the user to edit):

```markdown
# Weekly pipeline brief — {Week of YYYY-MM-DD}

## Headline (vs. last Monday)
- Total open pipeline: $X.XM (up $Y.YM, +Z%)
- Weighted pipeline: $X.XM (down $Y.YM, -Z%)
- Deal count: NNN (flat, +0)
- Avg deal size: $X.XK (up $Y.YK, +Z%)

## By segment
| Segment | Open $ | WoW | Deal count | WoW |
|---|---|---|---|---|
| Enterprise | $X.XM | up +Z% | NN | up +N |
| Mid-Market | $X.XM | down -Z% | NN | flat |
| SMB | $X.XM | up +Z% | NN | up +N |

## Top 3 deals moving the number
1. **{Deal name}** — {Owner}, $XXk. Stage 2 → Stage 4 this week; demo with
{stakeholder} landed.
2. **{Deal name}** — {Owner}, $XXk. New add; sourced from {channel}.
3. **{Deal name}** — {Owner}, $XXk. Amount up $XXk after scope expansion.

## Top 3 risks
1. **{Deal name}** — {Owner}, $XXk. Close date pushed for the second week.
2. **{Deal name}** — {Owner}, $XXk. Stage regressed 4 → 3.
3. **{Deal name}** — {Owner}, $XXk. No activity for 18 days; forecast Q-end.

## The pattern this week
{One paragraph naming the single biggest pattern. Flat statement, no hedging.}

## Recommended ask
{One sentence — the ask the VP makes of the room.}
```

If `comparison_mode = none`, replace the "(vs. last Monday)" header with "(baseline — no prior snapshot)" and drop every WoW column.

## Watch-outs

- **Confident-but-stale data.** The HubSpot snapshot is only as fresh as the extractor's last run. If `last_modified` on the snapshot file is more than 24 hours old, the brief prepends a one-line warning: "Snapshot is N hours stale — figures may not reflect Friday's late-week activity." Guard: the snapshot freshness check runs before step 1; the brief refuses to ship without it.
- **Hedging language drifting in despite removal.** The hedge-removal pass uses a fixed blocklist; new hedge phrasings the model invents will slip through. Guard: the user is expected to extend `references/hedge-words-blocklist.md` whenever they spot a hedge that landed. The blocklist is a living file, not a one-time setup.
- **Downstream readers citing this as the forecast.** The brief headlines an open-pipeline number, which a casual reader will round to "the forecast." Guard: the brief footer always reads "Operational summary, not a forecast. Forecast is owned by {VP name} and produced in the Friday call." This line is in the report-format template; do not remove it.
- **Owner reassignments mid-week.** If a deal changed owner since the previous snapshot, both the old owner's "lost the deal" delta and the new owner's "gained a deal" delta will fire — double-counting motion. Guard: the skill emits a "deals reassigned this week: N" footnote and excludes those deals from the "top deals moving the number" section to avoid attributing the move to either owner.

# Report format — TEMPLATE

> Replace the placeholders below with values from your snapshot. The
> weekly-pipeline-report skill reads this file as the literal layout it
> follows. Edit this file, not the skill, to change the report shape.

# Weekly pipeline brief — Week of {YYYY-MM-DD}

## Headline (vs. last Monday)

- Total open pipeline: {$X.XM} ({up/down/flat} {$Y.YM}, {±Z%})
- Weighted pipeline: {$X.XM} ({up/down/flat} {$Y.YM}, {±Z%})
- Deal count: {NNN} ({up/down/flat}, {±N})
- Avg deal size: {$X.XK} ({up/down/flat} {$Y.YK}, {±Z%})

> Every metric carries a movement-direction word. If the previous-snapshot
> input is missing, replace this whole block with: "Baseline run — no prior
> snapshot to compare against."

## By segment

| Segment      | Open $   | WoW         | Deal count | WoW         |
| ------------ | -------- | ----------- | ---------- | ----------- |
| Enterprise   | {$X.XM}  | {up +Z%}    | {NN}       | {up +N}     |
| Mid-Market   | {$X.XM}  | {down -Z%}  | {NN}       | {flat}      |
| SMB          | {$X.XM}  | {up +Z%}    | {NN}       | {up +N}     |
| Unsegmented  | {$X.XM}  | {-}         | {NN}       | {-}         |

> The unsegmented row stays in the table even when zero — its presence is the
> evidence that the segment-mapping pass actually ran.

## Top 3 deals moving the number

1. **{Deal name}** — {Owner}, {$XXk}. {What changed in plain English: stage transition, new add, scope expansion, slipped close date.}
2. **{Deal name}** — {Owner}, {$XXk}. {What changed.}
3. **{Deal name}** — {Owner}, {$XXk}. {What changed.}

## Top 3 risks

1. **{Deal name}** — {Owner}, {$XXk}. {Risk signal: pushed twice, stage regression, amount cut, dormant.}
2. **{Deal name}** — {Owner}, {$XXk}. {Risk signal.}
3. **{Deal name}** — {Owner}, {$XXk}. {Risk signal.}

## The pattern this week

{One paragraph naming the single biggest pattern across the segments, the moving deals, and the risks. Flat statement, no hedging. If the data is diffuse, write "no dominant pattern this week" rather than padding.}

## Recommended ask

{One sentence the VP can carry into the room. If the pattern was diffuse and no clean ask follows, write "no clear ask this week" — do not invent one.}

---

Operational summary, not a forecast. Forecast is owned by {VP name} and produced in the Friday forecast call.

Snapshot freshness: {N hours} (extractor ran {YYYY-MM-DD HH:MM}). Deals reassigned this week: {N} (excluded from top-moves section).

# Segment mapping — TEMPLATE

> Replace the rules below with your team's segmentation. The
> weekly-pipeline-report skill applies these rules to assign every deal in
> the snapshot to one segment row in the report. Deals that match no rule
> land in the visible `unsegmented` bucket — never silently dropped.

## Segment definitions

The skill emits one row per segment named here. Order in the report follows the order in this file.

- **Enterprise** — {definition rule, e.g. "deal `amount` >= $100k OR account headcount >= 1000"}
- **Mid-Market** — {definition rule, e.g. "$25k <= `amount` < $100k OR account headcount 100-999"}
- **SMB** — {definition rule, e.g. "`amount` < $25k OR account headcount < 100"}

> If your team segments by industry, geography, or product line instead of
> deal size, replace the dimensions above. The skill is agnostic — it
> applies whatever rules this file declares, in order.

## Assignment rule

When a deal would match more than one segment row, the **first match wins**. That is why segment order in this file matters. If you want amount-then-headcount precedence, list the amount segment first.

## Snapshot column

The skill expects each deal row in the snapshot to carry the columns the rules reference (e.g. `amount`, `account_headcount`, `industry`). If a rule references a column the snapshot does not have, the rule is skipped and the skill logs the skipped rule in the report's footer.

## Owner-to-segment override

Optional. Some teams assign owners to segments rather than deriving from the deal. If an owner-to-segment table is present here, it overrides the deal-level rules above.

| Owner ID  | Owner name      | Segment       |
| --------- | --------------- | ------------- |
| {12345}   | {Alice Example} | Enterprise    |
| {12346}   | {Bob Example}   | Mid-Market    |
| {12347}   | {Carol Example} | SMB           |

## Unsegmented handling

Deals that match no rule (and have no owner-to-segment override) appear in the report as `unsegmented`. The brief surfaces the count even when zero. A non-zero unsegmented count for two consecutive weeks is the signal to revisit this file.

## Last edited

{YYYY-MM-DD}

# Hedge words blocklist

> The weekly-pipeline-report skill runs a hedge-removal pass after the draft.
> If any term below appears in the brief, the skill rewrites the offending
> sentence before shipping. Extend this list whenever a hedge slips through
> in production — the file is meant to evolve.

## Why a blocklist

Hedging language drifts in because the model is being polite about uncertain data. A weekly brief that hedges every claim is unreadable, and the VP starts ignoring it. The blocklist enforces flat statements; the reader pushes back if a claim is wrong, which is the correct shape of the loop.

## Blocked phrases (rewrite required)

### Modal hedges

- may
- might
- could
- could potentially
- possibly
- perhaps
- presumably

### Epistemic hedges

- seems to
- appears to
- appears to suggest
- looks like it might
- it is unclear whether
- it is unclear if
- it is worth noting that
- it is important to note that

### Quantifier hedges

- somewhat
- relatively
- generally
- broadly
- to some extent
- in some cases
- arguably

### Qualified-recommendation hedges

- you may want to consider
- it might be worth
- one option could be
- it could be useful to
- you could potentially

### Vague intensifiers (allowed in dialog, blocked in the brief)

- significant
- meaningful
- notable

> The intensifiers above are blocked because they describe size without
> quantifying it. The brief carries every metric with a number; size words
> without numbers are noise.

## Allowed alternatives

The hedge-removal pass rewrites blocked phrases into one of these patterns:

- Replace "X may be Y" with "X is Y" (if the data supports it) or with "the data does not show whether X is Y" (if it does not).
- Replace "X seems to be growing" with "X grew $N WoW" or drop the claim.
- Replace "you may want to consider Z" with "Z" as an imperative, or with "do Z" — the brief is operational; the recommendation is the recommendation.
- Replace "significant increase" with the actual percent or dollar figure.

## Exceptions

The "Recommended ask" section may use an imperative without softening ("review the pushed-twice deals owner-by-owner"). It does not need an allowed-alternative rewrite — the imperative is already the target shape.

## Last edited

{YYYY-MM-DD}