# Objection Response Library

> objection-response-library

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

---


# objection-response-library

The companion to `copilot-faq-answerer` for **objection-shaped** questions. FAQ entries answer "how does X work?" — these entries answer "we're concerned about X." The difference matters: objections need acknowledgment of the underlying concern before answering, and they often have multiple layers (what the objector said, what they actually mean, what would satisfy them).

## When to use

- The user receives an objection in writing (email, PR comment, exception ticket).
- The user is preparing for a meeting where a known objection is expected.
- Drafting an objection-response section for the `stakeholder-update-writer`'s IC tier.

## When NOT to use

- Pure factual questions → `copilot-faq-answerer`.
- A net-new objection nobody has raised before — research it via `copilot-deep-dive` first, then add to the library.

## Response anatomy

Every objection response has 5 parts:

1. **Acknowledge the concern** — restate what the objector is actually worried about (steel-manned, not strawmanned). "You're concerned that X could happen because Y."
2. **What the org actually does** — the concrete control or process that addresses the concern.
3. **Source citation** — link to the canonical FAQ entry, GitHub Docs, regulator guidance, or internal policy.
4. **What this does NOT cover** — explicit limits. Objectors often have a follow-up objection ready; pre-empt it with honest scope.
5. **Next step if not satisfied** — what's the proper escalation / exception path.

**Anti-patterns to avoid** (and the skill warns against these):
- Dismissive: "GitHub indemnifies us, so this isn't a concern." (Doesn't acknowledge concern, doesn't address actual risk.)
- Evasive: "We're working on that." (Treat the objector as a peer who deserves a real answer.)
- Over-promising: "This is fully mitigated." (Real risk controls have limits; pretending otherwise costs credibility.)
- Vendor-speak: parroting GitHub's marketing language. The objector knows it's marketing.

## Resolution order

For each incoming objection:

1. **Match to a canonical objection** in `canonical-objections.md` by `objection_patterns`.
2. **Check the vault** via `vault-querier` for any newer fact or decision overriding the canonical response.
3. **Apply the org's posture** (regulated-org lens, your specific controls).
4. **Cite** the source.
5. **Surface limits** — what the canonical response does NOT cover.

If no canonical match: stop and report. Suggest invoking `copilot-deep-dive` to research, draft a proposed canonical entry, and once user-approved add to the library.

## Persisting new objections

When a net-new objection has been researched and steel-manned, persist it — a response that only lives in chat doesn't compound:

1. **Append the approved entry to `./canonical-objections.md`** in this skill folder, with all 5 anatomy parts and at least one source URL. This is the final step of every new-objection flow, not an optional follow-up.
2. **For significant new objections** — a new audience, a new risk class, or one likely to recur — also write a short note via `vault-writer.write_insight` to `vault/insights/YYYY-MM-DD-objection-{slug}.md` recording when the objection surfaced, who raised it, and how the org answered.

## Composes with

- `vault-querier` — newer facts may override canonical responses.
- `copilot-faq-answerer` — overlapping content; objection library wraps FAQ entries with the steel-man + limits structure.
- `stakeholder-update-writer` — IC-tier FAQ section often pulls from here.
- `vault-writer.write_insight` — records significant new objections in the vault.

## Acceptance test (for step 15 done-criteria)

The skill ships with ≥5 canonical objection entries in `canonical-objections.md` covering at minimum:
1. Legal — IP indemnity edge case ("what if our developer modifies a suggestion?")
2. Security — prompt injection from third-party content
3. Audit — lack of per-suggestion traceability for SOX evidence
4. Model risk (SR 11-7 successor) — Copilot doesn't fit MRM scope
5. Skeptical dev — quality / over-reliance / junior-dev impact

Each entry has all 5 anatomy parts populated and at least one source URL.