# Objection Mapper

> objection-mapper

- Skill: `themattberman/objection-mapper` (Agent Skill)
- Install (CLI): `npx skillmds@latest add themattberman/objection-mapper`
- Raw SKILL.md: https://api.skillmd.com/api/skills/themattberman/objection-mapper/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: TheMattBerman (https://skillmd.com/u/themattberman)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/themattberman/objection-mapper

---


# objection-mapper

you write the DEFENSIVE artifacts. the voice-extractor already wrote `03-voice-map.md`, which is FORWARD-looking (what to SAY). your job is what to ANSWER. you must hold that boundary mechanically or you'll write the same clusters twice and the run loses trust.

## the boundary (load-bearing)

before you put any cluster in your map, ask one question:

-> does this tell us what to SAY, or what to ANSWER?

if it's a desire, a myth, an enemy belief, buying language, or a charged word the market wants to hear -> that's voice-map. leave it alone. it already lives in `03-voice-map.md`.

if it's friction, fear, a hack people use to avoid the product, a reason they don't trust you, or the moment that flips them -> that's yours.

never copy a cluster from the voice-map into the objection-map. if a cluster could plausibly sit in either, it goes where its ACTION lives: say it -> voice. answer it -> objection. read `references/../../frontrun/references/run-contract.md` "voice-map vs objection-map boundary" if you're unsure.

## inputs

- `02-evidence-cards.json` (the atomic unit, your source of truth)
- `01-source-index.md` (to confirm receipts chain back to `raw/`)
- `00-intake.md` (competitor list, business type, market)
- `03-voice-map.md` (read it so you don't duplicate it)

every claim you make cites at least one `evidence_id`. no receipt, no claim.

## output 1: 04-objection-map.md

five sections. each item carries the verbatim that proves it, an `evidence_id`, and a confidence label. directional items (`weak_pattern`, `do_not_use_yet`) stay here, clearly marked. you are NOT gated to direct_quote/strong_inference the way the angle slate is.

write these sections in order:

### objections
the stated reason for "no." the literal sentence: "too expensive for a team of three," "we already use X." each: verbatim -> what it's really objecting to -> `evidence_id` -> confidence.

### anxieties
the unstated fear underneath. "what if i set this up and it breaks." "what if my boss asks and i can't explain it." quieter than objections, often inferred. mark these honestly: most are `strong_inference` or `weak_pattern`, rarely `direct_quote`.

### workarounds
the hack people use to avoid buying or to route around a missing feature. "i just export to a spreadsheet every monday." a workaround is a feature request and an objection wearing the same coat. name the exact hack.

### trust gaps
the place the market doubts the claim. "they say it's secure but there's no SOC 2 page." "the reviews look fake." each gap is a thing copy must answer with proof, not adjectives.

### trigger events
the moment that flips someone from idle to buying (or churning). "we hit 50 seats and the old tool fell over." "the day they removed CSV export." trigger events are the most commercial item in the map. tag them so brief-forge can build "why now" around them.

each section ends with a one-line `operator_action` for the highest-value item in it (verb from the enum: build, write, email, pause, test, capture, ship, assign, survey). example: `capture -> a SOC 2 trust page screenshot -> owner: founder -> this_week: true`.

close the file with a **What We Would NOT Say** block, minimum 2 entries: the persona-mush version of these objections you refuse to ship ("customers have concerns about pricing" is banned; name the exact objection or say nothing).

## output 2: 04b-competitor-map.md

one block per competitor named in `00-intake.md`. if the corpus has no voice about a listed competitor, say so explicitly ("no market voice found for X this run") rather than inventing it. required fields per competitor:

- **known_for**: what the market actually credits them with. their genuine strength.
- **frustration_points**: the specific verbatim complaints about them, each with `evidence_id`.
- **claim_they_own**: the phrase/position they own in the market's head. you do not contest this head-on.
- **where_not_to_attack**: their real strength. attacking it makes you look dishonest and loses the room. this field is mandatory and is the most important one. if you can't name where NOT to attack, you don't understand the competitor yet.
- **wedge**: the gap their strength forces them to leave open. where you win.
- **switch_trigger**: the exact moment/event that makes their customer leave them. trace to a trigger-event card if one exists.

each competitor block ends in source receipts (the `evidence_id`s used) and a one-line `operator_action`.

close the file with a **What We Would NOT Say** block, minimum 2 entries: the cheap-shot attacks on a competitor's genuine strength that would backfire.

## degradation

- thin pool / few competitor mentions: write fewer competitor blocks, mark them `weak_pattern`, do not fabricate. a half-empty honest map beats a full invented one.
- no trigger events found: say "no trigger events surfaced this run" and route a `survey` operator_action to go capture them. never invent a churn moment.

## hard rules

- no broad label without the exact verbatim under it.
- verbatim stays separate from your interpretation. never smooth the market's words into your own.
- every claim chains: claim -> `evidence_id` -> card -> `src_id` -> `raw/`.
- no em dashes. lowercase headers. CAPS sparingly. the operator stays the editor.

