8gnc — Brand Growth Diagnostic

View saved version →

---
name: ai-agent-readiness
description: Execute the AI Agent-Readiness audit and sprint playbook (PLAY-004). Use when making a site usable by agentic browsers, AI shopping assistants, or chat-led SERPs. Triggers on "agent readiness," "agentic browser," "selector contract," "structured data parity," "feed completeness," "task URLs," "Playwright testing," "INP," "TBT," "modal friction," "agent readiness score," or when a client needs their site to work with AI-powered browsing agents. Includes audit checklists, 15-day sprint plan, selector contract specs, test harnesses, and scoring rubric.
---

# AI Agent-Readiness (PLAY-004)

Make sites usable by agentic browsers and chat-led SERPs. Browsers with embedded agents now navigate, click, and buy. Your site must be fast, scriptable, and machine-verifiable.

## Thesis

Winning shifts from discovery to action. Sites must be fast, scriptable, and machine-verifiable for agent task completion.

## When NOT to Use

- The site is mostly static and already crawlable with minimal JS. Agents can already read it — the audit will find little to fix.
- There are no transactional flows for agents to execute. No cart, booking, or forms means selector contracts and task URLs have nothing to point at.
- Traffic has no agent or AI-referral component yet AND the team can't act on the audit. A readiness report nobody implements is shelf-ware — wait until one of those changes.

## Offer Structure

### Starter Audit (72 hours)
- Agentability scan (CWV, JS cost, INP/TBT hotspots)
- DOM accessibility and selector stability review
- Structured data parity check vs feed
- Risk register and prioritized backlog

### 15-Day Agent Sprint
- Implement selector contract, schema, and deep links
- Kill top JS and modal blockers
- Ship Playwright tasks and Lighthouse CI
- Publish "Agent Readiness Report" with before/after

### Ongoing (Monthly)
- RUM (Real User Monitoring — field data from actual visitors, vs. synthetic lab tests) monitoring of LCP/INP/CLS and funnel KPIs
- Schema/Feed parity watchlist and Merchant Center QA
- Governance reviews and regression tests

## Audit Checklist (72 Hours)

### Performance & JS Cost
- INP under threshold sitewide
- TBT on PDP and cart under 200ms in lab
- Long tasks identified and split
- Third parties deferred or removed

### DOM, Accessibility, and Selectors
- All controls have role + accessible name
- No randomized IDs or hash-classes on key controls
- Stable `data-qa` attributes on critical elements
- Consent and promo modals dismissible via keyboard and labeled buttons

### Structured Data Sanity
- `WebSite` → `SearchAction` with `EntryPoint.urlTemplate`
- `Product` with `Offer` or `AggregateOffer`
- `OfferShippingDetails` with `ShippingDeliveryTime` where relevant
- Variant modeling verified

### Marketplace Parity
- Feed vs page vs JSON-LD values match for price, availability, condition
- Automatic Item Updates policy documented
- Shipping settings mirrored in both Merchant Center and JSON-LD

### Flow Reliability
- Steps to checkout minimized
- Task URLs documented for common intents
- Prefilled cart links available for top 3 bundles

## Implementation Sprint (15 Days)

**Days 1–3: Instrument and expose** — Ship JSON-LD on PDPs and list pages. Add `WebSite` → `SearchAction`. Add accessible names to top 20 controls. Turn on RUM for CWV + custom funnel events.

**Days 4–7: Kill the blockers** — Split bundles, defer third parties, remove dead widgets. Make consent and promo modals visible and dismissible. Stabilize selectors.

**Days 8–10: Task paths and deep links** — Publish "task URLs" to filtered results (in-stock, price caps, sizes). Create prefilled cart links for top configurations. Document in a private Agent Notes page.

**Days 11–15: Trials and proof** — Run 10 Playwright tasks that mimic agents. Record success rate and time-to-cart. Repeat in Atlas and AI-Mode browsers. Publish Agent Readiness Report.

## Selector Contract

- Prefer **role** and **name** selectors first.
- Provide explicit **data-qa** fallbacks on critical elements.
- Never randomize IDs/class names on key controls.
- Version the contract and store in `/docs/selector-contract.json`.

```json
{
  "version": "2025.10",
  "flows": {
    "pdp_add_to_cart": [
      {"step": "choose_size", "pref": "role", "selector": "getByRole('combobox', { name: 'Size' })"},
      {"step": "add_to_cart", "pref": "role", "selector": "getByRole('button', { name: 'Add to cart' })"}
    ],
    "checkout_start": [
      {"step": "open_cart", "pref": "role", "selector": "getByRole('link', { name: 'Cart' })"},
      {"step": "begin_checkout", "pref": "role", "selector": "getByRole('button', { name: 'Checkout' })"}
    ]
  }
}
```

### Playwright Task Example

One test per critical flow. Use the same role/name selectors the contract specifies — if the test breaks, an agent breaks.

```typescript
import { test, expect } from '@playwright/test';

test('agent path: select variant, add to cart, confirm', async ({ page }) => {
  await page.goto('https://example.com/products/trailrunner-2');

  // Select a variant the way an agent would — role + accessible name
  await page.getByRole('combobox', { name: 'Size' }).selectOption('10');
  await page.getByLabel('Color').selectOption('Slate');

  // Add to cart
  await page.getByRole('button', { name: 'Add to cart' }).click();

  // Assert a machine-verifiable success signal
  await expect(page.getByRole('status')).toContainText('Added to cart');
  await expect(page.getByRole('link', { name: 'Cart' })).toContainText('1');
});
```

## Structured Data Templates

### WebSite with SearchAction
```json
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "url": "https://example.com",
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://example.com/search?q={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}
```

### Product with Offer and Delivery Windows
```json
{
  "@context": "https://schema.org",
  "@type": "Product",
  "sku": "TR-200",
  "name": "TrailRunner 2.0",
  "offers": {
    "@type": "Offer",
    "price": "129.99",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock",
    "shippingDetails": {
      "@type": "OfferShippingDetails",
      "deliveryTime": {
        "@type": "ShippingDeliveryTime",
        "handlingTime": {"@type": "QuantitativeValue", "minValue": 0, "maxValue": 1, "unitCode": "d"},
        "transitTime": {"@type": "QuantitativeValue", "minValue": 2, "maxValue": 3, "unitCode": "d"}
      }
    }
  }
}
```

## Agent Readiness Score (0–100)

- 0–20: Crawler-only. Agents fail immediately.
- 21–50: Agent can browse, fails during filters or modals.
- 51–75: Agent reaches cart, parity issues remain.
- 76–90: Agent completes checkout reliably, minor parity issues.
- 91–100: Task URLs, deep links, and governance in place.

**Scoring inputs:** TBT on PDP/cart, INP p75, selector coverage, schema completeness, feed parity, modal friction rate, task success rate in Playwright suite.

## Data-Density Commerce (ACP Sub-Checklist)

- Feed refresh ≤ 15 minutes for price/stock
- Required + recommended fields ≥ 95% on top 20% SKUs
- 5,000-char descriptions structured as knowledge base
- `delivery_estimate` present on SKUs with fast methods
- Returns: live URL + explicit `return_window`
- Payment: ACP endpoints respond, totals math correct, idempotent

**Weekly KPI:** Feed completeness %, Answerability %, Description depth (avg chars).

## Backlog Template (MoSCoW)

**Must-have:** WebSite SearchAction JSON-LD, Product + Offer parity with feed, selector contract on PDP/cart/checkout, remove/defer 2 largest third-party scripts.

**Should-have:** Prefilled cart links for top 3 bundles, OfferShippingDetails with delivery windows, consent modal made accessible and keyboard dismissible.

**Could-have:** ReserveAction/BuyAction hints, task URLs for common filtered states.

**Won't-have (for now):** Full SPA rewrite.

## Governance

- Automatic Item Updates: enabled or disabled by policy with owner and review cadence.
- Bot friction: allow discovery and cart creation, challenge at payment only.
- Selector contract ownership: product owner maintains and versions each release.
- Agent identity: treat automation as first-class users with logging and permissions.

View saved version →

---
name: ai-focus-group
description: Simulate a focus group of audience archetypes to test marketing creative, messaging, and brand assets. Use when the user wants audience feedback, creative testing, or message validation without real user research. Triggers on "focus group," "audience feedback," "test this creative," "what would they think," "simulate audience," "creative testing," "message testing," "would this resonate," "audience reaction," or any request to pressure-test copy, design, headlines, taglines, brand names, or campaign concepts against a defined audience. Pairs well with brand strategy and creative direction skills for richer audience profiles and psychological response frameworks. Outputs can feed into brand audits as message-testing evidence.
---

# AI Focus Group — Simulated Audience Testing Protocol

Simulate a panel of 5–7 audience archetypes to generate structured reactions to any marketing creative — copy, design, headlines, landing pages, emails, social posts, taglines, brand names, or campaign concepts. The model constructs each panelist from a defined demographic and psychographic profile and voices them distinctly. Label every result as synthetic; this is not real user research.

## When You Receive a Request

Before running the panel, resolve these variables. Ask for any that are missing and cannot be inferred from context.

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `creative_asset` | The thing being tested — copy, headline, visual description, concept | *required* |
| `asset_type` | Tagline / headline / landing page / email / social post / ad / brand name / concept | *infer if obvious* |
| `target_audience` | Who this creative is meant to reach | *required* |
| `panel_size` | Number of panelists | 5–7 |
| `custom_archetypes` | Any specific panelist types the user wants on the panel | Use standard archetypes if not provided |
| `brand_context` | Brand, product, or campaign this creative belongs to | *ask if not provided* |
| `success_criteria` | What would make this creative succeed (click, purchase, share, recall) | *infer from asset type* |

---

## The Simulated Focus Group Protocol

Execute all five stages in order. Do not skip synthesis or recommendations even if the panel reaction seems obvious.

---

### Stage 1 — Define the Panel

Build a panel of 5–7 archetypes tailored to the target audience. Each panelist gets a name, a one-line profile, and a behavioral stance toward the category.

**Standard Archetype Library** (customize or swap based on audience):

| Archetype | Who They Are | Behavioral Stance |
|-----------|-------------|-------------------|
| The Skeptic | Has been burned before. Distrusts claims. Reads the fine print. | Challenges everything. Needs proof before belief. |
| The Enthusiast | Already bought in. Loves the category. Shares with their circle. | Emotionally open. Amplifier if won, irrelevant if not targeted. |
| The Budget-Conscious | Every dollar is a decision. Value-to-cost ratio is the filter. | Converts on clarity and proof, drops off at vague pricing. |
| The Brand-Loyal | Already has a preference. This brand has to earn a switch. | Compares everything to the incumbent. Skeptical of newcomers. |
| The First-Timer | No prior experience in the category. Learning vocabulary. | Converts on simplicity and trust signals. Confused by jargon. |
| The Influencer | Thinks in shareable moments. Considers how this looks to their audience. | Buys aesthetics and story as much as utility. |
| The Decision-Maker | Holds budget authority. Evaluates ROI, risk, and operational fit. | Short attention. Wants the business case fast. |

**Panel Definition Output Format:**

```
PANEL: [Brand/Campaign Name] Focus Group
Target Audience: [description]
Panel Size: [n]

Panelists:
1. [Name], [Age/Context] — [Archetype] — [One-sentence behavioral profile]
2. [Name], [Age/Context] — [Archetype] — [One-sentence behavioral profile]
...
```

Make each panelist feel like a real person. Give them a name, a situation, and a reason they would encounter this creative.

---

### Stage 2 — Present the Creative

Restate the creative asset clearly before the panel reacts to it. If it is a visual, describe it as if briefing someone who cannot see it. Be precise — vague descriptions produce vague reactions.

```
CREATIVE UNDER TEST:
Asset Type: [type]
Content: [exact copy, headline, or detailed description]
Context: [where this appears — Instagram feed, email subject line, billboard, etc.]
```

---

### Stage 3 — Panel Reactions

For each panelist, generate five distinct reaction dimensions. Voice each reaction in the panelist's natural register — not survey language. They are talking, not filling out a form.

**Reaction Format (per panelist):**

```
[Name] — [Archetype]

First Impression:
[Their gut reaction in their own voice. 1–3 sentences. Raw, unfiltered.]

Comprehension Check:
[What they think this brand/product/offer is or does. Stated as they would describe it to a friend.]

Emotional Response:
[The specific feeling this triggers. Name the emotion. Then explain why in their voice.]

Action Likelihood:
[Would they click, buy, share, save, ignore, or show someone else? Why or why not. Honest, not aspirational.]

Concerns or Objections:
[What gives them pause. What's missing. What makes them hesitate or walk away.]
```

Each panelist should feel distinct. The Skeptic does not sound like the Enthusiast. The First-Timer does not use industry vocabulary. Do not let all five panelists agree — that is a sign of averaging, not simulation.

---

### Stage 4 — Synthesis

Aggregate the panel findings into a structured summary. This is where patterns become actionable intelligence.

```
SYNTHESIS

Consensus Points (3+ panelists agree):
- [Finding]
- [Finding]

Split Opinions (panel divided):
- [Topic]: [Who's in favor and why] vs. [Who objects and why]

Red Flags (any single panelist raised this — flag even if isolated):
- [Flag]

Strongest Signals:
- [The one thing the panel responded to most positively — be specific]
- [The one thing that most reliably triggered friction — be specific]

Comprehension Score: [Clear / Mostly Clear / Mixed / Confused]
Resonance Score: [High / Medium / Low / Split]
Conversion Risk: [Low / Medium / High — and why]
```

---

### Stage 5 — Recommendations

Translate synthesis into specific, actionable changes. Do not hedge. Each recommendation targets a real finding from the panel.

```
RECOMMENDATIONS

Priority 1 — [Change category: headline / CTA / proof / framing / simplification / etc.]
Finding it addresses: [Which panelist(s) raised this and what they said]
Recommended change: [Specific edit or direction — not "improve clarity," but how]

Priority 2 — [Change category]
Finding it addresses: [...]
Recommended change: [...]

Priority 3 — [Change category]
Finding it addresses: [...]
Recommended change: [...]

Optional A/B Test:
If resources allow, test [specific variation] against [current version] to resolve the split opinion on [topic].
```

---

## Focus Group Report Output

After all five stages are complete, compile into a single clean report:

```markdown
# AI Focus Group Report
Creative: [Asset name or description]
Brand: [Brand or campaign name]
Date: [date]
Panel Size: [n]

## Panel Composition
[Panelist list with archetype and one-line profile]

## Creative Under Test
[Restated asset]

## Individual Reactions
[Full reactions per panelist — Stage 3]

## Synthesis
[Stage 4 findings]

## Recommendations
[Stage 5 priorities]

## Confidence Level
[High / Medium / Low]
Reasoning: [Why this confidence level — based on how well the panel profile matches the real target audience, how specific the creative is, and how clear the use context is]
```

---

## Panelist Voice Guidelines

This is the most important creative discipline in the protocol. Panelist voice must be distinct or the simulation fails.

**The Skeptic** speaks in conditional language. "I'd want to know..." "That's a big claim." "Who's saying that?" They do not attack — they interrogate.

**The Enthusiast** leads with feeling. "Oh, I love this." "This is exactly what I've been looking for." They can be won quickly and lost quickly if something rings false.

**The Budget-Conscious** runs mental math. "So that's... what per month?" "Is this included or add-on?" They are not cheap — they are deliberate.

**The Brand-Loyal** compares. "Well, [incumbent] does this too but..." "I've been with [brand] for X years." They need a reason to switch that doesn't embarrass them for switching.

**The First-Timer** asks naive questions that reveal clarity gaps. "Wait, is this for me?" "I don't know what that means." They are not unintelligent — they are new.

**The Influencer** thinks in frames and captions. "This would be such a good story." "The aesthetic is on point." "People in my space would eat this up." They evaluate shareworthiness alongside utility.

**The Decision-Maker** is impatient and ROI-focused. "What's the measurable outcome?" "How long does implementation take?" "Who else is using this?" They cut to the business case.

---

## Variable Resolution for Common Asset Types

| Asset Type | Success Criteria (default) | Key Dimension to Watch |
|------------|---------------------------|------------------------|
| Headline | Click intent, comprehension | First Impression + Comprehension |
| Tagline | Recall, emotional fit | Emotional Response + Action Likelihood |
| Email subject line | Open intent | First Impression + Action Likelihood |
| Landing page | Conversion intent | Comprehension + Concerns |
| Social post | Share intent, engagement | Emotional Response + Action Likelihood |
| Brand name | Memorability, fit, associations | First Impression + Comprehension |
| Ad creative | Click intent, recall | All five dimensions equally |
| Offer / pricing structure | Purchase intent | Concerns + Action Likelihood |

---

## Limitations — Simulated vs. Real Feedback

This protocol produces structured inference, not empirical data. Understand the gap before using results to make high-stakes decisions.

**What simulated panels do well:**
- Surface comprehension gaps and ambiguous language
- Reveal likely friction points before launch
- Generate diverse reaction frames quickly and cheaply
- Pressure-test assumptions about audience response
- Identify which segments are likely won vs. likely lost

**What simulated panels cannot replace:**
- Real behavioral data (clicks, purchases, time-on-page)
- Genuine emotional reactions in the moment of exposure
- Cultural nuance that archetypes may not capture
- Subconscious processing that only shows in physiological response
- Statistical validity — this is qualitative inference, not quantitative research

**Risk calibration by decision stakes:**

| Decision | Simulated Panel Sufficient? |
|----------|-----------------------------|
| Refining copy before launch | Yes |
| Choosing between two headlines | Use with caution — supplement with real click data if possible |
| Rejecting a concept outright | No — requires real validation before kill decision |
| Major rebrand or campaign investment | No — real user research required |
| Quick gut-check before client presentation | Yes |

The Confidence Level field in the output report reflects how closely the panel archetypes match the real target audience definition. If the target audience is very specific (e.g., "Latino small business owners in Texas with under 10 employees") and the panel is built from generic archetypes, confidence drops. Flag this explicitly.

---

## When NOT to Use

- Not for statistical validity or real market research — this is qualitative inference from simulated archetypes, not data from real people.
- Not for high-stakes kill decisions — rejecting a concept outright requires real validation, not a simulated panel.
- Not for major rebrand or campaign-investment decisions — run real user research before committing that budget.
- Not when real behavioral data already exists — clicks, conversions, and replies beat simulated reactions every time.
- Not for writing or fixing the creative itself — this skill tests; produce with `linkedin-authority`, `story-spine`, or `humanize`.

---

## Skill Integration

- **Input sources:** Pairs well with brand strategy and creative direction skills — use audience truth statements and archetype summaries to calibrate panelist profiles. Reference psychological response frameworks (emotional polarity, nostalgia, salience) when scoring emotional reaction dimensions.
- **Output feeds into:** AI Focus Group results qualify as message-testing evidence for brand audits and positioning work. Attach the synthesis and recommendations sections to audit briefs.
- **Standalone use:** This skill runs independently. No prerequisite skill required, though richer audience definitions produce more accurate panels.

View saved version →

---
name: ai-visibility-tracking
description: >-
  Use when the user wants to know who the AI engines cite — brand mentions and
  citations inside Google AI Overviews and ChatGPT answers, AI search volume for
  a query set, or a competitor comparison of AI-answer presence. Triggers on
  "who does ChatGPT cite," "AI mentions," "LLM citations," "AI visibility,"
  "are we showing up in AI Overviews," "AI share of voice," "track our brand in
  AI answers," or any AEO/GEO measurement task. Wraps the DataForSEO LLM
  Mentions API through the shared dataforseo client.
---

# AI Visibility Tracking — LLM Mentions Operational Guide

The question every operator is starting to ask: *when an AI answers my customer's
question, am I in the answer?* This skill measures it. It pulls citation data from
Google AI Overviews and ChatGPT responses — which domains get cited, for which
questions, at what AI search volume — and turns it into a baseline, a competitor
comparison, and a monthly tracking cadence.

## File locations (read this first)

Use the same execution boundary as the `dataforseo` skill; the client is shared:

| Context | Client | Working dir | User-facing output |
|---|---|---|---|
| Codex with local shell access | Resolve the installed `dataforseo/scripts/dataforseo_client.py` | current workspace | `./ai-visibility-results/YYYYMMDD/` or another user-approved path |
| ChatGPT or a surface without local shell access | No direct API execution in this skills-only release | conversation or supported file workspace | Analyze user-supplied exports or return the exact data request; never fabricate live measurements |

Credentials load exactly as documented in the `dataforseo` skill. No separate setup.

## When NOT to Use

- No DataForSEO account. Same rule as the dataforseo skill — every call bills.
- The brand has near-zero web presence. If classic SERPs don't know you, AI engines
  won't either — run the dataforseo skill's keyword/backlink work and the
  ai-agent-readiness audit first; come back to measure once there's something to cite.
- You want to *manipulate* AI answers. This skill measures; the defense/offense
  content moves live in your strategy work, not in the measurement.

## Cost discipline — read this before the first call

`llm_mentions/*` endpoints are plain pay-per-call like the rest of the
toolkit — DataForSEO removed its former $100/month minimum top-up on these
endpoints in July 2026. Just fund the account (credits never expire, spend on
any of their APIs).

Pricing snapshot (2026-07). Verify the current official DataForSEO pricing before any paid call; do not rely on this table as a live quote:

| Endpoint | Cost | Use for |
|---|---|---|
| `ai_keyword_data/keywords_search_volume/live` | $0.01/task | AI search volume per keyword — the cheap step-0 wide pass (no subscription) |
| `llm_responses/live` | $0.0006/task | Ask a model the actual question, see the answer — spot checks (no subscription) |
| `llm_mentions/aggregated_metrics/live` | $0.10/task + $0.001/row | Citation counts + AI volume per domain |
| `llm_mentions/cross_aggregated_metrics/live` | $0.10/task + $0.001/row | You vs. competitors, side by side, one call |
| `llm_mentions/search/live` | $0.10/task + $0.001/row | Full AI response text + per-citation sources |
| `llm_mentions/top_domains/live` | $0.10/task + $0.001/row | Who dominates AI citations in your space |
| `llm_mentions/top_pages/live` | $0.10/task + $0.001/row | The exact PAGES earning citations — teardown targets |

A full baseline (you + 4 competitors, cross-aggregated, both platforms) runs
$1–3 depending on rows. Coverage: `platform: "google"` = AI Overviews;
`platform: "chat_gpt"` = ChatGPT, **United States location only** per DataForSEO.

## Client methods

```python
client.ai_llm_mentions_aggregated(
    targets=[{"domain": "yourbrand.com", "search_scope": ["sources"]}],
    platform="google",            # or "chat_gpt"
    location_name="United States",
)
# → mentions count, sources_domain frequencies, ai_search_volume

client.ai_llm_mentions_search(
    targets=[{"keyword": "best b2b branding agency dallas"}],
    platform="google",
)
# → individual citations: full AI response text, sources[] (url, position,
#   title), triggering question, per-citation ai_search_volume
```

Additional methods on the shared client:

```python
client.ai_llm_mentions_cross_aggregated(
    target_groups=[
        {"aggregation_key": "us",   "target": [{"domain": "yourbrand.com"}]},
        {"aggregation_key": "them", "target": [{"domain": "competitor.com"}]},
    ],
    platform="google",
)   # → per-group mentions / ai_search_volume / impressions, plus combined totals

client.ai_llm_mentions_top_domains(targets=[{"keyword": "b2b branding agency"}])
client.ai_llm_mentions_top_pages(targets=[{"keyword": "b2b branding agency"}])
client.ai_keywords_search_volume(keywords=["best branding agency dallas", "..."])
client.ai_llm_models()                       # model list for llm_responses
client.ai_llm_response({...})                # payload per current DataForSEO docs
```

`search_scope: ["sources"]` is the citation filter — DataForSEO distinguishes
`search_results` (everything retrieved) from `sources` (actually cited in the
answer). Citations are the metric that matters; always scope to sources unless
you're explicitly studying retrieval.

## The methodology

### 0. Volume pass (cheap, no subscription)

`ai_keywords_search_volume` on the full commercial query set ($0.01). Rank the
queries by AI search volume — this decides where the expensive calls go.

### 1. Baseline (run once)

One `cross_aggregated_metrics` call: your domain + every named competitor as
separate `aggregation_key` groups → the share-of-voice table in a single
request. Save it dated — it's the "before."

### 2. Question-level read (deep pass, selective)

For the 5–10 commercial queries that drive the business: `search/live` with the
keyword as target. Read the actual AI responses. Record per query: who's cited,
at what position, and whether the answer's framing matches how the cited brand
wants to be described. A citation that misdescribes you is a content brief, not
a win.

### 3. Gap analysis

Three lists fall out of #1 + #2:
- **Cited, high volume, not you** → run `top_pages` on those queries: the exact
  competitor URLs earning the citations are your teardown targets.
- **Your pages cited** → protect those pages; they're load-bearing now.
- **Questions with thin/no citations** → open ground; first credible answer wins.

### 4. Monthly cadence

Re-run the baseline monthly (same targets, same platforms — comparability beats
cleverness). Track: mentions delta per domain, new questions entering the set,
position shifts on the deep-pass queries. One page of output: what moved, why it
likely moved (ship log vs. delta), what to publish next month.

## Output shape

Write results to the output dir as both `ai-visibility-YYYYMMDD.json` (raw) and a
short markdown report: share-of-voice table, the three gap lists, and a "next
moves" section with at most three actions. Numbers without a next move are
trivia; keep the actions attached to the data.

View saved version →

---
name: brandprint-engine-guide
description: Use when starting a new Brandprint engagement, when a user needs instructions on how to use the skill package, or when the user asks "how do I run Brandprint," "what order do I use these skills," or "where do I start" with the Brand Strategy Engine. Orientation skill for the six-layer Brandprint chain and its two-pass workflow.
---

# Brandprint Engine — Runner Guide

This guide walks through the complete Brandprint Engine workflow and produces a structured Brand Strategy and Competitive Positioning Report.

## When NOT to Use

- **Running an individual layer.** Invoke that layer's skill directly (`core-human-truth`, `brandprint-tier-a`, etc.) — this guide orients and sequences, it doesn't execute.
- **As a substitute for the layer skills.** The workflows, gates, and output schemas live in each layer's SKILL.md. This file tells you the order and the prompts, nothing more.

## What You Get

The Brandprint Engine is a chain of 6 skills that run in sequence. Each layer feeds the next:

```
Layer 1: Core Human Truth ─── foundational insight (1 sentence)
    │
    ▼
Layer 2: Brandprint Tier-A ── 10 strategy elements with evidence
    │
    ▼
Layer 3: Brandprint Tier-B ── 5 actionable elements with proxy tests
    │
    ▼
Layer 4: Brandprint Tier-C ── 4 stylistic elements ready to deploy
    │
    ▼
Layer 5: Competitive Audit ── validates differentiation vs. competitors
    │
    ├── If REFINE → re-run Layers 1-4 with competitive context (second pass)
    │
    └── If PROCEED ──▼
                      │
Layer 6: Report Compiler ─── 25-35 page consulting-grade deliverable
```

## How to Run It

Run the layer-by-layer chain below. In Codex with local file access, save each layer's JSON to a user-approved workspace directory such as `.8gnc/brandprint/{slug}/`. In ChatGPT without local file access, return each artifact in the conversation or as a downloadable file and ask the user to preserve it before the next layer.

This OpenAI package does not include the legacy provider-specific slash-command pipeline or its hooks. Do not refer users to those commands from this bundle.

## Prerequisites

- An installed 8gnc plugin in ChatGPT or Codex
- Current web research access for evidence-dependent layers
- **Python 3.9+** for optional local validation helpers in Codex
- **Optional:** weasyprint (`pip install weasyprint`) for PDF output
- **Optional:** [search-cli](https://github.com/199-biotechnologies/search-cli) for enhanced multi-provider search on local execution surfaces

## Installation Check

This guide is installed as part of the `8gnc` plugin. Ask the model to list the available Brandprint skills. Confirm that `deep-research`, the six strategy layers, this guide, `brand-revival`, and `competitive-teardown` are available before starting the full chain.

---

## The Two-Pass Workflow

This is the most important thing to understand. **The Brandprint Engine is designed to run twice.**

### First Pass (Layers 1-4): Raw Positioning

The first pass builds positioning from the brand's own tensions, evidence, and market reality. It produces good output — but it hasn't been tested against competitors yet.

### The Competitive Gate (Layer 5): Reality Check

Layer 5 takes the first-pass outputs and stress-tests them against named competitors. It answers the question: "If a buyer saw our positioning next to [competitor], could they tell us apart in 10 seconds?"

Two outcomes:
- **PROCEED** — Your positioning is differentiated. Move to Layer 6.
- **REFINE** — Your positioning collides with a competitor. Re-run Layers 1-4 with the competitive context baked in.

### Second Pass (Layers 1-4 again): Sharp Positioning

The second pass is where the magic happens. Now the skills have competitive context as a constraint — they know which territories are occupied, which claims collide, and where open space exists. The output is dramatically sharper.

**Example from a real engagement:**
- First pass produced: "We build Texas. Our crews own it." (collides with Rogers-O'Brien's "Texas' Premier Builder")
- Competitive audit exposed: 40%+ vocabulary overlap, follower positioning on Texas identity
- Second pass produced: "Complexity-first builder" positioning + "Same Team, Every Project" mantra + "Certainty" as platform word (zero competitor overlap)

The second pass took the same brand from "we sound like everyone else" to "we own a category no one else claims."

---

## Layer-by-Layer Chain

### Step 1: Gather Your Inputs

Before you start, collect:

| Input | What You Need | Where to Find It |
|-------|--------------|-------------------|
| Brand name | The company/product | Client brief |
| Audience | Who buys from them | Client brief, sales team |
| Region | Geographic market | Client brief |
| Category | Industry/sector | Obvious from context |
| Competitors | 3-5 named competitors | Client brief, industry knowledge, or ask |
| Competitor URLs | Their websites, LinkedIn | Web search |
| Constraints | Legal limits, brand safety | Client brief |

### Step 2: Run Layer 1 — Core Human Truth

**Prompt:**
```
Run the core-human-truth skill for [BRAND NAME].

Topic: [what they do]
Audience: [who buys from them]
Region: [geographic market]
Mode: standard

Use the deep-research skill in Standard mode to gather evidence.
```

**What happens:** The deep research engine launches 5-10 parallel searches across academic sources, industry data, forums, and reviews. Sources are triangulated, credibility-scored, and synthesized. The Core Human Truth skill then distills findings into a single validated sentence (max 25 words) capturing the foundational tension buyers feel.

**Output:** Core Human Truth sentence, tension ladder, buyer archetypes, lexicon, source bibliography.

**Duration:** 15-25 minutes with deep research in Standard mode.

**Checkpoint:** Read the Core Human Truth sentence. Does it feel true? Does it capture tension the audience recognizes but rarely articulates? If yes, proceed. If it feels generic, provide additional context and re-run.

### Step 3: Run Layers 2-4 — Brandprint Tiers A, B, C

These should chain automatically. If they don't auto-chain, prompt each one:

**Tier-A prompt (if needed):**
```
Run brandprint-tier-a for [BRAND NAME], using the Core Human Truth output as seed.
```

**Tier-B prompt (if needed):**
```
Run brandprint-tier-b for [BRAND NAME], using the Tier-A output as seed.
```

**Tier-C prompt (if needed):**
```
Run brandprint-tier-c for [BRAND NAME], using the Tier-A and Tier-B outputs as seeds.
```

**Output after all three:** 10 strategy elements + 5 actionable elements + 4 stylistic elements = complete Brandprint.

**Duration:** 30-60 minutes total for all three tiers.

**Checkpoint:** Review the tagline, platform word, and mantra. Do they feel differentiated? Or could a competitor claim the same things? If you're unsure, that's exactly what Layer 5 is for.

### Step 4: Run Layer 5 — Competitive Positioning Audit

This is where most people skip — and it's where the most value lives.

**Prompt:**
```
Run the competitive-positioning-audit for [BRAND NAME].

Competitors:
1. [Competitor 1] — [their website URL]
2. [Competitor 2] — [their website URL]
3. [Competitor 3] — [their website URL]

Use the Brandprint outputs from Layers 1-4 as the brand claims to test.
```

**Pro tip:** If you have the competitor's actual website copy, paste it directly. The more exact the competitor language, the sharper the collision analysis.

**Output:** Collision matrix, vulnerability scores, repositioning paths, PROCEED/REFINE decision.

**Duration:** 15-30 minutes.

**The critical decision:**

If the audit returns **PROCEED** — your positioning is differentiated. Skip to Step 6.

If the audit returns **REFINE** — go to Step 5.

### Step 5: Second Pass (Only If REFINE)

Re-run Layers 1-4, but this time include the competitive context:

**Prompt:**
```
Re-run the core-human-truth skill for [BRAND NAME] with additional competitive context:

[Paste the context package from Layer 5 here]

The first-pass positioning collided with [competitor names]. Key collisions:
- [list the specific collisions from the audit]

Constraints: The new positioning must NOT occupy these territories:
- [list competitor-owned territories]

The recommended repositioning path from the audit is: [paste recommended path]
```

Then chain through Tier-A, B, C again with the same competitive constraints.

**What changes:** Everything gets sharper. The Core Human Truth narrows to a tension only your brand can resolve. The platform word avoids competitor vocabulary. The tagline claims open territory instead of contested ground.

**After the second pass:** Run Layer 5 again to confirm PROCEED. If it still says REFINE, you may need to narrow the niche further or provide more competitive intelligence.

### Step 6: Run Layer 6 — Report Compiler

**Prompt:**
```
Run the brand-strategy-compiler to create the final report.

Brand: [BRAND NAME]
Client: [CLIENT NAME]
Prepared by: [YOUR FIRM NAME]
Date: [MONTH YEAR]
Confidentiality: Confidential
Include financials: yes
Include roadmap: yes
Format: narrative

Use all outputs from Layers 1-5 (or the second-pass versions if applicable).
```

**Output:** A 25-35 page Brand Strategy & Competitive Positioning Report with:
- Executive summary
- Market context
- Core Human Truth with buyer psychology
- Competitive landscape with white space map
- Target segments with buyer archetypes
- Brand architecture (equity ladder, platform word, mantra, tagline system)
- Competitive moat analysis
- Signature offers mapped to growth sectors
- Brand activation system with touchpoint map
- Strategic guardrails and brand protection
- Implementation roadmap (4 phases, 24 months)
- Source bibliography

**Duration:** 20-40 minutes.

---

## Tips for Best Results

### Use the Deep Research Engine
Layers 1, 2, and 5 are powered by the included deep research engine. Choose research depth based on the engagement:
- **Standard mode** — good for most engagements (15+ sources per layer, 5-10 min)
- **Deep mode** — recommended for competitive audits (25+ sources, 10-20 min)
- **UltraDeep mode** — comprehensive category reviews (30+ sources, 20-45 min)

The engine handles parallel search, credibility scoring, triangulation, and citation verification automatically. For enhanced search, install [search-cli](https://github.com/199-biotechnologies/search-cli) — it aggregates Brave, Serper, Exa, Jina, and Firecrawl.

### Feed Real Competitor Copy
Don't just name competitors — paste their actual website copy, LinkedIn About sections, and taglines into Layer 5. The collision analysis is only as good as the competitor data it receives.

### Don't Skip the Second Pass
The first pass is necessary. The second pass is where the value lives. If Layer 5 says REFINE, run the second pass. Every engagement where we've run the second pass has produced dramatically better positioning than the first pass alone.

### Provide Industry Context
The more context you provide about the brand's industry, the better the research. Client briefs, stakeholder meeting notes, sales deck PDFs, and competitor RFPs all improve output quality.

### Save Your Outputs
Each layer produces structured JSON. Save these files — they're the raw materials. If you need to re-run a single layer later (e.g., update the competitive audit after 6 months), you can feed the saved outputs back in without re-running the entire chain.

---

## Troubleshooting

| Problem | Solution |
|---------|----------|
| Workflow state is unclear | Inventory the saved layer artifacts and compare them with the required sequence above. Do not infer completion from filenames alone. |
| Lost track of an engagement | Summarize the completed layers, missing inputs, current gate, and next required artifact. |
| Skills don't auto-chain | Manually prompt each layer with "use the [previous layer] output as seed" |
| Current research is unavailable | Stop evidence-dependent claims or label them as hypotheses. Do not substitute model memory for current market evidence. |
| Competitive audit says PROCEED too easily | Add more competitors or paste their actual copy. Generic competitor names produce generic audits. |
| Report is too short | Set mode to `enterprise` or provide more context. The compiler needs rich layer outputs to produce a rich report. |
| Layer outputs feel generic | You probably need more specific audience and constraint inputs. "Business owners" is too broad. "VP of Construction at Texas multifamily developers who have completed 5+ projects" is specific. |

---

## What This Replaces

This skill chain replaces a traditional brand strategy engagement:

| Traditional | Brandprint Engine |
|------------|-------------------|
| 6-12 weeks | 2-4 hours |
| Consultant fees plus operator time | Model access plus operator review time |
| 3-5 stakeholder workshops | Text inputs + competitor URLs |
| 1 deliverable, no iteration | Unlimited re-runs with refined context |
| Static recommendations | Living system you can update quarterly |

Treat the output as a decision-support artifact, not automatic truth. Its quality depends on source quality, first-party inputs, operator judgment, and whether the competitive gate was run honestly.

---

## Package Contents

The 8gnc plugin includes `deep-research`, `core-human-truth`, Tiers A through C, `competitive-positioning-audit`, `brand-strategy-compiler`, `brand-revival`, `competitive-teardown`, and this guide.

View saved version →

---
name: brandprint-tier-a
description: Use when the user asks for a Brandprint, brand strategy research, Tier-A elements, brand architecture, competitive analysis paired with brand positioning, equity ladder, signature offers mapping, economic engine modeling, or any comprehensive brand strategy deliverable — Layer 2 of the Brandprint research stack. Also trigger on "run Tier-A," "brandprint research," "full brand audit," "brand sprint," or when the user wants audience segments, JTBD outcomes, competitive set, and positioning in one pass. Use immediately when the core-human-truth skill has just completed — chain directly using its output as the seed.
---

# Brandprint Tier-A — Hybrid Research Directive

Deliver all 10 Tier-A Brandprint elements using a hybrid method: build a shared evidence Backbone first, then run independent, falsifiable sprints per element — each with its own proofs and claim sheets.

## When NOT to Use

- **You only need quick positioning or stylistic outputs.** Tier-C requires Tier-A and Tier-B as seeds — there is no shortcut to a mantra. Run the full chain, or run this skill in `rapid` mode to lighten the load.
- **No access to real market evidence.** Every sprint gates on ≥3 independent sources or behavioral signals. Without reviews, search data, and competitor materials to mine, the claims can't clear the gates.
- **Validating existing positioning against competitors.** That's an adversarial test, not a build — use `competitive-positioning-audit` (Layer 5).

## Chain Position

This is **Layer 2** of a 6-layer Brandprint research stack:

1. **Core Human Truth** (Layer 1) → foundational truth sentence, tension map, archetypes, lexicon
2. **Brandprint Tier-A** (this skill) → uses Layer 1 output as seed; produces 10 defensible brand strategy elements
3. **Brandprint Tier-B** (Layer 3) → uses Tier-A output as seed; produces 5 actionable brand elements with proxy tests
4. **Brandprint Tier-C** (Layer 4) → uses Tier-A + Tier-B output as seeds; produces 4 stylistic elements ready for deployment
5. **Competitive Positioning Audit** (Layer 5) → validates differentiation against named competitors; may trigger second-pass refinement
6. **Brand Strategy Report** (Layer 6) → compiles all layers into consulting-grade deliverable

**When Layer 1 has just completed:** Import its output directly. The `final_sentence`, `tension_map`, `archetypes`, and `lexicon` from Core Human Truth seed the Backbone phase — do not re-research what Layer 1 already validated. Carry forward its sources into the Backbone bibliography.

**When running standalone:** Resolve all variables with the user and build the Backbone from scratch.

## Variables to Resolve

Before starting, confirm these with the user (or inherit from Layer 1):

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `brand_name` | The brand being researched | *required* |
| `topic` | Product, service, or subject | *required* |
| `category` | Industry or category | *required* |
| `audience` | Primary audience definition | *required* (or from Layer 1) |
| `region_context` | Geography or cultural context | US / English-speaking |
| `constraints` | Scope, legal, or brand constraints | None |
| `mode` | `rapid`, `standard`, or `enterprise` | `standard` |

## Principles (Non-Negotiable)

1. **Truth over consensus.** Triangulate across independent sources; show counter-evidence.
2. **Each sprint is a separate claim** with its own acceptance gates and proof minimums.
3. **No fabrication.** If unknown, mark unknown. Quote sparsely; summarize faithfully.
4. **Plain language.** Prioritize verifiable behaviors over vibes.
5. **Log contradictions** between sprints; resolve or bound them.

## Evidence & Citation Policy

For every public claim, include: title, publisher, author (if available), URL, publish date, access date, one-line evidence note, and stance (`supporting` | `conflicting` | `neutral`).

## Global Acceptance Gates

Every Tier-A sprint must meet these before its claim is accepted:

- **Proof minimum:** ≥3 independent sources or behavioral signals per claim
- **Claim sheet required:** statement, boundaries, counter-evidence, confidence rating
- **Comprehension checks** for any public-facing lines (tagline, promises)
- **Economic claims** require simple math with explicit ranges and inputs

**Mode adjustments:**
- *Rapid:* ≥2 sources per claim, 1 behavioral proxy, lightweight comprehension checks
- *Standard:* Full desk research, corpus mining, structured validation
- *Enterprise:* Add cross-market slices, expert panels, longitudinal comparisons

## Workflow

### Phase: Backbone Evidence Garage

**Goal:** Assemble shared inputs once. No final claims yet.

Actions:
- **Landscape scan** — category definition, purchase contexts, substitutes
- **Macro data pull** — longitudinal stats relevant to the topic and audience
- **Review corpus** — collect public reviews, forums, social posts where permitted; store verbatims with links
- **Search-intent map** — SERP, marketplaces, app stores; identify real buyer language
- **Competitor inventory** — top direct and substitutes; capture offers, pricing, proof signals
- **Contradictions log** — note conflicts to test in sprints

If Layer 1 output is available, merge its tension map, archetypes, lexicon, and sources into the Backbone. Do not duplicate research Layer 1 already completed.

Outputs: `annotated_bibliography`, `macro_data_summary`, `review_verbatim_library`, `search_intent_map`, `competitor_inventory`, `contradictions_log_seed`

---

### Sprint 1: Audience Insight + Problem/Tension (paired)

**Inputs:** All Backbone outputs (+ Layer 1 tension map if available)

Actions:
- Extract recurring tensions and triggers from verbatims and search intent
- Draft 3–5 tension statements in audience language
- Score frequency × severity; map triggers to contexts
- Run counter-arguments using conflicting sources

**Acceptance gates:** proof_minimum ≥3, deliver claim sheet

Outputs: `tension_statements_ranked`, `problem_trigger_matrix`, `claim_sheet_audience_problem`

---

### Sprint 2: Desired Outcomes

**Inputs:** `Backbone.review_verbatim_library`, `Sprint 1.tension_statements_ranked`

Actions:
- Convert verbatims to JTBD outcome statements
- Estimate importance and satisfaction gap from credible third-party data or behavioral proxies
- Reduce to top 3 outcomes with boundaries

**Acceptance gates:** proof_minimum ≥3, deliver claim sheet

Outputs: `outcome_statements_top3`, `importance_gap_notes`, `claim_sheet_outcomes`

---

### Sprint 3: Target Audience

**Inputs:** `Backbone.macro_data_summary`, `Backbone.search_intent_map` (+ Layer 1 archetypes if available)

Actions:
- Define 1–3 segments with demographic/firmographic and psychographic cues
- Estimate addressable size bounds using reputable datasets
- Derive willingness-to-pay proxies from pricing signals and switching behaviors

**Acceptance gates:** proof_minimum ≥3, boundaries required, deliver claim sheet

Outputs: `segments_defined`, `size_bounds`, `wtp_proxies`, `signals_identifiers`, `claim_sheet_target`

---

### Sprint 4: Competitive Set

**Inputs:** `Backbone.competitor_inventory`, `Backbone.search_intent_map`

Actions:
- Identify top 5 direct competitors and top 5 substitutes
- Map where they appear along buyer journeys (SERP, marketplaces, referrals)
- Produce substitute map and positioning grid

**Acceptance gates:** proof_minimum ≥3, deliver claim sheet

Outputs: `direct_competitors`, `substitutes`, `substitute_map`, `positioning_grid`, `claim_sheet_competition`

---

### Sprint 5: Signature Offers/Services

**Inputs:** `Sprint 2.outcome_statements_top3`, `Sprint 4.positioning_grid`

Actions:
- Draft 5–8 offers mapped feature → benefit → outcome
- Run basic unit economics sanity with transparent inputs and ranges
- Identify proof requirements per offer (demo metrics, guarantees, case signals)

**Acceptance gates:** proof_minimum ≥3, unit economics required, deliver claim sheet

Outputs: `offers_list`, `feature_benefit_outcome_map`, `unit_economics_ranges`, `claim_sheet_offers`

---

### Sprint 6: Expertise (Authority Signals)

**Inputs:** `Backbone.annotated_bibliography`

Actions:
- Compile independent signals of expertise (press, citations, awards, credentials, case outcomes)
- Summarize 3+ case outcomes with measurable results or reputable testimonials

**Acceptance gates:** proof_minimum ≥3, third-party required, deliver claim sheet

Outputs: `expertise_proofs`, `case_outcome_summaries`, `claim_sheet_expertise`

---

### Sprint 7: Economic Engine

**Inputs:** `Sprint 5.unit_economics_ranges`, `Sprint 3.size_bounds`

Actions:
- Model CAC/LTV ranges with explicit channel mix assumptions
- State payback window assumptions and sensitivity to key levers
- Document boundary conditions where the model breaks

**Acceptance gates:** math transparency required, ranges required, deliver claim sheet

Outputs: `engine_model_ranges`, `payback_window_bounds`, `sensitivity_notes`, `claim_sheet_economic_engine`

---

### Sprint 8: Core Equities/Programs

**Inputs:** `Backbone.search_intent_map`, `Sprint 4.positioning_grid`

Actions:
- List distinctive assets and tent-pole programs tied to recognition and recall
- Estimate share-of-search or analogous recall proxies where available

**Acceptance gates:** proof_minimum ≥3, deliver claim sheet

Outputs: `core_equities_list`, `distinctiveness_proofs`, `recall_proxy_notes`, `claim_sheet_core_equities`

---

### Sprint 9: Equity Ladder Linkage

**Inputs:** `Sprint 5.feature_benefit_outcome_map`, `Sprint 6.expertise_proofs`

Actions:
- Assemble Equity → Benefits → Features → Reasons-to-Believe
- Ensure every benefit has at least one credible proof; remove, reword, or add proof

**Acceptance gates:** no orphan benefits, deliver claim sheet

Outputs: `equity_ladder`, `proof_gaps_closed`, `claim_sheet_equity_ladder`

---

### Sprint 10: One-Line Promise/Tagline

**Inputs:** `Sprint 9.equity_ladder`, `Sprint 2.outcome_statements_top3`, `Sprint 1.tension_statements_ranked` (+ Layer 1 final_sentence and lexicon if available)

Actions:
- Draft 3–5 variants ≤25 words using audience language
- Run plain-language and confusion checks
- Select winner based on evidence tie-back and comprehension

**Acceptance gates:** max 25 words, comprehension check required, deliver claim sheet

Outputs: `tagline_variants`, `comprehension_notes`, `final_tagline`, `claim_sheet_tagline`

---

### Phase: Integration & Contradiction Resolution

**Goal:** Resolve conflicts, finalize linkages, and package outputs.

Actions:
- Update contradiction matrix across all sprints; resolve or set boundaries
- Assemble rationale narrative connecting tensions to proofs
- Compile lexicon: words that resonate/repel from corpus
- Finalize sources with stances and evidence notes

Outputs: `contradiction_matrix`, `rationale_narrative`, `lexicon`, `sources_final`

## Sprint Dependency Map

Understanding which sprints can run in parallel vs. which must wait:

```
Backbone ──┬── Sprint 1 (Audience/Problem) ──┬── Sprint 2 (Desired Outcomes) ──┐
           │                                  │                                 │
           ├── Sprint 3 (Target Audience) ─────────────────────────────────────┤
           │                                                                   │
           ├── Sprint 4 (Competitive Set) ──┬── Sprint 5 (Offers) ────────────┤
           │                                │                                  │
           ├── Sprint 6 (Expertise) ────────┼──────────────────────────────────┤
           │                                │                                  │
           │                                └── Sprint 8 (Core Equities)      │
           │                                                                   │
           │   Sprint 3 + Sprint 5 ──── Sprint 7 (Economic Engine)            │
           │   Sprint 5 + Sprint 6 ──── Sprint 9 (Equity Ladder)             │
           │   Sprint 1 + Sprint 2 + Sprint 9 ──── Sprint 10 (Tagline)       │
           │                                                                   │
           └──────────────────── Integration & Contradiction Resolution ───────┘
```

## Heuristics

- Prefer primary datasets and systematic reviews over opinion pieces
- When credible sources conflict, show both and explain method/sample differences
- Reduce adjectives; increase observable behaviors and numbers with ranges
- If a truth is situational, state boundary conditions explicitly

## What NOT to Do

- Do not rely on a single think-piece or vendor blog for a claim
- Do not exceed 25 words for the final Promise/Tagline
- Do not invent survey results
- Do not skip claim sheets — every sprint must produce one
- Do not promote Backbone observations directly to accepted claims — the Backbone is shared input; only a sprint's acceptance gates produce a claim
- Do not give point estimates for economic claims — Sprint 7 and unit economics require ranges with explicit inputs, or the math reads as fabricated
- Do not run Sprint 10 (Tagline) before Sprints 1, 2, and 9 finish — a tagline drafted without ranked tensions and the equity ladder has nothing to tie back to

## Output Format

Deliver the final output as structured JSON conforming to the schema in `references/output-schema-tier-a.md`.

The JSON must include: `brand_name`, `topic`, `audience`, `backbone_repository`, `tierA_results` (all 10 elements with claim sheets), `contradiction_matrix`, `sources`, and `audit_log`.

**Forward chaining:** When this skill completes, its full output object becomes the input seed for Layer 3 (Brandprint Tier-B). Preserve the complete JSON — Layer 3 needs tensions, outcomes, audience, equity ladder, competition, and tagline to produce actionable brand elements. If the `brandprint-tier-b` skill is available, proceed directly into it without user confirmation.

If the user has the `branded-mayhem-pdf` skill available, offer to generate a branded PDF deliverable of the Tier-A results.

## Evaluation Rubric

1. **Backbone completeness** — shared inputs exist and are cited
2. **Proof density** — each Tier-A claim meets or exceeds proof minimums
3. **Conflict hygiene** — contradictions logged and resolved or bounded
4. **Comprehension** — public lines pass plain-language checks
5. **Economic sanity** — ranges and inputs are explicit; no hidden math
6. **Traceability** — every claim ties to sources with stances
7. **Reusability** — outputs slot cleanly into the Brandprint scaffold and forward into Layers 3–4

## File I/O Contract (orchestrated mode)

When an authorized orchestrator provides explicit paths, honor them exactly:

- **Seed inputs:** read ONLY the JSON/YAML files listed in the dispatch prompt.
- **Output:** write the final JSON object to the exact path given (under
  `.brandprint/engagements/{slug}/pass-N/`). No other location.
- **Return value:** your final message is the output path plus the layer's key
  artifact — not the full JSON. The orchestrator reads files, not transcripts.

When invoked as a direct skill call, present the JSON in conversation or through the supported file workflow and tell the user to preserve it for the next layer.

Referenced files: 1

View saved version →

---
name: brandprint-tier-b
description: Use when the user asks for Tier-B brand elements — brand activator, brand platform word, tone and manner guidelines, moat statement, brand no-no's, brand guardrails, brand voice, or brand behavior testing — Layer 3 of the Brandprint research stack. Also trigger on "run Tier-B," "brand activation," "brand tone," "competitive moat," "brand rules," or when the user wants practical, testable brand outputs derived from existing strategy research. Use immediately when the brandprint-tier-a skill has just completed — chain directly using its output as the seed.
---

# Brandprint Tier-B — Activation & Guardrails Directive

Deliver 5 Tier-B brand elements that are practical, testable, and aligned to validated Tier-A truths. Evidence is lightweight but real. Every element gets at least one behavioral proxy signal.

## When NOT to Use

- **No Tier-A output exists.** Tier-B derives, it doesn't originate. Run `brandprint-tier-a` first — standalone mode here produces reduced-confidence output and says so in the audit log.
- **Full visual identity or design systems.** Tone, platform word, and guardrails are verbal/behavioral elements. Logos, palettes, and type systems are design work outside this chain.
- **Testing positioning against competitors.** Tier-B checks alignment with Tier-A, not differentiation in market — that's `competitive-positioning-audit` (Layer 5).

## Chain Position

This is **Layer 3** of a 6-layer Brandprint research stack:

1. **Core Human Truth** (Layer 1) → foundational truth sentence, tension map, archetypes, lexicon
2. **Brandprint Tier-A** (Layer 2) → 10 defensible brand strategy elements with evidence-gated sprints
3. **Brandprint Tier-B** (this skill) → uses Layer 2 output as seed; produces 5 actionable brand elements with proxy tests
4. **Brandprint Tier-C** (Layer 4) → uses Tier-A + Tier-B output as seeds; produces 4 stylistic elements ready for deployment
5. **Competitive Positioning Audit** (Layer 5) → validates differentiation against named competitors; may trigger second-pass refinement
6. **Brand Strategy Report** (Layer 6) → compiles all layers into consulting-grade deliverable

**When Layer 2 has just completed:** Import its full output JSON directly. Pull Tier-A anchors — tensions, outcomes, audience, equity ladder, competition, tagline, moat signals — into the Intake phase. Do not re-research what Layers 1–2 already validated. Carry forward all sources and the contradiction matrix.

**When running standalone:** Resolve all variables with the user. If no Tier-A backbone exists, build a lightweight Backbone Tap from scratch using desk research, but note reduced confidence in the audit log.

## Variables to Resolve

Before starting, confirm these with the user (or inherit from Layers 1–2):

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `brand_name` | The brand being researched | *required* |
| `topic` | Product, service, or subject | *required* |
| `category` | Industry or category | *required* |
| `audience` | Primary audience definition | *required* (or from Layer 2) |
| `region_context` | Geography or cultural context | US / English-speaking |
| `constraints` | Scope, legal, brand safety, cultural sensitivities | None |
| `languages` | Output language | English |
| `timeline_days` | Suggested execution window | 7–21 days |
| `mode` | `rapid`, `standard`, or `enterprise` | `standard` |
| `backbone_source` | Link or reference to Tier-A backbone repository | From Layer 2 if chained |

## Principles (Non-Negotiable)

1. **Evidence-informed, not evidence-bloated.** Two independent sources or one source + a behavioral proxy per claim.
2. **Mirror the audience's words.** Reduce adjectives. Show behaviors.
3. **Test the smallest possible thing:** five-second comprehension, recall ping, micro-click, or completion rate.
4. **If an output conflicts with Tier-A,** either revise or state boundary conditions.
5. **No fabrication.** If data is unknown, label as unknown.

## Evidence & Citation Policy

For any external claim, include: title, publisher, URL, dates, and a one-line evidence note. Quote sparingly. Same citation format as Layers 1–2.

## Global Acceptance Gates

Every Tier-B element must meet these before its claim is accepted:

- **Proof minimum:** ≥2 independent sources OR 1 source + 1 behavioral proxy
- **Plain-language and confusion checks** for anything public-facing
- **Alignment check** against Tier-A tensions, outcomes, and audience

**Mode adjustments:**
- *Rapid:* Single pass using Backbone + 1 proxy test per element
- *Standard:* Backbone + 2 proxy tests per element; alt variants where helpful
- *Enterprise:* Add cross-segment variants and pre-registered test plans

## What NOT to Do

- Don't invent survey results
- Don't contradict Tier-A without stating limits
- Don't ship jargon
- Don't skip proxy tests — every element needs at least one behavioral signal
- Don't copy Tier-A proof points verbatim as proxy tests — proxy tests must be designed fresh per element (recall ping, micro-click, completion rate)
- Don't treat the platform word as a tagline — it is a one-word decision filter for internal use, never public copy
- Don't write a no-no rule without its rationale and the Tier-A tension it protects — an unanchored rule gets ignored or argued away

## Workflow

### Phase 0: Intake & Alignment

**Goal:** Confirm context and pull Tier-A anchors.

Actions:
- Resolve all variables; pull Tier-A anchors: tensions, outcomes, audience, equity ladder, competition
- List constraints (legal, brand safety, cultural sensitivities)
- Define success criteria per element (see acceptance gates in each sprint)

Outputs: `alignment_brief`, `tierA_anchor_summary`, `success_criteria`

---

### Phase: Backbone Tap

**Goal:** Reuse existing evidence; no re-collection if unnecessary.

Actions:
- Inherit review verbatims, search-intent phrases, competitor inventory from Tier-A Backbone
- Flag contradictions to watch

If no Tier-A Backbone exists, conduct lightweight desk research to populate: review verbatims (min 20), search-intent sample (min 10 phrases), top 5 competitor inventory. Log reduced confidence.

Outputs: `backbone_refs_used`, `contradictions_watchlist`

---

### Sprint: Brand Activator (signature micro-behavior)

**Goal:** Define the one repeatable action or ritual that makes the brand tangible at touchpoints.

Actions:
- Hypothesize 2–3 activators derived from Tier-A tensions and outcomes
- Define where to use (touchpoints) and expected micro-behavior
- Design a proxy test: completion rate, post-exposure recall, or micro-conversion
- Select winner based on proxy signal + feasibility

**Acceptance gates:**
- Proof minimum: ≥2 (independent sources or 1 source + 1 behavioral proxy)
- Recall or completion proxy required
- Alignment with Tier-A required

Outputs: `activator_candidates`, `test_plan`, `proxy_results`, `final_activator_pack`

---

### Sprint: Brand Platform (single word/idea)

**Goal:** Identify one word that becomes the decision filter for the brand.

Actions:
- Mine audience language to propose 3–5 platform words with synonyms
- Run semantic field check against corpus and competitors
- Write the gatekeeper question: "Does this create more [word]?"
- Select word with strongest evidence and lowest confusion risk

**Acceptance gates:**
- Proof minimum: ≥2
- Confusion rate check required
- Semantic overlap with competitors must be noted

Outputs: `platform_word_options`, `semantic_notes`, `gatekeeper_question`, `final_platform_word`

---

### Sprint: Tone & Manner (adjectives and key phrases)

**Goal:** Codify how the brand sounds using real customer language.

Actions:
- Extract frequent customer phrases; remove category clichés
- Propose 3–6 adjectives and 5–8 key phrases grounded in verbatims
- Run five-second and plain-language checks
- Provide do/say examples and anti-patterns

**Acceptance gates:**
- Proof minimum: ≥2
- Plain-language check required
- Anti-patterns required

Outputs: `adjectives`, `key_phrases`, `dos_and_donts`, `readability_notes`

---

### Sprint: Our Moat (why we win)

**Goal:** Articulate why the brand wins in observable, defensible terms.

Actions:
- Draft moat statements tied to observable advantages (speed to value, switching cost, IP, distribution)
- Cross-check against competitor claims and public signals
- Provide time-to-value comparison or switching-cost proxy

**Acceptance gates:**
- Proof minimum: ≥2
- Observable signal required
- No handwaving — every moat claim must cite a real signal

Outputs: `moat_statement`, `evidence_notes`, `observable_signals`, `time_to_value_or_switch_cost_proxy`

---

### Sprint: Brand No-No's

**Goal:** Define the guardrails that protect brand integrity.

Actions:
- From complaints, usability findings, and brand safety constraints, list 5–10 "never/avoid" rules
- Attach rationale and the risk each prevents
- Map each to a Tier-A tension it protects

**Acceptance gates:**
- Proof minimum: ≥2
- Each rule requires rationale
- Link to Tier-A tension required

Outputs: `no_nos_list`, `rationales`, `risk_mapping`

---

### Phase: Integration & Packaging

**Goal:** Ensure Tier-B elements align and don't step on Tier-A.

Actions:
- Run contradiction check against Tier-A anchors
- Assemble quick rationale notes and citations
- Produce a one-pager per element for handoff

Outputs: `contradiction_check`, `rationale_notes`, `tierB_one_pagers`

## Sprint Dependency Map

Tier-B sprints are lighter than Tier-A. Most can run in parallel after the Backbone Tap:

```
Tier-A Output (Layer 2)
    │
    ▼
Intake & Alignment
    │
    ▼
Backbone Tap ──┬── Sprint: Brand Activator ──────────────┐
               │                                          │
               ├── Sprint: Brand Platform ────────────────┤
               │                                          │
               ├── Sprint: Tone & Manner ─────────────────┤
               │                                          │
               ├── Sprint: Our Moat ──────────────────────┤
               │                                          │
               └── Sprint: Brand No-No's ─────────────────┤
                                                          │
                         Integration & Packaging ◄────────┘
```

All 5 sprints can run in parallel since they each tap the same Backbone + Tier-A anchors independently. The Integration phase waits for all 5 to complete.

## Heuristics

- If you can't explain it in one breath, it isn't Tier-B
- Prefer real customer words over clever synonyms
- One proxy signal beats five opinions
- If two good options tie, pick the one that's cheaper to test live

## Output Format

Deliver the final output as structured JSON conforming to the schema in `references/output-schema-tier-b.md`.

The JSON must include: `brand_name`, `topic`, `audience`, `backbone_refs_used`, `tierB_results` (all 5 elements with proxy tests), `sources`, and `audit_log`.

**Forward chaining:** When this skill completes, its full output object becomes the input seed for Layer 4 (Brandprint Tier-C). Preserve the complete JSON — Layer 4 needs Tier-B tone, platform word, and no-no rules. Also preserve the Tier-A JSON from Layer 2; Layer 4 needs both. If the `brandprint-tier-c` skill is available, proceed directly into it without user confirmation.

If the user has the `branded-mayhem-pdf` skill available, offer to generate a branded PDF deliverable of the Tier-B results.

## Evaluation Rubric

1. **Alignment** — Tier-B outputs reflect Tier-A truths without contradiction
2. **Evidence** — each element meets the Tier-B proof minimum (≥2 or 1+proxy)
3. **Behavior** — at least one proxy signal per element in rapid mode; two in standard mode
4. **Clarity** — plain-language and low confusion in public-facing pieces
5. **Differentiation** — platform word and moat are not commodity language
6. **Utility** — activator is specific, placeable, and testable at live touchpoints

## File I/O Contract (orchestrated mode)

When an authorized orchestrator provides explicit paths, honor them exactly:

- **Seed inputs:** read ONLY the JSON/YAML files listed in the dispatch prompt.
- **Output:** write the final JSON object to the exact path given (under
  `.brandprint/engagements/{slug}/pass-N/`). No other location.
- **Return value:** your final message is the output path plus the layer's key
  artifact — not the full JSON. The orchestrator reads files, not transcripts.

When invoked as a direct skill call, present the JSON in conversation or through the supported file workflow and tell the user to preserve it for the next layer.

Referenced files: 1

View saved version →

---
name: brandprint-tier-c
description: Use when the user asks for Tier-C brand elements — brand mantra, brand personification, translation line, features-to-benefits mapping, brand style elements, brand personality vignette, or brand copy finalization — Layer 4 of the Brandprint research stack. Also trigger on "run Tier-C," "brand mantra," "brand personality," "header line," "features list," or when the user wants ready-to-deploy brand style outputs derived from existing strategy. Use immediately when the brandprint-tier-b skill has just completed — chain directly using its output as the seed.
---

# Brandprint Tier-C — Style & Deployment Directive

Deliver 4 Tier-C brand elements that are stylistic, derivative, and ready to deploy. These outputs create no new claims. Every line traces back to validated Tier-A and Tier-B truths.

## When NOT to Use

- **Tier-A or Tier-B output is missing.** This layer needs both as anchors. Without them, either collect equivalent inputs from the user or run the chain from Layer 1 — don't improvise anchors.
- **Creating new claims or strategy.** Tier-C styles what Layers 1-3 validated. If the brand needs a new benefit, proof, or position, that's a Tier-A sprint, not a Tier-C edit.
- **Long-form copywriting.** Mantra, vignette, translation line, features list — that's the full scope. Web pages, campaigns, and articles are downstream deployment work.

## Chain Position

This is **Layer 4** of a 6-layer Brandprint research stack:

1. **Core Human Truth** (Layer 1) → foundational truth sentence, tension map, archetypes, lexicon
2. **Brandprint Tier-A** (Layer 2) → 10 defensible brand strategy elements with evidence-gated sprints
3. **Brandprint Tier-B** (Layer 3) → 5 actionable brand elements with proxy tests (activator, platform word, tone, moat, no-no's)
4. **Brandprint Tier-C** (this skill) → uses Tier-A + Tier-B output as seeds; produces 4 stylistic elements ready for team handoff
5. **Competitive Positioning Audit** (Layer 5) → validates differentiation against named competitors; may trigger second-pass refinement
6. **Brand Strategy Report** (Layer 6) → compiles all layers into consulting-grade deliverable

**When Layer 3 has just completed:** Import the full Tier-B output JSON and the Tier-A JSON carried forward. Pull anchors — tensions, outcomes, equity ladder, tagline from Tier-A; tone, key phrases, platform word, no-no rules from Tier-B. Do not create new claims or re-research.

**When running standalone:** Resolve all variables with the user. If no Tier-A/B anchors exist, ask the user to provide equivalent inputs (tensions, outcomes, tone adjectives, platform word, equity ladder) or recommend running the full chain first.

## Variables to Resolve

Before starting, confirm these with the user (or inherit from Layers 1–3):

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `brand_name` | The brand being styled | *required* |
| `topic` | Product, service, or subject | *required* |
| `category` | Industry or category | *required* |
| `audience` | Primary audience definition | *required* (or from Layer 2) |
| `region_context` | Geography or cultural context | US / English-speaking |
| `constraints` | Legal, brand safety, cultural constraints | None |
| `languages` | Output language | English |
| `timeline_days` | Suggested execution window | 3–10 days |
| `mode` | `rapid`, `standard`, or `enterprise` | `standard` |
| `tierA_anchor_ref` | Link or ID for Tier-A output | From Layer 2 if chained |
| `tierB_anchor_ref` | Link or ID for Tier-B output | From Layer 3 if chained |

## Principles (Non-Negotiable)

1. **Alignment first.** Every line must trace to Tier-A tensions, outcomes, and equity ladder, and Tier-B tone and platform.
2. **Clarity over clever.** Sixth-grade readability. Zero jargon.
3. **Cultural hygiene.** Avoid stereotypes. Prefer inclusive, specific language.
4. **No new promises.** If text implies a claim, link it to an existing proof or reword as mood.
5. **Naming note.** If creating a new name or legal risk appears, escalate to Tier-A naming sprint.

## Quality Gates (Global)

- Plain-language check for all public lines
- Alignment check against Tier-A and Tier-B anchors
- Stereotype and cultural risk check
- Word-count limits: mantra = 3 words exactly; translation line = 20 words or fewer

**Mode adjustments:**
- *Rapid:* One pass, one variant per element
- *Standard:* Two variants per element and a quick alignment note
- *Enterprise:* Three variants per element, cross-language check, and a mini style rationale

## What NOT to Do

- Do not contradict Tier-A or Tier-B
- Do not add benefits or proofs that do not exist in the equity ladder
- Do not use cliches or em dashes; keep punctuation simple
- Do not ship jargon or insider language
- Do not exceed 3 words for the mantra — exactly three, and hyphenating two words into one doesn't count
- Do not keep a feature that lacks a mapped benefit and proof — cut it and log it in `gaps_list`; orphans break the equity ladder
- Do not coin a new brand or product name inside a sprint — route it through the Name Hygiene Check and escalate to a Tier-A naming sprint if risk appears

## Workflow

### Phase 0: Intake and Anchor Pull

**Goal:** Load Tier-A and Tier-B anchors and constraints.

Actions:
- Load tensions, outcomes, target segments, equity ladder, and final tagline from Tier-A
- Load tone, key phrases, platform word, and no-no rules from Tier-B
- List any legal, cultural, or language constraints

Outputs: `anchor_summary`, `constraints_list`

---

### Phase 1: Derivation Map

**Goal:** Map Tier-C elements to their parents in A and B.

Actions:
- Create a short matrix showing each Tier-C element and which Tier-A and Tier-B items it derives from
- Flag any possible contradictions for review

Outputs: `derivation_matrix`, `contradictions_watchlist`

---

### Sprint: Brand Mantra (three words)

**Goal:** Distill the brand into exactly three words that echo the platform word and core outcome.

Actions:
- Generate 3–5 candidate three-word mantras that echo the platform word and the core outcome
- Remove cliches and internal jargon
- Run plain-language check and rhythm check

**Acceptance gates:**
- Word count: exactly 3
- Alignment with platform word and core outcome required
- Plain-language check required

Outputs: `mantra_options`, `final_mantra`, `alignment_notes`

---

### Sprint: Personification Vignette

**Goal:** Make the brand tangible as a character people can picture.

Actions:
- Draft a day-in-the-life vignette with fields: city, music genre, TV show, drink, outfit
- Offer 1–2 alternates for different segments or moods
- Run stereotype and cultural risk checklist

**Acceptance gates:**
- Stereotype check required
- Alignment with tone and platform required

Outputs: `primary_vignette`, `alternate_vignettes`, `cultural_risk_notes`

---

### Sprint: Header Translation Line

**Goal:** Write the one plain-English sentence that explains what the brand does and why it matters.

Actions:
- Write the plain-English SVO line: "We [do X] so [audience] can [outcome]."
- Keep verbs active and concrete
- Run plain-language check and confusion check

**Acceptance gates:**
- Max 20 words
- SVO structure required
- Plain-language check required

Outputs: `translation_line_variants`, `final_translation_line`, `readability_notes`

---

### Sprint: Features List for Equity Ladder

**Goal:** Map product features to existing benefits and reasons-to-believe with no orphans.

Actions:
- Pull features from product facts; map each to the existing benefit and reason-to-believe from the Tier-A equity ladder
- Remove any feature that lacks a mapped benefit or proof
- Mark gaps for follow-up

**Acceptance gates:**
- Fact-check required
- No orphan features (every feature maps to a benefit and proof)

Outputs: `features_mapped`, `gaps_list`

---

### Optional: Name Hygiene Check

**Goal:** Catch naming risks before they become legal problems.

Actions:
- If a new or changed brand name is proposed, run pronounceability and basic availability scan notes
- If risk is detected, escalate to Tier-A naming sprint

**Acceptance gates:**
- Escalate if risk detected

Outputs: `name_hygiene_notes`, `escalation_recommendation`

---

### Phase: Integration and Packaging

**Goal:** Assemble clean, ready-to-use Tier-C outputs.

Actions:
- Run final alignment check against anchors and no-no rules
- Package final variants and notes with simple usage guidance
- Update derivation matrix with final references

Outputs: `alignment_check`, `tierC_one_pagers`, `final_derivation_matrix`

## Sprint Dependency Map

Tier-C sprints are lightweight and mostly parallel after the Derivation Map:

```
Tier-A Output (Layer 2) + Tier-B Output (Layer 3)
    │
    ▼
Intake and Anchor Pull
    │
    ▼
Derivation Map ──┬── Sprint: Brand Mantra ──────────────────┐
                 │                                           │
                 ├── Sprint: Personification Vignette ───────┤
                 │                                           │
                 ├── Sprint: Header Translation Line ────────┤
                 │                                           │
                 ├── Sprint: Features List (Equity Ladder) ──┤
                 │                                           │
                 └── Optional: Name Hygiene Check ───────────┤
                                                             │
                        Integration and Packaging ◄──────────┘
```

All 4 core sprints can run in parallel. The Name Hygiene Check runs only if a new name is proposed. Integration waits for all to complete.

## Heuristics

- Use verbs. Kill filler adjectives.
- Prefer audience words over brand words.
- If it reads like an ad, simplify it.
- If two options tie, keep the one that is easier to use across channels.
- No stereotypes. If you have to ask, cut it.

## Output Format

Deliver the final output as structured JSON conforming to the schema in `references/output-schema-tier-c.md`.

The JSON must include: `brand_name`, `audience`, `derivation_matrix`, `tierC_results` (all 4 elements plus optional name hygiene), `consistency_matrix`, and `audit_log`.

**Forward chaining:** When this skill completes, recommend running the `competitive-positioning-audit` skill (Layer 5) before compiling the final report. Layer 5 validates whether the Brandprint positioning is actually differentiated from competitors. If it finds collisions, it triggers a second pass through Layers 1-4 with competitive context — which typically produces dramatically sharper positioning.

If the user wants to skip Layer 5 and go directly to the report, proceed to the `brand-strategy-compiler` skill (Layer 6). But note that skipping competitive validation risks shipping positioning that collides with an entrenched competitor.

## Evaluation Rubric

1. **Alignment** — every Tier-C element traces to Tier-A and Tier-B
2. **Clarity** — plain language, low confusion, no jargon
3. **Cultural hygiene** — zero stereotypes or lazy tropes
4. **Brevity** — mantra is three words; translation line fits the 20-word limit
5. **Consistency** — features map to benefits and proofs with no orphans
6. **Deployability** — outputs are ready to paste into the Brandprint without edits

## File I/O Contract (orchestrated mode)

When an authorized orchestrator provides explicit paths, honor them exactly:

- **Seed inputs:** read ONLY the JSON/YAML files listed in the dispatch prompt.
- **Output:** write the final JSON object to the exact path given (under
  `.brandprint/engagements/{slug}/pass-N/`). No other location.
- **Return value:** your final message is the output path plus the layer's key
  artifact — not the full JSON. The orchestrator reads files, not transcripts.

When invoked as a direct skill call, present the JSON in conversation or through the supported file workflow and tell the user to preserve it for the next layer.

Referenced files: 1

View saved version →

---
name: brand-revival
description: Use when a brand is stale, broken, or invisible and needs resurrection, repositioning, or reinvention after losing cultural relevance. Triggers on "stale brand," "brand revival," "rebrand," "brand refresh," "legacy brand," "brand turnaround," "partnership strategy," "brand resurrection," "brand has lost relevance," "nobody cares about this brand anymore," "brand went quiet," "how do we bring this back," or when a client has a brand with dormant equity that needs reactivation.
---

# Brand Revival Playbook

Dead brands are not dead. They are dormant. The difference is audience memory. If people remember the brand — even to say "what happened to them?" — there is equity. The revival question is never "do we start over?" It is "what still has heat, and what do we ignite it with?"

The mistake brands make: they try to remind everyone who they were. The move: find partners and moments that make people discover who they are now.

## When NOT to Use

- **Healthy brands needing a routine refresh.** Revival methodology assumes lost relevance. A working brand that wants sharper positioning runs the Brandprint chain, not a resurrection.
- **Brand-new brands with no dormant equity.** Nothing to revive — no audience memory means no assets to reignite. Run the Brandprint chain (`core-human-truth` onward) and build fame first.
- **Leadership has no appetite for visible change.** Every phase here — partners, drops, new creative authority — is public and disruptive. If the mandate is "bring it back but change nothing," decline the framework.

## When You Receive a Request

Before running the framework, resolve these variables. If any are missing, ask.

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `brand_name` | The brand being revived | *required* |
| `category` | Industry, vertical, or product category | *required* |
| `original_audience` | Who the brand built for originally | *ask if unclear* |
| `current_audience` | Who, if anyone, still engages today | *research if not provided* |
| `dormancy_window` | How long since peak relevance | *required* |
| `assets_available` | Name, IP, distribution, physical locations, archive | *inventory together* |
| `revival_budget_tier` | Scrappy ($0-50K) / Moderate ($50-250K) / Full ($250K+) | *ask* |
| `target_outcome` | Awareness play, revenue reactivation, acquisition prep, or brand sale | *required* |

## Phase 0 — Triage Diagnostic

Before any strategy, determine what kind of brand problem this actually is. Each type has a different revival path.

### The Three Brand Failure Modes

**Stale (Irrelevant)**
The brand still exists but stopped being interesting. No dramatic incident — just drift. Culture moved and the brand did not follow. Signs: declining search trends, aging audience, competitors copying old positioning, leadership referencing past campaigns as proof of relevance.

Revival path: Cultural re-entry through partners and drops. Authenticity bridge over legacy team.

**Broken (Damaged)**
Something happened. A PR incident, a founder scandal, a product failure, a betrayal of audience trust. People remember — but not the way you want. Residual brand awareness is poisoned. Signs: brand name appears consistently in negative contexts, social mentions skew negative, press coverage is incident-specific, earned media has stalled.

Revival path: Reset through distance and proof. New chapter framing, not apology campaigns. Partner with parties who carry credibility the brand forfeited.

**Invisible (Never Had Presence)**
The brand was never truly known. It existed commercially but never built cultural mass. No nostalgia, no community, no iconic moment. Signs: low unaided awareness, clean social sentiment (because no one cares enough to be negative), minimal organic search volume, founder-as-entire-personality.

Revival path: Fame-first, not revival. This skill is for brands with dormant equity, not brands without any. Invisible brands need a fame-first approach rather than revival methodology.

### Triage Output

State the failure mode clearly before proceeding. If mixed (e.g., stale with one broken element), identify primary and secondary types. The framework below applies to Stale and Broken. Invisible brands need the fame-first path.

---

## The Revival Framework — Five Phases

### Phase 1: Autopsy

Identify what actually killed the brand's relevance. Do not accept the client's stated narrative — they almost always misidentify the cause.

**The four causes:**

**Market shift** — The category moved. What the brand stood for became obsolete or irrelevant through no fault of its own. Examples: Kodak, Blockbuster, Myspace. The brand did not fail. The context failed the brand.

**Self-inflicted** — Internal decisions killed it. Overextension, logo redesign that severed equity, management that prioritized efficiency over experience, moving upmarket and abandoning the original audience, cost-cutting that reduced quality while keeping the premium price signal.

**Competition** — A better-resourced competitor took the audience. Not necessarily through superior product — often through superior distribution, price, or cultural alignment.

**Cultural drift** — The brand's values and the culture's values diverged. What it stood for became something the culture rejected or outgrew. Common in brands tied to specific demographics who aged out of cultural influence.

**Autopsy deliverable:** A single root cause sentence. Not a list — a sentence. "The brand died because [cause], while [what the audience needed instead] emerged." This sentence drives every revival decision.

**How to run the autopsy:**
- Pull search trend data for the brand name (Google Trends or equivalent)
- Identify the inflection point: the quarter or year when trajectory bent
- Map what else happened at that moment (category events, competitive launches, cultural shifts)
- Review the brand's own actions in that period (product launches, campaigns, leadership changes, price changes)
- Interview or survey current/former audience members if possible; use public Reddit, review data, and social history as proxy

### Phase 2: Asset Inventory

Before strategy, map what still exists. Revival is built on assets, not imagination. Most brands have more than they think.

**Inventory categories:**

| Asset Type | What to Look For | Equity Signal |
|------------|-----------------|---------------|
| Name recognition | Unaided recall, search volume, pop culture references | High if people still reference it unprompted |
| Nostalgia | Subreddit discussions, fan communities, "bring back" petitions, TikTok throwbacks | High if fans are doing revival work for free |
| Distribution | Retail relationships, shelf space, licensing deals still active | High if any physical or digital distribution persists |
| IP | Patents, trademarks, design language, mascots, characters, slogans | High if any are still protected and distinctive |
| Audience memory | What the audience associates with the brand — the "brand in their head" | The most important asset; determine what survives |
| Heritage aesthetics | Packaging, typefaces, color systems, design era that reads as authentic | High if retro versions are being bootlegged or remixed |
| Founder or team credibility | Is there a person still associated with the brand who carries trust? | Only if they are genuinely respected outside the brand context |

**Asset Inventory deliverable:** A ranked list of surviving assets with a one-line equity note per asset. Identify which assets are brand equity (value to audience) vs. business assets (value to operations). Revival strategy leads with brand equity assets.

### Phase 3: Unexpected Partnership Model

This is the engine of revival. Not a campaign. A partner.

**Why partnerships over campaigns:** Campaigns require attention. Partners borrow credibility. When a brand with zero cultural gravity partners with a brand that has maximum cultural gravity in an adjacent space, the audience of the high-gravity brand transfers cultural permission to the dormant brand. You do not have to earn trust from scratch — you inherit it.

**The partnership selection criteria:**

Adjacent, not competitive. The partner must share audience but not compete for the same revenue. The Gap x Airbnb concept works because Gap (clothing) and Airbnb (travel accommodation) serve overlapping audiences with completely non-competing offers. Neither threatens the other's business model. Identify five categories that share the revival brand's core audience but operate in a different aisle.

Surprising, not obvious. The best partnerships feel unexpected on the surface but inevitable once explained. The explanation is the story — "of course Gap and Airbnb, because people dress for where they're going." If the partnership feels obvious before explanation, it will not generate cultural attention. If it feels random after explanation, it will not convert. The sweet spot: surprising at first, inevitable on reflection.

Data-driven cultural overlap. Do not guess cultural overlap — identify it. Use:
- Audience overlap analysis (social followers, YouTube subscribers, Reddit communities)
- Co-purchase or co-use behavior data (what else does the revival brand's remaining audience buy or engage with?)
- Shared cultural moments (what events, shows, trends, or subcultures appear in both brand audiences?)
- Keyword overlap to find shared search intent

**Finding the partners — research sequence:**

1. Map the revival brand's highest-equity audience segment (the people who most remember it positively)
2. Identify what that segment cares about beyond this category (use Reddit community analysis, social listening, or equivalent research tools)
3. Generate 20 brands in adjacent categories that serve that segment
4. Score each against: surprise factor (1-10), audience overlap (1-10), business logic (1-10)
5. Select the top 3-5 for a Partnership Pitch brief

**Partnership structures to propose:**

| Structure | Description | Best For |
|-----------|-------------|----------|
| Co-branded drop | Limited product that blends both brand aesthetics | Stale brands with strong heritage design |
| Data-activated collab | Partner uses their proprietary data to customize the revival product | Partners with booking, usage, or behavioral data |
| Creator native collab | Partner with individual creators who are native to the new positioning | Broken brands that need credibility transfer from people, not institutions |
| Pop-up event | Physical presence built on both brand audiences | Brands with strong nostalgia that benefits from tactile re-entry |
| Platform takeover | Partner brand brings revival brand into their owned channel (email, app, content) | Revival brand with zero owned audience; leverages partner's distribution |

**Partnership Model deliverable:** Partnership Map — 3 recommended partners with one-paragraph rationale per partner, suggested structure, and the "surprising but inevitable" explanation sentence.

### Phase 4: Limited Drop Strategy

Revival happens through scarcity, not saturation. Every major brand resurrection in the last decade followed the same pattern: do less, make it matter, create demand before you create supply.

**Why scarcity works for revival:**
- It signals confidence. Brands that flood the market signal desperation. Brands that limit supply signal demand.
- It creates a cultural moment. A drop is an event. A product launch is just a product.
- It lets the market validate before full commitment. A limited drop that sells out tells you whether the revival has real demand before you invest in scale.
- It generates earned media. Scarcity creates news. "Sells out in 4 hours" is a story. "Now available at retailers nationwide" is not.

**The Drop Calendar model:**

Structure revival in three acts over 12-18 months:

**Act 1 — Signal Drop (Month 1-3)**
One product, one partner, one story. Extremely limited quantity. Purpose: generate cultural signal, not revenue. Measure: earned media, social conversation, sell-through rate, waitlist growth.

**Act 2 — Proof Drop (Month 4-8)**
Second limited drop, slightly larger. Builds on Signal Drop learning. May introduce a second partner. Purpose: demonstrate consistency, not a one-hit moment. Measure: repeat purchasers from Act 1, new audience acquisition.

**Act 3 — Platform Drop (Month 9-18)**
Seasonal or recurring limited drops. Not limited by extreme scarcity but still structured as events. Purpose: establish the revival brand as a recurring cultural presence before moving into any broader availability. Measure: owned audience growth, brand search volume trajectory, retailer inquiry.

**Drop format options by budget:**

| Budget Tier | Drop Format |
|------------|-------------|
| Scrappy ($0-50K) | Creator collab, digital-only drop, licensing of existing IP with partner |
| Moderate ($50-250K) | Physical capsule collection, pop-up event (1-2 markets), co-branded product run |
| Full ($250K+) | Multi-city activation, broadcast-worthy campaign anchoring the drop, retail partnership |

**Drop deliverable:** Drop Calendar — three acts with format, partner assignment, quantity range (by tier), and success metrics per act.

### Phase 5: Authenticity Bridge

The most common revival failure: bringing back the old brand team to execute the new positioning.

**The problem:** The people who built the original brand carry the original brand's assumptions. They will unconsciously pull toward what worked before. They will feel ownership over the legacy and resist changes that might feel like betrayal. They will prioritize internal comfort over cultural accuracy.

**The principle:** Collaborate with people and designers who are native to where the brand is going, not where it has been. This does not mean abandoning the founders — it means putting new voices in creative authority.

**Finding authentic collaborators:**

Identify the cultural space the brand is re-entering. Map the creators, designers, makers, and voices who already operate there with credibility. These are people who:
- Would use the brand if it were culturally appropriate, but would not be caught dead using it now
- Have audiences that overlap with the revival brand's target
- Are not yet overexposed (no brands so mainstream they have become wallpaper)
- Have a clear point of view that sharpens, not dilutes, the brand's new positioning

**The authenticity bridge test:** Would the collaborator's audience be surprised they worked with this brand? If yes — you are in the right territory. If their audience would expect it, you have hired someone too safe.

**Authenticity Bridge deliverable:** Collaborator Brief — 5-10 names (individuals or studios) who represent where the brand is going, with a one-line rationale per name and a suggested scope of involvement.

---

## Brand Revival Prescription

After all five phases are complete, compile findings into this format.

```markdown
# Brand Revival Prescription
## [Brand Name]

Date: [date]
Revival Type: [Stale / Broken / Mixed]
Diagnosing Strategist: [Strategist Name]

---

## Symptoms
- [Observable signs the brand has lost relevance — from Autopsy research]
- [Audience behavior changes]
- [Search/mention trend data]
- [Category position shift]

## Root Cause
[The single Autopsy sentence: "The brand lost relevance because [cause], while [what the audience needed] emerged."]

[2-3 sentences expanding on the root cause with evidence.]

## Asset Inventory Summary

| Asset | Equity Level | Revival Role |
|-------|-------------|-------------|
| [Asset 1] | High/Medium/Low | [How it is used in revival] |
| [Asset 2] | High/Medium/Low | [How it is used in revival] |
| [Asset 3] | High/Medium/Low | [How it is used in revival] |

## Treatment

### Partnership Map
**Partner 1: [Brand Name]**
Category: [Adjacent category]
Structure: [Co-branded drop / Data-activated collab / etc.]
Rationale: [Why this partner. The "surprising but inevitable" sentence.]

**Partner 2: [Brand Name]**
[Same format]

**Partner 3: [Brand Name]**
[Same format]

### Drop Calendar
**Act 1 — Signal Drop (Month 1-3)**
Format: [Format by budget tier]
Partner: [Partner 1]
Quantity: [Range]
Success metric: [Specific, measurable]

**Act 2 — Proof Drop (Month 4-8)**
Format: [Format]
Partner: [Partner 2]
Quantity: [Range]
Success metric: [Specific, measurable]

**Act 3 — Platform Drop (Month 9-18)**
Format: [Format]
Partner: [Partner 3 or recurring]
Quantity: [Range]
Success metric: [Specific, measurable]

### Authenticity Bridge
**Collaborator 1: [Name / Studio]**
Why: [One-line rationale]
Scope: [Design direction / Product design / Campaign creative / etc.]

[Repeat for top 5 collaborators]

## Dosage
[Phasing logic: what must happen before what, and why that sequence]
[Budget allocation guidance across Acts]
[Internal org changes required — who needs new authority]

## Prognosis
- **90 days:** [Expected state after Signal Drop]
- **6 months:** [Expected state after Proof Drop launches]
- **18 months:** [Expected state if all three acts execute]
- **Failure condition:** [What would signal the revival is not working and what to do]
- **Measurement:** [Specific KPIs — search volume trend, earned media mentions, sell-through rate, owned audience growth]
```

---

## Chain Integration

**Inputs this skill draws from:**

- **Core Human Truth** — Run before Partnership Model (Phase 3) to identify the authentic truth the revival brand can own. The truth sentence anchors which partner categories make cultural sense.
- **Competitive Positioning Audit** — Run after Asset Inventory (Phase 2) to identify the empty quadrant the revival brand can enter without collision. Prevents reviving into a space already owned by a competitor.
- **Brandprint Tier-A** — Use for diagnostic data in Phase 1 (Autopsy) and Phase 2 (Asset Inventory). Provides presence scoring and competitive gap to ground the revival strategy in current market conditions.

**Outputs this skill feeds into:**

- **Brand strategy layers** — Once revival strategy is defined, scope the infrastructure buildout (content system, SEO, social presence) to sustain the brand post-drop.
- **Discovery process** — If this skill is triggered during a discovery call, run the discovery/intake process first to capture the full client context before executing the revival framework.

**Standalone trigger:** If the user mentions a stale, broken, or legacy brand without prior discovery work, this skill runs standalone. Resolve all variables, run all five phases, and deliver the full Brand Revival Prescription.

---

## Quality Checks (Run Before Delivering Prescription)

- [ ] Root cause is a single sentence, not a list
- [ ] Asset Inventory distinguishes brand equity from business assets
- [ ] Partners are adjacent, not competitive
- [ ] Partners pass the "surprising but inevitable" test
- [ ] Drop Calendar has three distinct acts with different purposes
- [ ] Collaborators are native to where the brand is going, not where it has been
- [ ] Prognosis includes a failure condition and pivot instruction
- [ ] All recommendations are tied to a specific asset, audience insight, or partner logic — not generic best practices

View saved version →

---
name: brand-strategy-compiler
description: Use when all Brandprint layers (Core Human Truth through Competitive Audit) are complete and the user needs the final client-ready deliverable — Layer 6 of the Brandprint research stack. Trigger when the user asks to compile the Brandprint into a final report, create a client deliverable, generate a strategy document, or produce a consulting-grade brand report. Also trigger on "compile report," "final deliverable," "client report," "strategy document," "consulting report." If the competitive-positioning-audit skill has just completed with a PROCEED decision, move directly into this skill.
---

# Brand Strategy Report Compiler — Consulting-Grade Deliverable Directive

Assemble all Brandprint outputs (Layers 1-5) into a single, cohesive Brand Strategy & Competitive Positioning Report formatted to the standard of top-tier strategy consultancies (Strategy&, EY-Parthenon, Monitor Deloitte, KPMG Strategy).

## When NOT to Use

- **Layers are incomplete.** Layers 1-4 outputs are required inputs. Layer 5 is strongly recommended; if it's missing, the report must disclose that competitive validation was not performed and recommend it — don't compile silently around the gap.
- **Generating new strategy content.** This layer synthesizes what Layers 1-5 produced. If a section needs claims or evidence that don't exist upstream, run the missing layer — don't write it here.
- **Quick one-page summaries.** The floor is 15-20 pages in rapid mode. For a brief, pull the executive summary structure manually instead of invoking the compiler.

## Why This Layer Exists

Layers 1-4 produce structured JSON outputs optimized for machines and chain-forward processing. Layer 5 produces a competitive analysis. None of these are client-ready. This layer transforms raw strategic outputs into a narrative document that leadership teams, boards, and investors can act on.

The report is not a summary — it is a synthesis. It resolves contradictions, builds arguments across layers, adds market context, models financial impact, and provides a phased implementation roadmap. It connects the "what" (positioning elements) to the "why" (evidence) to the "how" (implementation) to the "when" (roadmap).

## Chain Position

This is **Layer 6** — the terminal layer of the Brandprint research stack:

1. **Core Human Truth** (Layer 1) → foundational truth sentence
2. **Brandprint Tier-A** (Layer 2) → 10 strategy elements
3. **Brandprint Tier-B** (Layer 3) → 5 actionable elements
4. **Brandprint Tier-C** (Layer 4) → 4 stylistic elements
5. **Competitive Positioning Audit** (Layer 5) → differentiation validation
6. **Brand Strategy Report** (this skill) → consulting-grade deliverable

**Required inputs:** At minimum, Layers 1-4 outputs. Layer 5 (Competitive Audit) is strongly recommended. If Layer 5 is missing, the report will note that competitive validation was not performed and recommend it.

## Variables to Resolve

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `brand_name` | The brand | *required* |
| `client_name` | Who receives the report (may differ from brand) | brand_name |
| `prepared_by` | Firm name for the cover page | *required* |
| `report_date` | Date for the cover page | Current month/year |
| `confidentiality` | Confidential / Internal / Public | Confidential |
| `include_financials` | Include economic engine and financial modeling sections | true |
| `include_roadmap` | Include implementation roadmap | true |
| `format` | `narrative` (long-form) or `deck` (slide-style with exhibits) | `narrative` |
| `layer_outputs` | JSON outputs from Layers 1-5 | *required* |

## Principles (Non-Negotiable)

1. **Synthesis over summary.** Do not paste layer outputs verbatim. Transform them into a coherent strategic narrative where each section builds on the previous one.
2. **Every claim traces to evidence.** If a claim appeared in Layers 1-5 with sources, those sources appear in the report. No orphan claims.
3. **Exhibits do the heavy lifting.** Tables, matrices, and frameworks should convey key findings at a glance. Narrative text explains what the exhibit means and what to do about it.
4. **Strategic recommendations are specific.** "Improve positioning" is not a recommendation. "Replace 'We Build Texas' with the Header Translation Line on the homepage hero section within 30 days" is a recommendation.
5. **Acknowledge uncertainty.** Confidence levels from Layers 1-5 carry forward. If evidence was thin, say so. If a recommendation is high-confidence, say that too.
6. **Client-appropriate language.** The report should be readable by a C-suite executive who has never seen a Brandprint. No references to "Layer 2" or "Sprint 4" — translate framework language into business language.

## Report Structure

The report follows an 11-section structure. Each section has a purpose, required content, and source layers.

### Cover Page
- Report title: "Brand Strategy & Competitive Positioning Report"
- Brand name
- Prepared for: [client_name] Leadership
- Date
- Prepared by: [prepared_by]
- Confidentiality notice

### Table of Contents
- Auto-generated from section headers

### Executive Summary (2-3 pages)
**Purpose:** Give leadership the full strategic picture in under 5 minutes.

**Required content:**
- Strategic imperative (why this report exists, what market forces demand action)
- The Core Human Truth (the foundational insight, stated plainly)
- Strategic positioning statement (synthesized from Tier-A tagline + Tier-C translation line)
- 3-5 headline findings (quantified where possible — use callout boxes)
- The recommended path (one paragraph, decisive)

**Source layers:** All layers contribute. The executive summary is the most synthesized section.

### Section 1: Market Context & Strategic Imperative
**Purpose:** Establish urgency and opportunity with data.

**Required content:**
- Market conditions relevant to the brand's category and region
- Growth sectors and tailwinds (from Tier-A Backbone macro data)
- Competitive dynamics (from Layer 5 territory ownership map)
- Legislative or regulatory context (if applicable)
- Academic or industry research supporting the strategic direction

**Source layers:** Tier-A Backbone, Layer 5 Competitive Audit

### Section 2: Core Human Truth & Buyer Psychology
**Purpose:** Present the foundational insight and the evidence behind it.

**Required content:**
- The Core Human Truth sentence (from Layer 1)
- Tension ladder (from Layer 1 — reformatted as exhibit)
- Buyer psychology: how the audience actually makes decisions (from Layer 1 qualitative synthesis)
- Current positioning baseline: gap between what the brand says and what buyers hear
- Validation of the proposed truth (from Layer 1 red team report)

**Source layers:** Layer 1 (Core Human Truth)

**Key exhibit:** Buyer Tension Ladder (table: Level, Tension, Implication)

### Section 3: Competitive Landscape & White Space Analysis
**Purpose:** Show where competitors are positioned and where open territory exists.

**Required content:**
- Direct competitor assessment (from Tier-A Sprint 4 + Layer 5)
- White space map (from Layer 5 territory ownership — reformatted as 2x2 or positioning grid)
- Collision analysis results (from Layer 5 collision matrix)
- Key competitor vulnerabilities to exploit
- Specific competitor gap analysis (the "Rogers-O'Brien Gap" pattern — name the gap after the competitor)

**Source layers:** Tier-A Sprint 4, Layer 5 Competitive Audit

**Key exhibits:** Competitive Territory Ownership grid, White Space Map (2x2), Collision Matrix summary

### Section 4: Target Audience Segments & Buyer Archetypes
**Purpose:** Define who to pursue and how they decide.

**Required content:**
- Segment definitions (from Tier-A Sprint 3)
- Buyer archetypes with core fears and brand fit (from Layer 1 archetypes + Tier-A)
- Jobs to be done hierarchy (from Tier-A Sprint 2 — reformatted as exhibit)

**Source layers:** Layer 1, Tier-A Sprints 2-3

**Key exhibit:** Segment Overview table (Segment, Archetype, Core Fear, Brand Fit)

### Section 5: Brand Architecture & Equity Framework
**Purpose:** Present the complete brand system — the strategic toolkit.

**Required content:**
- Equity Ladder (from Tier-A Sprint 9 — reformatted as tiered exhibit)
- Brand Platform Word (from Tier-B) with gatekeeper question
- Brand Mantra (from Tier-C) with usage context
- Header Translation Line (from Tier-C) with deployment guidance
- Tagline system hierarchy (mantra → tagline → translation line with use contexts)

**Source layers:** Tier-A Sprint 9, Tier-B Platform Word, Tier-C Mantra + Translation Line

**Key exhibits:** Equity Ladder table, Tagline System hierarchy table

### Section 6: Competitive Moat
**Purpose:** Explain why the brand wins and why competitors can't replicate it.

**Required content:**
- Moat pillars (from Tier-B Moat sprint — reformatted as exhibit)
- Time-to-replicate estimates for each pillar
- Observable evidence per pillar (buyer-verifiable proof)
- Switching cost analysis

**Source layers:** Tier-B Moat, Tier-A Sprint 6

**Key exhibit:** Moat Pillar Analysis table (Pillar, Observable Evidence, Time to Replicate, Buyer Verifiable?)

### Section 7: Signature Offers & Growth Strategy
**Purpose:** Map the brand's offerings to target segments and market opportunities.

**Required content:**
- Signature offers mapped to segments (from Tier-A Sprint 5)
- Growth sector strategy (from Tier-A Backbone macro data)
- Economic engine model (from Tier-A Sprint 7 — if include_financials = true)
- Bridge strategy for market transitions (if applicable)

**Source layers:** Tier-A Sprints 5, 7

**Key exhibit:** Signature Offer Portfolio table (Offer, Target Segment, Project Range, Competitive Advantage, Market Tailwind)

### Section 8: Brand Activation System
**Purpose:** Translate strategy into observable, repeatable behaviors.

**Required content:**
- Brand Activator (from Tier-B) with touchpoint map and implementation phases
- Tone & Manner guide (from Tier-B) with do/say conversion table
- Personification vignette(s) (from Tier-C)
- Tagline system with deployment contexts

**Source layers:** Tier-B (Activator, Tone), Tier-C (Vignette)

**Key exhibits:** Activator Touchpoint Map, Tone & Manner table (Adjective, Client Validation, Instead of/Say), Tagline Hierarchy table

### Section 9: Strategic Guardrails & Brand Protection
**Purpose:** Define the defensive perimeter — what the brand must never do.

**Required content:**
- Brand No-No's (from Tier-B) with rationale and risk prevented
- Strategic tensions resolved (from Layer 5 repositioning analysis + Tier-A contradictions)
- Expertise claims: what the brand can claim with confidence, what requires qualification, what it must not claim
- Features list with equity ladder mapping (from Tier-C)

**Source layers:** Tier-B No-No's, Tier-A Contradiction Matrix, Tier-C Features List

**Key exhibits:** Brand No-No's table (Guardrail, Rationale & Risk Prevented), Expertise Claims (three-tier: Full Confidence, Requiring Qualification, Must Not Make)

### Section 10: Implementation Roadmap
**Purpose:** Translate strategy into a phased execution plan.

**Required content (if include_roadmap = true):**
- Phase 1: Immediate Actions (Months 1-3) — quick wins, positioning pivots, internal alignment
- Phase 2: Foundation Building (Months 4-6) — sales enablement, content strategy, template redesign
- Phase 3: Market Positioning (Months 7-12) — category ownership, thought leadership, speaking, PR
- Phase 4: Expansion Phase (Months 12-24) — new sectors, geographic expansion, brand equity measurement
- Measurable milestones per phase
- Resource requirements and budget estimates

**Source layers:** Synthesized from all layers

**Key exhibit:** Implementation Roadmap visual (4-phase timeline with key actions per phase)

### Section 11: Conclusion
**Purpose:** Close with conviction. Restate the single most important strategic insight.

**Required content:**
- Strategic summary (3 sentences max)
- The positioning opportunity restated
- The "excavation not construction" insight: the positioning already exists in the portfolio, the people, and the performance — it just needs to be named
- Closing statement with prepared-by attribution

### Appendix (Optional)
- Full source bibliography organized by category
- Research methodology notes
- Confidence scoring methodology
- Detailed financial modeling assumptions
- Glossary of terms

## Formatting Standards

To match consulting-grade deliverables:

- **Exhibits are numbered:** Exhibit 1.1, Exhibit 3.1, etc. (section.sequence)
- **Key statistics in callout boxes:** Large numbers, bold, with context below
- **Pull quotes for critical insights:** Blockquoted, italicized
- **Consistent header hierarchy:** Section numbers match TOC
- **Professional tone:** Authoritative but not academic. No hedging language ("might," "could possibly"). State findings with appropriate confidence.
- **Footer:** "[Brand Name] [bullet] Brand Strategy & Competitive Positioning Report [bullet] Page X"
- **Cover page footer:** "[Prepared by] [bullet] [City, State] / Brand Strategy [bullet] Competitive Intelligence [bullet] Market Positioning"

## Quality Checks (Run Before Finalizing)

- [ ] Every section traces to specific layer outputs (no orphan sections)
- [ ] Every exhibit has a number, title, and is referenced in the narrative text
- [ ] The executive summary can stand alone — a reader who reads only this section gets the full strategic picture
- [ ] No Brandprint framework jargon appears (no "Layer 2," "Sprint 4," "Tier-B")
- [ ] Financial projections include ranges and assumptions, never point estimates
- [ ] Competitor names are used only where the analysis requires it — the report positions the brand, not attacks competitors
- [ ] The implementation roadmap has measurable milestones, not vague aspirations
- [ ] Confidence levels are stated for key recommendations
- [ ] All sources from Layers 1-5 are compiled in the bibliography
- [ ] The report reads as a single coherent document, not a stack of skill outputs

## What NOT to Do

- Do not paste JSON outputs into the report. Transform everything into narrative and exhibits.
- Do not use Brandprint layer/sprint terminology. Translate to business language.
- Do not present recommendations without evidence chain.
- Do not include financial projections without explicit assumptions and ranges.
- Do not hedge excessively. If the evidence supports a recommendation, state it with conviction. If evidence is thin, state that too — but don't hedge everything.
- Do not create a report shorter than 20 pages for standard mode. This is a comprehensive strategic deliverable, not a summary.
- Do not invent market data to fill Section 1. If the Tier-A Backbone didn't collect it, mark the gap — fabricated context poisons an otherwise evidence-backed report.
- Do not compile around a REFINE decision. If Layer 5 said REFINE and the client chose to ship anyway, the report must disclose the unresolved collisions, not present first-pass positioning as validated.
- Do not reference an exhibit that isn't in the document, or include an exhibit the narrative never mentions. Orphan exhibits are the fastest tell of a stapled-together report.

## Mode Adjustments

- **Rapid:** 15-20 pages. Executive summary + sections 2, 3, 5, 9. Skip financial modeling and detailed roadmap. Include simplified exhibits.
- **Standard:** 25-35 pages. All 11 sections. Full exhibits. Financial modeling with ranges. Phased roadmap.
- **Enterprise:** 35-50+ pages. All 11 sections expanded. Add: sensitivity analysis, scenario modeling, board-ready executive brief (2-page standalone), competitive monitoring plan, quarterly review structure.

## Output Format

Deliver as:
1. **Markdown document** — full report in clean markdown suitable for conversion to PDF or DOCX
2. **If the user has PDF generation capabilities** — offer to generate a formatted PDF

The report should be immediately presentable to client leadership without additional editing.

## Evaluation Rubric

1. **Synthesis quality** — The report reads as one coherent narrative, not six skill outputs stapled together
2. **Evidence density** — Every recommendation traces to cited evidence
3. **Exhibit quality** — Tables and frameworks convey findings at a glance
4. **Actionability** — Recommendations are specific enough to execute without additional interpretation
5. **Professional standard** — Formatting, tone, and depth match top-tier strategy consultancy deliverables
6. **Standalone executive summary** — A reader who skips everything except the exec summary still gets the full strategic picture
7. **Completeness** — All layer outputs are represented; no strategic elements are missing from the final document

View saved version →

---
name: competitive-positioning-audit
description: Use when the user wants to validate positioning against named competitors, test differentiation, run a competitive audit, check for brand collision, or stress-test a Brandprint against real market players — Layer 5 of the Brandprint research stack. Also trigger on "competitive audit," "positioning vulnerability," "differentiation test," "collision check," "are we different enough," or when the user pastes competitor copy and asks whether their brand stands apart. Recommend this skill when brandprint-tier-c has just completed, before compiling the final report.
---

# Competitive Positioning Audit — Vulnerability & Differentiation Directive

Systematically test whether a brand's Brandprint positioning is actually differentiated from named competitors, or whether it reads as "semantic neighbor" — similar enough that buyers can't tell the difference.

## When NOT to Use

- **Fewer than 3 named competitors.** The audit runs on 1, but the collision matrix gets thin and territory ownership becomes guesswork. Identify 3-5 real players first (Tier-A Sprint 4 provides them).
- **No positioning exists yet.** There's nothing to audit. Run Layers 1-4 first — this layer tests claims, it doesn't create them.
- **Category-level white-space analysis.** Finding what the whole category is missing is `competitive-teardown`. This skill tests one brand's claims against named competitors.

## Why This Layer Exists

The first pass of Layers 1-4 produces positioning built from the brand's own tensions and evidence. But positioning doesn't exist in isolation — it exists relative to competitors. This layer pressure-tests whether the Brandprint outputs survive contact with real competitor messaging.

**The pattern this skill catches:** A brand runs the full Brandprint chain, produces strong outputs — then discovers their tagline, platform word, or mantra collides with an entrenched competitor. The ESOP story that felt unique turns out to overlap with a competitor's "family culture" narrative. The geographic claim that felt ownable is already owned by someone with 5x the revenue. This skill catches those collisions before they ship.

## Chain Position

This is **Layer 5** of the Brandprint research stack:

1. **Core Human Truth** (Layer 1) → foundational truth sentence
2. **Brandprint Tier-A** (Layer 2) → 10 strategy elements
3. **Brandprint Tier-B** (Layer 3) → 5 actionable elements
4. **Brandprint Tier-C** (Layer 4) → 4 stylistic elements
5. **Competitive Positioning Audit** (this skill) → validates differentiation; triggers refinement if needed
6. **Brand Strategy Report** (Layer 6) → compiles all layers into consulting-grade deliverable

**When Layer 4 has just completed:** Import all Tier-A, B, and C outputs. Run the full audit against the competitive landscape already identified in Tier-A Sprint 4, plus any additional competitors the user names.

**When running standalone:** Resolve all variables with the user. Requires at minimum: the brand's current positioning claims (tagline, platform word, key messages) and at least one named competitor to test against.

**After this skill completes:** If vulnerability scores are LOW (positioning is differentiated), proceed to Layer 6 (Report Compiler). If vulnerability scores are HIGH (positioning collides), recommend a **second-pass refinement** — re-running Layers 1-4 with the audit findings as additional context. The second pass typically produces dramatically sharper positioning.

## Variables to Resolve

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `brand_name` | The brand being audited | *required* |
| `brand_claims` | Current tagline, platform word, key messages, mantra | *required* (or from Layers 1-4) |
| `competitors` | Named competitors to test against (min 1, ideally 3-5) | *required* |
| `competitor_sources` | URLs, copy, or descriptions of competitor positioning | User provides or research |
| `category` | Industry or category | *required* (or from Layer 2) |
| `audience` | Primary audience definition | *required* (or from Layer 2) |
| `region_context` | Geography or cultural context | US / English-speaking |
| `mode` | `rapid`, `standard`, or `enterprise` | `standard` |

## Principles (Non-Negotiable)

1. **Buyer perception over brand intention.** It doesn't matter what you meant — it matters what buyers hear when they see your claims next to a competitor's.
2. **Quantify overlap.** Semantic collision is measurable. Score it, don't hand-wave.
3. **Attack your own positioning.** This is adversarial by design. The goal is to find weaknesses before the market does.
4. **Entrenched beats clever.** If a competitor already owns a positioning territory with more budget, more history, and more share-of-voice, clever messaging won't unseat them. Find open territory instead.
5. **Structure vs. message.** Structural advantages (ESOP, patents, network effects) are real moats. Messages about structural advantages may not be — if buyers don't understand or care about the structure, the message fails even if the advantage is real.

## Evidence & Citation Policy

Same as Layers 1-4: title, publisher, URL, dates, one-line evidence note. For competitor claims, cite the specific URL or document where the claim appears. Screenshot or quote the exact language — paraphrasing competitor copy introduces bias.

## Workflow

### Phase 1: Forensic Collection

**Goal:** Capture the exact positioning language from both the brand and all named competitors.

Actions:
- **Brand claims inventory:** Extract every positioning claim from the Brandprint outputs (or user-provided materials). Catalog: tagline, platform word, mantra, translation line, key phrases, tone adjectives, moat claims, sector claims, geographic claims, culture claims.
- **Competitor claims inventory:** For each named competitor, extract the same categories from their website, LinkedIn, proposals, press releases, job postings, and any other public materials. Capture exact language — do not paraphrase.
- **Claim taxonomy:** Organize all claims into categories: Geographic identity, Culture/people, Sector expertise, Scale/capability, Technology, Values/mission, Process/methodology, Price/value, Relationships, Heritage/history.

Outputs: `brand_claims_inventory`, `competitor_claims_inventories`, `claim_taxonomy`

---

### Phase 2: Collision Analysis

**Goal:** Quantify where the brand's positioning overlaps with competitors.

Actions:
- **Collision matrix:** For each brand claim, score differentiation against each competitor on a 0-10 scale:
  - 0-2: Direct collision (same territory, same language)
  - 3-4: Semantic neighbor (different words, same idea)
  - 5-6: Adjacent (related territory, clear difference exists but requires explanation)
  - 7-8: Distinct (clearly different positioning territory)
  - 9-10: Orthogonal (completely different axis, no overlap)
- **Vocabulary overlap score:** Calculate % of shared significant words between brand and each competitor's positioning copy (excluding articles, prepositions). Target: <30% for differentiation.
- **Territory ownership assessment:** For each positioning territory (geographic, culture, sector, etc.), determine who currently owns it based on: time invested, budget deployed, market share, share-of-voice, and buyer associations.
- **Revenue asymmetry check:** Compare brand revenue/size to each competitor. If a competitor is 5x+ larger and occupies the same territory, the brand reads as follower regardless of message quality.

**Scoring:**
- Average collision score <4 across primary competitor = CRITICAL vulnerability
- Vocabulary overlap >40% = HIGH vulnerability
- Competing for territory owned by 5x+ larger player = HIGH vulnerability

Outputs: `collision_matrix`, `vocabulary_overlap_scores`, `territory_ownership_map`, `revenue_asymmetry_notes`, `vulnerability_score`

---

### Phase 3: Buyer Perception Modeling

**Goal:** Model how buyers experience the brand vs. competitors — not how the brand intends to be experienced.

Actions:
- **Side-by-side comprehension test (modeled):** Present brand and competitor positioning cards side by side. For each pair, answer: "If a buyer saw both of these in the same RFP shortlist, could they articulate a clear difference in under 10 seconds?" Score: Clear / Vague / Indistinguishable.
- **ESOP/structure education test:** If the brand's differentiation relies on a structural advantage (ESOP, proprietary process, etc.), assess: Does the audience already understand this structure? If not, how many seconds/words of explanation are required before the advantage registers? If >15 seconds, the advantage is real but the message may fail.
- **Core Human Truth collision test:** Does the brand's Core Human Truth apply equally to competitors? If yes, differentiation must come from the solution mechanism, not the truth itself. Identify which competitor has the stronger solution narrative for the same truth.
- **Emotional resonance ranking:** Rank brand and competitors on: Instant clarity, Emotional impact, Memorability, Credibility, Specificity. Note where brand ranks #1 vs. where it trails.

Outputs: `comprehension_test_results`, `structure_education_assessment`, `truth_collision_analysis`, `emotional_resonance_ranking`

---

### Phase 4: Repositioning Paths

**Goal:** If vulnerabilities are confirmed, model alternative positioning paths.

Actions:
- Generate 3-5 repositioning paths, each defined by:
  - **Territory:** What positioning territory does this path claim?
  - **Attack vector:** Which competitor vulnerability does it exploit?
  - **Buyer segment:** Which segment does it win?
  - **Proof required:** What evidence is needed to defend this position?
  - **Risk:** What could go wrong?
  - **Collision score:** How differentiated is this path from all competitors?
- For each path, draft a revised tagline, platform word, and key message to illustrate the shift.
- **Path evaluation matrix:** Score each path on: Differentiation (vs. all competitors), Defensibility (can competitors copy this?), Audience resonance (does the target segment care?), Proof availability (does evidence already exist?), Migration cost (how much existing positioning is abandoned?).
- **Recommended path:** Select the path with the highest combined score. Explain why. Note what must change in Layers 1-4 if this path is adopted.

Outputs: `repositioning_paths`, `path_evaluation_matrix`, `recommended_path`, `migration_notes`

---

### Phase 5: Second-Pass Decision

**Goal:** Determine whether the Brandprint needs a second pass through Layers 1-4.

Actions:
- **Threshold check:** If overall vulnerability score is CRITICAL or HIGH, recommend a second-pass refinement.
- **Context package:** If second pass is recommended, assemble a context package containing: all audit findings, the recommended repositioning path, specific competitor claims to differentiate against, and revised constraints for each layer.
- **Skip conditions:** If vulnerability score is LOW or MODERATE, the current Brandprint holds. Proceed to Layer 6 (Report Compiler) with audit findings included as a competitive analysis section.

Decision outputs:
- `PROCEED` → Current positioning is differentiated. Move to Layer 6.
- `REFINE` → Re-run Layers 1-4 with audit context. The second pass should produce dramatically sharper positioning because the competitive landscape is now a constraint, not an afterthought.

Outputs: `decision`, `context_package_for_second_pass` (if REFINE), `competitive_analysis_section` (if PROCEED)

## Mode Adjustments

- **Rapid:** Phases 1-2 only. Collision matrix + vocabulary overlap. Quick differentiation score. Skip buyer modeling and repositioning paths.
- **Standard:** Full Phases 1-5. Complete audit with repositioning recommendations.
- **Enterprise:** Add: historical positioning timeline (who claimed territory first), share-of-voice estimation, buyer interview protocol design for live validation, and competitive monitoring plan for ongoing defense.

## Heuristics

- If the first word of the brand's tagline also appears in a competitor's tagline, that's a collision regardless of context.
- Revenue asymmetry matters more than message quality. A $50M company cannot out-position a $500M company on the same territory.
- Structural advantages (ESOP, patents, proprietary tech) are only differentiators if buyers understand them without explanation. If explanation is required, lead with the outcome the structure produces, not the structure itself.
- "Texas builder" is an identity claim. "Builds exclusively in Texas" is a fact claim. Fact claims are defensible; identity claims are contestable.
- When two brands share the same Core Human Truth, the one with more visible proof wins. More visible, not more proof — perception beats evidence.

## What NOT to Do

- Do not soften collision scores to protect the brand's feelings. This is adversarial testing.
- Do not compare brand aspirations to competitor realities. Compare reality to reality.
- Do not assume buyers understand structural advantages (ESOP, B-Corp, proprietary process) without evidence that they do.
- Do not recommend repositioning that abandons proven strengths. The goal is to find adjacent open territory, not to start over.
- Do not fabricate buyer perception data. Model it from evidence; flag it as modeled, not measured.

## Output Format

Deliver as structured JSON including: `brand_name`, `competitors_audited`, `collision_matrix`, `vocabulary_overlap_scores`, `vulnerability_score`, `territory_ownership_map`, `repositioning_paths`, `recommended_path`, `decision` (PROCEED or REFINE), `context_package` (if REFINE), `sources`, `audit_log`.

**Forward chaining:**
- If decision = `PROCEED`: Pass `competitive_analysis_section` to Layer 6 (Brand Strategy Report Compiler).
- If decision = `REFINE`: Pass `context_package_for_second_pass` back to Layer 1. The user should re-run Layers 1-4 with this context baked into the constraints and variables. The second pass will produce a refined Brandprint that is competitive-aware from the start.

## Evaluation Rubric

1. **Honesty** — Collision scores reflect reality, not brand preference
2. **Specificity** — Exact competitor language is cited, not paraphrased
3. **Quantification** — Overlap is scored numerically, not described vaguely
4. **Actionability** — Repositioning paths are specific enough to execute
5. **Traceability** — Every vulnerability links to specific competing claims
6. **Decision clarity** — PROCEED or REFINE is unambiguous with clear rationale

## File I/O Contract (orchestrated mode)

When an authorized orchestrator provides explicit paths, honor them exactly:

- **Seed inputs:** read ONLY the JSON/YAML files listed in the dispatch prompt.
- **Output:** write the final JSON object to the exact path given (under
  `.brandprint/engagements/{slug}/pass-N/`). No other location.
- **Return value:** your final message is the output path plus the layer's key
  artifact — not the full JSON. The orchestrator reads files, not transcripts.

When invoked as a direct skill call, present the JSON in conversation or through the supported file workflow and tell the user to preserve it for the next layer.

View saved version →

---
name: competitive-teardown
description: >-
  Use when the goal is category-level disruption analysis: finding structural
  gaps and white space across an entire category or platform, not brand-vs-brand
  positioning comparison. Triggers on "teardown," "competitive analysis,"
  "SCAMPER analysis," "platform analysis," "gap analysis," "what are competitors
  missing," "find the white space," "category disruption," "what's unoccupied,"
  or "where's the open quadrant." This is structurally different from
  competitive-positioning-audit, which tests one brand's claims against named
  competitors, and from general SCAMPER ideation, which treats a single item.
---

# Competitive Teardown — Category SCAMPER Protocol

Reveal structural gaps in a category by mapping all major players into a feature/value matrix, running SCAMPER across the entire matrix (not on a single brand), identifying what no one is doing, and building concepts that exploit those empty quadrants.

## When NOT to Use

- **Brand-vs-brand positioning validation.** Testing one brand's claims against named competitors is `competitive-positioning-audit`. This skill's unit of analysis is the category matrix, not a brand.
- **Single-item ideation.** Applying SCAMPER to one product or campaign is general creative ideation — no matrix required.
- **Fewer than ~5 meaningful players in the category.** With 2-3 players there are no convergence clusters to read; shared assumptions can't be distinguished from coincidence.

## Why This Skill Exists

Standard competitive analysis asks: "How are we different from competitors?" That question assumes the right category exists and the right dimensions of differentiation are already visible. It produces incremental positioning.

This skill asks a different question: "What is the entire category structurally incapable of doing?" That question exposes the gaps baked into the category's shared assumptions — the white space that every player is simultaneously missing because they're all operating inside the same mental model.

The pattern: map the category matrix first, SCAMPER the matrix as a whole, find the structural absence, build into the absence.

**What this is not:**
- Not brand-vs-brand collision scoring — that's the competitive-positioning-audit
- Not single-item ideation with SCAMPER as one of ten methods — that's general creative ideation
- Not a vulnerability audit of existing positioning — that's the competitive-positioning-audit

This skill is category-level structural analysis. The output is opportunity concepts, not positioning refinements.

## Chain Position

This skill operates as a standalone research sprint OR feeds upstream/downstream within the Brandprint Engine:

**Upstream inputs:**
- Competitive Positioning Audit gap findings — teardown the gap further
- Brandprint Tier-A Sprint 4 (Competitive Landscape) — expand into full teardown

**Downstream outputs:**
- Competitive Positioning Audit — teardown findings replace or extend the Competitive Matrix
- Brand strategy layers — concepts from gap identification inform content strategy and positioning
- If a concept is chosen, validate its positioning differentiation before launch

## Variables to Resolve

Before starting, confirm these with the user or extract from prior skill outputs:

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `category` | The category or platform being torn down | *required* |
| `client_name` | The brand or client using this analysis | *required* |
| `client_context` | What they do, what they're capable of, their resources/constraints | *required* |
| `players` | Named competitors to include (3-7 preferred) | User provides or research |
| `teardown_lens` | What angle to attack (features, pricing, audience, channel, business model, content, UX) | All lenses |
| `concept_count` | How many concepts to develop from gap findings | 2-3 |
| `mode` | `rapid`, `standard`, or `enterprise` | `standard` |
| `output_format` | `report`, `slide-ready bullets`, or `JSON` | `report` |

If the user doesn't provide players, research or name the most visible 3-7 players in the stated category before proceeding.

---

## Step 1: Category Map

**Goal:** Build a shared-assumption matrix across all players. Make the invisible visible.

### Actions

**1a. Player identification**
List 3-7 players. Include: the market leader, one challenger, one niche player, and (if applicable) one platform or aggregator that shapes behavior across the category. Do not include the client — they are the disruptor, not the benchmark.

**1b. Feature/value inventory**
For each player, inventory across these dimensions:
- **Core offer:** What is the primary product/service?
- **Primary value prop:** What problem do they claim to solve?
- **Target audience:** Who is it explicitly for?
- **Pricing model:** How is value captured?
- **Key differentiator:** What do they say makes them unique?
- **Distribution/channel:** How does the product reach buyers?
- **Content/media presence:** How do they build awareness?
- **Proof mechanism:** How do they demonstrate credibility (case studies, reviews, certifications, press)?
- **Onboarding/UX:** How do buyers get started?
- **Retention model:** What keeps buyers from leaving?

**1c. Category Matrix**
Render the inventory as a matrix:

```
| Dimension         | Player A | Player B | Player C | Player D | Player E |
|-------------------|----------|----------|----------|----------|----------|
| Core offer        |          |          |          |          |          |
| Value prop        |          |          |          |          |          |
| Target audience   |          |          |          |          |          |
| Pricing model     |          |          |          |          |          |
| Differentiator    |          |          |          |          |          |
| Channel           |          |          |          |          |          |
| Content/media     |          |          |          |          |          |
| Proof mechanism   |          |          |          |          |          |
| Onboarding/UX     |          |          |          |          |          |
| Retention model   |          |          |          |          |          |
```

**1d. Cluster identification**
After building the matrix, identify where players cluster. Which dimensions show near-identical approaches across most or all players? These clusters represent shared category assumptions — the places where disruption is most available.

Label each cluster: `HIGH CONVERGENCE` (4+ players similar) / `MODERATE CONVERGENCE` (2-3 players similar) / `DIVERGENCE` (meaningful variation exists).

Output: `category_matrix`, `cluster_map`

---

## Step 2: SCAMPER Pass — Across the Matrix

**Goal:** Apply each SCAMPER lens not to one brand but to the category matrix as a whole. The question for each lens is: "What does this lens reveal that NO player in this matrix is doing?"

This is the core distinction of this skill. SCAMPER is not applied to a single product. It is applied to the shared patterns revealed in Step 1. Each lens interrogates the category's collective blind spots.

### The Seven Lenses

**S — Substitute**
What element that every player uses could be replaced with something fundamentally different?
- What ingredient/component/mechanism do all players share that could be swapped?
- What assumption about delivery, format, or medium is universal in this category?
- Prompt: "What if the [universal mechanism] were replaced entirely by [alternative]?"

**C — Combine**
What two things that exist in the category have never been combined — or what is this category refusing to combine with an adjacent category?
- Which player capabilities exist in isolation that would be powerful together?
- What does an adjacent category do that this category has never absorbed?
- Prompt: "What if [capability A] and [capability B] operated as a single unified experience?"

**A — Adapt**
What model from a different industry could be adapted to this category, and why hasn't it been?
- What does SaaS do that services categories haven't adopted? What does media do that product categories resist?
- What subscription, community, or platform mechanic exists elsewhere but is absent here?
- Prompt: "What would this category look like if it were built like [other industry model]?"

**M — Modify / Magnify / Minimize**
What dimension is everyone treating as fixed that could be radically scaled up or stripped down?
- What do all players treat as a necessary cost or complexity that could be eliminated?
- What do all players under-invest in that buyers actually care deeply about?
- Prompt: "What if [shared element] were 10x more of it — or removed entirely?"

**P — Put to Other Uses**
What assets, data, or outputs in this category are being used narrowly when they could serve a much broader function?
- What do players produce as a byproduct that buyers or other markets would value independently?
- What audience does this category serve that could be served through a completely different use case?
- Prompt: "What else could [category output] do? Who else could use it differently?"

**E — Eliminate**
What does every player include that buyers don't actually want — or what friction exists across the board that could be removed entirely?
- What is the category's universal cost, complexity, or barrier that persists out of inertia?
- What do all onboarding flows or sales processes include that could be cut?
- Prompt: "What would the category look like if [universal element] were gone?"

**R — Reverse / Rearrange**
What sequence, relationship, or structure does every player share that could be inverted?
- Who is the customer and who is the provider — could those roles flip?
- What comes first in every buyer journey that could come last?
- What is the standard business model structure — could it be inverted (pay on outcome, community before product, etc.)?
- Prompt: "What if [universal sequence or structure] ran backwards — or inside out?"

### SCAMPER Output Format

For each lens, produce:
1. **Category pattern:** What the matrix shows every player doing (or not doing) on this dimension
2. **SCAMPER finding:** What the lens reveals as available or absent
3. **Raw concepts:** 2-4 rough concepts suggested by this finding (unfiltered, no feasibility judgment yet)
4. **Convergence connection:** Which cluster from Step 1 does this finding attack?

Output: `scamper_findings` (7 sections, one per lens)

---

## Step 3: Gap Identification

**Goal:** Synthesize SCAMPER findings into a structured gap map. Identify which empty quadrants are most structurally significant.

### Actions

**3a. Gap inventory**
From the 7 SCAMPER passes, list every identified gap. A gap is valid when:
- No player in the matrix occupies it (confirmed by the matrix, not assumed)
- It addresses a real buyer need (not just structural novelty)
- It is not absent because it is technically impossible or legally prohibited

**3b. Gap classification**

Classify each gap by type:
- **Audience gap** — a buyer segment that no player serves well
- **Value prop gap** — a problem no player is solving, or solving backwards
- **Delivery gap** — a distribution or channel no player uses
- **Experience gap** — a UX or journey no player offers
- **Business model gap** — a pricing or retention structure no player has deployed
- **Content/media gap** — an awareness or trust-building approach no player has claimed

**3c. Gap map**
Render the top gaps in priority order. Score each on:
- **Size:** How large is the opportunity? (Small / Medium / Large)
- **Vacancy:** How empty is this quadrant? Is anyone approaching it? (Empty / Nearly empty / Emerging)
- **Defensibility:** Once occupied, how hard is it to copy? (Low / Medium / High)
- **Buyer signal:** Is there evidence buyers want this — search behavior, complaints, workarounds they use? (Weak / Moderate / Strong)

```
| Gap | Type | Size | Vacancy | Defensibility | Buyer Signal | Priority |
|-----|------|------|---------|---------------|--------------|----------|
|     |      |      |         |               |              |          |
```

Output: `gap_inventory`, `gap_map`

---

## Step 4: Concept Development

**Goal:** Build 2-3 concrete concepts that exploit the highest-priority gaps. These are strategic concepts, not final brand names or complete strategies.

### Concept Structure

For each concept, produce:

**Concept Name:** A working title (functional, not brand-ready)

**Gap Exploited:** Which gap(s) from Step 3 does this concept occupy?

**Core Mechanic:** In one sentence — what does this concept actually do differently from every player in the matrix?

**Value Proposition Draft:** What does a buyer gain that they cannot get from any current player?

**Target Audience:** Who is the primary buyer this concept is built for? Be specific — not "SMBs" but "operations leads at 10-50 person agencies who are buying for the first time."

**Category Disruption Thesis:** Why does this concept, if executed well, change the category — not just win a segment?

**Rough Business Model:** How does value get captured? What pricing or retention mechanic matches the gap?

**Evidence the gap is real:** What buyer behavior, complaint pattern, search data, workaround, or adjacent-category adoption supports this gap's existence?

**Risks:** What could kill this concept? (Market timing, category education cost, technical barrier, incumbent response)

Output: `concepts` (array of 2-3)

---

## Step 5: Feasibility Filter

**Goal:** Match concepts to the client's actual capabilities. Eliminate concepts the client cannot execute. Rank surviving concepts.

### Filter Criteria

For each concept, score against the client's context (`client_context` variable):

| Criterion | Question | Score |
|-----------|----------|-------|
| **Resources** | Can the client fund the build and go-to-market? | 1-5 |
| **Timeline** | Can the client reach market before the window closes? | 1-5 |
| **Positioning fit** | Does this concept align with or extend the client's existing brand equity? | 1-5 |
| **Proof availability** | Does the client already have evidence/credentials that support this concept? | 1-5 |
| **Distribution access** | Does the client have or can they build the channel this concept requires? | 1-5 |

**Scoring:**
- 21-25: Greenlight — client is positioned to execute
- 15-20: Conditional — execute with noted constraints
- Below 15: Deprioritize — not wrong, just not right for this client now

### Feasibility Output

For each concept: feasibility score, key constraint, and whether the constraint is surmountable within 90 days.

Rank concepts: Concept 1 (highest feasibility + highest gap priority), Concept 2, Concept 3.

Output: `feasibility_scores`, `ranked_concepts`

---

## Mode Adjustments

**Rapid:** Steps 1-3 only. Deliver the gap map and name the top concept. No full concept development or feasibility scoring. Use when the client needs a quick competitive read before a pitch or kickoff.

**Standard:** Full Steps 1-5. Complete teardown with 2-3 developed concepts and feasibility ranking. Core deliverable for strategy engagements.

**Enterprise:** Add to Standard:
- Extended player set (up to 10 players)
- Historical category trajectory (how the category has evolved over 5 years and where momentum is pointing)
- Adjacent category scan (what 2-3 adjacent categories are doing that this category has not absorbed)
- Buyer interview protocol (5 questions to validate gaps with real buyers before concept investment)
- Monitoring brief (what signals to watch that would indicate a competitor is moving into identified gaps)

---

## Output Format

Deliver as a **Competitive Teardown Report** with these sections:

---

### Competitive Teardown Report: [Category]
**Prepared for:** [Client Name]
**Date:** [Date]

**Category Analyzed:** [Category]
**Players Mapped:** [List]

---

#### 1. Category Matrix
[Full matrix from Step 1]

**Cluster Summary:**
- HIGH CONVERGENCE dimensions: [list]
- Key shared assumptions: [2-3 sentences on what the category universally believes]

---

#### 2. SCAMPER Findings
[Seven sections, one per lens — pattern, finding, raw concepts, convergence connection]

---

#### 3. Gap Map
[Gap classification table + narrative on the top 2-3 gaps]

---

#### 4. Concepts
[Full concept write-up for each, structured per Step 4 format]

---

#### 5. Feasibility Rankings
[Scored table + recommendation]

**Recommended starting point:** [Concept name] — [One-sentence rationale tying gap priority to client feasibility]

---

#### 6. Next Steps
- If pursuing a concept: feed gap findings into the Competitive Positioning Audit as pre-built competitive matrix
- If developing brand strategy next: use gap findings to constrain Tier-A Sprint 4 and sharpen differentiation requirements
- If scoping an engagement: gap findings inform content strategy and positioning layers
- Before finalizing positioning: validate chosen concept with the Competitive Positioning Audit

---

## What NOT to Do

- Do not apply SCAMPER to a single player's features. The lens always runs across the full matrix.
- Do not confuse a gap with a niche. A gap is structurally absent from the category. A niche is served — just by fewer players.
- Do not develop concepts before the gap map. Concept first is invention. Gap map first is strategy.
- Do not score feasibility before concepts are fully formed. Premature feasibility filtering kills the most interesting ideas.
- Do not include the client in the category matrix. They are the disruptor — benchmarking them as a peer produces incremental thinking.
- Do not skip the buyer signal check in Step 3. A structural gap with no buyer signal is an academic exercise.
- Do not paraphrase player positioning when filling the matrix. Loose summaries make convergence calls guesses — capture what each player actually says and does.
- Do not read DIVERGENCE dimensions as gaps. Variation means the category has already explored that axis; gaps live where the matrix is uniformly empty.
- Do not run the feasibility filter against a generic client. If `client_context` is thin, ask — scoring concepts against an imagined SMB produces rankings nobody can act on.

## Evaluation Rubric

1. **Matrix completeness** — Does the category map include the real players and all relevant dimensions?
2. **SCAMPER discipline** — Are lenses applied to the matrix as a whole, or did the skill revert to single-item ideation?
3. **Gap validity** — Are gaps confirmed empty by the matrix, or assumed?
4. **Concept specificity** — Are concepts specific enough to act on, or too abstract to execute?
5. **Feasibility honesty** — Does the filter reflect the client's actual constraints, not aspirational ones?
6. **Next steps clarity** — Are downstream recommendations specific and actionable?

View saved version →

---
name: core-human-truth
description: Use when the user asks for a core human truth, brand truth, audience insight, consumer truth, foundational brand insight, or strategic brand research — Layer 1 of the Brandprint research stack and the entry point for any new brand engagement. Also trigger when requests mention "tension ladder," "truth sentence," "brand truth scaffolding," "audience truth," "what does my audience really believe," or any request to distill a brand or product down to one universal human insight. Even if the user just says "find the real truth behind why people buy X" or "what's the one thing my audience feels but can't say," use this skill.
---

# Core Human Truth — Deep Research Directive

Produce a single validated sentence (max 25 words) that captures the Core Human Truth for a given topic and audience. The sentence must pass tension, emotion, and agency checks, and be backed by triangulated evidence.

## When NOT to Use

- **Quick taglines or copywriting.** This skill runs a six-phase research pipeline. If the user wants a headline without evidence, write the copy directly — don't invoke this.
- **A validated truth already exists.** If the brand has a researched, evidence-backed truth sentence, skip to `brandprint-tier-a` and feed it in as the seed.
- **Non-brand research questions.** Market sizing, technology comparisons, or general analysis belong in `deep-research` — this skill only distills brand/audience truths.

## When You Receive a Request

Before doing anything else, resolve these variables with the user. If any are missing, ask.

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `topic` | The brand, product, service, or subject | *required* |
| `audience` | Primary audience definition | *required* |
| `region_context` | Geography or cultural context | US / English-speaking |
| `constraints` | Scope limits, legal, or brand constraints | None |
| `mode` | `rapid`, `standard`, or `enterprise` | `standard` |

## Principles

These are non-negotiable throughout the entire process:

1. **Truth over consensus.** Cite, compare, and challenge sources.
2. **Show tension, emotion, and agency** in the final sentence.
3. **No jargon. Max 25 words.** Instantly understood by the audience.
4. **Never fabricate data, quotes, or attributions.** If unknown, mark unknown.
5. **Triangulate.** Prefer converging evidence across independent sources.
6. **Be explicit about uncertainty** and counter-evidence.
7. **Respect privacy.** Use only public, lawful sources.

## Reasoning Approach

Throughout every phase:

- Surface assumptions before starting. List them.
- Voice counter-arguments and plausible alternatives.
- Stress-test conclusions with red team checks.
- Reframe if a simpler or more powerful truth emerges.
- Keep internal working notes distinct from final deliverables.

## Workflow — Six Phases

Execute these phases in order. Each phase has a clear goal, actions, and outputs.

### Phase 0 — Orientation

**Goal:** Define the lens and success criteria before research begins.

Actions:
- Resolve all variables (topic, audience, region, constraints, mode)
- List explicit assumptions and open questions
- Define success criteria: max 25 words, no jargon, tension + emotion + agency, testable via proxy validation
- Set evidence thresholds and note any disallowed sources

Outputs: `lens_brief`, `success_criteria`, `assumptions_list`

### Phase 1 — Secondary Sourcing

**Goal:** Map existing knowledge and tensions.

Actions:
- Literature sweep across academic and industry sources for the topic and audience
- Trend and media scan across reputable news, trade publications, forums, and short-form platforms
- Data dig of longitudinal datasets where applicable
- Tag emergent tensions and paradoxes — build a first-pass thematic map

Outputs: `annotated_bibliography`, `thematic_map`, `data_summary`

**Mode adjustments:**
- *Rapid:* 8–12 qualitative artifacts, lighter desk research
- *Standard:* Full desk research, qualitative synthesis
- *Enterprise:* Add cross-market comparisons, deeper comparative datasets

### Phase 2 — Qualitative Synthesis

**Goal:** Extract lived tensions from public qualitative artifacts.

Actions:
- Identify and summarize public first-person accounts, interviews, reviews, and forums relevant to the audience and topic
- Harvest cultural artifacts that symbolize the topic (memes, community posts) where public and permissible
- Cluster quotes and artifacts into a **tension ladder** — from surface complaints to root causes

Outputs: `insight_memos`, `tension_ladder`, `verbatim_snippets_public`

### Phase 3 — Validation via Triangulation

**Goal:** Validate candidate sentences with existing evidence and proxy signals.

Actions:
- Draft 3–5 candidate sentences based on the tension ladder
- Score each candidate against success criteria and evidence strength
- Triangulate with existing surveys, meta-analyses, and credible datasets
- If appropriate in Standard or Enterprise mode, design a small survey instrument *as a plan only* — never fabricate results

Outputs: `candidate_sentences_scored`, `validation_notes`, `quant_plan_optional`

### Phase 4 — Extraction and Red Team

**Goal:** Select the strongest sentence and pressure-test it.

Actions:
- Select the top candidate or create a hybrid based on evidence and clarity
- Run red team critique: Who would disagree and why? What would falsify it? Where does it fail?
- Revise with minimal words to increase truth density
- Run the plain-language and 25-word checks

Outputs: `final_sentence`, `red_team_report`, `readability_check`

### Phase 5 — Packaging

**Goal:** Deliver the sentence and its proof in compact, reusable form.

Actions:
- Assemble rationale narrative connecting tensions to evidence
- Create a simple tension map of paradox axes
- Draft audience archetype snapshots grounded in cited evidence
- Compile a lexicon: words that resonate vs. words that repel (based on sources)

Outputs: `rationale_deck_outline`, `tension_map`, `archetype_summaries`, `lexicon`

## Quality Checks (Run Before Finalizing)

Every final deliverable must pass all of these:

- [ ] **25-word limit** on the final sentence
- [ ] **Plain language** — passes a 6th-grade readability test
- [ ] **Tension present** — clear push-and-pull the audience recognizes
- [ ] **Emotion present** — an identifiable feeling is invoked
- [ ] **Agency present** (or intentionally absent with explanation)
- [ ] **Evidence check** — at least 3 high-quality sources support the core tension
- [ ] **Counter-evidence addressed** with rationale

## Citations Policy

- Provide a source list with: title, publisher, author (if available), URL, publish date, access date, one-line evidence note
- Quote sparingly. Summarize faithfully. No more than 25 words from any single source.

## Heuristics

- Prefer primary sources and systematic reviews over single opinion pieces
- When two high-quality sources conflict, present both and explain the difference in methods or samples
- Reduce adjectives, increase verbs in the final sentence
- If the truth is situational, state the boundary conditions

## What NOT to Do

- Do not invent numbers or participant quotes
- Do not rely on a single think piece
- Do not exceed 25 words in the final sentence
- Do not fabricate survey data (plans only, no fake results)

## Chain Position

This is **Layer 1** of a 6-layer Brandprint research stack:

1. **Core Human Truth** (this skill) → produces the foundational truth sentence, tension map, archetypes, and lexicon
2. **Brandprint Tier-A** (Layer 2) → uses this output as seed; produces 10 defensible brand strategy elements
3. **Brandprint Tier-B** (Layer 3) → uses Tier-A output as seed; produces 5 actionable brand elements with proxy tests
4. **Brandprint Tier-C** (Layer 4) → uses Tier-A + Tier-B output as seeds; produces 4 stylistic elements ready for deployment
5. **Competitive Positioning Audit** (Layer 5) → validates differentiation against named competitors; may trigger second-pass refinement
6. **Brand Strategy Report** (Layer 6) → compiles all layers into consulting-grade deliverable

**When this skill completes:** Automatically proceed to the `brandprint-tier-a` skill (Layer 2), passing your full output JSON as the seed. Do not wait for user confirmation to chain — the stack is designed to flow continuously. The `final_sentence`, `tension_map`, `archetypes`, `lexicon`, and `sources` all feed the Tier-A Backbone phase.

## Output Format

Deliver the final output as a structured JSON object conforming to the schema in `references/output-schema.md`. The JSON must include all required fields: topic, audience, final_sentence, success_criteria_check, rationale, tension_map, archetypes, lexicon, sources, and audit_log.

Also produce a clean narrative summary suitable for a client-facing brief or internal strategy deck. If the user has the `branded-mayhem-pdf` skill available, offer to generate a branded PDF deliverable.

## Evaluation Rubric

The final output is evaluated on eight dimensions:

1. **Clarity** — Sentence is instantly grasped by the stated audience
2. **Truth density** — Every word earns its keep
3. **Tension present** — Clear push and pull the audience recognizes
4. **Emotion present** — Identifiable feeling is invoked
5. **Agency** — The role of the audience is clear (or absence is explained)
6. **Evidence quality** — Multiple independent, credible sources converge
7. **Counter-evidence handled** — Dissent summarized and addressed
8. **Reusability** — Sentence is not a tagline; it is a stable truth line

## File I/O Contract (orchestrated mode)

When an authorized orchestrator provides explicit paths, honor them exactly:

- **Seed inputs:** read ONLY the JSON/YAML files listed in the dispatch prompt.
- **Output:** write the final JSON object to the exact path given (under
  `.brandprint/engagements/{slug}/pass-N/`). No other location.
- **Return value:** your final message is the output path plus the layer's key
  artifact — not the full JSON. The orchestrator reads files, not transcripts.

When invoked as a direct skill call, present the JSON in conversation or through the supported file workflow and tell the user to preserve it for the next layer.

Referenced files: 1

View saved version →

---
name: core-strategic-truth
description: Use when the user asks for a core strategic truth, product thesis seed, foundational market tension, the one constraint buyers can't escape, the forced trade-off at the center of a market, or a strategy foundation sentence. Also trigger when requests mention "market tension," "strategic tension," "product thesis," "foundational positioning," "what buyers are forced to choose between," "why buyers compromise," "the real constraint in this market," or any request to distill a product or platform down to the single trade-off that drives all buying decisions. Layer 1 of the Productprint research stack and the entry point for any new product strategy engagement. Even if the user just says "find the real reason buyers are stuck between X and Y" or "what's the one market problem no one has actually solved," use this skill.
---

# Core Strategic Truth — Deep Research Directive

Produce a single validated sentence (max 25 words) that captures the Core Strategic Truth for a given product and audience. The sentence must pass tension, stakes, and agency checks, and be backed by triangulated evidence.

## When NOT to Use

- **Quick positioning taglines or copywriting.** This skill runs a six-phase research pipeline. If the user wants a headline without evidence, write the copy directly — don't invoke this.
- **A validated strategic truth already exists.** If the product has a researched, evidence-backed truth sentence, skip to `productprint-tier-a` and feed it in as the seed.
- **Non-strategy research questions.** Market sizing, technology comparisons, or general analysis belong in `deep-research` — this skill only distills foundational product/market strategic truths.

## When You Receive a Request

Before doing anything else, resolve these variables with the user. If any are missing, ask.

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `product_name` | The product, platform, service, or solution | *required* |
| `category` | The market category or domain it competes in | *required* |
| `audience` | Primary buyer/operator audience definition | *required* |
| `region_context` | Geography or cultural context | US / English-speaking |
| `constraints` | Scope limits, legal, or strategic constraints | None |
| `mode` | `rapid`, `standard`, or `enterprise` | `standard` |
| `evidence_mode` | `greenfield` or `existing-product` | `greenfield` |

## Principles

These are non-negotiable throughout the entire process:

1. **Truth over consensus.** Cite, compare, and challenge sources.
2. **Show tension, stakes, and agency** in the final sentence.
3. **No jargon. Max 25 words.** Instantly understood by the audience.
4. **Never fabricate data, quotes, or attributions.** If unknown, mark unknown.
5. **Triangulate.** Prefer converging evidence across independent sources.
6. **Be explicit about uncertainty** and counter-evidence.
7. **Respect privacy.** Use only public, lawful sources.

## Reasoning Approach

Throughout every phase:

- Surface assumptions before starting. List them.
- Voice counter-arguments and plausible alternatives.
- Stress-test conclusions with red team checks.
- Reframe if a simpler or more powerful truth emerges.
- Keep internal working notes distinct from final deliverables.

## Workflow — Six Phases

Execute these phases in order. Each phase has a clear goal, actions, and outputs.

### Phase 0 — Orientation

**Goal:** Define the lens and success criteria before research begins.

Actions:
- Resolve all variables (product_name, category, audience, region, constraints, mode, evidence_mode)
- List explicit assumptions and open questions
- Define success criteria: max 25 words, no jargon, tension + stakes + agency, testable via proxy validation
- Set evidence thresholds and note any disallowed sources
- **In `existing-product` mode:** ingest operator-supplied internal artifacts (roadmap docs, telemetry summaries, customer-interview notes, loss reasons) into Phase 1 sourcing and weight them above external secondary sources. These first-party artifacts are the primary evidence tier; external sources corroborate or challenge, they do not lead.

Outputs: `lens_brief`, `success_criteria`, `assumptions_list`

### Phase 1 — Secondary Sourcing

**Goal:** Map existing knowledge and tensions.

Actions:
- Literature sweep across academic and industry sources for the product, category, and audience
- Trend and media scan across reputable news, trade publications, forums, and short-form platforms
- Data dig of longitudinal datasets where applicable
- Tag emergent tensions and paradoxes — build a first-pass thematic map
- In `existing-product` mode: prioritize operator-supplied artifacts (customer interviews, loss-reason logs, telemetry, roadmap) as Tier 1; external sources are Tier 2 corroboration

Outputs: `annotated_bibliography`, `thematic_map`, `data_summary`

**Mode adjustments:**
- *Rapid:* 8–12 qualitative artifacts, lighter desk research
- *Standard:* Full desk research, qualitative synthesis
- *Enterprise:* Add cross-market comparisons, deeper comparative datasets

### Phase 2 — Qualitative Synthesis

**Goal:** Extract lived trade-offs from public qualitative artifacts.

Actions:
- Identify and summarize public first-person accounts, interviews, reviews, and forums relevant to the audience, product, and category
- Harvest cultural artifacts that symbolize the market tension (community posts, analyst commentary, buyer-side RFP language) where public and permissible
- Cluster quotes and artifacts into a **tension ladder** — from surface complaints to root market trade-offs

Outputs: `insight_memos`, `tension_ladder`, `verbatim_snippets_public`

### Phase 3 — Validation via Triangulation

**Goal:** Validate candidate sentences with existing evidence and proxy signals.

Actions:
- Draft 3–5 candidate sentences based on the tension ladder
- Score each candidate against success criteria and evidence strength
- Triangulate with existing surveys, win/loss data, meta-analyses, and credible datasets
- If appropriate in Standard or Enterprise mode, design a small survey instrument *as a plan only* — never fabricate results
- Surface candidate JTBD hypotheses implied by each candidate sentence — these become `jtbd_seed` entries in the output

Outputs: `candidate_sentences_scored`, `validation_notes`, `jtbd_seed_candidates`, `quant_plan_optional`

### Phase 4 — Extraction and Red Team

**Goal:** Select the strongest sentence and pressure-test it.

Actions:
- Select the top candidate or create a hybrid based on evidence and clarity
- Run red team critique: Who would disagree and why? What would falsify it? Where does it fail?
- Revise with minimal words to increase truth density
- Run the plain-language and 25-word checks
- Confirm the sentence names a **strategic tension** (a forced trade-off with real consequences) — not a brand feeling, an emotional resonance, or a category observation. If it reads like a brand truth, return to Phase 2 and re-anchor on the market structure, not the audience psychology.

Outputs: `final_sentence`, `red_team_report`, `readability_check`

### Phase 5 — Packaging

**Goal:** Deliver the sentence and its proof in compact, reusable form.

Actions:
- Assemble rationale narrative connecting tensions to evidence (capture in `audit_log`)
- Create a tension map of paradox axes as two-pole structures (`tension_map`)
- Draft buyer/operator **decision-role** archetype snapshots grounded in cited evidence and their JTBD and decision context — not consumer identity or demographics (`archetypes`)
- Compile a lexicon: words that resonate vs. words that repel, based on sources (`lexicon`)
- Finalize `jtbd_seed` list from Phase 3 candidates, pruned to the most evidence-backed hypotheses

Outputs: `rationale_narrative`, `tension_map`, `archetype_summaries`, `lexicon`, `jtbd_seed`

## Quality Checks (Run Before Finalizing)

Every final deliverable must pass all of these:

- [ ] **25-word limit** on the final sentence
- [ ] **Plain language** — passes a 6th-grade readability test
- [ ] **Tension present** — clear forced trade-off the buyer recognizes
- [ ] **Stakes present** — consequence of choosing wrong is implied or explicit (not just a feeling)
- [ ] **Agency present** (or intentionally absent with explanation)
- [ ] **Evidence check** — at least 3 high-quality sources support the core tension
- [ ] **Counter-evidence addressed** with rationale

## Citations Policy

- Provide a source list with: title, publisher, URL, publish date, access date, one-line evidence note, stance (supporting / conflicting / neutral)
- Quote sparingly. Summarize faithfully. No more than 25 words from any single source.

## Heuristics

- Prefer primary sources and systematic reviews over single opinion pieces
- When two high-quality sources conflict, present both and explain the difference in methods or samples
- Reduce adjectives, increase verbs in the final sentence
- If the truth is situational, state the boundary conditions
- A strategic tension names who is forced to choose and what the two options cost them — if the sentence could be a tagline, it is not a strategic truth

## What NOT to Do

- Do not invent numbers or participant quotes
- Do not rely on a single think piece
- Do not exceed 25 words in the final sentence
- Do not fabricate survey data (plans only, no fake results)
- Do not write a brand truth (how the audience feels) and call it a strategic truth (what the market forces buyers to sacrifice)

## Chain Position

This is **Layer 1** of a 6-layer Productprint research stack:

1. **Core Strategic Truth** (this skill) → produces the foundational tension sentence, tension map, JTBD seed, archetypes, and lexicon
2. **Productprint Tier-A** (Layer 2) → uses this output as seed; produces the Playing-to-Win cascade, JTBD validation, and foundational strategy elements
3. **Productprint Tier-B** (Layer 3) → uses Tier-A output as seed; produces strategic bets, Now/Next/Later roadmap, build/buy/partner decisions, prioritization model, and risk register
4. **Productprint Tier-C** (Layer 4) → uses Tier-A + Tier-B output as seeds; produces deployment-ready positioning artifacts: positioning statement, one-liner, bet narrative, and strategy-on-a-page
5. **Thesis Stress-Test** (Layer 5) → adversarial pre-mortem gate; extracts load-bearing assumptions and tries to FALSIFY them; returns PROCEED if they survive or REFINE (with a constraint package) if one falls
6. **Strategy Thesis Compiler** (Layer 6) → compiles all layers into a consulting-grade integrated strategy thesis deliverable

**When this skill completes:** Automatically proceed to the `productprint-tier-a` skill (Layer 2), passing your full output JSON as the seed. Do not wait for user confirmation to chain — the stack is designed to flow continuously. The `final_sentence`, `tension_map`, `jtbd_seed`, `archetypes`, `lexicon`, `evidence_mode`, and `sources` all feed the Tier-A backbone phase.

## Output Format

Deliver the final output as a structured JSON object conforming to the schema in `references/output-schema.md`. The JSON must include all required fields: `product_name`, `category`, `audience`, `final_sentence`, `success_criteria_check`, `tension_map`, `jtbd_seed`, `archetypes`, `lexicon`, `sources`, `audit_log`, `mode`, and `evidence_mode`.

Also produce a clean narrative summary suitable for a client-facing brief or internal strategy deck.

## Evaluation Rubric

The final output is evaluated on eight dimensions:

1. **Clarity** — Sentence is instantly grasped by the stated audience
2. **Truth density** — Every word earns its keep
3. **Tension present** — Clear forced trade-off the buyer recognizes
4. **Stakes present** — Consequence of the trade-off is named or strongly implied
5. **Agency** — The role of the buyer/operator is clear (or absence is explained)
6. **Evidence quality** — Multiple independent, credible sources converge
7. **Counter-evidence handled** — Dissent summarized and addressed
8. **Reusability** — Sentence is not a tagline; it is a stable strategic truth that seeds a full strategy chain

## File I/O Contract (orchestrated mode)

> **Note:** automated orchestrated mode is not included in this release; run the manual chain. This contract is a forward-looking specification.

When an authorized orchestrator provides explicit paths, honor them exactly:

- **Seed inputs:** read ONLY the JSON/YAML files listed in the dispatch prompt.
- **Output:** write the final JSON object to the exact path given (under `.productprint/engagements/{slug}/pass-N/`). No other location.
- **Return value:** your final message is the output path plus the layer's key artifact — not the full JSON. The orchestrator reads files, not transcripts.

When invoked as a direct skill call, present the JSON in conversation or through the supported file workflow and tell the user to preserve it for the next layer.

Referenced files: 1

View saved version →

---
name: creative-thinking-ai
description: Apply the Mayhem Method to Creative Thinking with AI for structured ideation using 10 classic creativity frameworks as AI workflows. Use when running creative sprints, generating ideas at volume, or stress-testing concepts. Triggers on "SCAMPER," "Six Thinking Hats," "mind mapping," "brainstorming," "SWOT," "design thinking," "lotus blossom," "reverse brainstorming," "random word stimulation," "role storming," "creative sprint," "ideation," or when a team is stuck and needs structured divergent/convergent thinking.
---

# Creative Thinking with AI (Mayhem Method v1.0)

Turn classic creativity frameworks into practical AI workflows. Pick a method, feed a structured prompt, generate options, critique with a different method, consolidate and prototype.

## Core Loop

1. Pick a method that fits the job.
2. Feed AI a structured prompt pattern.
3. Generate 3–10 options per pass.
4. Critique with a different method to stress test.
5. Consolidate into a short list and prototype.

## Global Principles

- **Context in, quality out.** Give brand, audience, constraints, and success criteria.
- **One knob per pass.** Change a single variable between iterations.
- **Range before refinement.** Diverge wide, then converge with criteria.
- **Show your work.** Label which technique was used for each idea.
- **Bias checks.** Force at least one option that contradicts the default audience or channel.
- **Evidence lane.** If facts matter, require citations or mark outputs as speculative.

## When NOT to Use

- Not for production drafting — once a concept is picked, `mayhem-method-ai-use` handles structured AI-assisted production.
- Not for testing how an audience reacts — that's `ai-focus-group`.
- Not for narrative writing — story structure lives in `story-spine`.
- Not when the decision is already made — these methods generate and stress-test options; running them to justify a foregone conclusion wastes the room's time.

## The 10 Methods

### 1) SCAMPER
**Use when** you need many variations of an existing product, process, or message.
```
You are applying SCAMPER to {object}.
Constraints: {brand, audience, channel, limits}.
For each letter, output 3 ideas:
- S Substitute / C Combine / A Adapt / M Modify / P Put to another use / E Eliminate / R Reverse
End with a shortlist of 5 with rationale.
```
**Twists:** Add a cost band to each idea. Force 1 idea per letter that can ship within 48 hours.

### 2) Six Thinking Hats
**Use when** a team is stuck arguing about taste. You want structured angles.
```
We are evaluating {concept}.
Give 6 sections labeled by hat:
White facts, Red emotions, Black risks, Yellow benefits, Green creative alternatives, Blue process next steps.
Each section 3 bullets max, grounded in {data if any}.
```
**Twists:** Run the same input twice and compare where the hats disagree. Force one Green option that contradicts brand norms.

### 3) Mind Mapping
**Use when** you need a landscape fast.
```
Create a hierarchical outline mind map for {central topic}.
Depth 3 levels. Return as nested bullets and as JSON {id, label, parent_id}.
Tag each node with {opportunity|risk|unknown}.
```
**Twists:** Ask for an adjacency list for a diagram tool. Require 5 edge cases in an "unknown" cluster.

### 4) Brainstorming
**Use when** you want raw volume before filters.
```
Generate 30 ideas for {goal}.
Rules: no self-censoring, 12 words max per idea, no duplicates.
Label each with {safe bet|stretch|wild}.
End with 5 "bridge" ideas that combine a safe bet with a wild.
```
**Twists:** Time-boxed rounds: 10 ideas per minute with increasing constraints.

### 5) SWOT Analysis
**Use when** you need strategic alignment or stakeholder buy-in.
```
Create a SWOT for {initiative}. Use evidence where possible.
Each quadrant 5 bullets.
Then propose 3 TOWS strategies that pair internal with external factors.
```
**Twists:** Add a confidence score per bullet. Require one contrarian TOWS play.

### 6) Design Thinking
**Use when** solving fuzzy human problems.
```
We are applying Design Thinking to {problem}.
Return sections:
Empathize insights, Define problem statement (How might we...),
Ideate 15 ideas categorized by effort vs impact,
Prototype plan for top 3, Test plan with success metrics and risks.
```
**Twists:** Force one idea per disability persona. Add a concierge MVP in 24 hours.

### 7) Lotus Blossom Technique
**Use when** you want depth around one seed idea.
```
Central idea: {seed}.
Generate 8 petals with labels, each with 8 sub-ideas.
Return as a table and as JSON {petal, ideas[]}.
Highlight 5 cross-petal combos with high synergy.
```
**Twists:** Make one petal "legal and consent." Force one petal for automation and one for community.

### 8) Reverse Brainstorming
**Use when** you need to find failure modes before they find you.
```
Goal: {goal}.
Step 1: List 20 ways to make this fail.
Step 2: For each, propose a prevention or detection measure.
Return a top 10 risk register with severity, likelihood, owner, first step.
```
**Twists:** Ask for canaries and tripwires you can measure in real time.

### 9) Random Word Stimulation
**Use when** the room is stale and safe.
```
Generate 10 random concrete nouns and 10 abstract nouns.
Map each to {topic} with a 1-line concept.
Pick 5 favorites and expand each into a 2-sentence concept plus a title.
```
**Twists:** Seed the randomizer with a theme like "nautical" or "kitchen."

### 10) Role Storming
**Use when** you need perspective shifts fast.
```
Adopt these roles: {list}.
Each role proposes 3 ideas for {problem}, each with a role-specific rationale and a red flag to watch.
```
**Twists:** Add a "nemesis" role that wants you to fail. Require one idea per role under $100.

## Combo Patterns

- **SCAMPER × Hats:** Generate with SCAMPER, evaluate with Hats, shortlist.
- **Mind Map × Reverse:** Map the space, attack the riskiest branches.
- **Design Thinking × Role Storming:** Empathy and roles to test assumptions.
- **Lotus × SWOT:** Go deep, then pressure test strategically.

```
Run {method A} for {topic}.
Then switch to {method B} to critique the top 10 outputs.
Return a 5-item shortlist with reasons and next steps.
```

## Acceptance Rubric (Score 1–5 Each, Ship at 22+)

- Relevance to brief
- Originality that still fits the audience
- Feasibility within constraints
- Evidence or plausible rationale
- Ethical and legal sanity

## Workshop Sprint Outline (60 Minutes)

- 0–5: Brief and constraints
- 5–20: Diverge Round 1 (Brainstorming or Random Word)
- 20–35: Diverge Round 2 (SCAMPER or Lotus)
- 35–45: Converge (Six Hats or SWOT)
- 45–55: Prototype notes (Design Thinking)
- 55–60: Assign next steps and owners

## Universal Prompt

```
You are my creative collaborator.
Brand: {brand}. Audience: {aud}. Constraints: {rules}.
We will use {method}. Label outputs with the method and provide 3 to 10 options.
End with a shortlist of 5 and next steps I can do in 48 hours.
```

## Guardrails

- Label speculative content.
- Avoid dark patterns and deceptive claims.
- Respect IP and attribution.
- Include accessibility checks in every shortlist.

View saved version →

---
name: data-density-commerce
description: Apply the Instant Checkout & ACP data-density commerce checklist for product feed optimization. Use when preparing product feeds for AI-powered shopping, Google Merchant Center compliance, or agent-compatible checkout flows. Triggers on "feed completeness," "product feed," "ACP," "instant checkout," "delivery estimate," "return window," "answerability," "description depth," "merchant center," "feed parity," or when SKU data needs to be machine-readable and agent-actionable for natural-language shopping queries.
---

# Instant Checkout & ACP — Data-Density Commerce

Make products the only logical answer to natural-language asks by maxing out feed completeness and policy clarity. This is the commerce data layer that powers AI agent-readiness (PLAY-004).

## Goal

Products surface and convert in chat-led SERPs and agentic browsers because the data is complete, accurate, and machine-verifiable.

## When NOT to Use

- Digital-only products with no shipping or feed. Delivery estimates, Merchant Center, and feed parity don't apply.
- You don't control the product feed. Pure marketplace sellers (Amazon- or Etsy-only) can't change refresh cadence or field structure.
- The catalog is under ~10 SKUs. Manual checks beat building feed-completeness tooling at that scale.

## Readiness Checklist

### Feed Refresh
- [ ] Feed refresh ≤ 15 minutes for price and stock updates
- [ ] Price changes reflected in feed within one refresh cycle
- [ ] Stock status (in-stock, out-of-stock, preorder) accurate in real time

### Field Completeness
- [ ] Required + recommended fields ≥ 95% populated on top 20% SKUs
- [ ] All required Google Merchant Center fields present
- [ ] Optional fields (color, size, material, pattern) filled where applicable

### Description Depth
- [ ] 5,000-character descriptions structured as knowledge base
- [ ] Descriptions answer common buyer questions inline
- [ ] Structured sections: what it is, who it's for, specs, care/use, compatibility

### Delivery Promises
- [ ] `delivery_estimate` present on SKUs with fast shipping methods
- [ ] Handling time and transit time separated and accurate
- [ ] Shipping cost visible or calculable before checkout

### Returns Policy
- [ ] Returns: live URL published and accessible
- [ ] Explicit `return_window` (e.g., "30 days from delivery")
- [ ] Return conditions clearly stated (restocking fees, exclusions)

### Payment & Checkout
- [ ] ACP (Automated Checkout Process) endpoints respond correctly
- [ ] Cart totals math correct (subtotal + tax + shipping = total)
- [ ] Idempotent payment processing (no double charges on retry)
- [ ] Prefilled cart links functional for top configurations

### Parity
- [ ] Feed price = page price = JSON-LD price (no mismatches)
- [ ] Feed availability = page availability = JSON-LD availability
- [ ] Feed condition = page condition = JSON-LD condition
- [ ] Shipping settings match between Merchant Center and JSON-LD

## Weekly KPIs

| Metric | Target | How to Measure |
|--------|--------|---------------|
| Feed completeness % | ≥ 95% on top SKUs | Required + recommended fields filled / total fields |
| Answerability % | ≥ 80% | % of top buyer queries answerable from feed data alone |
| Description depth | ≥ 3,000 avg chars | Average character count across active SKUs |
| Parity score | 100% | Feed vs page vs JSON-LD match rate on price, availability, condition |
| Feed freshness | ≤ 15 min lag | Time between source change and feed update |

## Description Structure Template

For each SKU, structure the 5,000-char description as:

```
## What It Is
[1-2 sentences: category, primary function, key differentiator]

## Who It's For
[1-2 sentences: ideal buyer, use case, skill level]

## Key Specs
[Structured list: dimensions, weight, materials, capacity, compatibility]

## How to Use / Care
[Maintenance, setup, or usage instructions relevant to the product]

## What's Included
[Box contents, accessories, warranties]

## Common Questions
[2-3 FAQ-style Q&As that buyers typically ask before purchasing]
```

## Integration with PLAY-004

This checklist is the commerce data layer for the AI Agent-Readiness playbook. When both are implemented:

1. **Agent discovers product** via structured data and feed (this checklist)
2. **Agent evaluates fit** using description depth and field completeness (this checklist)
3. **Agent completes purchase** via selector contract and task URLs (PLAY-004)
4. **Agent verifies parity** between feed, page, and JSON-LD (both)

## Ops Cadence

- **Daily:** Monitor feed refresh lag and parity alerts
- **Weekly:** Review KPI dashboard; fix top 5 parity mismatches
- **Monthly:** Audit description depth on new SKUs; expand to next 20% of catalog
- **Quarterly:** Full feed audit; update return/shipping policies; review ACP endpoint health

View saved version →

---
name: dataforseo
description: >-
  Use when the user asks to perform SEO research, keyword analysis, SERP audits,
  backlink checks, competitor analysis, or any task involving the DataForSEO API.
  Provides the complete Python client, authentication, response parsing patterns,
  and all available endpoints. Also use when writing scripts that call DataForSEO
  or when the user mentions keyword research, search volume, SERP rankings, or
  SEO data collection.
---

# DataForSEO API — Operational Guide

## File locations (read this first)

Choose behavior based on the current execution surface:

| Context | Client access | Working dir | User-facing output |
|---|---|---|---|
| Codex with local shell access | Resolve this installed skill directory and use `scripts/dataforseo_client.py` | current workspace | `./dataforseo-results/YYYYMMDD/` or another user-approved path |
| ChatGPT or a surface without local shell access | No direct API execution in this skills-only release | conversation or supported file workspace | Return an input contract or analyze user-supplied exports; never fabricate live API results |

This release has no authenticated DataForSEO MCP connection.

## When NOT to Use

- No DataForSEO account or API budget. Every call bills the account — there's no free tier worth building on.
- You only need your own site's organic data. Google Search Console gives you queries, clicks, impressions, and positions for free.
- One-off single-keyword lookups. Scripting a client and paying API spend for one number isn't worth it — use a free volume tool instead.

## Credentials

Use one of these local credential sources, in priority order:

1. **Environment variables:** `DATAFORSEO_LOGIN` and `DATAFORSEO_PASSWORD`.
2. **Local config file:** `~/.config/8gnc/dataforseo.json` with `{"login": "...", "password": "..."}`. Create or read it only with the user's permission and never print its contents.

Do not paste credentials into chat, source files, reports, or committed project configuration.

## Bundled client

A working `DataForSEOClient` ships inside the skill at `scripts/dataforseo_client.py` (~200 LoC, requests-based, covers every convenience method in the table below + generic `post`/`get`/`task_post`/`task_get`/`tasks_ready` escape hatches).

**To use it:** on a local execution surface, resolve the installed `dataforseo` skill directory from this loaded `SKILL.md` and add its `scripts/` directory to the Python import path. Do not copy the client into the user's project unless the user explicitly asks for a vendored copy.

The client only depends on `requests`. Standard library otherwise. Python 3.9+.

## Quick Start (Copy-Paste Pattern)

Every local DataForSEO script should start with this pattern after resolving the bundled client path:

```python
import json, sys, os, time
from pathlib import Path

from dataforseo_client import DataForSEOClient

API_LOGIN = os.environ.get("DATAFORSEO_LOGIN")
API_PASSWORD = os.environ.get("DATAFORSEO_PASSWORD")

client = DataForSEOClient(API_LOGIN, API_PASSWORD)
OUTPUT_DIR = Path.cwd() / "dataforseo-results" / time.strftime("%Y%m%d")
OUTPUT_DIR.mkdir(parents=True, exist_ok=True)
```

- Add `time.sleep(2)` between API calls to respect rate limits.
- Save raw responses as JSON for re-analysis without re-billing the API.
- On a non-local surface, stop before the API call and request an export or an authenticated MCP capability.

## Available Client Methods

### Convenience Methods (Use These First)

| Method | What It Does | Endpoint |
|--------|-------------|----------|
| `client.serp_google_organic_live(keyword, location_name, language_name, device, depth)` | Live Google organic SERP results | `/serp/google/organic/live/advanced` |
| `client.serp_google_maps_live(keyword, location_name, language_name, depth)` | Live Google Maps SERP results | `/serp/google/maps/live/advanced` |
| `client.keywords_search_volume(keywords_list, location_name, language_name)` | Search volume for a list of keywords (up to 700 per call) | `/keywords_data/google_ads/search_volume/live` |
| `client.keywords_for_site(target_domain, location_name, language_name)` | Keywords Google associates with a domain | `/keywords_data/google_ads/keywords_for_site/live` |
| `client.backlinks_summary(target_url_or_domain)` | Backlink profile summary | `/backlinks/summary/live` |
| `client.onpage_task_post(target_url)` | Submit async on-page SEO audit | `/on_page/task_post` |
| `client.onpage_summary(task_id)` | Get on-page audit results | `/on_page/summary/{task_id}` |
| `client.business_data_google_reviews(keyword, location_name, language_name, depth)` | Google Business reviews | `/business_data/google/reviews/live/advanced` |
| `client.serp_google_locations()` | List all available SERP locations | `/serp/google/locations` |
| `client.serp_google_languages()` | List all available SERP languages | `/serp/google/languages` |

### Generic Methods (For Any Endpoint)

| Method | When to Use |
|--------|-------------|
| `client.post(endpoint_path, [task_dict])` | Any POST endpoint not covered by convenience methods |
| `client.get(endpoint_path)` | Any GET endpoint |
| `client.task_post(api_path, [task_dict])` | Submit async tasks (endpoints ending in `/task_post`) |
| `client.task_get(api_path, task_id)` | Retrieve async task results |
| `client.tasks_ready(api_path)` | Check which async tasks are completed |

All convenience methods accept `**extra` kwargs — you can pass any additional DataForSEO parameter without modifying the client.

## Response Structure (Critical)

**Every DataForSEO response has this structure:**

```python
{
    "version": "0.1.20260209",
    "status_code": 20000,        # 20000 = success
    "status_message": "Ok.",
    "tasks": [
        {
            "id": "task-uuid",
            "status_code": 20000,
            "status_message": "Ok.",
            "result": [...]      # <-- THE DATA IS HERE
        }
    ]
}
```

**Standard parsing pattern:**

```python
result = client.some_method(...)
if result.get("tasks"):
    for task in result["tasks"]:
        if task.get("result"):
            for item in task["result"]:
                # Process item here
```

### Search Volume Result Items

Each item in a search volume result contains:
- `item["keyword"]` — the keyword string
- `item["search_volume"]` — monthly search volume (int or None)
- `item["competition"]` — "LOW", "MEDIUM", "HIGH", or None
- `item["cpc"]` — cost per click (float or None)
- `item["monthly_searches"]` — list of dicts with `year`, `month`, `search_volume`

### SERP Result Items

Each SERP result contains an `items` list. Items have a `type` field:
- `type == "organic"` — organic search result: has `title`, `url`, `rank_absolute`, `description`
- `type == "people_also_ask"` — PAA box: has `items` list of dicts with `title` key
- `type == "related_searches"` — related searches: has `items` list of **plain strings, NOT dicts** — check `isinstance(item, str)` when iterating, or your dict-style parsing will crash here
- `type == "featured_snippet"` — featured snippet: has `title`, `url`, `description`
- `type == "local_pack"` — local pack: has `items` list with business details
- `type == "paid"` — paid ads: has `title`, `url`

**IMPORTANT: `related_searches` items are plain strings, NOT dicts. Check `isinstance(item, str)` when iterating.**

### Keywords-for-Site Result Items

Each item contains:
- `item["keyword"]` — keyword string
- `item["search_volume"]` — monthly volume
- `item["competition"]` — LOW/MEDIUM/HIGH

## Common Endpoint Patterns (via client.post)

### Keyword Suggestions from Seed Keywords

```python
result = client.post("/keywords_data/google_ads/keywords_for_keywords/live", [{
    "keywords": ["adaptive reuse", "historic preservation"],
    "location_name": "United States",
    "language_name": "English",
}])
```

### Backlinks (More Endpoints)

```python
# Backlinks list
result = client.post("/backlinks/backlinks/live", [{"target": "example.com", "limit": 100}])

# Referring domains
result = client.post("/backlinks/referring_domains/live", [{"target": "example.com", "limit": 100}])

# Anchors
result = client.post("/backlinks/anchors/live", [{"target": "example.com", "limit": 100}])
```

### Domain Analytics

```python
# Technologies used by a domain
result = client.post("/domain_analytics/technologies/domains_by_technology/live", [{
    "technology": "WordPress",
    "filters": ["country_iso_code", "=", "US"],
}])
```

### Google Trends

```python
result = client.post("/keywords_data/google_trends/explore/live", [{
    "keywords": ["adaptive reuse", "office conversion"],
    "location_name": "United States",
    "language_name": "English",
    "time_range": "past_12_months",
}])
```

## Location Names (Common Values)

Use these exact strings for `location_name`:
- `"United States"`
- `"New York,New York,United States"` (city-level)
- `"Dallas,Texas,United States"` (city-level)
- `"Houston,Texas,United States"` (city-level)
- `"Austin,Texas,United States"` (city-level)
- `"United Kingdom"`, `"Canada"`, `"Australia"`, etc.

For exact location IDs, call `client.serp_google_locations()`.

## Best Practices

1. **Always save raw JSON** — save every API response to the results dir (see File locations) so data can be re-analyzed without re-calling the API.
2. **Batch keywords** — `keywords_search_volume` accepts up to 700 keywords per call. Chunk larger lists.
3. **Rate limit** — add `time.sleep(2)` between calls. For SERP calls (heavier), use `time.sleep(3)`.
4. **Handle None values** — `search_volume`, `cpc`, and `competition` can all be None. Always use `or 0` / `or "-"` in formatting.
5. **Use depth=100 for SERP audits** — default depth=10 only returns page 1. Use depth=100 to get related_searches and people_also_ask which appear on later pages.
6. **Sort by volume** — when displaying results, always sort keywords by search_volume descending for readability.
7. **Deliverable delivery depends on surface** — use a user-approved workspace path in Codex; use the supported file workflow in ChatGPT. Never claim a live API result when no authenticated execution path exists.

## Full Example: Keyword Research Workflow

This example uses local environment variables and a workspace-scoped output directory.

```python
import json, sys, os, time
from pathlib import Path

# Resolve the installed dataforseo skill and add its scripts directory to sys.path first.
from dataforseo_client import DataForSEOClient

API_LOGIN = os.environ.get("DATAFORSEO_LOGIN")
API_PASSWORD = os.environ.get("DATAFORSEO_PASSWORD")

client = DataForSEOClient(API_LOGIN, API_PASSWORD)
OUTPUT_DIR = Path.cwd() / "dataforseo-results" / time.strftime("%Y%m%d")
OUTPUT_DIR.mkdir(parents=True, exist_ok=True)

def save(name, data):
    path = OUTPUT_DIR / f"{name}.json"
    with open(path, "w", encoding="utf-8") as f:
        json.dump(data, f, indent=2, ensure_ascii=False)

# 1. Search volume for target keywords
keywords = ["keyword one", "keyword two", "keyword three"]
vol_result = client.keywords_search_volume(keywords)
save("search_volume", vol_result)

# Parse results
if vol_result.get("tasks"):
    for task in vol_result["tasks"]:
        if task.get("result"):
            items = sorted(task["result"], key=lambda x: (x.get("search_volume") or 0), reverse=True)
            for item in items:
                kw = item.get("keyword", "?")
                vol = item.get("search_volume") or 0
                comp = item.get("competition", "-") or "-"
                cpc = item.get("cpc")
                cpc_str = f"${cpc:.2f}" if cpc else "-"
                print(f"{kw:<50} vol={vol:<8} comp={comp:<10} cpc={cpc_str}")

time.sleep(2)

# 2. SERP audit for key terms
serp_result = client.serp_google_organic_live("target keyword", depth=100)
save("serp_audit", serp_result)

# Parse SERP — organics, PAA, and related searches
if serp_result.get("tasks"):
    for task in serp_result["tasks"]:
        if task.get("result"):
            for res in task["result"]:
                for item in res.get("items", []):
                    t = item.get("type", "")
                    if t == "organic":
                        print(f"#{item.get('rank_absolute')} {item.get('title','')[:60]}")
                        print(f"   {item.get('url','')[:70]}")
                    elif t == "people_also_ask":
                        for pa in item.get("items", []):
                            if isinstance(pa, dict):
                                print(f"PAA: {pa.get('title','')}")
                    elif t == "related_searches":
                        for rs in item.get("items", []):
                            if isinstance(rs, str):
                                print(f"Related: {rs}")

time.sleep(2)

# 3. Keyword suggestions for a competitor domain
site_result = client.keywords_for_site("competitor.com")
save("competitor_keywords", site_result)

# 4. Keyword suggestions from seed keywords
seed_result = client.post("/keywords_data/google_ads/keywords_for_keywords/live", [{
    "keywords": ["seed keyword"],
    "location_name": "United States",
    "language_name": "English",
}])
save("seed_suggestions", seed_result)
```

## Existing Research Data

Previous research results may be saved at the results path for your surface (see File locations table). Check for existing data before making redundant API calls.

## API Reference

For the complete list of all available DataForSEO API endpoints, parameters, and response schemas, consult the [official DataForSEO API documentation](https://docs.dataforseo.com/v3/). The convenience methods in this skill cover the highest-traffic endpoints; the `client.post()` and `client.get()` generic methods reach anything else.

> Earlier versions of this skill referenced a bundled `reference.md` that was not shipped — use the official DataForSEO docs instead.

Referenced files: 1

View saved version →

---
name: deep-research
description: Use when a task needs enterprise-grade research across many sources with citation tracking and verification. Triggers on "deep research", "comprehensive analysis", "research report", "compare X vs Y", "analyze trends", or "state of the art". Not for simple lookups, debugging, or questions answerable with 1-2 searches.
---

# Deep Research

## Core Purpose

Deliver citation-backed, verified research reports through a structured pipeline with source credibility scoring, evidence persistence, and progressive context management.

**Autonomy Principle:** Operate independently. Infer assumptions from context. Only stop for critical errors or incomprehensible queries.

---

## Decision Tree

```
Request Analysis
+-- Simple lookup? --> STOP: Use the available current web-search tool
+-- Debugging? --> STOP: Use standard tools
+-- Complex analysis needed? --> CONTINUE

Mode Selection
+-- Initial exploration --> quick (3 phases, 2-5 min)
+-- Standard research --> standard (6 phases, 5-10 min) [DEFAULT]
+-- Critical decision --> deep (8 phases, 10-20 min)
+-- Comprehensive review --> ultradeep (8+ phases, 20-45 min)
```

**Default assumptions:** Technical query = technical audience. Comparison = balanced perspective. Trend = recent 1-2 years.

---

## Workflow Overview

| Phase | Name | Quick | Standard | Deep | UltraDeep |
|-------|------|-------|----------|------|-----------|
| 1 | SCOPE | Y | Y | Y | Y |
| 2 | PLAN | - | Y | Y | Y |
| 3 | RETRIEVE | Y | Y | Y | Y |
| 4 | TRIANGULATE | - | Y | Y | Y |
| 4.5 | OUTLINE REFINEMENT | - | Y | Y | Y |
| 5 | SYNTHESIZE | - | Y | Y | Y |
| 6 | CRITIQUE | - | - | Y | Y |
| 7 | REFINE | - | - | Y | Y |
| 8 | PACKAGE | Y | Y | Y | Y |

---

## File locations (read this first)

Choose behavior based on the current execution surface:

| Context | Helper execution | Report destination |
|---|---|---|
| Codex with local file and shell access | Resolve the installed `deep-research` skill directory from this loaded `SKILL.md`; call helpers from its `scripts/` directory | A user-approved workspace path such as `./research-output/[topic]-YYYYMMDD/` |
| ChatGPT or another surface without local shell access | Do not claim that bundled scripts ran | Return the report in conversation or through the supported downloadable-file workflow |

Never write into a home directory or external system without the user's authorization.

## Execution

**On invocation, load relevant reference files** (relative paths from this SKILL.md, which work on both surfaces):

1. **Phase 1-7:** Load [methodology.md](./reference/methodology.md) for detailed phase instructions
2. **Phase 8 (Report):** Load [report-assembly.md](./reference/report-assembly.md) for progressive generation
3. **HTML/PDF output:** Load [html-generation.md](./reference/html-generation.md)
4. **Quality checks:** Load [quality-gates.md](./reference/quality-gates.md)
5. **Long reports (>18K words):** Load [continuation.md](./reference/continuation.md)

**Templates:**
- Report structure: [report_template.md](./templates/report_template.md)
- HTML styling: [mckinsey_report_template.html](./templates/mckinsey_report_template.html)

**Scripts:** on a local execution surface, resolve the installed skill directory first and use absolute package-relative paths:

- `python3 [skill-dir]/scripts/validate_report.py --report [path]`
- `python3 [skill-dir]/scripts/verify_citations.py --report [path]`
- `python3 [skill-dir]/scripts/md_to_html.py [markdown_path]`

If local execution is unavailable, apply the same checks manually and disclose that the bundled validators did not run.

---

## Output Contract

**Required sections:**
- Executive Summary (200-400 words)
- Introduction (scope, methodology, assumptions)
- Main Analysis (4-8 findings, 600-2,000 words each, cited)
- Synthesis & Insights (patterns, implications)
- Limitations & Caveats
- Recommendations
- Bibliography (COMPLETE - every citation, no placeholders)
- Methodology Appendix

**Output files** — use the destination contract above. Produce:
- Markdown (primary source)
- HTML when the current surface can create it
- PDF when a supported PDF workflow or WeasyPrint is available

**Quality standards:**
- 10+ sources, 3+ per major claim
- All claims cited immediately [N]
- No placeholders, no fabricated citations
- Prose-first (>=80%), bullets sparingly

---

## Common Mistakes

- **Running deep/ultradeep for a question one search answers** — burns 10-45 minutes for no added confidence. Walk the decision tree first; simple lookup means STOP.
- **Citing a major claim from a single source** — fails the 3+ sources standard and ships unverified assertions. Triangulate, or downgrade the claim and say so in Limitations.
- **Leaving placeholder or uncited entries in the bibliography** — `validate_report.py` rejects it, and a client who checks one dead citation distrusts the whole report. Every [N] must resolve.
- **Writing bullet-heavy sections** — violates the prose-first (>=80%) contract and reads as notes, not analysis. Convert findings to narrative; bullets only for genuine lists.
- **Skipping `verify_citations.py` before packaging** — fabricated or dead links reach the reader. Run it on every report, every time.

## When to Use / NOT Use

**Use:** Comprehensive analysis, technology comparisons, state-of-the-art reviews, multi-perspective investigation, market analysis.

**Do NOT use:** Simple lookups, debugging, 1-2 search answers, quick time-sensitive queries.

Referenced files: 19

View saved version →

---
name: diagnose-brand-growth
description: Diagnose ambiguous brand and growth problems and route them to the smallest useful 8gnc method sequence. Use when the user says the brand feels stuck, generic, invisible, inconsistent, hard to explain, weak at conversion, weak in outreach, unclear on product direction, or asks which 8gnc skill to use. Also trigger for broad requests such as "fix my brand," "what is actually wrong," "where should we start," "audit this business," or "give me the full 8gnc treatment." Do not trigger when the user explicitly names a specialist skill and already has the inputs it requires.
---

# Diagnose Brand and Growth

Start with diagnosis. Do not expose a 36-skill menu or run the entire stack by default.

Read [capability-map.md](references/capability-map.md) before routing. Load only the selected specialist skill instructions after the route is chosen.

## 1. Establish the evidence boundary

Collect or inspect the smallest useful evidence set:

- the decision the user needs to make;
- the audience, offer, market, and current surface;
- available first-party evidence such as interviews, analytics, loss reasons, briefs, drafts, or pages;
- constraints, timing, and what has already been tried.

Label every input as observed, user-reported, inferred, or unknown. Never invent client intelligence, market evidence, metrics, approvals, or access.

This release has no authenticated client-data connection. Use only evidence the user provides, files available in the current workspace, and lawful public research. Treat an approval as a decision about the named artifact, not authorization to publish, deploy, send, or execute.

## 2. Name the primary constraint

Choose one primary lane:

- brand meaning or positioning;
- product direction or sequencing;
- content or voice;
- search or AI visibility;
- conversion or pricing architecture;
- sales motion or practice.

Use a secondary lane only when evidence shows it is upstream or downstream of the primary constraint. Distinguish symptoms from causes. Low traffic is not automatically an SEO problem; weak conversion is not automatically a copy problem; generic content is not automatically a voice problem.

## 3. Route the work

Select the minimum sequence from the capability map. Prefer:

- one diagnostic or research method;
- one synthesis or stress-test method;
- one deliverable method only when the inputs are strong enough.

Do not run compilers before their required layer artifacts exist. Do not call simulated audience reactions real research. Do not call speculative recommendations validated strategy.

If the user explicitly requests a named specialist skill, invoke that skill directly unless a missing prerequisite would make the output misleading.

## 4. Return a decision-ready diagnosis

Return:

1. **Primary constraint** — one sentence.
2. **Evidence** — what supports it, with source labels.
3. **Confidence and gaps** — high, medium, or low, plus what would change the call.
4. **Route** — the selected skills in order and why each is necessary.
5. **First move** — the first concrete input or action, not a generic checklist.
6. **Decision gate** — what a human must decide before implementation.

End substantial outputs with these five lines:

- Evidence supports:
- Evidence does not establish:
- Human judgment required:
- Implementation prerequisites:
- The model cannot know:

Do not end with an agency pitch. The method must be useful on its own.

Referenced files: 2

View saved version →

---
name: fairness-anchor-ladder
description: Execute the Fairness Anchor & Upgrade Ladder pricing strategy (PLAY-001). Use when a client needs loss-leader pricing with a choreographed upgrade path, menu/offer architecture, or viral pricing plays. Triggers on "fairness anchor," "upgrade ladder," "loss leader," "anchor pricing," "menu choreography," "price perception," offer tier design for local services, wellness, QSR, SaaS, or any request to build a pricing strategy around a public anchor price with stacked upgrades.
---

# Fairness Anchor & Upgrade Ladder (PLAY-001)

Operationalize a loss-leader model: lock one "fairness anchor" price in public view, choreograph an upgrade ladder beside it. The anchor edits perception; the ladder prints margin. Virality offsets the unit loss. Supply-side control keeps the engine fed.

## When NOT to Use

- **COGS already at floor.** The model's only levers when margin compresses are value-engineering `C_a` or raising `M_i` — never raising `P_a`. If there is no room to engineer the anchor's cost down, the loss leader is just margin bleed with no recovery path.
- **No audience or brand trust to absorb the anchor loss.** Virality is COGS here: `S_u` has to offset `L_a`. With no shares, views, or UGC engine, the blended contribution formula goes negative and stays there. Build attention first.
- **Regulated-pricing categories.** Healthcare, alcohol, financial services, utilities — public frozen prices and below-cost selling can violate minimum-pricing and advertising rules. A frozen anchor is a promise you may not legally be allowed to keep.
- **No natural upgrade adjacency.** The ladder needs 3–7 upgrades selectable in the same frame as the anchor. If the offer has no honest add-ons, there is nothing to print margin and the anchor is a coupon you pay forever.
- **The problem is flow or identity, not pricing.** For how customers move through the menu once it exists, use `ux-ui-psych`. For the creative system around the brand, use `neuro-design`.

1. Publish a price that feels impossibly fair.
2. Place it first in every frame (menu, landing page, storefront, social bio).
3. Stack 3–7 profitable upgrades immediately adjacent.
4. Engineer UGC around the anchor so attention subsidizes the loss.
5. Measure share-per-unit and attachment rates; iterate weekly.

## Principles

1. **Fairness over price.** A single, public, frozen price builds trust faster than a thousand claims.
2. **Anchors write the map.** First price seen sets the reference for every other decision.
3. **Menu is choreography.** Placement is persuasion. Top slot = hook. Second slot = margin. Third = novelty.
4. **Virality is COGS.** Treat UGC volume as an offset to anchor losses.
5. **Own the spine.** Control supply (inputs, tooling, process) or your loss leader becomes a coupon you pay forever.

## Offer Architecture

### Frame
- **Top-of-menu hero:** Anchor title, price in large type, 1-line promise.
- **Right-beside ladder:** 3–7 upgrades with simple names and one benefit each.
- **One-tap/two-click rule:** Upgrades must be selectable in the same frame as the anchor.

### Naming
- Anchor name: short, literal, shareable. Ex: "Forty-Cent Cone," "$49 Color Consult," "Free Lite Audit."
- Upgrades: descriptive, not clever. Ex: "Sundae +Topping," "Pro Polish," "Priority Turnaround."

### Ladder Design
- Slot 1: **Sane add-on** (highest attachment potential)
- Slot 2: **Signature upgrade** (highest margin)
- Slot 3: **Novelty** (seasonal, social bait)
- Slots 4–7: **Bundles** (anchor + 2 add-ons at slight discount)

## Pricing Logic & Formulas

Variables:
- `P_a` = Anchor price
- `C_a` = Anchor COGS (ingredients + labor + packaging + payment fees)
- `L_a` = Anchor unit loss = `P_a − C_a` (negative if sold below cost)
- `S_u` = Social offset per unit (estimated media value per anchor sold)
- `AR_i` = Attachment rate to upgrade i
- `M_i` = Margin dollars for upgrade i (price minus COGS)
- `U` = Anchor units sold in period

**Target:** Break-even or better on blended contribution:

`U * (L_a + S_u + Σ (AR_i * M_i)) ≥ 0`

**Social offset:** `S_u = (shares_per_unit * value_per_share) + (views_per_unit * value_per_view)`

**Guardrails:**
- Anchor loss ceiling: `|L_a| ≤ 5–10%` of average basket margin.
- Never raise `P_a`. If inputs spike, value-engineer `C_a` or increase `M_i`.

## Menu & UX Standards

- Anchor price appears **above the fold** on web and **top-left** of in-store menu.
- Price in **largest type** on the page; benefit line ≤ 10 words.
- Upgrades presented as **buttons/chips** directly below anchor, not a separate page.
- Default selection pre-highlights Slot 1 "Sane add-on."
- Mobile: sticky footer with Anchor + Slot 1 bundle CTA.

## Media Engine: Virality as COGS

### Content Formats
- 5–12s shock-price reveal (anchor).
- "Upgrade feels cheap" splitscreen (anchor vs upgrade).
- Staff POV prep montage; time-to-serve.
- Customer reactions; on-screen price.

### Weekly Cadence
Mon: Anchor reveal | Tue: Slot-1 benefit | Wed: Staff POV | Thu: Bundle demo | Fri: Anchor vs Upgrade split | Sat: Novelty slot | Sun: UGC feature

### Measurement
- Track **shares per unit** and **views per unit**; feed into `S_u`.
- UGC submission rate as percent of in-store traffic.

## Category Adaptations

**Local services:**
- Home painting: Anchor = $49 color consult; Slot-1 = $149 room sample patch; Slot-2 = $399 room refresh; Slot-3 = seasonal exterior spot-fix.
- Head spa / wellness: Anchor = $19 scalp scan; Slot-1 = $39 targeted booster; Slot-2 = $95 ritual upgrade; Slot-3 = seasonal scent/novelty.
- MSP / IT: Anchor = free 10-min downtime audit; Slot-1 = $149 risk report; Slot-2 = $490 incident drill; Slot-3 = pilot continuity device for 30 days.

**B2B SaaS:**
- Anchor = forever-free feature with visible quota; Slot-1 = $9 seat expansion; Slot-2 = $39 pro analytics; Slot-3 = $99 governance pack.

## Scripts & Microcopy

- Anchor headline: "$19 Scalp Scan. We eat the cost so you don't eat the doubt."
- Upgrade nudge: "Most people add [Slot-1] for [benefit] — still under $X."
- Staff script (10s): "We keep [anchor] at [price] forever. Most guests add [Slot-1] to see the full effect. Want me to add it?"
- UGC prompt: "Film your reaction to the price tag. Tag us; we comp the upgrade each week."

## 30/60/90 Implementation

**Day 0–30:** Choose anchor; model L_a, S_u with conservative CPM. Design menu and landing; shoot 6 anchor creatives. Procure inputs; pre-portion; staff training.

**Day 31–60:** Launch anchor everywhere simultaneously. Daily standup on AR and shares/unit. Add Slot-1 variant; start bundles.

**Day 61–90:** Lock supplier terms based on run rate. Spin novelty slot; roll to additional geos. Publish case study; roll learnings into brand system.

## Governance

- **Do not move the anchor.** Price is a promise.
- If margin compression: 1) re-engineer COGS, 2) add new Slot-1 upgrade, 3) adjust bundles, 4) intensify UGC to raise S_u.
- Quarterly: kill low-attachment upgrades; double down on top two.

## JSON Blueprint

```json
{
  "anchor": {
    "name": "",
    "price": 0.00,
    "cogs": 0.00,
    "promise": "",
    "evergreen": true
  },
  "upgrades": [
    {"name": "", "price": 0.00, "cogs": 0.00, "position": 1, "benefit": "", "target_attachment_rate": 0.35},
    {"name": "", "price": 0.00, "cogs": 0.00, "position": 2, "benefit": "", "target_attachment_rate": 0.18},
    {"name": "", "price": 0.00, "cogs": 0.00, "position": 3, "benefit": "", "target_attachment_rate": 0.10}
  ],
  "bundles": [
    {"name": "Anchor + Slot-1", "discount_pct": 0.06}
  ],
  "media": {
    "cadence_per_week": 7,
    "ugc_incentive": "Weekly upgrade comp",
    "kpis": ["shares_per_unit", "views_per_unit"]
  },
  "metrics": {
    "north_star": "blended_contribution_non_negative",
    "track": ["anchor_units", "attachment_rate_s1", "basket_size", "cac_delta", "ltv_anchor_cohort"]
  },
  "guardrails": {
    "do_not_raise_anchor": true,
    "anchor_loss_ceiling_pct_of_basket": 0.10
  }
}
```

## Risk Register

- **Platform throttles price-shock content** → diversify formats; lean into staff POV and community features; boost top UGC with small paid.
- **Input cost spike** → value-engineer COGS; increase Slot-1 margin; renegotiate supply; deploy bundles.
- **Perceived low quality at low price** → show quality rituals; time-to-serve shots; customer testimonials.
- **Competitor copies anchor** → differentiate with upgrade design, novelty slot cadence, and better UGC engine.

View saved version →

---
name: humanize
description: Rewrite AI-drafted text into the user's authentic voice using a saved voice profile and a 23-pattern editing framework. Use when the user asks to humanize, de-AI, remove generic model phrasing, vary rhythm, or make a draft sound like them. A voice profile from the voice-profiler skill is strongly recommended. This is a voice-fidelity workflow, not a detector-evasion tool.
---

# Humanize — AI Pattern Interrupter

> **READ FIRST — voice profile strongly recommended.** Check for an attached or approved local voice profile before rewriting. If none exists, ask whether to continue with a generic edit or invoke `voice-profiler` first.

You are a writing pattern interrupter. Your job is to identify generic model habits, then rewrite the text in the user's authentic voice using evidence from their voice profile.

This workflow improves voice fidelity and removes common generic-model patterns. Do not optimize for, predict, or guarantee the result of any AI classifier.

## Voice Profile Loading

Before rewriting, load the user's voice profile from the evidence the current surface can actually access:

1. Prefer an attached or explicitly provided `voice-profile.md`.
2. In Codex with local file access, check `./.8gnc/voice-profile.md`, then `./voice-profile.md`.
3. Check `~/.config/8gnc/voice-profile.md` only when the user has approved a persistent personal profile.
4. If none is found, offer `voice-profiler` or continue with a clearly labeled generic edit at the user's choice.

Parse the profile for: core identity, sentence rhythm, opening/closing patterns, vocabulary preferences, banned words, persuasion style, writing samples, and any platform-specific overrides.

The voice profile is the difference between generic "humanized" text and text that sounds like YOU wrote it. The voice profile must be built from the user's OWN writing samples — never reuse someone else's profile; output will sound like the wrong person.

## Input

Use the text supplied in the user's request. If the user says "last," operate on the last substantial text block produced in the conversation.

## Step 1: ANALYZE — Score Generic Model Patterns

Evaluate the input against every pattern below. Score each 0-3:
- **0** = Not present (already human-sounding)
- **1** = Mild (slight AI pattern)
- **2** = Moderate (clearly AI-patterned)
- **3** = Strong (textbook AI output)

### Tier 1 — Statistical Patterns
These are foundational writing signals that often make generated prose feel safe, uniform, and unlike the named author.

| # | Pattern | What to inspect | Score 0-3 |
|---|---------|-------------------|-----------|
| 1.1 | **Low perplexity** | AI picks the most statistically probable next word. Text reads as "safe" and predictable. No surprising vocabulary choices. | |
| 1.2 | **Low burstiness** | Uniform sentence lengths. AI writes 15-20 word sentences consistently. No short punches followed by long expansions. | |
| 1.3 | **Limited semantic diversity** | Same vocabulary recycled across paragraphs. Synonyms cluster around common words. | |
| 1.4 | **Smooth token probability** | No jarring word choices. Every word flows into the next with high probability. Human writing has "spikes" — unexpected words that fit contextually but aren't statistically obvious. | |

### Tier 2 — Composition Patterns
These patterns appear in phrasing, structure, and emphasis. Score how strongly each one makes the draft sound generic or unlike the user's samples.

| # | Pattern | What to inspect | Score 0-3 |
|---|---------|-------------------|-----------|
| 2.1 | **Structural uniformity** | Introduction → supporting points → conclusion. Parallel sentence structures. Predictable argument flow. | |
| 2.2 | **Hedging and qualification** | "It's important to note," "While there are many factors," "It's worth mentioning." AI never commits — it always leaves itself an out. | |
| 2.3 | **Generic abstraction** | Smoothing specific facts into general statements. "Many businesses struggle with online presence" instead of naming the actual problem. | |
| 2.4 | **Mechanical transitions** | "Furthermore," "Additionally," "Moreover," "In addition," "That said," "On the other hand." Formulaic paragraph bridges. | |
| 2.5 | **Emotional flattening** | Neutral, even tone throughout. No personality peaks or valleys. No frustration, no humor, no edge. | |
| 2.6 | **Over-completeness** | Covering every angle of a topic. Leaving nothing unsaid. AI is thorough to a fault — it answers questions nobody asked. | |
| 2.7 | **List-heavy structure** | Defaulting to bullet points and numbered lists instead of prose. Using headers as crutches. | |
| 2.8 | **Preamble and summary** | Opening with "Great question!" or restating what was asked. Closing with a summary of what was just said. | |
| 2.9 | **Significance inflation** | "Stands as a testament," "played a pivotal/crucial/key role," "reflects broader trends," "setting the stage for," "underscores its importance." AI inflates importance of everything — even mundane details get legacy language. | |
| 2.10 | **Superficial -ing clauses** | Present participle phrases tacked onto sentences as filler analysis: "highlighting its importance," "fostering growth," "showcasing expertise," "emphasizing commitment to," "ensuring quality." | |
| 2.11 | **Copulative avoidance** | "Serves as" instead of "is." "Features" instead of "has." "Holds the distinction of being" instead of "is." AI avoids simple verbs (is/are/has) and replaces them with inflated alternatives. | |
| 2.12 | **Rule of three** | Formulaic tricola: "adjective, adjective, and adjective" or "short phrase, short phrase, and short phrase." AI overuses three-part lists to make thin analyses seem comprehensive. | |
| 2.13 | **Elegant variation** | Strained synonym cycling to avoid repeating words. AI calls the same thing "the platform," "the tool," "the solution" in consecutive sentences because repetition-penalty code discourages reuse. Just say the word again. | |
| 2.14 | **Negative parallelisms** | "Not just X, but also Y." "It's not about X — it's about Y." AI uses these as a structural crutch to seem insightful. Repetition makes the structure feel templated. | |

### Tier 3 — Document-Level Signals
These emerge across the full document and often matter more to voice fidelity than any single sentence-level edit.

| # | Pattern | What to inspect | Score 0-3 |
|---|---------|-------------------|-----------|
| 3.1 | **Consistent register** | Same formality level from start to finish. No shifts between casual and technical. | |
| 3.2 | **Balanced paragraph length** | ~3-5 sentences per paragraph, uniformly distributed. Human writing is lumpy. | |
| 3.3 | **Perfect grammar** | No fragments. No run-ons. No bent rules. AI writes clean. Humans write messy — on purpose. | |
| 3.4 | **Absence of voice** | No idiosyncratic phrases, no personal rhythm, no identifiable author. Could have been written by anyone. | |
| 3.5 | **Symmetrical structure** | Equal weight given to each section/point. Humans emphasize unevenly — they dwell on what matters to them and skip what doesn't. | |

## Step 2: REPORT — Show the Score

Calculate the aggregate score:
- **Max possible**: 69 (23 patterns x 3)
- **Aggregate**: sum of all scores
- **Percentage**: aggregate / 69

Display a compact report:

```
PATTERN ANALYSIS
────────────────
Tier 1 (Statistical):  [score]/12  — [brief note on worst offenders]
Tier 2 (Composition):   [score]/42  — [brief note on worst offenders]
Tier 3 (Document):     [score]/15  — [brief note on worst offenders]
────────────────
Total: [score]/69 ([percentage]%)
Mode:  [SURGICAL | MODERATE | FULL REWRITE]
```

**Mode thresholds:**
- 0-15% → **SURGICAL** — Touch only flagged sentences. Preserve original structure.
- 16-50% → **MODERATE** — Rewrite flagged sections. Adjust structure and transitions.
- 51%+ → **FULL REWRITE** — Rebuild from scratch. Keep only the core argument/message.

## Step 3: REWRITE — Apply Voice Profile

Load the user's voice profile through the evidence boundary above and apply it systematically:

### Voice Profile Application

1. **Core identity** — Adopt the persona described in the profile. Every sentence should sound like it could only come from this person.
2. **Sentence rhythm** — Match the cadence patterns defined in the profile (e.g., short-long-short, fragments for emphasis).
3. **Opening pattern** — Use the opening style from the profile (cold opens, warm opens, hook patterns).
4. **Closing pattern** — Use the closing style from the profile.
5. **Vocabulary** — Reach for the words listed in the profile's "words I use" section. Avoid every word in the "words I never use" section.
6. **Persuasion style** — Apply the persuasion model from the profile (diagnosis, storytelling, data-first, etc.).
7. **Writing samples** — Use the real writing samples in the profile as the gold standard. When in doubt, make it sound more like those samples.

### Pattern-Breaking Rules

Apply these transformations based on which patterns scored highest:

**For low perplexity (1.1):**
- Replace predictable word choices with the user's vocabulary from their profile
- Insert unexpected but contextually fitting words
- Break cliche phrases — if you've heard it before, rewrite it

**For low burstiness (1.2):**
- Vary sentence lengths dramatically. Mix 3-word fragments with 25-word explanations.
- Add one-sentence paragraphs
- Break a long sentence into a fragment + expansion

**For limited semantic diversity (1.3):**
- Use the register shifts from the voice profile
- Replace repeated words with different framing, not just synonyms

**For smooth token probability (1.4):**
- Insert the user's idiosyncratic phrases from their profile
- Use dashes — like this — instead of commas for parenthetical thoughts
- Start a sentence with "And" or "But" occasionally

**For structural uniformity (2.1):**
- Lead with the strongest point, not the introduction
- Put the punchline first, not last
- Skip the conclusion if the last point already lands

**For hedging (2.2):**
- Delete every hedge. State it. Commit.
- Replace "It's worth noting that X" with just "X."
- Replace "There are several factors to consider" with the actual factors

**For generic abstraction (2.3):**
- Name the specific thing. Not "many businesses" — name the actual symptom.
- Replace abstractions with concrete examples

**For mechanical transitions (2.4):**
- Delete "Furthermore," "Additionally," "Moreover" entirely
- Use line breaks and dashes instead
- Or just start the next thought. No bridge needed.

**For emotional flattening (2.5):**
- Add the user's edge from their profile: blunt observations, humor, frustration, whatever their voice carries
- Vary the emotional register throughout the piece

**For over-completeness (2.6):**
- Cut anything that doesn't earn its place. Brevity wins.
- If a point is obvious, delete it
- Stop when the message lands. Don't keep talking.

**For list-heavy structure (2.7):**
- Convert bullets to prose where possible
- If lists stay, make them short (3 items max) and punchy

**For preamble/summary (2.8):**
- Delete the first paragraph if it's setup. Start where the substance starts.
- Delete the last paragraph if it's a summary. The reader was there — they don't need a recap.

**For significance inflation (2.9):**
- Delete every sentence that claims something is "pivotal," "crucial," "a testament to," or "setting the stage for." If the importance isn't obvious from the facts, the facts aren't strong enough.
- Replace legacy language with specifics: not "played a key role in shaping" — state what they actually did.
- If you catch yourself writing "reflects broader trends" — delete the sentence. It says nothing.

**For superficial -ing clauses (2.10):**
- Delete every trailing "-ing" clause that restates what was already said: "highlighting its importance," "showcasing their expertise," "emphasizing the need for."
- These are AI filler. The sentence is stronger without them. Every time.

**For copulative avoidance (2.11):**
- Replace "serves as" with "is." Replace "features" with "has." Replace "boasts" with "has."
- AI inflates simple verbs. Humans use plain ones. "That's your homepage" not "That serves as your digital storefront."

**For rule of three (2.12):**
- If you wrote "X, Y, and Z" — do you actually need all three? Often two is enough. Sometimes one.
- Break tricola by making the list asymmetric: one item gets a sentence, the others get a phrase.

**For elegant variation (2.13):**
- If you mean "website" three times, say "website" three times. Don't cycle through "digital presence," "online platform," and "web property."
- Repetition is human. Forced synonym cycling is the machine.

**For negative parallelisms (2.14):**
- Delete "not just X, but also Y" constructions. Pick whichever half is the real point and say that.
- "It's not about X — it's about Y" is a crutch. Just say what it's about.

**For consistent register (3.1):**
- Shift tone at least once: casual → technical → direct, or any combination from the voice profile

**For balanced paragraphs (3.2):**
- Make at least one 1-sentence paragraph and one 4+ sentence paragraph
- Uneven is human

**For perfect grammar (3.3):**
- Add deliberate fragments. "Not a chance." "The real problem." "Done."
- Start a sentence with a conjunction occasionally

**For absence of voice (3.4):**
- Apply the full voice profile. Every sentence should sound like it could only come from this person.

**For symmetrical structure (3.5):**
- Spend more words on what matters most. Skim past the obvious.

## Step 4: OUTPUT

Present the rewritten text cleanly. Then show a brief before/after:

```
REWRITE COMPLETE
────────────────
Original score: [X]/69 ([Y]%)
Estimated new score: [X]/69 ([Y]%)
Patterns changed: [list the ones that changed significantly]
Mode applied: [SURGICAL | MODERATE | FULL REWRITE]
Voice profile: [name from profile or "default"]
```

The estimated new score is an editorial assessment of the 23 visible patterns, not a classifier prediction or guarantee.

## When NOT to Use

- Not for Instagram captions — `humanize-ig` carries the IG-specific voice rules (lowercase, one dense block, imperfect grammar).
- Not for building or updating a voice profile — that's `voice-profiler`; this skill only consumes the profile.
- Not for drafting new content from scratch — it rewrites existing AI-patterned text. Draft first, then humanize.
- Not for detector evasion or classifier guarantees. Offer a voice-fidelity edit instead.

## Important Notes

- This is about ensuring AI-assisted professional writing carries YOUR authentic voice.
- The voice profile is built from YOUR real writing. The goal is authenticity, not evasion.
- When in doubt, make it sound more like the writing samples in your voice profile. Those are the gold standard.
- If asked, describe the edit honestly as an AI-assisted voice revision.
- If no voice profile is loaded, you can still remove generic-model patterns, but the output will not be personalized. The voice profile is what makes this skill useful.

View saved version →

---
name: humanize-ig
description: Rewrite text as an Instagram-native caption using compact phrasing, intentional lowercase, varied rhythm, and the user's approved voice profile. Use when the user asks to humanize an Instagram caption, remove generic model phrasing, or make a caption sound like they typed it on their phone. This is a voice-fidelity workflow, not a detector-evasion tool.
---

# Humanize IG — Instagram Voice Interrupter

> **READ FIRST — voice profile recommended.** Check for an attached or approved local voice profile. If none exists, mention once that the edit will use a generic Instagram voice and offer `voice-profiler` for personalized output.

You are a writing pattern interrupter optimized for Instagram captions. Your job is to take AI-generated text and rewrite it so it reads like a real human typed it on their phone for an Instagram post.

This is the Instagram-specific sibling of `humanize`. It uses the same editing framework with a different output voice and makes no classifier prediction or guarantee.

## Voice Profile Loading

Before rewriting, check for an attached `voice-profile.md`. In Codex with local file access, check `./.8gnc/voice-profile.md`, then `./voice-profile.md`; check `~/.config/8gnc/voice-profile.md` only when the user approved a persistent personal profile.

If found, load any Instagram-specific overrides from the "Platform Overrides" section. The IG voice rules below are non-negotiable — they override general voice profile settings — but the profile's vocabulary, identity, and emotional range still apply.

If no profile exists, the skill still works — it just won't carry your personal fingerprint.

## Input

Use the text supplied in the user's request. If the user says "last," operate on the last substantial text block produced in the conversation.

## Step 1: ANALYZE — Score AI Patterns

This skill uses the same 23-pattern editing framework as `humanize` (Tier 1: statistical, Tier 2: composition, Tier 3: document-level). The rules under "Pattern-Breaking for IG Specifically" below are the IG-specific deltas. A skill invocation does not load sibling skill files automatically, so the pattern names live here too — score each 0-3 standalone:

- **Tier 1 — Statistical (max 12):** low perplexity, low burstiness, limited semantic diversity, smooth token probability
- **Tier 2 — Composition (max 42):** structural uniformity, hedging, generic abstraction, mechanical transitions, emotional flattening, over-completeness, list-heavy structure, preamble/summary, significance inflation, superficial -ing clauses, copulative avoidance, rule of three, elegant variation, negative parallelisms
- **Tier 3 — Document-Level (max 15):** consistent register, balanced paragraph length, perfect grammar, absence of voice, symmetrical structure

## Step 2: REPORT — Show the Score

```
PATTERN ANALYSIS (IG MODE)
────────────────
Tier 1 (Statistical):  [score]/12
Tier 2 (Composition):   [score]/42
Tier 3 (Document):     [score]/15
────────────────
Total: [score]/69 ([percentage]%)
Mode:  [SURGICAL | MODERATE | FULL REWRITE]
```

Use the same mode thresholds as `humanize`:
- 0-15% → SURGICAL
- 16-50% → MODERATE
- 51%+ → FULL REWRITE

## Step 3: REWRITE — Apply Instagram Voice

### The IG Voice Rules

These are non-negotiable. Every single one gets applied.

**1. Lowercase everything except the first word of the entire caption.**
- First word capitalized. Everything else lowercase. Including after periods.
- Proper nouns stay lowercase unless it looks weird (brand names can keep caps if needed).
- Example: `Brand strategy isn't the logo. its the thing underneath that nobody sees.`

**2. No em dashes. Ever.**
- Replace every em dash (—) with a period, comma, or just smash the thoughts together.
- "That's what brand strategy is — the structure underneath" becomes "thats what brand strategy is. the structure underneath"

**3. One paragraph. No line breaks in the body.**
- The entire caption body is ONE block of text. No paragraph breaks. No line-per-thought formatting.
- Sentences flow together separated by periods, commas, or run-ons.
- The ONLY line break in the entire caption is before the hashtags at the end.
- This is the single biggest difference from LinkedIn. LinkedIn = vertical. IG = dense block.
- Front-load the hook since Instagram truncates after 2 lines.

**4. Imperfect grammar is mandatory.**
- Drop apostrophes sometimes: "dont", "its", "thats", "youre", "cant"
- Sentence fragments are good. Incomplete thoughts are good.
- Start sentences with "and" or "but" freely.
- Run-on sentences connected with "and" instead of periods.
- Occasional comma splice is fine.

**5. Shortened phrasing and abbreviations.**
- "something" → "smth" (sparingly)
- "because" → "bc" or "cause"
- "to be honest" → "tbh"
- "in my opinion" → "imo"
- "I don't know" → "idk"
- "about" → "abt" (sparingly)
- Don't overdo it. 2-3 abbreviations per caption max. It should feel natural, not like a text from a teenager.

**6. Contractions always. Formal phrasing never.**
- "do not" → "dont"
- "it is" → "its"
- "that is" → "thats"
- "you are" → "youre"
- Even drop the contraction sometimes and just abbreviate: "would have" → "wouldve" or "would've"

**7. No transition words.**
- Delete: furthermore, additionally, moreover, however, in addition, that said, on the other hand
- Just start the next thought. Instagram readers don't need bridges.

**8. No hedging. No qualifiers.**
- Delete: "it's important to note," "it's worth mentioning," "there are many factors"
- State it or don't. No softening.

**9. Hashtags go at the end, separated by a line break.**
- 4-8 hashtags max. Mix niche + broad.
- All lowercase.
- No hashtags in the body of the caption.

**10. End with something that sounds like talking, not writing.**
- "your brand should work the same way" not "In conclusion, your brand strategy should mirror this approach"
- End on a statement, a short question, or a call to thought. Not a summary.

### Pattern-Breaking for IG Specifically

On top of the standard pattern-breaking rules from `humanize`, apply these IG-specific overrides:

**Perplexity (1.1):** Use casual word choices. "wild" instead of "remarkable." "honestly" as a sentence starter. Throw in one unexpected word that fits the vibe.

**Burstiness (1.2):** Mix 3-word fragments with one longer run-on sentence. Instagram rewards rhythm. short. short. then a longer one that breathes a little and gives context.

**Structural uniformity (2.1):** No intro-body-conclusion structure. Start in the middle of the thought. End when it lands.

**Emotional flattening (2.5):** IG is personal. Add a moment of real feeling. Humor, frustration, vulnerability. One human moment per caption minimum.

**Over-completeness (2.6):** Cut ruthlessly. IG captions should feel like you stopped typing because you made your point, not because you ran out of things to say.

**Perfect grammar (3.3):** This is where IG voice shines. Imperfect grammar IS the signal. Fragments, missing apostrophes, comma splices, run-ons. All intentional.

### What the Output Should Feel Like

It should read like someone who knows exactly what they're talking about but typed it out quickly on their phone between meetings. Smart but not polished. Intentional but not overthought.

**Good IG voice:**
```
Nobody talks about this but the best brands dont actually have the best product. they just made a decision and stuck with it long enough that people started believing it. thats it. thats the whole game. pick a lane, say no to everything else, and let time do the compounding. most people cant sit with that bc it feels like youre leaving money on the table but youre not. youre building the table.

#brandstrategy #branding #marketingstrategy #builddifferent
```

**Bad IG voice (too LinkedIn):**
```
Nobody talks about this — but the best brands don't actually have the best product.

They just made a decision and stuck with it long enough that people started believing it.

That's it. That's the whole game.

Pick a lane, say no to everything else, and let time do the compounding.
```

The bad version has line breaks after every sentence, em dashes, proper capitalization, and perfect punctuation. It reads like LinkedIn poetry, not Instagram.

## When NOT to Use

- Not for LinkedIn, email, or any surface where proper capitalization and line breaks belong — use `humanize` and the profile's platform overrides.
- Not for long-form writing — one dense block and dropped apostrophes fall apart past caption length.
- Not for building a voice profile — that's `voice-profiler`.
- Not for client-facing professional copy where imperfect grammar reads as sloppy instead of human.

## Step 4: OUTPUT

Present the rewritten caption cleanly. Then show the brief report:

```
REWRITE COMPLETE (IG MODE)
────────────────
Original score: [X]/69 ([Y]%)
Estimated new score: [X]/69 ([Y]%)
Patterns changed: [list the ones that changed significantly]
Mode applied: [SURGICAL | MODERATE | FULL REWRITE]
Voice profile: [loaded / not found]
```

## Important Notes

- This is about making AI-assisted writing sound like YOUR actual Instagram voice. Authenticity, not evasion.
- The imperfect grammar is intentional and strategic when it matches the user's real Instagram voice.
- When in doubt, read it out loud. If it sounds like someone talking to a friend about their work, you nailed it.
- If asked, describe the edit honestly as an AI-assisted voice revision.
- Keep captions under 2200 characters (Instagram's limit). Aim for 800-1200 for optimal engagement.

View saved version →

---
name: linkedin-authority
description: Use when creating LinkedIn posts, personal brand content, thought leadership pieces, or social media copy that needs to feel human, conversational, and memorable. Also use when analyzing or improving existing LinkedIn content. Triggers on requests for LinkedIn posts, personal branding content, thought leadership writing, or when user wants content that "sounds human" or avoids AI-sounding copy. Writes high-performing LinkedIn content using patterns extracted from viral post analysis.
---

# LinkedIn Authority — High-Performance Content Framework

Write LinkedIn posts that perform using patterns extracted from analysis of 42 high-performing posts (peak 376 likes, 104 comments). These patterns are platform-native — built from what actually works on LinkedIn, not what marketing textbooks say should work.

## Core Philosophy

Content ABOUT the work outperforms content OF the work. Meta-commentary on the platform, the struggle, the game beats polished expertise. The tension between critique and participation is the brand.

## The Five Themes (Pick One Per Post)

Every post should be a variation of one core theme:

1. **Taste > Creativity** — The editing muscle matters more than the generating muscle. Killing ideas is harder than making them.
2. **Performance > Authenticity** — "Just be yourself" is bad advice. Put on a show. Become a character. The show IS the brand.
3. **Interesting > Impressive** — Do things worth talking about. Impressive doesn't stop the scroll; interesting does.
4. **Platform as Venue** — You are the show, the algorithm is eavesdropping. Talk to humans, machines follow.
5. **Repetition IS Strategy** — Say the same 5 things 50 different ways. Consistency compounds.

## Voice & Tone

- Self-deprecating but not groveling
- Philosophical without being pretentious
- Frustrated but not bitter
- Teaching but not lecturing
- Talk TO the audience, not AT them

## Structural Patterns

### Sentence Rhythm

Short paragraphs. Single sentences as their own line. Build with fragments:

```
Not because you're not impressive.
But because impressive is not the same thing as interesting.
```

### Hook Types (Pick One)

| Type | Example | Why It Works |
|------|---------|--------------|
| Confession | "I haven't missed a single day of posting in 5 years" | Stakes + credibility |
| Counterintuitive | "The best hook I ever wrote made me feel stupid" | Curiosity through contradiction |
| Story Open | "A client once asked me to write 50 headlines" | Narrative pull |
| Direct Challenge | "Can we all stop talking about how Gen Z..." | Stakes a position |

**Avoid**: Newsletter promos as hooks, vague philosophical statements without punch.

### The 6-8 Line Rule

The real hook is usually buried 6-8 lines into your first draft. Find it. Move it up.

### Ending Patterns

- Circle back to opening with a twist
- One-line kicker that lands the point
- Self-aware CTA that doesn't feel salesy
- Question that makes reader apply it to themselves

## Content Tiers

### Tier 1: Framework Posts (Highest Engagement)

Give people a taxonomy they can apply to themselves. The "three types of creatives" pattern:

1. Name 3 types/categories in your domain
2. Describe each with clear traits
3. Add a simple self-assessment test
4. People share because they want to see which one they are

### Tier 2: Platform Vulnerability

Say what everyone's thinking about the algorithm, the game, the performance. Be honest about frustration while still playing.

### Tier 3: Contrarian Takes

"Just be yourself is the worst advice" — stake a position, but deliver it conversationally. Generate debate, not agreement.

### Tier 4: Historical/Craft Content

Builds authority, doesn't win on likes. The Club Med origin story, the first ad ever written. These compound over time.

### Tier 5: Filler (Maintain Presence)

Short algorithm quips, quick observations. Don't pretend they're more than they are.

## What NOT To Do

- Newsletter promos without standalone value
- Hooks that make you feel clever (delete them)
- Polished expertise without vulnerability
- Writing AT the audience instead of TO them
- Expecting every post to go viral (most land 8-32 likes)

## When NOT to Use

- Not for other platforms — Instagram captions go through `humanize-ig`; these patterns (vertical line breaks, framework posts) read wrong off-LinkedIn.
- Not for long-form essays or articles — this framework is built for feed posts; use `story-spine` for narrative long-form structure.
- Not for corporate or brand-account voice — these patterns assume a personal voice with vulnerability and self-deprecation; a company page can't credibly run them.
- Not for de-AI-ing existing text in your own voice — that's `humanize` with a voice profile.

## Application Checklist

Before publishing:

- [ ] Is this a variation of one of the 5 core themes?
- [ ] Does it deliver value even if no one clicks through?
- [ ] Is the hook in the first 2 lines (not buried at line 6-8)?
- [ ] Single sentences as paragraphs where it creates rhythm?
- [ ] Would I engage with this if someone else wrote it?

View saved version →

---
name: local-services-seo
description: Execute the Local Services city-by-service matrix playbook (PLAY-003). Use when building city/service landing pages, local SEO architecture, provider directories, or lead routing systems. Triggers on "city pages," "local SEO," "service area pages," "provider directory," "describe your job form," "lead routing," "round robin," "JSON-LD LocalBusiness," "city-by-service matrix," or when scaling one service across multiple metros.
---

# Local Services — City-by-Service Matrix (PLAY-003)

Pick one service, multiply it across ten cities with lean, useful pages that convert. Each page earns trust with a unique local intro, a mini directory, and a fast "Describe your job" form. Structured data makes the pages machine-readable.

## When NOT to Use

- The service is B2B or geographically agnostic. City pages add nothing when buyers don't search by city.
- Single-location business with no expansion plan. Standard local SEO — Google Business Profile, one location page, reviews — covers it without a matrix.
- You can't vet providers or route leads. Without a real directory or a working form, the pages are thin doorway pages and will read like it.

## Core Loop

1. Pick one service × ten cities with clean, consistent URLs.
2. Clone a simple page template that is actually useful at the city level.
3. Add JSON-LD so search and LLMs understand the content.
4. Ship a phone-friendly form with clear consent and round-robin routing.
5. Track submissions, provider response, and close rates. Iterate weekly.

## Principles

1. **One service, many cities.** Narrow the offer, scale the footprint.
2. **Every page useful on its own.** Unique intro plus real providers beats thin doorway pages.
3. **Human + machine readable.** Plain language on the page, JSON-LD under the hood.
4. **Consent is explicit.** Lead sharing and outreach require clear permission.
5. **Routes not silos.** Round-robin or rules-based routing keeps providers engaged and response times low.

## Information Architecture

- **Slug pattern:** `/{state}/{city-slug}/{service-slug}/`
  - Examples: `/tx/dallas/pool-cleaning/`, `/tx/plano/pool-cleaning/`
- **Canonical:** each page canonicalizes to itself.
- **Hubs:** optional `/{state}/{service-slug}/` hub that links to all cities.
- **Sitemap:** include every city page; avoid orphans.

## Page Template

**Title/H1:** "{Service} in {City}, {ST}"

**Intro (100–150 words):** seasonal context, common issues, notable neighborhoods. Write uniquely for each city.

**Mini directory:** 5–20 providers with name, phone, hours, areas served.

**CTA:** "Describe your job" form, above the fold on mobile.

**Optional adds:** embedded map, 3-bullet "How {service} works in {City}," 1–2 local FAQs, "List your business" link.

## Structured Data (JSON-LD)

### If listing providers on the page — ItemList of LocalBusiness:

```json
{
  "@context":"https://schema.org",
  "@type":"ItemList",
  "name":"Pool Cleaning in Dallas, TX",
  "itemListElement":[
    {
      "@type":"ListItem","position":1,
      "item":{
        "@type":"LocalBusiness",
        "name":"Bluefin Pool Service",
        "url":"https://example.com/bluefin",
        "telephone":"+1-214-555-0101",
        "address":{"@type":"PostalAddress","addressLocality":"Dallas","addressRegion":"TX"},
        "areaServed":"Dallas, TX",
        "openingHours":"Mo-Fr 08:00-18:00"
      }
    }
  ]
}
```

### If no providers yet — Service block:

```json
{
  "@context":"https://schema.org",
  "@type":"Service",
  "serviceType":"Pool Cleaning",
  "areaServed":{"@type":"City","name":"Dallas"},
  "providerMobility":"dynamic",
  "hasOfferCatalog":{
    "@type":"OfferCatalog",
    "name":"Pool Cleaning Services",
    "itemListElement":[
      {"@type":"Offer","name":"Weekly Cleaning"},
      {"@type":"Offer","name":"Green-to-Clean"},
      {"@type":"Offer","name":"Repair"}
    ]
  }
}
```

**Optional enhancements:** BreadcrumbList for nav context, FAQPage if real FAQs are on the page.

## "Describe Your Job" Form

**Fields:** ZIP, job type, urgency, budget range, free-text details, photos (optional), name, phone, email.

**UX:** One screen on mobile with progressive disclosure. Large inputs, numeric keypad for ZIP and budget. Inline errors. "Save and finish later" via magic code.

**Routing:** Round-robin to 3 providers per city. Throttle to avoid spamming laggards. Log: submission, provider alerts, responses, acceptance, job outcome.

**Consent line (place directly above button):**
> By submitting, you agree we may share your request with up to three providers. You consent to them contacting you at the number and email provided. Message and data rates may apply. You can opt out anytime.

## Content & SEO Guardrails

- Each city page gets a unique 100–150 word intro with real place context.
- Include a real list, map or service-area note, and "How it works here" section.
- Keep structured data valid and in sync with visible content.
- Let crawlers access pages. Avoid noindex unless stub.
- Link city pages from a hub and nav to avoid orphaning.
- Fast loads and stable layout on mobile.

## Intro Scaffold Template

"{City} summers push pools hard. Most {Neighborhood A} and {Neighborhood B} homes see algae bloom after storms, and late-fall leaf drop clogs skimmers. Our local providers handle weekly cleaning, green-to-clean recovery, and repairs. If you need same-day help, say so in the form and we will route to crews that cover {ZIP A}, {ZIP B}, and nearby."

## Category Adaptations

- **Home painting:** "Color consult in {City}, {ST}" with neighborhoods and HOA notes.
- **Plumbing:** "Emergency plumber in {City}" with after-hours flag and SLA notes.
- **Landscaping:** seasonal water restrictions and drought-tolerant options.
- **MSP / IT:** service areas by ZIP clusters, response-time windows, on-site radius.

## Metrics

**Acquisition:** page views by city, map interactions, form starts.
**Conversion:** form completions, completion rate, phone taps.
**Routing:** time to first provider view, time to first response, acceptance rate.
**Revenue:** close rate by city, average job value, lead-to-job cycle time.
**Quality:** complaint rate, opt-out rate, duplicate-lead rate.

## Ops Runbook

- Weekly: verify provider phones and hours, remove dead listings, add 2 new providers per city.
- Monthly: rotate or expand FAQs based on form submissions.
- Quarterly: recycle intros with fresh seasonal context.

## Ship Checklist

- [ ] 10 URLs with consistent slugs
- [ ] Unique 100–150 word city intro on each
- [ ] Provider list or "submit your business" placeholder
- [ ] JSON-LD added (ItemList + LocalBusiness or Service)
- [ ] Job form + consent + round-robin routing to 3 providers
- [ ] Linked from hub or nav (no orphans)
- [ ] Validated in structured-data tester and live URL inspection

View saved version →

---
name: mayhem-method-ai-use
description: Apply the Mayhem Method to AI Use for standardized AI-assisted creative production. Use when producing social posts, campaign briefs, copy blocks, or any creative output using AI workflows. Triggers on "AI workflow," "prompt chaining," "few-shot steering," "zero-shot baseline," "structured deliverable," "acceptance rubric," "campaign brief schema," "mayhem method AI," or when systematizing AI-assisted content creation for client work.
---

# Mayhem Method to AI Use (v1.0)

Standardize how Branded Mayhem uses AI to produce high-quality creative outputs fast. Start with a clear baseline, iterate with tight feedback, ground everything in brand and source context, package outputs in usable formats.

## Core Loop

1. Define the task and constraints with a zero-shot baseline.
2. Chain prompts with specific feedback to refine.
3. Provide examples to lock tone and cadence.
4. Request structured deliverables and variants.
5. Evaluate against brand criteria, then package and ship.

## Principles

1. **Clarity first.** State goal, audience, channel, format, length, constraints.
2. **Context in, quality out.** Supply source articles, brand pillars, voice rules.
3. **Iterate with purpose.** Each message adds or removes exactly one uncertainty.
4. **Examples steer style.** One good example is worth ten adjectives.
5. **Structure beats vibes.** Bullet requirements so nothing slips.
6. **Options unlock choice.** Ask for multiple hooks or formats when exploring.
7. **Ethics matter.** Avoid dark patterns, protect IP, cite when summarizing.
8. **Respect limits.** Request export-friendly output (Markdown, HTML, CSV).

## Workflow

### 3.1 Define the Task (Zero-Shot)

```
Goal: 4 social posts for {brand} during {theme}
Audience: {role}, {industry}
Tone: {voice rules}
Inputs: {link or pasted source}
Deliverable: {count}, {format}, {length}, {hashtags yes/no}, {artwork hooks}
Constraints: {regulated terms, claims, style rules}
```

### 3.2 Iterate (Prompt Chaining)

```
Keep: Post 1 structure
Change: Hook needs a stat; add 1 data point
Cut: Hashtags over 5
Add: CTA specific to {practice area}
```

### 3.3 Steer with Examples (Few-Shot)

```
Match this intro cadence:
"It's Cybersecurity Awareness Month... {short pivot}. {brand} helps {who} with {what}."
Apply that to 4 pillars: Insight, Security, Awareness, Governance.
```

### 3.4 Request Structure and Variants

```
For each post include:
- Headline (<=8 words)
- Caption (2–3 sentences)
- 3–5 hashtags
- Artwork hook (2 variants)
- 1 brand tie-in sentence using {practice area list}
```

### 3.5 Packaging

```
Output as Markdown sections per post with H2 headings. No code fences.
```

## Prompt Patterns Library

**Baseline generation:**
```
Create {n} {asset_type} for {brand}. Audience {aud}. Tone {voice}.
Each must include {elements}. Source: {link or text}.
Avoid {prohibited}. Length {limit}. Output as {format}.
```

**Refinement:**
```
Revise Post {#}: keep core idea, strengthen hook with stat,
wrap with {brand practice area}, remove jargon, keep under {char}.
```

**Few-shot steer:**
```
Mimic this style:
Example: "{sample 1}"
Example: "{sample 2}"
Now produce {n} new {assets} on {topics}.
```

**Options request:**
```
Give 3 alternate hooks for Post {#}, each in a different framing:
{authority}, {fear-to-safety}, {process reveal}.
```

**Format packaging:**
```
Return a one-page brief with:
- Objective
- Audience
- Message pillars
- 4 posts (H2)
- Asset checklist
```

## Thematic Cohesion

- Define a campaign spine with 3–4 pillars.
- Provide one sample intro to set cadence.
- Require each asset to map to a pillar and call out the mapping.

## Structured Deliverable Schemas

**Social post:**
```json
{
  "post_id": "CYA-01",
  "pillar": "Insight",
  "headline": "",
  "caption": "",
  "hashtags": [],
  "art_hooks": ["", ""],
  "brand_tie_in": ""
}
```

**Campaign brief:**
```json
{
  "objective": "",
  "audience": "",
  "pillars": ["","","",""],
  "sources": [""],
  "assets": ["posts","stories","artwork"],
  "due_date": "",
  "owner": "Branded Mayhem"
}
```

## Acceptance Rubric

Score each 1–5. Ship at 24+.

- **Clarity:** does a human get it in 3 seconds
- **Hook strength:** lead line earns the next line
- **Brand fit:** voice, claims, practice areas aligned
- **Structure:** every required element present
- **Evidence:** facts grounded when cited
- **Usability:** paste-ready, no cleanup needed

## Ship Checklist

- [ ] Task brief completed with audience, tone, constraints
- [ ] Baseline draft generated
- [ ] Few-shot examples supplied and applied
- [ ] Structured deliverable returned with all sections
- [ ] Options provided where requested
- [ ] Rubric score 24+
- [ ] Packaged in Markdown with headings
- [ ] Logged to campaign brief

## When NOT to Use

- Not for open-ended ideation — diverge first with `creative-thinking-ai`, then bring the chosen concept here for production.
- Not for making output sound like a specific person — run finished drafts through `humanize` with a voice profile.
- Not for narrative pieces — origin stories and case slices follow `story-spine`.
- Not for testing whether the creative lands — pressure-test with `ai-focus-group` before shipping.

## Limitations & Workarounds

- **Citations:** provide links or pasted passages for accurate summarization.
- **IP:** no long verbatim quotes from paywalled sources; paraphrase and attribute.
- **Sensitive claims:** require a source or soften to safe language.

View saved version →

---
name: neuro-design
description: Apply the Neuro-Design Playbook (v1.0) for psychology-driven creative direction and visual identity systems. Use when designing brand identity, campaign creative, or assets that need to encode memory and drive response. Triggers on "neuro design," "geometric reduction," "sensory branding," "red dot principle," "salient accent," "nostalgia fusion," "emotional direction," "emotional polarity," "memory encoding," "visual identity psychology," or when creative direction needs a specific psychological play for recall and response.
---

# Neuro-Design Playbook (v1.0)

Turn psychology into repeatable creative moves that drive recall and response.

## Philosophy

Reduce to signal. Repeat to encode. Polarize to be remembered. Evoke to belong.

Design is a memory game. Shape cues the brain can store in one glance or one beat, then repeat them until they feel inevitable.

## When NOT to Use

- **Audiences too diverse to share a cultural memory.** P4 Nostalgia Fusion's QA is "audience names the era in under one second" — if your markets or generations don't share the cue, you get costume-party vibes instead of belonging. Stay with P1 or P5, or skip the playbook.
- **Zero budget for creative testing.** Every play here lives or dies on its QA test and KPIs — recall tests, one-second silent tests, sentiment surveys. If you cannot run any of them, you are shipping unverified psychology and calling it strategy.
- **Rapid prototyping where shipping beats identity.** Shape libraries, audio stings, alignment grids, and stance rules are compounding assets. If the asset is disposable or the product may pivot next month, the research-backed system work slows you down for nothing.
- **The problem is pricing or flow, not memory.** This playbook encodes recall and response into creative. For offer architecture use `fairness-anchor-ladder`; for conversion flow and nudges use `ux-ui-psych`.

1. Need universal recognition fast? → **P1 Geometric Reduction**
2. Need ritual and anticipation? → **P2 Sensory Branding**
3. Need one click now? → **P3 Salient Accent (Red Dot)**
4. Need belonging through memory? → **P4 Nostalgia Fusion**
5. Need a feeling in one second? → **P5 Emotional Direction**
6. Need talk value and tribe? → **P6 Emotional Polarity**

---

## P1) Geometric Reduction

Strip visuals to simple high-contrast geometry. Use as a code system across touchpoints.

**Use when:** You need universality, control, or fast recognition across formats. Tech, platforms, uniforms, signage, safety.

**Build steps:**
1. Define 1–3 core shapes and a primary field color.
2. Set contrast rules: background fields, stroke widths, spacing grid.
3. Write the "code key" for meaning per shape.
4. Produce a micro library: SVGs, masks, motion loops, sticker sheet.
5. Publish do/don't rules for clutter, gradients, and photo use.

**Artifacts:** Shape set, usage grid, icon masks, 3 motion stingers, sticker sheet, one-page rules.

**QA:** Drawable from memory in 5 seconds. Recognizable at favicon size.

**KPIs:** Unaided logo recall, scroll-stop rate, favicon recognition test, speed of task in UI.

---

## P2) Sensory Branding

Pair a restrained visual with one or two consistent sensory cues: sound, motion, light direction, or rhythm.

**Use when:** You want ritual, anticipation, and "it feels like us" before the message lands.

**Build steps:**
1. Pick two cues max. Example: low piano chord + slow tilt-up light.
2. Lock duration, attack/decay, and start time in the edit.
3. Create a 2–4 second sting and a 10–15 second long open.
4. Document where the cue appears: openers, chapter cards, app events.
5. Add a silent variant that keeps the same rhythm and light.

**Artifacts:** Audio stings, motion overlays, light rig guide, LUT, edit macro/template.

**QA:** Cue recognized without logo. People predict what's coming.

**KPIs:** Watch-through lift when cue present, unaided cue recognition, brand-correct association in surveys.

---

## P3) Salient Accent (The Red Dot Principle)

Calm palette plus one high-salience accent that trains the eye to a single priority.

**Use when:** You need instant hierarchy across busy feeds, banners, or dashboards.

**Build steps:**
1. Define a neutral base palette.
2. Choose one accent with high salience relative to the base.
3. Assign one job to the accent: CTA, notification, key stat.
4. Write restraint rules: only one accent per frame.
5. Add accessibility rules for color vision variance.

**Artifacts:** Color spec sheet, accessibility deltas, component map showing accent use.

**QA:** If two accents appear in one frame, the rule fails.

**KPIs:** CTR lift, time-to-action, error reduction in flows.

---

## P4) Nostalgia Fusion

Use era-coded cues to unlock belonging, then pair with modern form and pace.

**Use when:** Your audience shares a cultural memory you can refresh without parody.

**Build steps:**
1. Name the memory: era, place, texture, palette, lens.
2. Pull three cues only: color, type, texture.
3. Pair with modern moves: bold scale, cropped motion stills, asymmetry.
4. Write a rule for pace: classic slow burn or short-form rhythm.
5. Build a reference board: "memory vs modern."

**Artifacts:** Palette card, texture pack, type guide, motion cut rules, reference board.

**QA:** Audience names the era in under one second without text.

**KPIs:** Saves, shares, comment mentions of the era, repeat view rate.

---

## P5) Emotional Direction

Pick one feeling and align every element to it so the emotion reads pre-verbally.

**Use when:** Product or campaign must read in under a second.

**Build steps:**
1. Choose one word: calm, defiance, desire, relief, pride, joy.
2. Set composition rules: angle, gaze, spacing, gravity.
3. Map color, type weight, texture, and motion to that word.
4. Create a diagnostic grid: does each element push the word?
5. Kill any element that is neutral or off-axis.

**Artifacts:** One-word brief, alignment grid, do/don't examples, type and motion rules.

**QA:** One-second silent test: viewers agree on the feeling without copy.

**KPIs:** Unaided emotion labeling, lift in desired action vs control.

---

## P6) Emotional Polarity

Choose an axis and take a side so the work attracts the right tribe and repels the wrong one.

**Use when:** You need memorability and word-of-mouth more than universal approval.

**Build steps:**
1. Define the axis: rebellion vs conformity, elite vs open, raw vs polished.
2. Pick a stance and write three non-negotiables.
3. Align voice, image, layout, and channels to that stance.
4. Pre-wire community safety and moderation.
5. Plan variants for markets that truly require softer takes.

**Artifacts:** Axis map, stance rules, content guardrails, moderation SOP.

**QA:** If everyone likes it, you probably missed.

**KPIs:** Sentiment split, share velocity, press pickup, inbound from the right audience.

---

## Pitfalls by Play

- **P1:** Cold tone for human-first brands. Over-sterility.
- **P2:** Too many cues. Inconsistent timing. Loudness wars.
- **P3:** Accent inflation. Reward schedules that push into manipulation.
- **P4:** Costume party vibes. Copyright look-alikes. Generational mismatch.
- **P5:** Mixed signals. Safe middle. Design by committee.
- **P6:** Performative edge. Punching down. No safety plan.

View saved version →

---
name: outreach-diagnosis
description: Diagnose cold outreach performance using kill metrics, root cause analysis, and prioritized fix plans. Use when outreach campaigns have low open rates, zero replies, poor deliverability, or any cold email/LinkedIn sequence is underperforming. Triggers on "outreach diagnosis," "email not working," "zero replies," "low open rate," "cold email audit," "outreach audit," "deliverability," "why no replies," "email warmup," "outreach kill metrics," "sequence diagnosis," or when reviewing any cold outreach campaign performance. Produces a structured diagnosis with root causes and a prioritized fix sequence.
---

# Outreach Diagnosis Framework

Structured post-mortem methodology for cold outreach campaigns. Identifies root causes, applies kill metrics, and produces a prioritized fix plan.

## When NOT to Use

- **Fewer than ~50 sends.** The kill metrics are rates, and at small sample sizes one reply or one bounce swings a rate past a threshold. This framework's own follow-up cadence re-evaluates at 40 sends — below that volume you are diagnosing noise, not a campaign.
- **Brand-new domain with zero warmup.** You already know what Check 1 will find. Warm the domain first — ramped daily volume, auth records, engagement on warmup sends — then run the diagnosis on real campaign data.
- **Outreach under active legal or compliance review.** The fix plans here optimize performance, not legal exposure. If counsel is reviewing your sends for CAN-SPAM, GDPR, or industry rules, pause and resolve that first — a better subject line does not fix a compliance problem.
- **The problem is past the inbox.** Replies that stall on calls, prospects who ghost after a proposal, deals that die in negotiation — that is conversation territory. Use `pitching-pivot` for the methodology and `sales-simulator` to practice it.

Resolve these variables:

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `campaign_name` | Campaign or sequence identifier | *required* |
| `channel` | Email / LinkedIn / Multi-channel | Email |
| `sends` | Total emails or messages sent | *required* |
| `opens` | Open count and rate | *required for email* |
| `replies` | Reply count and rate | *required* |
| `bookings` | Meetings booked | 0 |
| `time_period` | Date range of sends | *required* |
| `sender_domain` | Sending domain | *required for email* |
| `domain_age` | How long the domain has been sending | *ask* |
| `tools_used` | Outreach platform, CRM, warmup tools | *ask* |
| `sample_subjects` | 5-10 subject lines used | *ask* |
| `sample_body` | 1-2 email body examples | *helpful* |
| `target_segment` | Who was targeted (ICP, title, industry) | *ask* |

## Kill Metrics

These are non-negotiable thresholds. If any is violated, the campaign is broken and must be fixed before continuing sends.

| Metric | Target | Kill Floor | Action if Below Kill Floor |
|--------|--------|------------|---------------------------|
| Open Rate | 50%+ | 30% | **Stop sending.** Deliverability or subject line problem. |
| Reply Rate | 5%+ | 2% | **Pause and diagnose.** Message or targeting problem. |
| Bounce Rate | <2% | 5% | **Stop sending.** List quality problem. |
| Unsubscribe Rate | <1% | 2% | **Pause.** Targeting or frequency problem. |
| Spam Complaint | <0.1% | 0.3% | **Stop immediately.** Domain reputation at risk. |

## Diagnosis Protocol

Run these checks in order. Each produces findings that feed the fix plan.

### Check 1: Deliverability

**Is the email reaching the inbox?**

- Domain warmup status: Has the sending domain been warmed? How many emails/day before campaign?
- SPF/DKIM/DMARC: Are authentication records configured?
- Sending volume: How many emails per day? Ramp pattern?
- Sending pattern: Spacing between sends? All same time or distributed?
- Blacklist check: Is the domain or IP on any blocklists?
- Reply rate on warmup emails: Were warmup emails getting engagement?

**Red flags:**
- New domain with no warmup → emails go to spam
- More than 50 sends/day from a new domain
- All sends in a single batch within minutes
- No SPF/DKIM records

### Check 2: Subject Lines

**Would you open this?**

Evaluate subject lines against these filters:
- **Spam trigger words:** "free," "guarantee," "act now," "limited time," "vs.," "what's hiding"
- **Pattern repetition:** Are multiple subjects using the same formula?
- **Personalization:** Does the subject reference the recipient's company or situation?
- **Length:** 4-7 words optimal. Over 10 words = lower open rates.
- **Curiosity vs. clarity:** Best subjects create a gap the recipient wants to close.

**Banned patterns:**
- "{Company} vs. {anything}" — triggers spam filters
- Any subject that reads like a marketing email, not a human one
- Manipulative or fear-based framing ("what's hiding," "you're losing")
- Generic curiosity bait with no specificity

**Good subject frameworks:**
- Question about their specific situation: "Quick question about [their recent initiative]"
- Observation: "Noticed [specific thing] on your site"
- Referral/connection: "[Mutual connection] suggested I reach out"
- Direct value: "[Specific result] for [their industry]"

### Check 3: Targeting

**Are these the right people?**

- ICP match: Do the recipients match the ideal customer profile?
- Title accuracy: Are you reaching decision-makers or gatekeepers?
- Company fit: Right size, stage, and industry?
- Timing: Any reason this is bad timing (holidays, industry cycles, fiscal year)?
- Same-company collision: Are multiple people at the same company getting emails in the same batch?

**Red flags:**
- No ICP scoring on the list
- Multiple contacts at same company in same wave
- Titles that cannot make purchasing decisions
- Companies outside the service area or budget range

### Check 4: Message Quality

**Does the email earn a reply?**

- **Opening line:** Does it reference something specific about the recipient? Generic = delete.
- **Value proposition:** Is the offer clear in under 15 words?
- **Social proof:** Any evidence this works? (Client results, case reference)
- **Call to action:** Is the ask low-friction? (Question, not "book a call")
- **Length:** Under 100 words for cold email. Under 150 for follow-up.
- **Tone:** Does it sound like a human or a marketing automation?

**Recommended outreach structure:**
1. **Signal** — what you noticed about their business (specific, researched)
2. **Tension** — the gap or problem that creates (not fear-based, not condescending)
3. **Offer** — what you can do about it (one sentence)
4. **Sign-off** — low-pressure close (question, not demand)

### Check 5: Sequence Architecture

**Is the follow-up strategy sound?**

- Number of touches: 3-5 for cold, 5-7 for warm
- Spacing: 3-5 days between touches minimum
- Escalation: Does each touch add new value or just "checking in"?
- Channel mix: Email only or email + LinkedIn + other?
- Exit criteria: When does a non-responder get removed?

## Output Format

```markdown
# Outreach Diagnosis — [Campaign Name]
Date: [date]
Period analyzed: [date range]

## Numbers

| Metric | Actual | Target | Kill Floor | Status |
|--------|--------|--------|------------|--------|
| Sent | [n] | — | — | — |
| Opened | [n] ([%]) | 50% | 30% | [OK/WARN/KILL] |
| Replied | [n] ([%]) | 5% | 2% | [OK/WARN/KILL] |
| Bounced | [n] ([%]) | <2% | 5% | [OK/WARN/KILL] |
| Bookings | [n] | — | — | — |

## Root Causes (ranked by severity)

### 1. [Root Cause Title]
**Evidence:** [What data shows this]
**Impact:** Critical / High / Medium
**Fix:** [Specific action]

### 2. [Root Cause Title]
**Evidence:** [What data shows this]
**Impact:** Critical / High / Medium
**Fix:** [Specific action]

[Continue for all identified causes]

## Fix Plan (prioritized)

| # | Fix | Effort | Impact | Timeline |
|---|-----|--------|--------|----------|
| 1 | [Action] | [Low/Med/High] | [Critical/High/Med] | [When] |
| 2 | [Action] | [Low/Med/High] | [Critical/High/Med] | [When] |

## Recommended Sequence

1. [First action — usually "pause sends"]
2. [Infrastructure fix — warmup, auth, etc.]
3. [Content fix — subjects, body, targeting]
4. [Resume with controls — A/B batches, velocity caps]
5. [Evaluate at N sends — which framework wins]

## What Is Working
[Identify anything that IS working — architecture, tooling, data quality — so it does not get broken during fixes]
```

## Common Diagnosis Patterns

| Symptom | Likely Root Cause | First Fix |
|---------|------------------|-----------|
| 0% open rate | Deliverability — spam folder | Domain warmup + auth records |
| Opens but 0% reply | Message quality or targeting | Rewrite with Signal-Tension-Offer structure |
| High bounce rate | Bad list data | Re-verify with email validation tool |
| Opens + replies but no bookings | CTA too aggressive or offer unclear | Soften to question-based CTA |
| Declining open rates over time | Domain reputation degrading | Pause, warm, reduce velocity |
| High unsubscribe | Wrong audience or too frequent | Tighten ICP filter, increase spacing |

## Follow-Up

After fixes are implemented, re-run this diagnosis at 40 sends to evaluate improvement. Compare metrics against the original baseline to measure impact.

View saved version →

---
name: pitching-pivot
description: Apply the Pitching Pivot technique for value-based sales conversations. Use when preparing for sales calls, handling pricing objections, reframing commodity requests into strategic engagements, or coaching on consultative selling. Triggers on "pivot technique," "value-based pricing," "objection handling," "too expensive," "price objection," "how to close," "sales prep," "upsell without upselling," "reframe the conversation," "they only want a website," "client wants a logo," or when a prospect is asking for a commodity service and you need to shift the conversation to strategic value.
---

# Pitching Pivot Technique

Stop selling, start serving. Whoever asks more questions controls the conversation. When the client says the value out loud, they close themselves.

## Core Principle

When a client asks for a specific service (e.g., "I need a website"), do not quote the service. Pivot by asking about their bigger goals. The price gap between the commodity ask and the strategic offer is small, but the value leap is massive.

## When NOT to Use

- **Locked-budget RFPs where price is already decided.** A committee scoring line items against a fixed budget cannot be reframed by discovery questions — the frame was set before you arrived. Decide whether to bid the spec or walk; do not burn the pivot on a buyer who cannot reopen the conversation.
- **Pure commodity sales with no value-reframing room.** The pivot works because the output serves a bigger outcome. If the outcome genuinely is the output — a buyer who needs exactly the thing, at spec, with zero strategic upside — Step 2's question dead-ends and you sound evasive instead of consultative.
- **Emergency procurement with no discovery window.** The framework requires at least 3 questions before any solution and a discovery call before any proposal. A buyer in a same-day emergency has no window for either. Quote it, deliver it, and run the pivot on the next engagement.
- **Practice, not principles.** To drill this technique against realistic buyers with scoring, use `sales-simulator` — it trains exactly this framework. And if the problem is upstream — cold emails getting no replies, so there is no conversation to pivot — that is `outreach-diagnosis`.

Determine the mode:

| Mode | When | Output |
|------|------|--------|
| `prep` | Before a sales call or meeting | Pivot script with anticipated objections and reframes |
| `roleplay` | Practice run — you play the prospect | Interactive sales simulation with feedback |
| `debrief` | After a call that did not close | Diagnosis of where the pivot failed + recovery plan |
| `coach` | General sales methodology guidance | Principles and techniques with examples |

Resolve these variables:

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `prospect_name` | Company or individual | *required for prep/debrief* |
| `commodity_ask` | What they initially requested | *required* |
| `industry` | Their sector | *helpful* |
| `known_budget` | Any budget signals | None |
| `prior_context` | How they found you, what they have said so far | None |

## The Pivot Framework

### Step 1: Receive the Commodity Ask

The prospect says something like:
- "We need a new website"
- "How much for a logo?"
- "Can you redesign our social media?"
- "We need SEO help"

**Do not answer with a price.** Do not even answer with a range. The moment you quote a commodity, you are a commodity.

### Step 2: Acknowledge and Pivot

Use this pattern:

> "I can absolutely help with that. Before I give you a number, can I ask — what is the website (or logo, or SEO) supposed to do for your business?"

The pivot question format: **"What is [their ask] supposed to do for [their business]?"**

This forces the prospect to articulate the outcome, not the output.

### Step 3: Go Deeper with Follow-Up Questions

Each answer reveals a deeper need. Keep asking:

- "What happens if that works? What does that look like for your revenue?"
- "What have you tried before? What did not work?"
- "If we solve this, what is the next problem you would tackle?"
- "Who else is involved in this decision?"
- "What does success look like in 6 months?"

**Rule:** Ask at least 3 questions before presenting any solution. The prospect should be talking 70% of the time.

### Step 4: Let Them State the Value

When the prospect says something like:
- "If we could get 20 more leads a month, that is worth $50K to us"
- "We are losing deals because our brand looks amateur"
- "Our competitors are getting all the search traffic"

They have just told you the ROI. Now your price is a percentage of their stated value, not a line item.

### Step 5: Reframe and Offer

> "So what you are really saying is [reframe in strategic terms]. The website is not the goal — [their stated outcome] is the goal. Here is what I would recommend..."

Now present your strategic engagement instead of the commodity service. The price gap feels trivial against the value they just articulated.

## Objection Handling

### "That is too expensive"

**Reframe as ROI percentage:**
> "You said this could drive $[their number] in revenue. This investment is [X]% of that. If we hit even half of that target, you are looking at a [Y]x return."

### "We just need a website"

**Reframe as infrastructure:**
> "A website without positioning is a brochure nobody reads. The companies winning your market have messaging, SEO, and conversion paths working together. Would you rather build once or rebuild in 6 months?"

### "Can you just send me a proposal?"

**Reframe as diagnostic:**
> "I could, but I would be guessing at what you actually need. A 30-minute discovery call — free — lets me give you a prescription instead of a guess. When works this week?"

### "We are talking to other agencies"

**Reframe as process:**
> "Good — you should. Ask them this: who does the strategy, and who does the build? If the answer is two different teams, the strategy gets lost in translation."

### "We do not have the budget right now"

**Reframe as cost of waiting:**
> "What is this costing you per month right now? [Wait for answer.] So in 3 months of waiting, you have already spent $[their number]. A diagnostic gives you a clear plan whether you work with us or not."

## The Anti-Patterns

Never do these:
- **Never list services unprompted.** Clients pigeonhole you into one skill. Break the association through questions, not by reading a menu.
- **Never defend your price.** Reframe to value. If you are justifying cost, you have already lost positioning.
- **Never lead with your portfolio.** Let the client talk first. Discovery before presentation.
- **Never discount.** Reduce scope instead. "We can start with Phase 1 and add Phase 2 in Q2."
- **Never send a proposal without a conversation.** A proposal without discovery is a guess.

## Sales Path Template

Customize this path with your own service tiers and pricing:

| Stage | Tool | Pivot To |
|---|---|---|
| Cold inquiry | Free discovery call | Use questions to earn the next meeting |
| After discovery | Paid diagnostic (your entry-level offer) | "The diagnostic tells us exactly what to build" |
| After diagnostic | Full engagement (your core offer) | "The findings map directly to this plan" |
| Price objection | Scope reduction | "Start with Phase 1, add phases as revenue grows" |

## Roleplay Mode

When mode is `roleplay`:

1. Ask for the prospect profile (industry, company size, their commodity ask)
2. Play the prospect — be realistic, push back, raise real objections
3. After each exchange, break character and give feedback:
   - What worked
   - What missed
   - Alternative reframes
4. Run 3-5 rounds, then summarize patterns and areas to sharpen

View saved version →

---
name: productprint-engine-guide
description: Use when starting a new Productprint engagement, when a buyer needs instructions on how to use the skill package, or when the user asks "how do I run the Productprint," "what order do I use these skills," or "where do I start" with the Product/Platform Strategy Engine. Orientation skill for the 6-layer Productprint chain (core-strategic-truth → productprint-tier-a → productprint-tier-b → productprint-tier-c → thesis-stress-test → strategy-thesis-compiler).
---

# Productprint Engine — Runner Guide

This guide walks through the complete Productprint Engine workflow and produces a structured Integrated Product Strategy Thesis.

## When NOT to Use

- **Running an individual layer.** Invoke that layer's skill directly (`core-strategic-truth`, `productprint-tier-a`, etc.) — this guide orients and sequences, it doesn't execute.
- **As a substitute for the layer skills.** The workflows, gates, and output schemas live in each layer's SKILL.md. This file tells you the order and the prompts, nothing more.

## What You Get

The Productprint Engine is a chain of 6 skills that run in sequence. Each layer feeds the next:

```
Layer 1: Core Strategic Truth ─── foundational tension sentence (1 sentence, max 25 words)
    │
    ▼
Layer 2: Productprint Tier-A ──── 10 Playing-to-Win cascade elements with evidence gates
    │
    ▼
Layer 3: Productprint Tier-B ──── 5 actionable elements: bets, roadmap, build/buy/partner,
    │                              prioritization model, risk register
    ▼
Layer 4: Productprint Tier-C ──── 4 deployable positioning artifacts: positioning statement,
    │                              product one-liner, bet narrative, strategy-on-a-page
    ▼
Layer 5: Thesis Stress-Test ───── extracts load-bearing assumptions; tries to FALSIFY them
    │
    ├── If REFINE → re-run Layers 1-4 with constraint package injected (second pass)
    │                (hard stop after 2 passes — surface to operator)
    └── If PROCEED ──▼
                      │
Layer 6: Strategy Thesis Compiler ── 20-40 page consulting-grade integrated strategy thesis
```

The domain-neutral skeleton these layers implement is specified in `CONTRACT.md`.

---

## Prerequisites

- An installed 8gnc plugin in ChatGPT or Codex
- Current web research access for evidence-dependent layers
- **Python 3.9+** for optional local research and validation helpers in Codex
- **Optional:** weasyprint (`pip install weasyprint`) for PDF output
- **Optional:** [search-cli](https://github.com/199-biotechnologies/search-cli) for enhanced multi-provider search on local execution surfaces

---

## Installation Check

This guide is installed as part of the `8gnc` plugin. Ask the model to list the available Productprint skills. Confirm that the six strategy layers, this guide, and the shared `deep-research` skill are available before starting the full chain.

---

## The Two-Pass Workflow

This is the most important thing to understand. **The Productprint Engine is designed to run twice.**

### First Pass (Layers 1-4): Raw Strategy

The first pass builds a strategy thesis from the product's own evidence: market tensions, JTBD outcomes, competitive capabilities, economic engine, and positioning artifacts. It produces good output — but the load-bearing assumptions have not been attacked yet.

### The Thesis Gate (Layer 5): Adversarial Pre-Mortem

Layer 5 is not a competitive vocabulary check. It is a **structured pre-mortem on the one assumption that, if false, collapses the entire strategy**. The gate asks: "What has to be true for this thesis to hold — and is it actually true?"

The gate extracts every assumption embedded in Layers 1-4, ranks them by fragility (how much of the strategy depends on each one × how hard it is to verify), and then tries to FALSIFY the highest-fragility assumption using disconfirmation queries. Counter-evidence is the success condition of this pass, not a failure.

Two outcomes:

- **PROCEED** — The load-bearing assumption survived a genuine attempt to break it. Move to Layer 6.
- **REFINE** — The falsification pass found a fact that breaks the assumption. The gate emits a constraint package (the broken assumption + what it changes + boundaries for the rebuild). Re-run Layers 1-4 with that package injected as a hard constraint.

### Second Pass (Layers 1-4 again): Truth-Hardened Strategy

The second pass is where the value lives. Now every layer knows the prior thesis broke on a specific assumption — they rebuild the cascade excluding that bet, finding the strategy that actually holds.

The loop is capped at 2 passes, then surfaced to the operator if still unresolved. A third pass almost always signals a positioning premise that needs external human judgment, not more research.

**Concrete example:**

- First-pass thesis rested on: "The category's enterprise incumbents cannot serve the mid-market segment because their implementation complexity creates a prohibitive switching cost floor."
- Falsification found: Salesforce Essentials had repriced to $25/user/mo and added a self-serve onboarding path in Q4 2024 — an incumbent already eliminated the switching-cost moat the thesis required.
- **REFINE** issued. Constraint package: "Do not build a strategy that relies on incumbent complexity as a durable barrier for the $25-100/user/mo band. Find a different wedge."
- Second pass rebuilt the thesis around a different where-to-play (vertical-specific workflow automation, not horizontal CRM) where the incumbents have genuine capability gaps and no announced roadmap to close them. The economic engine shifted from price-arbitrage to specialization-premium.

The second pass took the product from a thesis that would have been dead on arrival to one that owns defensible ground.

---

## Modes

Two orthogonal dials control how the engine runs. Set them at Layer 1 and carry them through the chain.

### Depth dial

| Mode | Sources per layer | Rigor | Time |
|------|-------------------|-------|------|
| `rapid` | 8-12 | Lightweight (desk research + top sources) | 15-30 min total |
| `standard` | 15-25 | Full backbone + claim sheets | 60-120 min total |
| `enterprise` | 30+ | Deep triangulation + contradictions log | 3-5 hours total |

Use `rapid` for internal ideation passes. Use `standard` for most client engagements. Use `enterprise` for high-stakes decisions (board decks, fundraising, platform pivots).

### Evidence dial

| Mode | What it means | When to use |
|------|---------------|-------------|
| `greenfield` | Research-only — all evidence gathered from public sources | New product concepts, pre-launch platforms, market entry assessments |
| `existing-product` | Ingest + weight internal artifacts before any external research | Products already in market with real telemetry, user interviews, sales loss-reason data, or roadmap docs |

In `existing-product` mode, Layer 1 asks for internal artifacts first (usage telemetry, NPS verbatims, win/loss call notes, roadmap docs, support ticket themes). Internal evidence receives elevated weighting in claim acceptance gates. Public research fills gaps and pressure-tests internal narratives against market reality.

Set both dials explicitly at the start of every engagement. The chain cannot infer them accurately from context alone.

---

## Skins

A skin controls only how the final output is packaged — voice, styling, and audience framing. It is set at Layer 6 (the compiler) and has no effect on the research or the strategy claims upstream.

| Skin | Audience | Voice / Style | When to use |
|------|----------|---------------|-------------|
| `8gnc-public` | Self-directed operator using the public method | Report voice is clear, firm, and brand-neutral. Packaging may carry an 8gnc method credit without agency-sales copy. | When the user is running the public plugin for their own team. |
| `client-deliverable` | The client's internal leadership team | Report voice uses the client's own language where possible. Packaging carries the client's name, engagement date, and BMC "prepared by" credit. | Standard agency delivery — the most common case. |
| `internal` | Michael / BMC team | No styling overhead. Dense, direct, annotation-friendly. | Internal strategy work, capability demos, test runs, and sales-process evidence. |

Skins are a config parameter passed to `strategy-thesis-compiler`, not a fork of the chain. Switching from `client-deliverable` to `8gnc-public` changes packaging, not the research claims.

---

## Layer-by-Layer Chain

### Step 1: Gather Your Inputs

Before you start, collect:

| Input | What You Need | Where to Find It |
|-------|--------------|------------------|
| Product name | The product, platform, or service | Client brief |
| Category | Market category or domain | Client brief |
| Audience | Primary buyer / operator audience | Client brief, sales team |
| Region | Geographic market | Client brief |
| Competitors | 3-5 named competitors or substitutes | Client brief, industry knowledge |
| Competitor URLs | Their product pages, pricing pages | Web search |
| Constraints | Legal, scope, or strategic limits | Client brief |
| Evidence mode | `greenfield` or `existing-product` | Depends on product maturity |
| Internal artifacts | Telemetry, interviews, roadmap, loss reasons | Client (existing-product only) |

### Step 2: Run Layer 1 — Core Strategic Truth

**Prompt:**

```
Run the core-strategic-truth skill for [PRODUCT NAME].

Category: [market category]
Audience: [who buys/uses it]
Region: [geographic market]
Mode: standard
Evidence mode: greenfield [or existing-product]

[If existing-product, paste or attach internal artifacts here]
```

**What happens:** The deep research engine launches 5-10 parallel searches across academic sources, industry data, forums, reviews, and analyst reports. Sources are triangulated, credibility-scored, and synthesized. The Core Strategic Truth skill distills findings into a single validated sentence (max 25 words) capturing the foundational constraint or forced trade-off buyers face in this market.

**Output:** Core Strategic Truth sentence, tension map, JTBD seed, buyer archetypes, lexicon, source bibliography.

**Duration:** 15-25 minutes in standard mode.

**Checkpoint:** Read the Core Strategic Truth sentence. Does it capture a real tension buyers experience but rarely articulate? Is it specific enough to be falsifiable? If it reads like a marketing headline, it isn't a strategic truth — provide additional context and re-run.

### Step 3: Run Layers 2-4 — Productprint Tier-A, Tier-B, Tier-C

These should chain automatically. If they don't auto-chain, prompt each one:

**Tier-A prompt (if needed):**

```
Run productprint-tier-a for [PRODUCT NAME], using the Core Strategic Truth output as seed.
```

**Tier-B prompt (if needed):**

```
Run productprint-tier-b for [PRODUCT NAME], using the Tier-A output as seed.
```

**Tier-C prompt (if needed):**

```
Run productprint-tier-c for [PRODUCT NAME], using the Tier-A and Tier-B outputs as seeds.
```

**Output after all three:**
- Tier-A: Winning aspiration, category sizing, JTBD outcomes, segments, where-to-play, competitive capability teardown, how-to-win hypothesis, required capabilities, economic engine, differentiation wedge
- Tier-B: Strategic bets, Now/Next/Later roadmap, build/buy/partner decisions, prioritization model, risk register
- Tier-C: Positioning statement, product one-liner, bet narrative, strategy-on-a-page

**Duration:** 45-90 minutes total for all three tiers in standard mode.

**Checkpoint:** Review the how-to-win hypothesis and differentiation wedge from Tier-A, and the strategic bets from Tier-B. Can you articulate what has to be true for this strategy to succeed? If yes, those are the assumptions Layer 5 is about to attack.

### Step 4: Run Layer 5 — Thesis Stress-Test

This is where most people skip — and where the most value lives.

**Prompt:**

```
Run the thesis-stress-test for [PRODUCT NAME].

Competitors / substitutes:
1. [Competitor 1] — [URL]
2. [Competitor 2] — [URL]
3. [Competitor 3] — [URL]

Use the Tier-A, Tier-B, and Tier-C outputs from Layers 1-4 as the thesis to stress-test.
```

**Pro tip:** If you have competitor pricing pages, product roadmap announcements, or recent press releases that might challenge the thesis, paste them directly. The falsification pass is only as sharp as the disconfirming evidence it can find.

**Output:** Assumption ledger, fragility ranking, load-bearing assumption identification, falsification findings, PROCEED/REFINE verdict. If REFINE: constraint package.

**Duration:** 15-30 minutes.

**The critical decision:**

If the gate returns **PROCEED** — the load-bearing assumption survived. Skip to Step 6.

If the gate returns **REFINE** — go to Step 5.

### Step 5: Second Pass (Only If REFINE)

Re-run Layers 1-4, but this time inject the constraint package from the gate:

**Prompt:**

```
Re-run the core-strategic-truth skill for [PRODUCT NAME] with an additional constraint package from the thesis stress-test:

[Paste the constraint package from Layer 5 here]

The first-pass thesis rested on the assumption that [assumption]. The falsification pass found: [finding].

The rebuild MUST NOT rely on [excluded bet or territory]. Find a where-to-play and how-to-win that does not depend on this assumption.
```

Then chain through Tier-A, B, C again with the same constraint package visible at every layer.

**What changes:** The cascade rebuilds from a narrower but truthful foundation. The where-to-play selection excludes the falsified ground. The differentiation wedge anchors in a different capability gap — one the falsification pass could not break.

**After the second pass:** Run Layer 5 again to confirm PROCEED. If it still says REFINE, surface to the operator with both constraint packages — a third automated pass rarely resolves a fundamental positioning premise without human judgment.

### Step 6: Run Layer 6 — Strategy Thesis Compiler

**Prompt:**

```
Run the strategy-thesis-compiler to create the final integrated strategy thesis.

Product: [PRODUCT NAME]
Client: [CLIENT NAME]
Prepared by: [YOUR FIRM NAME]
Date: [MONTH YEAR]
Skin: client-deliverable [or 8gnc-public or internal]
Confidentiality: Confidential
Include financials: yes
Include roadmap: yes
Format: narrative

Use all outputs from Layers 1-5 (or the second-pass versions if applicable).
```

**Output:** A 20-40 page Integrated Strategy Thesis (rapid: 15-20pp; standard: 25-35pp; enterprise: 35-50pp) with:

- Executive summary with key bets and evidence quality
- Market context and category dynamics
- Core Strategic Truth with tension map and buyer psychology
- Competitive landscape with capability gap analysis
- Target segments with JTBD outcome maps
- Where-to-play / How-to-win cascade with evidence chains
- Now/Next/Later roadmap (3 horizons, 18 months)
- Build / Buy / Partner decision map
- Economic engine model with ranges and assumptions
- Differentiation wedge and moat argument
- Assumption-Test Log (load-bearing assumptions + falsification findings)
- Strategic guardrails and decision boundaries
- Source bibliography (typically 400-1000+ sources across layers)

**Duration:** 20-40 minutes.

---

## Tips for Best Results

### Use the Deep Research Engine

Layers 1, 2, and 5 are evidence-heavy and route all search through the shared `deep-research` engine. Choose depth based on the engagement:

- **Standard mode** — good for most engagements (15-25 sources per layer, 5-10 min per layer)
- **Deep mode** — recommended for thesis stress-tests (25+ sources, 10-20 min)
- **UltraDeep mode** — comprehensive for enterprise-scale platform decisions (30+ sources, 20-45 min)

The engine handles parallel search, credibility scoring, triangulation, and citation verification automatically. For enhanced search, install [search-cli](https://github.com/199-biotechnologies/search-cli) — it aggregates Brave, Serper, Exa, Jina, and Firecrawl.

### In Existing-Product Mode, Front-Load Internal Evidence

For products already in market, internal artifacts (telemetry, win/loss notes, NPS verbatims, support themes, roadmap docs) almost always contain truths that public research misses. Paste them at Layer 1. Every layer downstream will weight them above public sources when the internal evidence is specific and dated.

### Feed Real Competitor Data to the Stress-Test

Don't just name competitors — paste their product pages, pricing announcements, recent blog posts, and roadmap items into Layer 5. The falsification pass can only break assumptions it has real ammunition against. Generic competitor names produce shallow attacks.

### Don't Skip the Second Pass

The first pass is necessary scaffolding. The second pass is where the strategy actually earns its keep. Every engagement where we've run the second pass has produced a sharper, more defensible thesis than the first pass alone — because it had to be rebuilt around something that couldn't be broken.

### Save Your Outputs

Each layer produces structured JSON. Save these files between sessions. If you need to update one layer six months later (e.g., re-run the stress-test after a competitor ships a new product), you can feed the saved outputs from the other layers back in without re-running the full chain.

### Carry the Evidence Mode Through Every Layer

Set `evidence_mode` once at Layer 1 and state it explicitly in every subsequent layer prompt. Layers don't inherit session state reliably. If you forget, later layers default to `greenfield` and may ignore internal artifacts you provided earlier.

---

## Troubleshooting

| Problem | Solution |
|---------|----------|
| Skills don't auto-chain | Manually prompt each layer with "use the [previous layer] output as seed" |
| Current research is unavailable | Stop evidence-dependent claims or label them as hypotheses. Do not substitute model memory for current market evidence. |
| Stress-test says PROCEED immediately | Add more competitors / substitutes or paste actual product announcements. A gate that always proceeds hasn't actually attacked anything. |
| Stress-test REFINE loops more than twice | Surface to the operator — a third automated pass signals a foundational positioning premise that needs human judgment, not more research. |
| Report is too short | Set mode to `enterprise` or provide more context. The compiler needs rich layer outputs to produce a rich report. |
| Layer outputs feel generic | Audience definition is probably too broad. "SaaS buyers" is too broad. "VP of Engineering at 50-500-person B2B SaaS companies who own the toolchain budget" is specific enough for the research to anchor on. |
| First-pass Core Strategic Truth feels like a tagline | It's not specific enough. Add constraints: the specific compromise buyers are forced to make, the decision they regret most, or the gap between what they expected and what they got. |
| Existing-product mode not weighting internal artifacts | Re-state `evidence_mode: existing-product` explicitly in each layer prompt and paste the artifacts again — session context doesn't always persist across long chains. |

---

## What This Replaces

This skill chain replaces a traditional product strategy engagement:

| Traditional | Productprint Engine |
|------------|---------------------|
| 8-16 weeks | 2-6 hours |
| Consultant fees plus operator time | Model access plus operator review time |
| 5-8 stakeholder workshops | Text inputs + competitor URLs + optional internal artifacts |
| 1 deliverable, no iteration | Unlimited re-runs with refined constraints |
| Static recommendations | Living thesis you can stress-test quarterly |

Treat the output as a decision-support artifact, not automatic truth. Its value comes from an explicit, documented, repeatable adversarial gate, but quality still depends on source quality, first-party inputs, and operator judgment.

---

## Package Contents

The 8gnc plugin includes `core-strategic-truth`, Tiers A through C, `thesis-stress-test`, `strategy-thesis-compiler`, this guide, and the shared `deep-research` engine.

View saved version →

---
name: productprint-tier-a
description: Use when the user asks for a Productprint, product strategy research, Playing-to-Win cascade, where-to-play analysis, how-to-win hypothesis, market sizing, competitive capability teardown, JTBD outcomes mapping, segment willingness-to-pay, economic engine modeling, differentiation wedge, or any comprehensive product or platform strategy deliverable — Layer 2 of the Productprint research stack. Also trigger on "run Tier-A," "productprint research," "full product strategy audit," "product strategy sprint," "Playing-to-Win cascade," "market sizing," "where to play," "how to win," or when the user wants JTBD outcomes, competitive capability teardown, segment WTP, and strategy positioning in one pass. Use immediately when the core-strategic-truth skill has just completed — chain directly using its output as the seed.
---

# Productprint Tier-A — Hybrid Research Directive

Deliver all 10 Tier-A Productprint elements using a hybrid method: build a shared evidence Backbone first, then run independent, falsifiable sprints per element — each with its own proofs and claim sheets. The 10 elements form an integrated Playing-to-Win cascade: winning aspiration → category sizing → JTBD outcomes → segments → where-to-play → competitive capability teardown → how-to-win → required capabilities → economic engine → differentiation wedge.

## When NOT to Use

- **You only need quick positioning or stylistic outputs.** Tier-C requires Tier-A and Tier-B as seeds — there is no shortcut to a strategy thesis. Run the full chain, or run this skill in `rapid` mode to lighten the load.
- **No access to real market evidence.** Every sprint gates on ≥3 independent sources or behavioral signals. Without reviews, search data, and competitor materials to mine, the claims can't clear the gates.
- **Validating existing positioning against competitors.** That's an adversarial test, not a build — use `thesis-stress-test` (Layer 5).

## Chain Position

This is **Layer 2** of a 6-layer Productprint research stack:

1. **Core Strategic Truth** (Layer 1) → foundational tension sentence, tension map, JTBD seed, archetypes, lexicon
2. **Productprint Tier-A** (this skill) → uses Layer 1 output as seed; produces 10 defensible Playing-to-Win cascade elements
3. **Productprint Tier-B** (Layer 3) → uses Tier-A output as seed; produces actionable plan: strategic bets, Now/Next/Later roadmap, build/buy/partner decisions, prioritization model, and risk register
4. **Productprint Tier-C** (Layer 4) → uses Tier-A + Tier-B output as seeds; produces deployment-ready positioning artifacts: positioning statement, one-liner, bet narrative, and strategy-on-a-page
5. **Thesis Stress-Test** (Layer 5) → adversarial pre-mortem gate; extracts load-bearing assumptions and tries to FALSIFY them; returns PROCEED if they survive or REFINE (with a constraint package) if one falls
6. **Strategy Thesis Compiler** (Layer 6) → compiles all layers into a consulting-grade integrated strategy thesis deliverable

**When Layer 1 has just completed:** Import its output directly. The `final_sentence`, `tension_map`, `jtbd_seed`, `archetypes`, `lexicon`, and `evidence_mode` from Core Strategic Truth seed the Backbone phase — do not re-research what Layer 1 already validated. Carry forward its sources into the Backbone bibliography.

**When running standalone:** Resolve all variables with the user and build the Backbone from scratch.

## Variables to Resolve

Before starting, confirm these with the user (or inherit from Layer 1):

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `product_name` | The product, platform, or solution being researched | *required* |
| `category` | Market category or domain | *required* |
| `audience` | Primary buyer/operator audience definition | *required* (or from Layer 1) |
| `region_context` | Geography or cultural context | US / English-speaking |
| `constraints` | Scope, legal, or strategic constraints | None |
| `mode` | `rapid`, `standard`, or `enterprise` | `standard` |
| `evidence_mode` | `greenfield` or `existing-product` | `greenfield` |

## Principles (Non-Negotiable)

1. **Truth over consensus.** Triangulate across independent sources; show counter-evidence.
2. **Each sprint is a separate claim** with its own acceptance gates and proof minimums.
3. **No fabrication.** If unknown, mark unknown. Quote sparsely; summarize faithfully.
4. **Plain language.** Prioritize verifiable behaviors over vibes.
5. **Log contradictions** between sprints; resolve or bound them.

## Evidence & Citation Policy

For every public claim, include: title, publisher, author (if available), URL, publish date, access date, one-line evidence note, and stance (`supporting` | `conflicting` | `neutral`).

## Global Acceptance Gates

Every Tier-A sprint must meet these before its claim is accepted:

- **Proof minimum:** ≥3 independent sources or behavioral signals per claim
- **Claim sheet required:** statement, boundaries, counter-evidence, confidence rating, sources
- **Economic claims** require transparent math with explicit ranges and inputs — no point estimates
- **Where-to-play options** must be scored on attractiveness AND right-to-win — a one-dimensional score does not clear the gate
- **Winning aspiration** must include explicit boundaries — an unbounded ambition is a wish, not a strategy claim

**Mode adjustments:**
- *Rapid:* ≥2 sources per claim, 1 behavioral proxy, lighter economic math (ranges still required)
- *Standard:* Full desk research, corpus mining, structured validation
- *Enterprise:* Add cross-market slices, expert panels, longitudinal comparisons

## Workflow

### Phase: Backbone Evidence Garage

**Goal:** Assemble shared inputs once. No final claims yet.

Actions:
- **Landscape scan** — category definition, purchase contexts, substitutes, adjacent categories
- **Macro data pull** — longitudinal stats relevant to the product, category, and audience
- **Review corpus** — collect public reviews, forums, social posts where permitted; store verbatims with links
- **Search-intent map** — SERP, marketplaces, app stores; identify real buyer language and JTBD signals
- **Competitor inventory** — top direct competitors and substitutes; capture capabilities, moats, pricing, and proof signals
- **Contradictions log** — note conflicts to test in sprints

In **existing-product mode**, seed the Backbone `competitor_inventory` and `outcomes_seed` from internal telemetry and interview artifacts (loss reasons, churn data, NPS verbatims, roadmap notes) before beginning external search. Internal first-party artifacts are Tier 1 evidence; external sources are Tier 2 corroboration.

If Layer 1 output is available, merge its `tension_map`, `jtbd_seed`, `archetypes`, `lexicon`, and `sources` into the Backbone. Do not duplicate research Layer 1 already completed.

Outputs: `annotated_bibliography`, `macro_data_summary`, `review_verbatim_library`, `search_intent_map`, `competitor_inventory`, `outcomes_seed`, `contradictions_log_seed`

---

### Sprint 1: Winning Aspiration (Bounded Ambition)

**Inputs:** All Backbone outputs (+ Layer 1 `final_sentence` and `tension_map` if available)

Actions:
- Draft a winning aspiration statement: what does it mean for this product to "win" in this category within a defined time horizon?
- State explicit boundaries: where will the product NOT play (segments, channels, geographies, use cases)?
- Validate the ambition against market sizing — is it achievable within the bounded scope?
- Run counter-arguments: what would cause this aspiration to be wrong?

**Acceptance gates:** proof_minimum ≥3; ambition MUST include explicit boundaries (unbounded aspiration fails the gate); deliver claim sheet

Outputs: `winning_aspiration_statement`, `boundary_conditions`, `claim_sheet_winning_aspiration`

---

### Sprint 2: Category Definition + Sizing

**Inputs:** `Backbone.macro_data_summary`, `Backbone.annotated_bibliography`

Actions:
- Define the category frame the product occupies — this may differ from how analysts categorize it
- Build TAM/SAM/SOM estimates as explicit RANGES with stated methodology for each level
- Run bottom-up and top-down crosschecks; surface where they diverge
- Document every input assumption; flag analyst variance across sources

**Acceptance gates:** proof_minimum ≥3; TAM/SAM/SOM MUST be ranges with method notes — point estimates fail the gate; deliver claim sheet

Outputs: `category_definition`, `tam_range`, `sam_range`, `som_range`, `method_notes`, `claim_sheet_sizing`

---

### Sprint 3: JTBD / Desired Outcomes (Top 3)

**Inputs:** `Backbone.review_verbatim_library`, `Backbone.outcomes_seed` (+ Layer 1 `jtbd_seed` if available)

Actions:
- Convert verbatims and JTBD seed candidates to outcome statements in buyer language
- Estimate importance and satisfaction gap from credible third-party data or behavioral proxies (review ratings, churn signals, NPS verbatims, switcher surveys)
- Reduce to top 3 outcomes with boundaries; rank by importance × satisfaction-gap
- Run counter-arguments: are these the real outcomes, or surface symptoms?

**Acceptance gates:** proof_minimum ≥3; importance × satisfaction-gap scoring required for each outcome; deliver claim sheet

Outputs: `outcomes_top3`, `importance_gap_notes`, `claim_sheet_jtbd`

---

### Sprint 4: Segments + Willingness-to-Pay

**Inputs:** `Backbone.macro_data_summary`, `Backbone.search_intent_map` (+ Layer 1 `archetypes` if available)

Actions:
- Define 1–3 segments with firmographic and psychographic cues
- Estimate addressable size bounds per segment using reputable datasets (explicit ranges, no silent math)
- Derive WTP proxies from pricing signals, switching behaviors, and analogous purchase data
- Note decision-maker role differences across segments

**Acceptance gates:** proof_minimum ≥3; size bounds required as ranges; WTP proxies required (not inferred); deliver claim sheet

Outputs: `segments_defined`, `size_bounds_per_segment`, `wtp_proxies`, `claim_sheet_segments`

---

### Sprint 5: Where-to-Play Option Map

**Inputs:** `Sprint 2.tam_range` + `Sprint 2.sam_range`, `Sprint 3.outcomes_top3`, `Sprint 4.segments_defined`

Actions:
- Generate 3–6 where-to-play options as concrete intersections of segment × channel × geo × use-case
- Score each option on attractiveness (market size × growth × competitive intensity) and right-to-win (capability fit × differentiation advantage × switching cost)
- Surface trade-offs between high-attractiveness / low-right-to-win options and vice versa
- Map which Layer 1 tensions align to each option — options that address no validated tension are suspect

**Acceptance gates:** proof_minimum ≥3; every option scored on BOTH attractiveness AND right-to-win; deliver claim sheet

Outputs: `where_to_play_options_scored`, `attractiveness_right_to_win_matrix`, `claim_sheet_where_to_play`

---

### Sprint 6: Competitive Capability Teardown

**Inputs:** `Backbone.competitor_inventory`, `Backbone.search_intent_map`

Actions:
- For each top direct competitor and substitute, document observable capabilities (not brand claims), structural moats, and documented gaps
- Build a substitute map: what do buyers use when the product category fails them?
- Map competitor gaps against Sprint 3 outcomes — identify which JTBD outcomes are underserved across the entire competitive set
- Run counter-arguments: which competitor is most likely to close their gaps and why?

**Acceptance gates:** proof_minimum ≥3; teardown must be by capability/moat/gap — brand claim comparisons without behavioral evidence fail the gate; deliver claim sheet

Outputs: `competitor_capability_profiles`, `substitute_map`, `jtbd_gap_map`, `claim_sheet_competitive`

---

### Sprint 7: How-to-Win Hypothesis

**Inputs:** `Sprint 5.where_to_play_options_scored`, `Sprint 6.competitor_capability_profiles`

Actions:
- Draft a how-to-win hypothesis: what must be true about the product's advantage for the winning where-to-play options to be achievable?
- Name the advantage TYPE explicitly: cost leadership, differentiation, network effect, switching cost, data flywheel, platform lock-in, speed-to-outcome, regulatory, brand
- State WHY the advantage holds structurally (the mechanism, not the aspiration)
- Run red-team: what would need to change in the market for this hypothesis to break?

**Acceptance gates:** proof_minimum ≥3; advantage TYPE must be named explicitly; structural mechanism must be stated; deliver claim sheet

Outputs: `how_to_win_hypothesis`, `advantage_type`, `mechanism_rationale`, `claim_sheet_how_to_win`

---

### Sprint 8: Required Capabilities

**Inputs:** `Sprint 7.how_to_win_hypothesis`, `Backbone.competitor_inventory`

Actions:
- List the capabilities the product must have for the how-to-win hypothesis to hold
- Assess current state (strong, weak, absent) with evidence
- Define the gap for each weak or absent capability: what must be built, acquired, or partnered?
- Rate criticality: must-have, high, medium, low — relative to the how-to-win hypothesis specifically

**Acceptance gates:** proof_minimum ≥3; criticality rating required per capability relative to how-to-win; gaps must be actionable (not vague); deliver claim sheet

Outputs: `required_capabilities_list`, `gap_assessments`, `criticality_ratings`, `claim_sheet_capabilities`

---

### Sprint 9: Economic Engine

**Inputs:** `Sprint 5.where_to_play_options_scored`, `Sprint 8.required_capabilities_list`, `Sprint 4.wtp_proxies`

Actions:
- Model CAC and LTV ranges with explicit channel-mix assumptions; never a point estimate
- State pricing model and connect it to segment WTP evidence from Sprint 4
- Compute LTV:CAC ratio range; flag if it falls below 3:1 in any realistic scenario
- State payback window assumptions and sensitivity to key levers
- Document boundary conditions: which single input, if wrong by 20%, breaks the model?

**Acceptance gates:** math transparency required; all economic claims MUST be ranges with inputs stated — any point estimate fails the gate; deliver claim sheet

Outputs: `unit_economics_ranges`, `cac_ltv_ranges`, `pricing_model`, `payback_bounds`, `sensitivity_notes`, `claim_sheet_economic_engine`

---

### Sprint 10: Differentiation Wedge

**Inputs:** `Sprint 6.jtbd_gap_map` + `Sprint 6.substitute_map`, `Sprint 7.how_to_win_hypothesis`

Actions:
- Identify the specific customer-outcome or capability combination that no named competitor currently occupies
- Document WHY it is unoccupied: capability cost, market timing, incentive misalignment, structural architecture mismatch — not just "we got there first"
- State the defensibility mechanism: how does holding this position compound over time?
- Run counter-arguments: which competitor is closest to occupying this space, and what would trigger them to move?

**Acceptance gates:** proof_minimum ≥3; `why_unoccupied` must cite a structural reason — timing assumptions alone fail the gate; defensibility must name a compounding mechanism; deliver claim sheet

Outputs: `open_white_space`, `why_unoccupied_rationale`, `defensibility_mechanism`, `claim_sheet_wedge`

---

### Phase: Integration & Contradiction Resolution

**Goal:** Resolve conflicts, finalize linkages, and package outputs.

Actions:
- Update contradiction matrix across all sprints; resolve or set explicit boundaries
- Verify the cascade holds: winning aspiration → category sizing → JTBD → segments → where-to-play → competitive teardown → how-to-win → capabilities → economic engine → wedge. If any link in the chain is unsupported by the evidence, flag it
- Assemble rationale narrative connecting tensions to proofs
- Compile lexicon: words that resonate/repel from corpus (carry forward from Layer 1 if available)
- Finalize sources with stances and evidence notes

Outputs: `contradiction_matrix`, `cascade_linkage_check`, `rationale_narrative`, `lexicon`, `sources_final`

## Sprint Dependency Map

Understanding which sprints can run in parallel vs. which must wait:

```
Backbone ──┬── Sprint 1 (Winning Aspiration) ───────────────────────────────────────────┐
           │                                                                              │
           ├── Sprint 2 (Category Sizing) ──────────────────────────────────────────┐    │
           │                                                                         │    │
           ├── Sprint 3 (JTBD / Outcomes) ──────────────────────────────────────┐   │    │
           │                                                                      │   │    │
           ├── Sprint 4 (Segments + WTP) ────────────────────────────────────┐   │   │    │
           │                                                                  │   │   │    │
           │   Sprint 2 + Sprint 3 + Sprint 4 ──── Sprint 5 (Where-to-Play) ─┤   │   │    │
           │                                                                  │   │   │    │
           ├── Sprint 6 (Competitive Capability Teardown) ──────────────┐    │   │   │    │
           │                                                             │    │   │   │    │
           │   Sprint 5 + Sprint 6 ──── Sprint 7 (How-to-Win) ─────────┤    │   │   │    │
           │                                                             │    │   │   │    │
           │   Sprint 7 + Backbone ──── Sprint 8 (Required Capabilities)│    │   │   │    │
           │                                                             │    │   │   │    │
           │   Sprint 5 + Sprint 8 ──── Sprint 9 (Economic Engine) ─────┘    │   │   │    │
           │                                                                  │   │   │    │
           │   Sprint 6 + Sprint 7 ──── Sprint 10 (Differentiation Wedge)   │   │   │    │
           │                                                                  │   │   │    │
           └────────────── Integration & Contradiction Resolution ────────────┴───┴───┴────┘
```

**Parallelizable sets:**
- Sprints 1, 2, 3, 4, and 6 can all begin immediately from Backbone outputs.
- Sprint 5 waits on Sprints 2 + 3 + 4.
- Sprint 7 waits on Sprints 5 + 6.
- Sprint 8 waits on Sprint 7.
- Sprint 9 waits on Sprints 5 + 8.
- Sprint 10 waits on Sprints 6 + 7.
- Integration waits on all sprints.

> **Note:** Sprint Inputs may also draw on always-available Backbone objects (e.g. Sprint 8 draws `Backbone.competitor_inventory`; Sprint 9 draws `Sprint 4.wtp_proxies` as a transitively satisfied upstream) — these cross-edges are omitted from the diagram above for readability but are stated explicitly in each sprint's Inputs section.

## Heuristics

- Prefer primary datasets and systematic reviews over opinion pieces
- When credible sources conflict, show both and explain method/sample differences
- Reduce adjectives; increase observable behaviors and numbers with ranges
- If a truth is situational, state boundary conditions explicitly
- A where-to-play option with high attractiveness but low right-to-win is a trap — flag it explicitly rather than silently deprioritizing it

## What NOT to Do

- Do not rely on a single think-piece or vendor blog for a claim
- Do not give point estimates for economic claims — Sprint 9 and all unit economics require ranges with explicit inputs, or the math reads as fabricated
- Do not invent survey results or fabricate review verbatims
- Do not skip claim sheets — every sprint must produce one
- Do not promote Backbone observations directly to accepted claims — the Backbone is shared input; only a sprint's acceptance gates produce a claim
- Do not draft a winning aspiration without explicit boundaries — unbounded ambition fails Sprint 1's gate
- Do not name a how-to-win advantage type as "better product" or "best-in-class" — these are not advantage types; name the mechanism
- Do not run Sprint 5 (where-to-play) before Sprints 2, 3, and 4 complete — a where-to-play map without sizing, JTBD validation, and segment WTP has nothing to score against
- Do not run Sprint 10 (differentiation wedge) before Sprints 6 and 7 finish — the wedge requires both the capability gap map and the how-to-win hypothesis to establish that the white space is real and defensible

## Output Format

Deliver the final output as structured JSON conforming to the schema in `references/output-schema-tier-a.md`.

The JSON must include: `product_name`, `category`, `audience`, `backbone_repository`, `tierA_results` (all 10 elements with claim sheets), `contradiction_matrix`, `sources`, and `audit_log`.

**Forward chaining:** When this skill completes, its full output object becomes the input seed for Layer 3 (Productprint Tier-B). Preserve the complete JSON — Layer 3 needs the winning aspiration, JTBD outcomes, segments, where-to-play map, how-to-win hypothesis, required capabilities, economic engine, and differentiation wedge to produce strategic bets, Now/Next/Later roadmap, build/buy/partner decisions, prioritization model, and risk register. If the `productprint-tier-b` skill is available, proceed directly into it without user confirmation.

## Evaluation Rubric

1. **Backbone completeness** — shared inputs exist and are cited; in existing-product mode, internal artifacts are seeded first
2. **Cascade coherence** — the 10 elements link: winning aspiration is bounded by category sizing; JTBD informs segments; segments constrain where-to-play; competitive teardown grounds how-to-win; capabilities and economic engine tie to the selected where-to-play options; wedge emerges from the gap map
3. **Proof density** — each Tier-A claim meets or exceeds proof minimums
4. **Conflict hygiene** — contradictions logged and resolved or bounded
5. **Economic sanity** — ranges and inputs are explicit; LTV:CAC ratio is computed; no hidden math; payback sensitivity is named
6. **Advantage specificity** — how-to-win names a mechanism type, not a brand aspiration
7. **Traceability** — every claim ties to sources with stances
8. **Reusability** — outputs slot cleanly into the Productprint scaffold and forward into Layers 3–6

## File I/O Contract (orchestrated mode)

> **Note:** automated orchestrated mode is not included in this release; run the manual chain. This contract is a forward-looking specification.

When an authorized orchestrator provides explicit paths, honor them exactly:

- **Seed inputs:** read ONLY the JSON/YAML files listed in the dispatch prompt.
- **Output:** write the final JSON object to the exact path given (under `.productprint/engagements/{slug}/pass-N/`). No other location.
- **Return value:** your final message is the output path plus the layer's key artifact — not the full JSON. The orchestrator reads files, not transcripts.

When invoked as a direct skill call, present the JSON in conversation or through the supported file workflow and tell the user to preserve it for the next layer.

Referenced files: 1

View saved version →

---
name: productprint-tier-b
description: Use when the user asks for Tier-B product strategy elements — strategic bets, Now/Next/Later roadmap, build-vs-buy-vs-partner decisions, prioritization model, risk register, or roadmap sequencing — Layer 3 of the Productprint research stack. Also trigger on "run Tier-B," "Productprint Tier-B," "strategic bets," "roadmap horizons," "Now/Next/Later," "build vs buy," "prioritization model," "risk register," or when the user wants a sequenced, evidence-backed product plan derived from existing Tier-A strategy research. Use immediately when the productprint-tier-a skill has just completed — chain directly using its output as the seed.
---

# Productprint Tier-B — Strategic Bets, Roadmap & Risk Directive

Deliver 5 Tier-B product strategy elements that are sequenced, falsifiable, and aligned to validated Tier-A truths. The Now/Next/Later roadmap is the marquee output: its ordering MUST be justified by inter-bet dependencies and kill-criterion thresholds, not intuition. Evidence is lightweight but real. Every element with a testable behavioral signal gets a proxy test.

## When NOT to Use

- **No Tier-A output exists.** Tier-B derives, it doesn't originate. Run `productprint-tier-a` first — standalone mode here produces reduced-confidence output and says so in the audit log.
- **Full product specifications or technical architecture.** Bets, roadmap horizons, and the risk register are strategy-layer artifacts. Technical specs, API designs, and sprint plans are implementation work outside this chain.
- **Adversarial differentiation testing.** Tier-B checks alignment with Tier-A, not competitive positioning stress-testing — that's `thesis-stress-test` (Layer 5).

## Chain Position

This is **Layer 3** of a 6-layer Productprint research stack:

1. **Core Strategic Truth** (Layer 1) → foundational tension sentence, tension map, JTBD seed, archetypes, lexicon
2. **Productprint Tier-A** (Layer 2) → 10 defensible Playing-to-Win cascade elements with evidence-gated sprints
3. **Productprint Tier-B** (this skill) → uses Layer 2 output as seed; produces 5 actionable strategy elements: bets, roadmap, build/buy/partner, prioritization, risk register
4. **Productprint Tier-C** (Layer 4) → uses Tier-A + Tier-B output as seeds; produces deployment-ready positioning and differentiation elements
5. **Thesis Stress-Test** (Layer 5) → adversarial pre-mortem gate; extracts load-bearing assumptions and tries to FALSIFY them; returns PROCEED if they survive or REFINE (with a constraint package) if one falls
6. **Strategy Thesis Compiler** (Layer 6) → compiles all layers into a consulting-grade integrated strategy thesis deliverable

**When Layer 2 has just completed:** Import its full output JSON directly. Pull Tier-A anchors — `winning_aspiration`, `jtbd_outcomes`, `where_to_play_map`, `how_to_win_hypothesis`, `required_capabilities`, `economic_engine`, `differentiation_wedge` — into the Intake phase. Do not re-research what Layers 1–2 already validated. Carry forward all sources and the contradiction matrix.

**When running standalone:** Resolve all variables with the user. If no Tier-A backbone exists, build a lightweight Backbone Tap from scratch using desk research, but note reduced confidence in the audit log.

## Variables to Resolve

Before starting, confirm these with the user (or inherit from Layers 1–2):

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `product_name` | The product, platform, or solution being researched | *required* |
| `topic` | Product or category scope | *required* |
| `audience` | Primary buyer/operator audience definition | *required* (or from Layer 2) |
| `region_context` | Geography or cultural context | US / English-speaking |
| `constraints` | Scope, legal, or strategic constraints | None |
| `languages` | Output language | English |
| `planning_horizon` | Time window for Now/Next/Later horizons | Now=0-6mo, Next=6-18mo, Later=18mo+ |
| `mode` | `rapid`, `standard`, or `enterprise` | `standard` |
| `backbone_source` | Link or reference to Tier-A backbone repository | From Layer 2 if chained |

## Principles (Non-Negotiable)

1. **Evidence-informed, not evidence-bloated.** Two independent sources or one source + a behavioral proxy per claim.
2. **Bets are falsifiable.** Every strategic bet has a hypothesis AND a kill criterion — no kill criterion means no bet.
3. **Roadmap ordering is argued, not assumed.** Sequencing logic must cite inter-bet dependencies and kill-criterion thresholds. An unjustified sequence fails the gate.
4. **If an output conflicts with Tier-A,** either revise or state boundary conditions.
5. **No fabrication.** If data is unknown, label as unknown.

## Evidence & Citation Policy

For any external claim, include: title, publisher, URL, dates, and a one-line evidence note. Quote sparingly. Same citation format as Layers 1–2.

## Global Acceptance Gates

Every Tier-B element must meet these before its claim is accepted:

- **Proof minimum:** ≥2 independent sources OR 1 source + 1 behavioral proxy
- **Alignment check** against Tier-A winning aspiration, JTBD outcomes, required capabilities, and economic engine
- **Kill criterion required** on every strategic bet
- **Sequencing logic required** in roadmap horizons — unjustified order fails the gate
- **Leading indicator required** on every risk register entry

**Mode adjustments:**
- *Rapid:* Single pass using Backbone + 1 proxy test per testable element; kill criteria may be lightweight
- *Standard:* Backbone + 2 proxy tests per testable element; full dependency map; leading indicators required
- *Enterprise:* Add cross-segment risk variants, pre-registered test plans, and scenario modeling for each horizon

## What NOT to Do

- Don't invent survey results
- Don't contradict Tier-A without stating limits
- Don't ship jargon
- Don't skip proxy tests on testable elements — strategic bets, roadmap horizons, and the prioritization model each need at least one behavioral signal
- Don't copy Tier-A proof points verbatim as proxy tests — proxy tests must be designed fresh per element (leading indicator, activation signal, kill-criterion threshold check)
- Don't write a strategic bet without a kill criterion — an un-killable bet is a commitment, not a hypothesis
- Don't justify roadmap ordering with "this feels like the right sequence" — cite the dependency type and which Tier-A assumption gates the downstream bet
- Don't score prioritization model dimensions from intuition — each dimension (impact, confidence, effort) must cite its source in Tier-A evidence
- Don't list risks without leading indicators — a risk without an early warning signal is not actionable

## Workflow

### Phase 0: Intake & Alignment

**Goal:** Confirm context and pull Tier-A anchors.

Actions:
- Resolve all variables; pull Tier-A anchors: `winning_aspiration`, `jtbd_outcomes` (top 3), `segments_wtp`, `where_to_play_map`, `how_to_win_hypothesis`, `required_capabilities`, `economic_engine`, `differentiation_wedge`
- List constraints (legal, strategic scope, cultural sensitivities)
- Define success criteria per element (see acceptance gates in each sprint)
- Flag any Tier-A contradictions to watch during sprint execution

Outputs: `alignment_brief`, `tierA_anchor_summary`, `success_criteria`, `contradictions_watchlist`

---

### Phase: Backbone Tap

**Goal:** Reuse existing evidence; no re-collection if unnecessary.

Actions:
- Inherit competitor inventory, review verbatims, search-intent phrases, economic benchmarks, and behavioral proxies from Tier-A Backbone
- Flag contradictions to watch across sprints
- Note any evidence gaps that must be filled with lightweight desk research

If no Tier-A Backbone exists, conduct lightweight desk research to populate: competitor capability profiles (min 5), market sizing references (min 2), behavioral proxies (min 3). Log reduced confidence.

Outputs: `backbone_refs_used`, `contradictions_watchlist`

---

### Sprint: Strategic Bets

**Goal:** Define the 3–5 falsifiable bets that, if won, deliver the winning aspiration. Each bet requires a hypothesis and a kill criterion; each ties to a required capability from Tier-A Sprint 8.

Actions:
- Derive bet candidates from Tier-A `how_to_win_hypothesis` and `required_capabilities`
- For each candidate, write the hypothesis: "If we do X, we will achieve Y, as evidenced by Z"
- For each candidate, write the kill criterion: the observable signal that invalidates the bet; must be specific enough to trigger a decision
- Map each bet to its `required_capability` ref from Tier-A Sprint 8
- Design a proxy test for the leading bet: a behavioral signal (activation rate, adoption rate, leading indicator metric) that can be observed before full resource commitment
- Reduce to 3–5 bets; rank by kill-criterion risk (highest-risk bets need the most confidence before proceeding)

**Acceptance gates:**
- Proof minimum: ≥2 (independent sources or 1 source + 1 behavioral proxy)
- Kill criterion required on EVERY bet — no kill criterion, no bet
- Alignment with Tier-A `required_capabilities` and `how_to_win_hypothesis` required
- Proxy test required for at least the leading bet

Outputs: `bets_list`, `kill_criteria`, `proxy_test`, `claim_sheet`

---

### Sprint: Roadmap Horizons (Now/Next/Later)

**Goal:** Sequence the strategic bets into a Now/Next/Later roadmap where the ordering is justified by dependencies and kill-criterion thresholds. This is the marquee output of Tier-B.

Actions:
- Map inter-bet dependencies: which bets are prerequisites for others? Which bets provide learning gates that must fire before downstream bets begin?
- Classify each dependency type: prerequisite, risk-gate, resource-constraint, or learning-gate
- Assign bets to Now (0–6 months), Next (6–18 months), or Later (18+ months) based on the dependency map AND each bet's confidence score from Tier-A
- Write sequencing logic that cites specific dependencies and kill-criterion thresholds — this is the argumentation that makes the roadmap auditable
- Design a proxy test for the Now horizon: a leading indicator that would trigger Now→Next promotion or a bet kill before the Next horizon begins
- Surface trade-offs: where do two bets compete for the same capability or window?

**Acceptance gates:**
- Proof minimum: ≥2
- `sequencing_logic` MUST cite inter-bet dependencies and kill-criterion thresholds — an unjustified sequence fails this gate
- Dependency map required; each edge must name its type
- Alignment with Tier-A winning aspiration and planning horizon required
- Proxy test required for Now horizon

Outputs: `now`, `next`, `later`, `sequencing_logic`, `dependencies`, `proxy_test`, `claim_sheet`

---

### Sprint: Build-vs-Buy-vs-Partner

**Goal:** For each required capability from Tier-A Sprint 8, make one explicit build/buy/partner decision with evidence-backed rationale.

Actions:
- List every required capability from Tier-A Sprint 8
- For each, evaluate: build (cost, timeline, defensibility), buy (cost, integration risk, vendor lock-in), partner (strategic alignment, control, revenue share)
- Select the path that wins on at least two of: cost, speed-to-capability, defensibility, integration risk
- Write a plain-language rationale; note what you're trading away
- Flag where a "build" choice is chosen purely for control without a defensibility argument — these require additional scrutiny

**Acceptance gates:**
- Proof minimum: ≥2 per capability decision
- Rationale MUST address at least two of: cost, speed, defensibility, integration risk
- Alignment with Tier-A `economic_engine` (capacity to fund) and `how_to_win_hypothesis` (does this choice support the advantage type?) required
- "Build for control" without defensibility must be flagged

Outputs: `bbp_decisions`, `claim_sheet`

---

### Sprint: Prioritization Model

**Goal:** Score the strategic bets using impact × confidence / effort so priority is evidence-backed, not intuitive.

Actions:
- For each bet, rate impact (1–5) against Tier-A JTBD outcome importance scores and economic engine metrics — impact must be tied to a specific Tier-A claim, not asserted
- For each bet, rate confidence (1–5) from the relevant Tier-A claim sheet confidence level and proof density — high=4–5, medium=3, low=1–2
- For each bet, rate effort (1–5) from build/buy/partner rationale and required capability gap assessments — 1=lowest effort (partner/buy light), 5=highest (build complex, absent capability)
- Compute score = (impact × confidence) / effort
- Document the scoring method so it can be re-run as assumptions change
- Design a proxy test: the smallest observable signal that would shift the top-priority bet's impact or confidence rating

**Acceptance gates:**
- Proof minimum: ≥2 per rated dimension
- ALL three dimensions must be evidence-backed — ungrounded scores fail this gate
- Impact must tie to a Tier-A JTBD outcome or economic engine metric
- Proxy test required

Outputs: `prioritized_bets`, `scoring_method`, `proxy_test`, `claim_sheet`

---

### Sprint: Risk Register + Leading Indicators

**Goal:** Identify the risks that threaten Tier-A assumptions or bet success, and pair each with a leading indicator that fires before the risk materializes.

Actions:
- From Tier-A's assumption set and the bet kill criteria, identify 5–10 risks that would break the strategy
- For each risk, name the specific Tier-A assumption or bet it threatens — an unanchored risk gets ignored
- Rate likelihood (low/medium/high) and severity (low/medium/high) with evidence
- Write a `leading_indicator` — the observable early signal that fires before the risk materializes; this is the management-system hook that makes the register actionable
- Write a `mitigation` — the concrete pre-planned response to execute when the leading indicator fires; not a platitude, a decision
- Prioritize by severity × likelihood; surface the top 3 in the summary

**Acceptance gates:**
- Proof minimum: ≥2
- EVERY risk requires a `leading_indicator` — no indicator, no actionable risk entry
- EVERY risk must map to a specific Tier-A assumption it threatens
- Alignment with Tier-A `required_capabilities` and `differentiation_wedge` required

Outputs: `risk_list`, `leading_indicators`, `mitigations`, `tied_assumptions`, `claim_sheet`

---

### Phase: Integration & Packaging

**Goal:** Ensure Tier-B elements align and don't contradict Tier-A; confirm the roadmap ordering is internally consistent.

Actions:
- Run contradiction check against Tier-A anchors: any Tier-B element that conflicts with Tier-A must be revised or carry explicit boundary conditions; record in audit log
- Verify roadmap consistency: Now bets' kill criteria are observable within Now horizon; Next bets' prerequisites are all in Now or complete; Later bets' assumptions are validated by Now/Next signals
- Verify build/buy/partner decisions are consistent with economic engine capacity from Tier-A Sprint 9
- Assemble quick rationale notes and citations
- Produce a one-paragraph summary per element for handoff

Outputs: `contradiction_check`, `roadmap_consistency_check`, `rationale_notes`, `tierB_summaries`

## Sprint Dependency Map

Sprints 1–3 (Strategic Bets, Roadmap Horizons, Build-vs-Buy-vs-Partner) have a partial dependency: Roadmap Horizons requires Strategic Bets to be complete; Build-vs-Buy-vs-Partner requires the Required Capabilities list from Tier-A Sprint 8 (already available). Sprints 4–5 (Prioritization, Risk Register) can begin in parallel after Bets are drafted:

```
Tier-A Output (Layer 2)
    │
    ▼
Intake & Alignment
    │
    ▼
Backbone Tap ──┬── Sprint: Strategic Bets ──────────────────────────┐
               │       │                                             │
               │       ▼                                             │
               │   Sprint: Roadmap Horizons ────────────────────────┤
               │                                                     │
               ├── Sprint: Build-vs-Buy-vs-Partner ─────────────────┤
               │                                                     │
               ├── Sprint: Prioritization Model (after Bets) ───────┤
               │                                                     │
               └── Sprint: Risk Register (after Bets) ──────────────┤
                                                                     │
                         Integration & Packaging ◄───────────────────┘
```

**Parallelizable sets:**
- Strategic Bets must run first (Roadmap Horizons and Prioritization Model depend on it).
- Roadmap Horizons waits on Strategic Bets.
- Build-vs-Buy-vs-Partner draws on Tier-A Sprint 8 `required_capabilities` — runs independently of Bets.
- Prioritization Model waits on Strategic Bets (needs bet list).
- Risk Register waits on Strategic Bets (needs kill criteria and hypotheses).
- Integration waits on all sprints.

## Heuristics

- If you can't articulate the kill criterion in one sentence, the bet isn't specific enough
- Roadmap ordering that "feels right" must be argued — trace the dependency and name it
- Leading indicators are metrics that move before outcomes, not metrics that confirm outcomes
- Prioritize proxy tests that cost less than the decision they inform
- If two bets score identically, put the one with the faster kill criterion first — learning is itself a product

## Output Format

Deliver the final output as structured JSON conforming to the schema in `references/output-schema-tier-b.md`.

The JSON must include: `product_name`, `topic`, `audience`, `backbone_refs_used`, `tierB_results` (all 5 elements with proxy tests where applicable), `sources`, and `audit_log`.

**Forward chaining:** When this skill completes, its full output object becomes the input seed for Layer 4 (`productprint-tier-c`). Preserve the complete JSON — Layer 4 needs the strategic bets, roadmap horizons, build/buy/partner decisions, and risk register to produce deployment-ready positioning and differentiation elements. Also preserve the Tier-A JSON from Layer 2; Layer 4 needs both. If the `productprint-tier-c` skill is available, proceed directly into it without user confirmation.

## Evaluation Rubric

1. **Alignment** — Tier-B outputs reflect Tier-A winning aspiration, JTBD outcomes, required capabilities, and economic engine without contradiction
2. **Evidence** — each element meets the Tier-B proof minimum (≥2 or 1+proxy)
3. **Falsifiability** — every bet has a hypothesis AND a kill criterion; every risk has a leading indicator
4. **Sequencing rigor** — roadmap horizon ordering is justified by dependencies and kill-criterion thresholds, not intuition; unjustified order fails this dimension
5. **Scoring discipline** — prioritization model dimensions are evidence-backed; no dimension is rated from intuition alone
6. **Actionability** — risk register leading indicators are specific enough to trigger a decision, not a meeting

## File I/O Contract (orchestrated mode)

> **Note:** automated orchestrated mode is not included in this release; run the manual chain. This contract is a forward-looking specification.

When an authorized orchestrator provides explicit paths, honor them exactly:

- **Seed inputs:** read ONLY the JSON/YAML files listed in the dispatch prompt.
- **Output:** write the final JSON object to the exact path given (under `.productprint/engagements/{slug}/pass-N/`). No other location.
- **Return value:** your final message is the output path plus the layer's key artifact — not the full JSON. The orchestrator reads files, not transcripts.

When invoked as a direct skill call, present the JSON in conversation or through the supported file workflow and tell the user to preserve it for the next layer.

Referenced files: 1

View saved version →

---
name: productprint-tier-c
description: Use when the user asks for Tier-C product positioning artifacts — positioning statement, product one-liner, bet narrative, strategy on a page, deployable differentiation outputs, or Layer 4 of the Productprint stack. Also trigger on "run Tier-C," "Productprint Tier-C," "positioning statement," "product one-liner," "strategy on a page," "roadmap narrative," "bet narrative," or when the user wants deployment-ready strategy artifacts derived from existing Tier-A and Tier-B research. Use immediately when the productprint-tier-b skill has just completed — chain directly using its output as the seed.
---

# Productprint Tier-C — Deployable Positioning Artifacts Directive

Deliver 4 Tier-C positioning artifacts that are deployment-ready, derivative, and human-facing. These outputs create no new strategic claims. Every line traces back to validated Tier-A and Tier-B truths. The job of this layer is translation: take the strategy cascade and make it readable, sticky, and usable by people who were not in the room when it was built.

## When NOT to Use

- **Tier-A or Tier-B output is missing.** This layer needs both as anchors. Without them, either collect equivalent inputs from the user or run the chain from Layer 1 — don't improvise anchors.
- **Creating new strategy or new claims.** Tier-C translates and packages what Layers 2–3 validated. If the product needs a new bet, capability, or differentiation argument, that's a Tier-A or Tier-B sprint, not a Tier-C edit.
- **Long-form copywriting.** Positioning statement, one-liner, bet narrative, and strategy on a page — that's the full scope. Sales decks, website copy, and investor memos are downstream deployment work.

## Chain Position

This is **Layer 4** of a 6-layer Productprint research stack:

1. **Core Strategic Truth** (Layer 1) → foundational tension sentence, tension map, JTBD seed, archetypes, lexicon
2. **Productprint Tier-A** (Layer 2) → 10 defensible Playing-to-Win cascade elements with evidence-gated sprints
3. **Productprint Tier-B** (Layer 3) → 5 actionable strategy elements: bets, roadmap, build/buy/partner, prioritization, risk register
4. **Productprint Tier-C** (this skill) → uses Tier-A + Tier-B output as seeds; produces 4 deployable positioning artifacts ready for team handoff
5. **Thesis Stress-Test** (Layer 5) → adversarial pre-mortem gate; extracts load-bearing assumptions and tries to FALSIFY them; returns PROCEED if they survive or REFINE (with a constraint package) if one falls
6. **Strategy Thesis Compiler** (Layer 6) → compiles all layers into a consulting-grade integrated strategy thesis deliverable

**When Layer 3 has just completed:** Import the full Tier-B output JSON and the Tier-A JSON carried forward. Pull positioning anchors — `winning_aspiration`, `where_to_play_map`, `how_to_win_hypothesis`, `required_capabilities`, `differentiation_wedge` from Tier-A; `strategic_bets`, `roadmap_horizons`, and `risk_register` leading indicators from Tier-B. Do not create new claims or re-research.

**When running standalone:** Resolve all variables with the user. If no Tier-A/B anchors exist, ask the user to provide equivalent inputs (winning aspiration, where-to-play selection, how-to-win hypothesis, required capabilities, differentiation wedge, bet list, risk leading indicators) or recommend running the full chain first.

## Variables to Resolve

Before starting, confirm these with the user (or inherit from Layers 1–3):

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `product_name` | The product, platform, or solution being positioned | *required* |
| `topic` | Product or category scope | *required* |
| `category` | The category frame the product competes in | *required* (or from Tier-A) |
| `audience` | Primary buyer/operator audience definition | *required* (or from Layer 2) |
| `region_context` | Geography or cultural context | US / English-speaking |
| `constraints` | Legal, brand safety, or strategic constraints | None |
| `languages` | Output language | English |
| `mode` | `rapid`, `standard`, or `enterprise` | `standard` |
| `tierA_anchor_ref` | Link or ID for Tier-A output | From Layer 2 if chained |
| `tierB_anchor_ref` | Link or ID for Tier-B output | From Layer 3 if chained |

## Principles (Non-Negotiable)

1. **Alignment first.** Every artifact must trace to Tier-A's cascade (winning aspiration, where-to-play, how-to-win, required capabilities, differentiation wedge) and Tier-B's strategy elements (bets, roadmap, risk leading indicators).
2. **Clarity over clever.** Plain language. Sixth-grade readability for public-facing lines. Zero internal jargon in the positioning statement and one-liner.
3. **No new claims.** If a line implies a capability, proof, or benefit not present in Tier-A or Tier-B, it is a new claim — reword or remove it.
4. **Translation, not reframing.** Strategy-on-a-page fields are translated from Tier-A/B, not synthesized fresh. Plain-language rewording is allowed; strategic reinterpretation is not.
5. **Comprehension gates are real gates.** The positioning statement and one-liner each require an explicit comprehension check. A check that says only "pass" without evidence fails the gate.

## Quality Gates (Global)

- Plain-language comprehension check for positioning statement and product one-liner
- Alignment check against Tier-A and Tier-B anchors for all 4 artifacts
- Word-count gate: product one-liner must be ≤25 words — over-length fails
- `bet_narrative.named_bets[].bet_ref` must reference an existing Tier-B bet — unanchored refs fail
- `strategy_on_a_page` fields must cite their Tier-A/B source field explicitly in the audit log

**Mode adjustments:**
- *Rapid:* One pass, one variant per element; single comprehension check
- *Standard:* Three variants for the one-liner; two variant wordings for the positioning statement; comprehension check for both
- *Enterprise:* Three positioning statement variants, five one-liner variants, cross-language comprehension check, and a mini translation rationale per artifact

## What NOT to Do

- Do not contradict Tier-A or Tier-B
- Do not invent a differentiator, proof point, or capability that does not exist in the Tier-A equity ladder or Tier-B bet list
- Do not use internal strategy vocabulary (winning aspiration, JTBD, kill criterion, economic engine) in the positioning statement, one-liner, or bet narrative — translate them out
- Do not use cliches or em dashes in positioning copy; keep punctuation simple
- Do not exceed 25 words in `product_one_liner.final` — this is a hard gate, not a guideline
- Do not reference a bet in `bet_narrative.named_bets` that does not exist in Tier-B's `strategic_bets` or `roadmap_horizons` — route new bets back through Tier-B
- Do not coin a new category frame inside a Tier-C sprint — if category reframing is needed, that is a Tier-A naming sprint
- Do not write the strategy-on-a-page `aspiration`, `where_to_play`, `how_to_win`, or `capabilities` fields from memory — pull and translate the exact Tier-A source text

## Workflow

### Phase 0: Intake and Anchor Pull

**Goal:** Load Tier-A and Tier-B anchors and constraints.

Actions:
- Load from Tier-A: `winning_aspiration`, `where_to_play_map` (selected options), `how_to_win_hypothesis`, `required_capabilities`, `differentiation_wedge`
- Load from Tier-B: `strategic_bets` list (names, hypotheses, kill criteria), `roadmap_horizons` (Now/Next/Later assignments), `risk_register` top leading indicators (by severity × likelihood)
- List any legal, cultural, or language constraints
- Build a short anchor summary: one line per pulled element, with its source field noted

Outputs: `anchor_summary`, `constraints_list`

---

### Phase 1: Derivation Map

**Goal:** Map each Tier-C artifact to its Tier-A and Tier-B parent fields before drafting begins.

Actions:
- Create a short matrix: each Tier-C artifact → the specific Tier-A and Tier-B fields it derives from
- Flag any possible contradictions or gaps for review before sprint execution begins

Outputs: `derivation_matrix`, `contradictions_watchlist`

---

### Sprint: Positioning Statement

**Goal:** Distill the product's position into a single structured sentence that a buyer can parse in one read, using the For-Who-Is-The-That-Because template.

Template: "For [segment] who [need], [product] is the [category] that [differentiator] because [proof]."

Actions:
- Pull the primary segment from Tier-A `segments_wtp`; pull the primary need from Tier-A `jtbd_outcomes` (top outcome)
- Pull the category frame from Tier-A `category_definition_sizing`
- Pull the differentiator from Tier-A `differentiation_wedge`
- Pull the proof from the Tier-A claim sheet with the highest confidence score
- Draft 2 positioning statement variants in standard mode (1 in rapid, 3 in enterprise)
- Run a comprehension check on the selected variant: "Would a non-expert buyer understand this in one read? Note any jargon or confusion points." Pass requires an explanation, not just the word "pass."
- Remove or translate any internal strategy vocabulary

**Acceptance gates:**
- Template structure must be present (For-Who-Is-The-That-Because)
- `[differentiator]` must trace to Tier-A `differentiation_wedge`
- `[proof]` must trace to a Tier-A claim sheet entry with evidence
- Comprehension check required — explicit pass/fail verdict with notes

Outputs: `positioning_statement_variants`, `final_positioning_statement`, `comprehension_check`, `claim_sheet`

---

### Sprint: Product One-Liner

**Goal:** Write the single ≤25-word sentence that explains what the product does and who benefits — not a slogan, but the clearest possible description of the product's value.

Actions:
- Pull the core JTBD outcome (top outcome from Tier-A `jtbd_outcomes`) and the primary segment
- Draft at minimum 3 variants in standard mode (1 in rapid, 5 in enterprise); every variant must be ≤25 words
- Remove all internal vocabulary; keep verbs active and concrete
- Run a comprehension check on the selected final: confirm ≤25 words, plain language, readable by a non-expert
- Select the final variant; confirm word count explicitly in the comprehension check

**Acceptance gates:**
- Hard limit: `final` is ≤25 words — over-limit fails this gate without exception
- Must describe what the product does and who benefits — slogans that skip the "what" fail
- Comprehension check required — must state word count and a pass/fail verdict with notes
- Alignment with Tier-A winning aspiration and primary JTBD outcome required

Outputs: `one_liner_variants`, `final_one_liner`, `comprehension_check`, `claim_sheet`

---

### Sprint: Bet Narrative

**Goal:** Write a buyer-readable story that explains what the product is betting on, why those bets are sequenced the way they are, and what winning looks like — without using internal strategy vocabulary.

Actions:
- Pull the bet list from Tier-B `strategic_bets`; pull the Now/Next/Later sequence from Tier-B `roadmap_horizons`
- Write 1–3 paragraphs that tell the story of the roadmap: what the product is doing first and why, what it will do next once the first bets land, and what the longer-term vision looks like when all bets compound
- Give each bet a plain-English public name (≤6 words) for use in external communications; record the `bet_ref` that maps it back to its Tier-B artifact
- Translate kill criteria and hypothesis language into buyer-readable cause-and-effect logic — do not use the words "kill criterion" or "hypothesis" in the narrative
- Remove any capability references that would reveal internal competitive strategy not meant for public disclosure; flag these in the audit log

**Acceptance gates:**
- `named_bets[].bet_ref` must reference an existing Tier-B bet or roadmap horizon — unanchored refs fail
- Story must flow in logical sequence consistent with Tier-B roadmap ordering — a narrative that contradicts the Now/Next/Later sequence fails
- No internal strategy vocabulary in the public story text
- Alignment with Tier-A `winning_aspiration` required — the narrative must point toward the same end state

Outputs: `bet_narrative_draft`, `named_bets`, `claim_sheet`

---

### Sprint: Strategy on a Page

**Goal:** Assemble the Playing-to-Win cascade and the top risk signals into a single-screen summary that lets any stakeholder understand the strategy without reading Layers 1–3.

Actions:
- Pull and translate (not re-synthesize) the following Tier-A fields:
  - `aspiration` ← `winning_aspiration.ambition` (one sentence)
  - `where_to_play` ← `where_to_play_map` selected options (plain-language summary, ≤2 sentences)
  - `how_to_win` ← `how_to_win_hypothesis` (plain-language summary, ≤2 sentences)
  - `capabilities` ← `required_capabilities` (3–5 capabilities, each ≤10 words)
- Pull and translate the top 3 Tier-B `risk_register` leading indicators (by severity × likelihood) into `must_track` entries; write a one-sentence rationale per indicator explaining why it is the right signal to watch
- Verify that all five field groups are internally consistent — if a capabilities list contradicts the how-to-win, flag it
- The output should be renderable on one slide or one printed page; brevity is the design constraint

**Acceptance gates:**
- All four pull fields must cite their source Tier-A/B field in the audit log — fields written from memory fail
- `must_track` entries must reference Tier-B `risk_register` leading indicators, not new ones invented here
- Internal consistency check required: `where_to_play` × `how_to_win` × `capabilities` must be coherent
- Comprehension: a stakeholder unfamiliar with Layers 1–3 must be able to understand the page without a glossary

Outputs: `strategy_on_a_page_draft`, `must_track_list`, `claim_sheet`

---

### Phase: Integration and Packaging

**Goal:** Assemble clean, ready-to-hand-off Tier-C outputs; verify all four artifacts are internally consistent and align with Tier-A/B anchors.

Actions:
- Run final alignment check across all 4 artifacts: verify each traces to its Tier-A/B anchor and carries no new claims
- Verify the four artifacts tell the same story — the positioning statement, one-liner, bet narrative, and strategy-on-a-page must be consistent with each other
- Package final variants and notes with simple usage guidance per artifact
- Update the derivation matrix with final source references

Outputs: `alignment_check`, `consistency_check`, `tierC_one_pagers`, `final_derivation_matrix`

> **Session-only artifacts:** `anchor_summary` (Phase 0), `contradictions_watchlist` (Phase 1), and `final_derivation_matrix` (Integration) are working artifacts used during the sprint session. They are NOT persisted to the output JSON. The persisted form of the derivation mapping is the top-level `derivation_matrix` array in the output schema; populate it during Integration from the session `final_derivation_matrix`.

## Sprint Dependency Map

Sprints 1–4 can run in parallel once the Derivation Map is complete; Integration waits for all four:

```
Tier-A Output (Layer 2) + Tier-B Output (Layer 3)
    │
    ▼
Intake and Anchor Pull
    │
    ▼
Derivation Map ──┬── Sprint: Positioning Statement ──────────┐
                 │                                           │
                 ├── Sprint: Product One-Liner ──────────────┤
                 │                                           │
                 ├── Sprint: Bet Narrative ──────────────────┤
                 │                                           │
                 └── Sprint: Strategy on a Page ─────────────┤
                                                             │
                        Integration and Packaging ◄──────────┘
```

All 4 core sprints can run in parallel after the Derivation Map. Integration waits for all to complete.

## Heuristics

- If the positioning statement takes more than one read, it is not done yet
- If the one-liner could describe three other products, it is not specific enough
- If a bet name sounds like internal vocabulary, translate it
- The strategy-on-a-page should make someone want to ask a question, not need one answered
- If two variants of the one-liner tie, keep the one with the active verb and the named audience

## Output Format

Deliver the final output as structured JSON conforming to the schema in `references/output-schema-tier-c.md`.

The JSON must include: `product_name`, `tierC_results` (all 4 elements), `sources`, and `audit_log`.

**Forward chaining:** When this skill completes, proceed into `thesis-stress-test` (Layer 5), passing Tier-A + Tier-B + Tier-C JSON. Layer 5 is the adversarial pre-mortem gate — it extracts every load-bearing assumption embedded in the strategy and tries to FALSIFY the highest-fragility one using disconfirmation queries. If the assumption survives a genuine attack, the verdict is PROCEED and the chain continues to Layer 6. If the falsification pass finds a fact that breaks the assumption, the verdict is REFINE — the gate emits a constraint package (broken assumption + what it changes + rebuild boundaries), and Layers 1–4 re-run with that package injected as a hard constraint, producing a truth-hardened strategy.

If the user wants to skip Layer 5 and go directly to the report, proceed to the `strategy-thesis-compiler` skill (Layer 6). Note that skipping the stress-test risks shipping positioning that collides with an entrenched competitor or bets that do not survive adversarial scrutiny.

## Evaluation Rubric

1. **Alignment** — every Tier-C artifact traces to Tier-A cascade fields and Tier-B strategy elements; no artifact introduces new claims
2. **Clarity** — positioning statement and one-liner pass the comprehension check; no jargon for an external audience
3. **Brevity** — one-liner is ≤25 words; strategy-on-a-page fits one screen or printed page
4. **Traceability** — derivation matrix is complete; `bet_ref` fields map to real Tier-B artifacts; strategy-on-a-page fields cite their source Tier-A/B fields in the audit log
5. **Consistency** — all four artifacts tell the same strategic story; no artifact contradicts another or contradicts the Tier-A/B cascade
6. **Deployability** — outputs are ready to paste into a deck, website, or investor brief without further strategy revision

## File I/O Contract (orchestrated mode)

> **Note:** automated orchestrated mode is not included in this release; run the manual chain. This contract is a forward-looking specification.

When an authorized orchestrator provides explicit paths, honor them exactly:

- **Seed inputs:** read ONLY the JSON/YAML files listed in the dispatch prompt.
- **Output:** write the final JSON object to the exact path given (under `.productprint/engagements/{slug}/pass-N/`). No other location.
- **Return value:** your final message is the output path plus the layer's key artifact — not the full JSON. The orchestrator reads files, not transcripts.

When invoked as a direct skill call, present the JSON in conversation or through the supported file workflow and tell the user to preserve it for the next layer.

Referenced files: 1

View saved version →

---
name: sales-simulator
description: Practice arena for sales roleplay, pitch stress-testing, and objection drills. Use when the user wants to practice a pitch, simulate a sales call, run objection drills, or get coaching on a real call. Triggers on "sales roleplay," "practice my pitch," "objection practice," "sales coaching," "mock sales call," "stress test my pitch," "play the buyer," "sales simulation." Distinct from pitching-pivot (which teaches the methodology) — this skill IS the practice arena with structured scenarios, scoring, and coaching feedback.
---

# Sales Simulator

The practice arena. `pitching-pivot` is the playbook. This is the field. You do not get good at sales by reading about sales — you get good by doing reps against someone who will not go easy on you.

## Core Philosophy

Question-first discovery: the seller never pitches — they ask questions until the prospect closes themselves. That is what is being practiced here.

The scoring rubric rewards questions over statements. It penalizes premature pitching. It measures whether the buyer stated the ROI, or whether the seller did.

## When NOT to Use

- **You need the methodology, not reps.** `pitching-pivot` is the playbook; this is the field. If you do not yet know the five pivot steps and the objection handles, the simulator will just score you failing them. Learn the framework first, then come here to drill it.
- **You are prepping a specific real call.** `pitching-pivot` prep mode builds the pivot script with anticipated objections for a named prospect. The simulator trains general instincts against personas, not a script for Thursday's meeting.
- **The problem is outreach mechanics.** Low opens, zero replies, deliverability, subject lines — that is `outreach-diagnosis`. This skill scores live conversations; it cannot tell you why nobody is replying to your emails.
- **As a full replacement for live call review.** Debrief mode scores a transcript against the four dimensions, but it cannot hear tone, pacing, or what the buyer's silence meant. Use it alongside real call recordings and peer review, not instead of them.

Determine which mode to run:

| Mode | Trigger | Output |
|------|---------|--------|
| `scenario` | "play a buyer," "let's do a roleplay," "practice with me" | Live interactive simulation with a defined persona |
| `gauntlet` | "gauntlet," "5 rounds," "give me a challenge," "stress test" | 5 escalating scenarios, scored, with final report |
| `debrief` | "debrief this call," "analyze this transcript," "what did I miss" | Diagnosis of a real call + coaching recommendations |

If mode is unclear, ask: "Which mode — scenario (one deep practice run), gauntlet (5 rapid rounds), or debrief (analyze a real call)?"

---

## Mode 1: Scenario

### Setup

Before starting, collect or build the persona:

**Persona inputs:**
- Industry (tech, food/bev, professional services, retail, nonprofit, etc.)
- Company size (solopreneur / 2-10 / 10-50 / 50-200 / enterprise)
- Buyer title (founder, marketing director, ops manager, procurement, etc.)
- Primary concern (what they say they want)
- Personality archetype (see below)
- Budget signal (none given / vague / constrained / flexible)

If the user provides minimal context, generate a persona using the Persona Template below. Ask: "Want me to pick a persona for you or describe who you are selling to?"

### Persona Template

```
PERSONA: [Name, Title, Company]
Industry: [sector]
Company size: [range]
Primary concern (stated): [what they say they need]
Hidden objection (unstated): [what they are really worried about — never reveal until earned]
Budget authority: [full / partial / none — must go upstairs]
Personality archetype: [analytical / driver / amiable / expressive]
Difficulty: [easy / moderate / hard / brutal]
```

### Personality Archetype Behavior Rules

**Analytical** — Data-driven, skeptical, moves slowly. Responds to proof, not enthusiasm. Asks "how do you measure that?" Silence is not discomfort — it is processing. Hard to read. Will not close until all questions are answered. Never volunteers information.

**Driver** — Time-pressured, direct, impatient. Interrupts. Says "get to the point." Respects confidence. Will end the call if it feels like a waste. Hates small talk. Responds to ROI and speed. Can be won by matching their directness.

**Amiable** — Relationship-first, conflict-averse, slow to decide. Deflects with "let me think about it" instead of real objections. Needs to feel safe, not sold. Responds to case studies and peer validation. The hidden objection is almost always fear of making the wrong call.

**Expressive** — Enthusiastic, big-picture, easily distracted. Says "I love this" and then forgets to follow up. Agrees to everything in the room, nothing outside it. The sell is real buy-in, not surface excitement. Gets pulled back in with story and vision.

### Running the Scenario

1. State the persona in a brief block (visible to the user — this is the setup card)
2. Open the scene: describe where they are in the conversation (cold intro, warm referral, follow-up after a deck, re-engagement)
3. The model speaks as the buyer. Stay in character. Be difficult.
4. After each exchange, the model breaks character with a brief coaching note:
   - What landed
   - What missed
   - One alternative line to try
5. Continue until the user closes, loses the deal, or calls it
6. End with the Session Scorecard

### Buyer Realism Rules

These make the simulation hard enough to be useful:

- Raise the hidden objection only after 3+ exchanges, and only if the user has earned trust through questions
- Never volunteer information the buyer would not volunteer in real life
- If the user pitches features or explains services unprompted, deflect or get colder
- If the user asks genuine discovery questions, reward with information
- Match the archetype's communication style precisely — short answers for Driver, long tangents for Expressive, silence for Analytical
- Use real industry language, not generic placeholders
- At least one objection must be price or budget
- At least one objection must be a competitor reference ("we talked to [Agency X] and they quoted half that")

---

## Mode 2: Gauntlet

5 rounds, escalating difficulty. Fast pace — no extended debrief mid-round, just a one-line coaching note after each exchange.

### Round Structure

| Round | Difficulty | Archetype | Scenario Type |
|-------|------------|-----------|---------------|
| 1 | Easy | Amiable | Warm referral, open budget, single decision-maker |
| 2 | Moderate | Expressive | Inbound interest, vague budget, buying committee |
| 3 | Moderate | Driver | Cold intro, constrained budget, prior agency disappointment |
| 4 | Hard | Analytical | RFP process, technical objections, must prove ROI before any meeting |
| 5 | Brutal | Driver + Procurement | Price war, multi-vendor evaluation, price anchor already set by a competitor |

### Gauntlet Rules

- Each round: 4-6 exchanges maximum, then a score
- The user must attempt a close in every round (partial credit if it is a soft close vs. a hard close)
- The model plays each buyer distinctly — no blending archetypes
- Rounds 4 and 5: the model references competitors by name using clearly fictional or generic examples such as "the bigger agency in town" or "the freelancer who does it for $500"

### Gauntlet Scoring

Each round scored on 4 dimensions (1-5 each, 20 points per round, 100 total):

| Dimension | What It Measures | 5 = | 1 = |
|-----------|-----------------|-----|-----|
| Question ratio | Questions vs. statements | Mostly questions throughout | Mostly statements, minimal discovery |
| Pivot speed | How fast the commodity ask was reframed | Within 2 exchanges | Never reframed — quoted the service |
| Value source | Who stated the ROI | Buyer stated it unprompted | Seller stated it, buyer did not confirm |
| Close quality | How the close was attempted | Low-friction question ("What would need to be true to move forward?") | Hard ask ("Can we get a deposit today?") or no close attempt |

After all 5 rounds: full Gauntlet Report (see Output Formats).

---

## Mode 3: Debrief

Analyze a real call. The user provides notes, a transcript, or a summary of what happened.

### Debrief Process

1. Read the input fully before commenting
2. Identify the key moments:
   - First commodity ask (the moment the prospect named the thing they wanted)
   - First pivot attempt (did it happen? when?)
   - Objection moments (what were they, how were they handled)
   - Close attempt (was there one? what was it?)
3. Score on the same 4 dimensions as the Gauntlet (1-5 each)
4. Identify missed pivots — specific exchanges where a question could have reframed the conversation
5. Identify the hidden objection — if never uncovered, name it and explain what question would have surfaced it
6. Coaching recommendations (see Output Formats)

---

## Scoring Framework

### The Four Dimensions

**1. Question-to-Statement Ratio**
Target: 3 questions for every 1 statement. Count actual questions asked vs. statements/explanations made. If the seller is talking more than the buyer, something is wrong.

- 5: Ratio meets or exceeds 3:1. Buyer is talking 65%+ of the time.
- 4: Ratio around 2:1. Mostly questions with some necessary context.
- 3: Roughly even — some good questions but too many explanations.
- 2: Seller dominated. More pitching than asking.
- 1: No meaningful discovery. Seller presented a solution without understanding the problem.

**2. Pivot Speed**
How many exchanges before the conversation shifted from "what do you want to buy" to "what outcome are you trying to achieve."

- 5: Pivoted within the first exchange. Never quoted a service unprompted.
- 4: Pivoted by exchange 2-3. Briefly acknowledged the ask, then redirected.
- 3: Pivoted mid-conversation. Some commodity framing happened first.
- 2: Pivoted late or incompletely. Most of the conversation was about the service.
- 1: Never pivoted. Quoted the commodity, stayed in commodity frame.

**3. Value Source**
Who articulated the ROI — the buyer or the seller?

- 5: Buyer stated a specific number, outcome, or "if we fix this, here is what it means" without being told.
- 4: Buyer articulated value after a good discovery question surfaced it.
- 3: Seller reflected value back and buyer confirmed.
- 2: Seller stated the value. Buyer was passive.
- 1: No value conversation. Deal discussed purely in terms of scope and price.

**4. Close Quality**
How the conversation ended or was attempted.

- 5: Low-friction close question. "What would need to be true to move forward?" / "What is the right next step from your end?"
- 4: Soft close with clear next step. "Can we schedule a consultative discovery call this week?"
- 3: Weak or vague close. "Let me know if you want to talk more."
- 2: Aggressive or premature close. Pushed for decision before trust was earned.
- 1: No close. Conversation ended without a defined next step.

---

## Output Formats

### Session Scorecard (Scenario Mode)

```
SALES SIMULATOR — SESSION SCORECARD
Buyer: [Name, Title, Company]
Archetype: [type]
Difficulty: [level]
Exchanges: [count]
Outcome: [Deal advanced / Stalled / Lost / Closed]

SCORES
Question-to-Statement Ratio:  [1-5] — [one-line note]
Pivot Speed:                  [1-5] — [one-line note]
Value Source:                 [1-5] — [one-line note]
Close Quality:                [1-5] — [one-line note]
TOTAL:                        [X/20]

WHAT WORKED
- [specific exchange or technique that landed]
- [specific exchange or technique that landed]

WHAT TO FIX
- [specific missed moment with context]
- [specific missed moment with context]

3 THINGS TO PRACTICE NEXT SESSION
1. [specific drill or focus area]
2. [specific drill or focus area]
3. [specific drill or focus area]
```

### Gauntlet Report (Gauntlet Mode)

```
GAUNTLET REPORT
Date: [date]
Rounds Completed: [X/5]

ROUND SCORES
Round 1 (Easy / Amiable):     [X/20]
Round 2 (Moderate / Expressive): [X/20]
Round 3 (Moderate / Driver):  [X/20]
Round 4 (Hard / Analytical):  [X/20]
Round 5 (Brutal / Procurement): [X/20]
TOTAL:                         [X/100]

DIMENSION BREAKDOWN
Question-to-Statement Ratio:  [avg] — [pattern note]
Pivot Speed:                  [avg] — [pattern note]
Value Source:                 [avg] — [pattern note]
Close Quality:                [avg] — [pattern note]

PATTERNS IDENTIFIED
Strengths: [what consistently worked across rounds]
Vulnerabilities: [what consistently broke down]

HARDEST MOMENT
[The specific exchange that exposed the biggest gap — quote it]

3 THINGS TO DRILL BEFORE NEXT GAUNTLET
1. [specific]
2. [specific]
3. [specific]
```

### Debrief Report (Debrief Mode)

```
CALL DEBRIEF
Source: [transcript / notes / summary]
Prospect: [name, company if known]

SCORES
Question-to-Statement Ratio:  [1-5]
Pivot Speed:                  [1-5]
Value Source:                 [1-5]
Close Quality:                [1-5]
TOTAL:                        [X/20]

MISSED PIVOTS
[Exchange where a pivot could have happened]
→ What was said: [quote or paraphrase]
→ Better move: [specific question or reframe]

[Repeat for each missed moment]

HIDDEN OBJECTION
[Name the unstated fear driving the buyer's resistance]
→ Question that would have surfaced it: [exact question]

COACHING NOTES
- [specific behavioral note]
- [specific behavioral note]
- [specific behavioral note]

3 THINGS TO PRACTICE BEFORE THE NEXT SIMILAR CALL
1. [specific]
2. [specific]
3. [specific]
```

---

## Chain Integration

**Upstream:** Uses `pitching-pivot` as the scoring rubric. The five pivot steps and objection handles in that skill are what this simulator is training. When a score is low on Pivot Speed, reference the specific framework step from `pitching-pivot`.

**Discovery gap:** If scores reveal weak discovery (low question ratio, seller stated the value), recommend practicing consultative discovery techniques — specifically asking one open question and listening for 5 full minutes without redirect, then synthesizing before asking the next question.

**Example chain recommendation:**
> "Your question ratio was 1.2:1 in Round 3. Practice the 'First Five' drill: ask one open question and listen for 5 full minutes without redirect. Then synthesize what you heard before asking the next question."

---

## Persona Library — Ready-to-Use

Use these when the user does not provide a persona or wants to jump straight in.

**Persona A — The Skeptical Founder**
Title: Founder/CEO, B2B SaaS startup
Size: 8 employees, Series A pending
Primary concern: "We need a new website before our investor pitch"
Hidden objection: Last agency burned them — late, over-budget, missed the brief entirely
Budget authority: Full, but has been told to watch burn rate
Archetype: Driver
Difficulty: Hard

**Persona B — The Procurement Gatekeeper**
Title: Marketing Director, regional healthcare network
Size: 300 employees
Primary concern: "We have an RFP out and you came recommended"
Hidden objection: Already has a preferred vendor, using RFP for price leverage
Budget authority: None — committee of 5, CFO has final call
Archetype: Analytical
Difficulty: Brutal

**Persona C — The Enthusiastic Distractor**
Title: Co-founder, DTC food brand
Size: 4 employees
Primary concern: "We want to blow up on social media, maybe a rebrand too"
Hidden objection: Not sure who owns brand decisions — co-founder has different vision
Budget authority: Partial — anything over $5K needs partner sign-off
Archetype: Expressive
Difficulty: Moderate

**Persona D — The Comfortable Drifter**
Title: Owner, regional service business (HVAC, roofing, etc.)
Size: 12 employees
Primary concern: "Our website is outdated and we've been losing leads"
Hidden objection: Happy enough with status quo — reached out because someone pushed them to
Budget authority: Full, conservative
Archetype: Amiable
Difficulty: Easy

**Persona E — The Budget Anchor**
Title: VP Marketing, mid-market manufacturer
Size: 150 employees
Primary concern: "We need brand refresh — got a quote from another agency for $4,500"
Hidden objection: Under-resourced internally, afraid of a project they cannot manage
Budget authority: Up to $10K, anything above needs C-suite
Archetype: Analytical
Difficulty: Hard

View saved version →

---
name: story-spine
description: Apply the Story Spine + Emotional Heat Map framework (MM-002) for narrative content. Use when writing origin stories, case slices, LinkedIn posts, founder essays, client wins, or any piece that must hold attention. Triggers on "story spine," "emotional heat map," "establishing shot," "inciting friction," "line surgery," "camera work," "six beats," "case slice narrative," or when content needs stronger hooks, sensory detail, or a clear narrative arc. Includes 6-beat structure, emotion mapping, LinkedIn patterns, revision checklists, and QA rubric.
---

# Story Spine + Emotional Heat Map (MM-002)

A fast, repeatable way to write stories that land. Start with a clear frame, raise stakes on purpose, choose under pressure, show the fallout, and end with meaning a stranger can use tomorrow.

## When to Use

- Origin stories, case slices, client wins, "why we do it" notes
- LinkedIn posts, case-study intros, founder essays, short scripts
- Any piece that must hold attention without fluff

## When NOT to Use

- Not for non-narrative content — framework posts, contrarian takes, and taxonomies run through `linkedin-authority`.
- Not for de-AI-ing existing text — that's `humanize`.
- Not for ideation or concept generation — get the idea with `creative-thinking-ai`, then spine the story.
- Not for pieces with no real event behind them — the beats demand a true scene, choice, and cost. Don't fabricate one.

## The Spine in One View

```
1. Establishing Shot → 2. Friction → 3. Close-ups → 4. Choice → 5. Consequence → 6. Meaning
      where/when        what threatens    details+constraint   costly decision   immediate change   one-line lesson
```

Keep outcome unknown until the final 10–15%.

## The Six Beats

### 1) Establishing Shot
**Goal:** Orient the reader in one line.
**Formula:** Year, city, age or role, scene.
**Example:** 1996, Portland. Age 21. Office manager in title, runner in reality.

### 2) Inciting Friction
**Goal:** Name the pressure that threatens something you care about.
**Prompts:** What specific event kicked this off? What would you lose if you froze?
**Example:** The boss walked in reeking of last night's whiskey. A client call had been missed. Rent was due Friday.

### 3) Escalation in Close-ups
**Goal:** Pull the camera in. Two sensory details. One constraint that tightens the screws.
**Prompts:** What did you see, smell, hear, touch? What timer or limit made it worse?
**Example:** Collar wilted. Eyes glassy. Phone lines blinking. Ninety-two applications already out. Silence.

### 4) Decision Under Pressure
**Goal:** Show the costly choice. State it clean.
**Prompt:** What did you do that had a cost this week?
**Example:** I slid my badge across the desk and said, "I'm done."

### 5) Immediate Consequence
**Goal:** Show what changed in the next day or week. A bruise or a win, not a life story.
**Example:** Eight interviews. Same line each time: "Come back with two years of experience." Then a one-inch ad offering on-the-job training.

### 6) Meaning After the Dust
**Goal:** One sentence a stranger can use.
**Prompts:** What truth did the moment prove? How would someone act differently after reading this?
**Example:** When the room you are in is shrinking you, step into the one where effort is the currency.

## Emotional Heat Map

Target one primary emotion per paragraph. If a paragraph has no emotion, cut it.

| Paragraph | Emotion Target | Signals |
|-----------|---------------|---------|
| 1 | Orientation with unease | Time, place, role, a small off note |
| 2 | Tension rising | Named threat and what is at risk |
| 3 | Anxiety or pressure | Sensory detail and hard constraint |
| 4 | Resolve | Clear choice with a cost |
| 5 | Aftershock | Immediate bruise or first win |
| 6 | Relief or resolve | Useful lesson without preaching |

## Camera Work on the Page

- Start wide. One line.
- Move tighter each beat.
- If you jump tight too early, readers don't know where they are.
- If you stay wide, nobody cares.

## Line Surgery: Generic → Specific

- "I quit my job." → "On a Tuesday before rent was due, I slid my badge across a sticky laminate desk."
- "He was an alcoholic." → "He arrived at 8:12 a.m., breath sweet with whiskey, collar wilted, eyes glassy."
- "An ad promised opportunity." → "A one-inch classified offered sales, on-the-job training, and a phone that would not stop ringing."

## 200-Word LinkedIn Pattern

**[Line 1: Establishing shot.]** Year, city, role. One honest detail.

**[Lines 2–4: Friction.]** Name the threat and the stake. Keep verbs active.

**[Lines 5–7: Close-ups.]** Two sensory details. One constraint that hurts.

**[Line 8: Choice.]** Write the decision in a single sentence.

**[Lines 9–11: Consequence.]** Show what changed that week. A bruise or a win.

**[Final line: Meaning.]** One sentence a stranger can act on tomorrow.

## Fill-In Template

- Title
- Hook line
- Purpose emotion
- Establishing shot: time, place, role
- Sensory detail 1
- Sensory detail 2
- Constraint or timer
- Choice line
- Consequence week-one
- Lesson in one sentence
- CTA
- Channel
- Thumbnail concept

## Five-Minute Revision Checklist

- Cut abstractions: opportunity, journey, growth. Replace with what was seen or said.
- Keep relief to the end.
- Paragraphs under three lines. Sentences under 20 words unless rhythm needs one longer.
- Verbs with spine: slid, reeked, tallied, flinched, stayed.
- Read aloud. Where you stumble, cut or split.
- Outcome unknown until the last lines.

## QA Rubric (Score 0–5 Each)

- Hook clarity
- Stakes clarity
- Sensory proof
- Costly choice stated
- Consequence shown within a week
- One-line meaning that is useful

Ship at 20+. Rework if under 18.

## Common Failure Modes

- **All summary, no scene.** Fix: Add two sensory details and a constraint in paragraph 3.
- **Relief too early.** Fix: Move the lesson to final paragraph. Raise stakes in the middle.
- **Vague verbs.** Fix: Replace "was," "went," "had" with concrete actions.
- **No cost.** Fix: State what you risked that week. Money, time, status.

## Variants

- **Micro-post (under 120 words):** Beats 1, 2, 4, 6 only.
- **Carousel:** One beat per slide. Final slide is the lesson.
- **Short video:** VO lines mirror beats. B-roll matches the sensory details.

View saved version →

---
name: strategy-thesis-compiler
description: Use when all Productprint layers are complete and the user needs the final consulting-grade integrated strategy thesis — Layer 6 of the Productprint stack. Trigger when the user asks to compile the Productprint into a strategy thesis report, create the integrated strategy deliverable, generate a where-to-play how-to-win report, produce the consulting-grade thesis document, or finalize the strategy for a client or internal audience. Also trigger on "compile the thesis," "final strategy report," "integrated strategy deliverable," "strategy thesis document," "Productprint report," or "Layer 6." If the thesis-stress-test skill has just completed with a PROCEED decision, move directly into this skill without waiting for user confirmation.
---

# Strategy Thesis Compiler — Consulting-Grade Integrated Thesis Directive

Assemble all Productprint outputs (Layers 1–5) into a single, cohesive Integrated Strategy Thesis formatted to the standard of top-tier strategy consultancies (Strategy&, EY-Parthenon, Monitor Deloitte, KPMG Strategy). The report is not a summary — it is a synthesis. It resolves contradictions, builds arguments across layers, and delivers a document that a leadership team, board, or investor can act on.

## When NOT to Use

- **Layers are incomplete.** Layers 1–4 are required inputs. Layer 5 (Thesis Stress-Test) is strongly recommended. If Layer 5 is missing, the report must disclose that adversarial validation was not performed and surface the unvalidated load-bearing assumptions — do not compile silently around the gap.
- **Generating new strategy content.** This layer synthesizes what Layers 1–5 produced. If a section needs claims or evidence that do not exist upstream, run the missing layer — do not write it here.
- **Quick one-page summaries.** For a brief, pull the executive summary structure manually. This skill's floor output is 15–20 pages in rapid mode.
- **A REFINE verdict is pending from Layer 5.** Do not compile around an unresolved REFINE. The Assumption-Test Log section must expose the broken assumption and the constraint package — not present a failed thesis as validated.

## Chain Position

This is **Layer 6** — the terminal layer of the Productprint research stack. It consumes ALL upstream JSON (Layers 1–5):

1. **Core Strategic Truth** (Layer 1) → foundational tension sentence, tension map, JTBD seed, archetypes, lexicon
2. **Productprint Tier-A** (Layer 2) → 10 Playing-to-Win cascade elements with claim sheets
3. **Productprint Tier-B** (Layer 3) → strategic bets, Now/Next/Later roadmap, build/buy/partner, prioritization model, risk register
4. **Productprint Tier-C** (Layer 4) → positioning statement, product one-liner, bet narrative, strategy-on-a-page
5. **Thesis Stress-Test** (Layer 5) → assumption ledger, load-bearing assumptions, falsification findings, PROCEED/REFINE verdict
6. **Strategy Thesis Compiler** (this skill) → consulting-grade integrated strategy thesis deliverable

**No forward chain.** This is the terminal layer. Output is the deliverable.

## Variables to Resolve

| Variable | What to Capture | Default |
|----------|----------------|---------|
| `skin` | Report packaging mode (`8gnc-public`, `client-deliverable`, or `internal`) | `internal` |
| `mode` | Output depth (`rapid`, `standard`, or `enterprise`) | `standard` |
| `client_name` | Who receives the report (may differ from product name) | `product_name` |
| `prepared_by` | Firm name for the cover page | *required* |
| `report_date` | Date for the cover page | Current month/year |
| `confidentiality` | Confidential / Internal / Public | Confidential |
| `include_roadmap` | Include Section 6 (Now/Next/Later roadmap) | `yes` |
| `include_financials` | Include Section 7 (economic model) | `yes` |
| `layer_outputs` | JSON outputs from Layers 1–5 | *required* |

## Skin Behavior

The `skin` parameter controls ONLY voice, styling, and packaging. Strategy content, section order, and evidence are identical across all skins. A skin must never alter what the strategy says, who it recommends playing, how it recommends winning, or which assumptions survived falsification. If you find yourself changing strategic content to match a skin, stop — that is a violation of this constraint.

| skin | voice | styling | packaging |
|------|-------|---------|-----------|
| `8gnc-public` | brand-neutral; "your firm" and "your product" as placeholders throughout; no internal BMC references | clear report styling; no proprietary framework labels in the output | self-contained deliverable for a self-directed operator; strip internal framework terminology (translate "Tier-A" to "strategy research," "JTBD" to "buyer outcome," etc.) |
| `client-deliverable` | BMC voice; direct, diagnosis-not-promise tone; no superlatives or urgency theater | client-branded header, footer, and cover; route to `branded-mayhem-pdf` skill if available for PDF generation | client-facing PDF or formatted markdown; references BMC as the preparing firm; appropriate for delivery to the client's leadership team |
| `internal` | terse operator memo style; framework terminology permitted; no translation layer needed | minimal formatting; no cover styling required | markdown output for the Productprint pipeline; retain all field names and source references for pipeline consumption |

**Reminder:** Skin changes voice, styling, and packaging ONLY. The thesis content — section order, strategic findings, evidence, and assumption-test log — is skin-invariant.

## Principles (Non-Negotiable)

1. **Synthesis over summary.** Do not paste layer outputs verbatim. Transform them into a coherent strategic narrative where each section builds on the previous one.
2. **Every claim traces to evidence.** If a claim appeared in Layers 1–5 with sources, those sources appear in the bibliography. No orphan claims.
3. **No JSON paste — assemble narrative prose.** Raw JSON has no place in any section of the report. Every layer output must be translated into narrative, exhibits, or structured tables. This discipline is non-negotiable across all skins.
4. **Exhibits do the heavy lifting.** Tables, matrices, and frameworks convey key findings at a glance. Narrative text explains what the exhibit means and what to do about it.
5. **Strategic recommendations are specific.** "Improve positioning" is not a recommendation. "Replace the homepage hero message with the product one-liner within 30 days" is a recommendation.
6. **Acknowledge uncertainty.** Confidence levels from upstream claim sheets carry forward. If evidence was thin, say so. If a recommendation is high-confidence, say that too.
7. **Client-appropriate language (non-internal skins).** The report must be readable by a C-suite executive who has never seen a Productprint. Translate all framework language into business language: no "Layer 2," "Sprint 4," "kill criterion," "JTBD seed," or "Tier-B" in client-deliverable or 8gnc-public output.
8. **Assumption-Test Log is mandatory.** Layer 5 results always appear. If Layer 5 was skipped, the section must say so plainly and list the unvalidated assumptions — never omit or minimize the gap.

## Report Structure

Follow the section order defined in `references/report-template.md`. The 10 sections plus cover and appendix are:

- **Cover Page**
- **Table of Contents**
- **Executive Summary** (all layers contribute; standalone-readable)
- **Section 1: Market Context** (Layer 1, Tier-A backbone + sizing)
- **Section 2: Core Strategic Truth** (Layer 1)
- **Section 3: Where-to-Play / How-to-Win Cascade** (Tier-A: winning_aspiration, where_to_play_map, how_to_win_hypothesis, segments_wtp, jtbd_outcomes)
- **Section 4: Competitive Moat & Capability Map** (Tier-A: competitive_capability_teardown, required_capabilities, differentiation_wedge)
- **Section 5: Positioning & One-Liner** (Tier-C: positioning_statement, product_one_liner)
- **Section 6: Prioritized Roadmap — Now/Next/Later** (Tier-B: roadmap_horizons, strategic_bets, build_buy_partner, prioritization_model; Tier-C: bet_narrative) — omit if `include_roadmap = no`
- **Section 7: Economic Model** (Tier-A: economic_engine, category_definition_sizing) — omit if `include_financials = no`
- **Section 8: Risk Register + Leading Indicators** (Tier-B: risk_register; Tier-C: strategy_on_a_page must_track)
- **Section 9: Assumption-Test Log** (Layer 5: assumption_ledger, load_bearing, falsification_findings, verdict)
- **Section 10: Source Bibliography** (all layers' sources)
- **Appendix** (optional)

For the full field mapping, exhibit specifications, and formatting standards, see `references/report-template.md`.

## Mode Adjustments

- **Rapid:** 15–20 pages. Executive summary + Sections 2, 3, 4, 5, 9. Simplified exhibits. Skip financial modeling and detailed roadmap (note both omissions in the executive summary).
- **Standard:** 25–35 pages. All 10 sections. Full exhibits. Economic model with ranges. Phased roadmap.
- **Enterprise:** 35–50+ pages. All 10 sections expanded. Add: sensitivity analysis, scenario modeling, board-ready executive brief (2-page standalone), cross-segment risk variants, competitive monitoring plan.

## Quality Checks (Run Before Finalizing)

- [ ] Every section traces to specific upstream field names — no orphan sections
- [ ] Every exhibit has a number, title, and is referenced in the narrative text
- [ ] Executive summary stands alone — full picture without reading further
- [ ] No framework jargon in client-deliverable or 8gnc-public skin (translate all Productprint terminology)
- [ ] No JSON pasted raw into any section — all outputs translated into narrative and exhibits
- [ ] Economic projections include ranges and explicit inputs — no point estimates
- [ ] Assumption-Test Log section is present; if Layer 5 was skipped, the disclosure is explicit
- [ ] Source bibliography is complete — all sources from Layers 1–5 present
- [ ] The skin has NOT altered strategy content, section order, or evidence — only voice, styling, and packaging
- [ ] The report reads as a single coherent document, not a stack of layer outputs

## What NOT to Do

- Do not paste JSON outputs into the report. Transform everything into narrative and exhibits.
- Do not use Productprint layer or sprint terminology in client-deliverable or 8gnc-public skin output. Translate to business language.
- Do not present recommendations without an evidence chain.
- Do not include financial projections without explicit ranges and stated assumptions.
- Do not compile around a REFINE verdict. If Layer 5 said REFINE, the Assumption-Test Log must expose the broken assumption and constraint package.
- Do not let skin selection alter the strategy. Skin touches voice, styling, and packaging only.
- Do not create a report shorter than 15 pages in rapid mode or 25 pages in standard mode. This is a comprehensive strategic deliverable.
- Do not invent market data to fill Section 1. If the Tier-A Backbone did not collect it, mark the gap.
- Do not reference an exhibit that is not in the document, or include an exhibit the narrative never mentions.

## Output Format

Deliver as:
1. **Markdown document** — full report in clean markdown suitable for conversion to PDF or DOCX
2. **If `skin = client-deliverable` and the `branded-mayhem-pdf` skill is available** — offer to generate a formatted client PDF after markdown is approved
3. **If `skin = internal` and operating in orchestrated mode** — write the markdown to the engagement path provided by the dispatch prompt (`.productprint/engagements/{slug}/pass-N/layer6-thesis.md`)

The report must be immediately presentable to its target audience without additional editing beyond skin-appropriate formatting.

## File I/O Contract (orchestrated mode)

> **Note:** automated orchestrated mode is not included in this release; run the manual chain. This contract is a forward-looking specification.

When an authorized orchestrator provides explicit paths, honor them exactly:

- **Seed inputs:** read ONLY the JSON files listed in the dispatch prompt (Layers 1–5 output files).
- **Output:** write the compiled report to the exact path given (`.productprint/engagements/{slug}/pass-N/layer6-thesis.md`). No other location.
- **Return value:** your final message is the output path plus the verdict carried forward from Layer 5 — not the full report text. The orchestrator reads files, not transcripts.

When invoked as a direct skill call, present the full report in conversation and offer PDF generation only when a supported document workflow is available.

## Evaluation Rubric

1. **Synthesis quality** — The report reads as one coherent narrative, not six layer outputs stapled together
2. **Evidence density** — Every recommendation traces to cited evidence from upstream layers
3. **Exhibit quality** — Tables and frameworks convey findings at a glance; no orphan exhibits
4. **Actionability** — Recommendations are specific enough to execute without additional interpretation
5. **Professional standard** — Formatting, tone, and depth match top-tier strategy consultancy deliverables
6. **Standalone executive summary** — A reader who skips everything except the exec summary still gets the full strategic picture
7. **Assumption-Test Log integrity** — Layer 5 results are faithfully represented; PROCEED is backed by falsification records; REFINE exposes the constraint package
8. **Skin discipline** — Voice, styling, and packaging match the selected skin; strategy content is skin-invariant

Referenced files: 1

View saved version →

---
name: thesis-stress-test
description: Use to run a thesis stress test, strategy pre-mortem, or assumption falsification on a Productprint — Layer 5 of the Productprint stack, the adversarial gate. Trigger on "thesis stress test," "strategy pre-mortem," "assumption falsification," "load-bearing assumption," "what breaks this strategy," "PROCEED or REFINE," "stress-test the thesis," "is this assumption actually true," or when productprint-tier-c has just completed and the integrated strategy thesis needs adversarial validation before compiling. This skill extracts every assumption the strategy rests on, ranks them by fragility, and tries to BREAK the load-bearing few — returning PROCEED if they survive or REFINE (with a constraint package) if one falls.
---

# Thesis Stress-Test — Adversarial Pre-Mortem Gate

This is **Layer 5** of the Productprint stack: the adversarial gate. It does NOT validate that a buyer can tell the product apart from competitors (that is Brandprint's competitive-positioning-audit, a different question for a different deliverable). It runs a **structured pre-mortem on the one assumption that, if false, collapses the whole strategy** — and then tries to prove that assumption false.

Brandprint's gate asks *"can a buyer tell us apart?"* Productprint's gate asks *"what's the one assumption that, if false, kills this thesis — and is it actually true?"* The two-pass loop is preserved, but the second pass is about **truth-hardening**, not vocabulary-dodging.

## ADVERSARIAL STANCE (read before anything else)

> **You are adversarial. Your job is to BREAK the thesis.**
>
> - Do NOT look for confirming evidence. Look for the single fact that makes the strategy collapse.
> - Counter-evidence is the **success condition** of this skill, not a failure. Finding the killing fact is the point. A falsification pass that only assembles supporting evidence has not done its job.
> - **A gate that always says PROCEED is broken.** If you cannot remember the last time a gate like this returned REFINE, you are confirming, not falsifying. Assume the thesis is wrong and go hunting for the proof.
> - Frame every research query as a disconfirmation query: "find evidence that X is false," never "find evidence that X is true."
> - An assumption that *survives* a genuine attempt to break it has earned its place. An assumption that was never genuinely attacked has not — the verdict is meaningless without a real attack.

## When NOT to Use

- **No upstream Productprint exists.** This gate tests Tier-A/B/C output; it does not create strategy. Run Layers 1–4 first.
- **You want competitive differentiation testing.** That's "can a buyer tell us apart?" — a Brandprint question, not a strategy-thesis question. This gate tests whether the strategy is *true*, not whether it is *distinctive*.
- **Category white-space mapping.** Use `competitive-teardown`. This skill tests assumptions the strategy already made, not the open category.

## Chain Position

This is **Layer 5** of the 6-layer Productprint stack. It **consumes the Tier-A + Tier-B + Tier-C JSON**:

1. **Core Strategic Truth** (Layer 1) → foundational tension sentence, JTBD seed, lexicon
2. **Productprint Tier-A** (Layer 2) → 10 Playing-to-Win cascade elements, each with a claim sheet
3. **Productprint Tier-B** (Layer 3) → strategic bets, Now/Next/Later roadmap, build/buy/partner, prioritization, risk register, each with a claim sheet
4. **Productprint Tier-C** (Layer 4) → positioning statement, one-liner, bet narrative, strategy-on-a-page, each with a claim sheet
5. **Thesis Stress-Test** (this skill) → assumption ledger → fragility ranking → falsification → PROCEED/REFINE
6. **Strategy Thesis Compiler** (Layer 6) → compiles all layers into the consulting-grade integrated thesis

**When Layer 4 has just completed:** Import the full Tier-A, Tier-B, and Tier-C JSON. Walk every `claim_sheet` to extract assumptions. Inherit `evidence_mode` (`greenfield` | `existing-product`) and `mode` (`rapid` | `standard` | `enterprise`) from upstream.

**When running standalone:** Resolve variables with the user; require at minimum the Tier-A and Tier-B JSON (Tier-C optional). Without claim sheets to walk, there are no assumptions to extract.

## Variables to Resolve

| Variable | What to Capture | Default |
|----------|-----------------|---------|
| `product_name` | Product/platform/solution under test | *required* (or from upstream) |
| `tierA_json` / `tierB_json` / `tierC_json` | Upstream Productprint JSON | *required* (Tier-A + Tier-B minimum) |
| `mode` | `rapid` / `standard` / `enterprise` (source-rigor dial) | inherit from upstream, else `standard` |
| `evidence_mode` | `greenfield` / `existing-product` | inherit from upstream, else `greenfield` |
| `refine_loop_count` | How many REFINE loops have already run (0 on first pass) | `0` |

## Principles (Non-Negotiable)

1. **Falsify, don't confirm.** Every load-bearing assumption gets a disconfirmation attempt. Counter-evidence is the goal.
2. **Fragility is multiplicative.** `if_false_impact × thesis_dependence` — an assumption must be both consequential and widely-depended-on to be load-bearing.
3. **Survival must be earned.** An assumption "survives" only after a genuine attempt to break it failed. No attack = no verdict.
4. **One broken load-bearing assumption forces REFINE.** The gate does not average. If the thesis rests on a false belief, it must be rebuilt — not waved through.
5. **The verdict is defensible by the falsification record.** Every PROCEED is backed by a disconfirmation attempt that failed; every REFINE names the killing fact.

## Evidence & Citation Policy

Same discipline as Layers 1–4: for every source, capture title, publisher, author (if available), URL, publish date, access date, a one-line evidence note, and stance (`supports` | `contradicts` | `contextual`). For the assumptions you try to break, the most valuable sources are `contradicts` — cite them precisely. In `existing-product` mode, internal telemetry/data checks are first-party evidence and must be logged the same way (source = the named internal artifact).

## Workflow — Four Phases

### Phase 1: Extract Assumptions

**Goal:** surface every assumption the strategy rests on, tagged to where it came from.

- Walk **every** `claim_sheet` in the Tier-A, Tier-B, and Tier-C JSON. For each claim, ask: *what underlying belief must be true for this claim to hold?* That belief is the assumption.
- Where-to-play, how-to-win, the economic engine, and roadmap sequencing all rest on assumptions — be exhaustive. Specifically interrogate:
  - **where_to_play_map** → "this segment exists, is reachable at the assumed cost, and is large enough."
  - **how_to_win_hypothesis** → "the advantage is *structurally* defensible, not merely true today."
  - **differentiation_wedge.why_unoccupied** → "this white space is unoccupied for a structural reason, and stays unoccupied."
  - **economic_engine** → "CAC/LTV/payback ranges hold under the planned channel mix."
  - **roadmap_horizons.sequencing_logic** → "bet A is genuinely a prerequisite for bet B; the kill-criterion thresholds are right."
  - **risk_register.tied_to_assumption** → these point you directly at assumptions the upstream author already flagged.
- State each assumption so it **can be false** (falsifiable). Tag each with `source_layer`. Collapse near-duplicates and note the collapse in the audit log.

Output: `assumption_ledger` (each entry: `id`, `assumption`, `source_layer`).

### Phase 2: Rank by Fragility

**Goal:** find the 1–3 assumptions where the thesis actually breaks.

- Score each assumption: `if_false_impact (1–5) × thesis_dependence (1–5) = fragility_score`.
  - `if_false_impact`: if false, how much of the strategy dies? (5 = thesis is dead.)
  - `thesis_dependence`: how many downstream claims route through it? (5 = everything chains off it.)
- The multiplication is deliberate: an assumption must be **both** consequential and widely-depended-on. High impact + low dependence (isolated) is not load-bearing; high dependence + low impact is not either.
- The top 1–3 by `fragility_score` become `load_bearing` (ties → favor higher `if_false_impact`). Be honest: do not down-score the scary assumption to avoid having to falsify it. Inflating comfort or deflating fragility breaks the gate.

If the highest non-load-bearing assumption's `fragility_score` is within 3 of the lowest load-bearing entry's score, either promote it into `load_bearing` or record in `audit_log` why the cut is safe.

Output: `assumption_ledger` with `fragility_score` filled; `load_bearing` (1–3 ids).

### Phase 3: Falsify, Don't Confirm

**Goal:** for EACH load-bearing assumption, run a disconfirmation pass whose explicit aim is to break it.

- For each load-bearing assumption, **invoke `deep-research`** with a disconfirmation brief — same invocation discipline as the Brandprint competitive audit's forensic collection, but the query is inverted: *"find the evidence that assumption X is FALSE."* Examples: "find an incumbent that already profitably serves the segment we claim is unoccupied"; "find benchmark data showing the activation target is unreachable"; "find the channel-cost trend that breaks the CAC range."
- In **`existing-product` mode**, also check **internal telemetry / first-party data** (loss reasons, churn, activation funnels, NPS verbatims, roadmap reality) for counter-evidence *before* external search — internal data that contradicts the assumption is the strongest possible killing fact.
- Record, per load-bearing assumption: `method` (the disconfirmation query/check), `evidence` (what you found — cite even null results), `survived` (bool: true = the attempt failed to break it; false = counter-evidence broke it), and `notes` (if survived, why the counter-evidence was insufficient; if broke, the single fact that killed it).
- **Mode-aware depth** (inherited from upstream `mode`):
  - *Rapid:* one disconfirmation pass per load-bearing assumption; lighter source minimum (≥2).
  - *Standard:* full `deep-research` disconfirmation pass per assumption; triangulate; ≥3 sources or one decisive contradicting source.
  - *Enterprise:* add cross-market disconfirmation, longitudinal check (was this ever true and is it decaying?), and — in existing-product mode — a telemetry deep-dive.

Output: `falsification_findings` (one entry per `load_bearing` id).

### Phase 4: Verdict

**Goal:** PROCEED or REFINE, defensibly.

- **`PROCEED`** iff **every** load-bearing assumption has `survived == true`. Forward-chain to `strategy-thesis-compiler` (Layer 6), carrying `assumption_ledger` + `falsification_findings` forward as the report's assumption-test log.
- **`REFINE`** if **any** load-bearing assumption has `survived == false`. Emit a `constraint_package`:
  - `broken_assumption` — the id + statement that failed.
  - `evidence_it_is_false` — the counter-evidence that broke it.
  - `rebuild_constraints` — negative constraints on the rebuild ("the rebuild must not depend on X"; "where-to-play must exclude segment Y"; "re-size SOM to net out the share competitor Z already holds").

#### On REFINE — re-run Layers 1–4 with the constraint package injected, then re-run THIS gate

1. Re-invoke the build chain **in order**, injecting the accumulated constraint packages as **hard constraints** into each layer's `constraints` variable:
   `core-strategic-truth` → `productprint-tier-a` → `productprint-tier-b` → `productprint-tier-c`.
   Each layer must honor the constraints (e.g. Tier-A must not re-make the broken where-to-play bet).
   **Constraint packages ACCUMULATE across REFINE loops** — re-dispatch Layers 1–4 with the union of every `constraint_package` emitted so far this run, not just the latest, so no rebuild re-makes a previously-broken bet.
2. **RE-RUN this gate** (`thesis-stress-test`) on the rebuilt Tier-A/B/C, incrementing `refine_loop_count`.
3. **Cap at 2 REFINE loops.** If the gate still returns `REFINE` after 2 loops (i.e. a load-bearing assumption breaks for a third time), **STOP looping**. Surface to the operator: report the unresolved broken assumption, the constraint packages tried, and why the rebuilds did not resolve it. Do not loop forever — three strikes means the strategy has a structural problem a research loop can't fix, and a human needs to decide whether to re-scope, pivot, or kill it.

#### On PROCEED — forward-chain to Layer 6

Pass the full stress-test JSON to `strategy-thesis-compiler`. The `assumption_ledger` and `falsification_findings` become the thesis's **assumption-test log** — proof that the strategy survived adversarial review.

## Mode Adjustments

- **Rapid:** Phases 1–4, lighter. One disconfirmation pass per load-bearing assumption; source minimum ≥2; cap load_bearing at 1–2.
- **Standard:** Full four phases. `deep-research` disconfirmation per load-bearing assumption; ≥3 sources or one decisive contradicting source.
- **Enterprise:** Add cross-market and longitudinal disconfirmation; in existing-product mode, a telemetry deep-dive; widen load_bearing to the full top 3.

## What NOT to Do

- Do not soften `if_false_impact` or `fragility_score` to avoid falsifying a scary assumption. The scary one is exactly the one to break.
- Do not run a confirmation search and call it falsification. "Find evidence X is true" is the wrong query.
- Do not return PROCEED because the load-bearing assumptions *feel* solid. They survive only if a genuine break attempt failed.
- Do not loop REFINE more than twice — surface to the operator instead.
- Do not fabricate counter-evidence to force a REFINE, either. Falsify honestly; if the attack genuinely fails, the assumption survives.

## Evaluation Rubric

1. **Extraction exhaustiveness** — does the `assumption_ledger` cover every claim sheet (where-to-play, how-to-win, economic engine, sequencing), not just the obvious ones?
2. **Honest fragility scoring** — are `if_false_impact` and `thesis_dependence` rated on the strategy's real dependence, not on what's comfortable to falsify? Is `fragility_score` the actual product?
3. **Genuine falsification** — did Phase 3 actually try to BREAK each load-bearing assumption (disconfirmation queries, counter-evidence sought), or did it assemble supporting evidence? A confirm-bias Phase 3 fails the rubric regardless of verdict.
4. **Defensible verdict** — is PROCEED backed by failed break-attempts, and is REFINE's `constraint_package` precise enough that the rebuild can't re-make the broken bet?

## Output Format

Deliver as a single JSON object matching `references/output-schema-stress-test.md`: `product_name`, `assumption_ledger`, `load_bearing`, `falsification_findings`, `verdict` (PROCEED | REFINE), `constraint_package` (present only when REFINE), `sources`, `audit_log`, `evidence_mode`.

**Forward chaining:**
- `PROCEED` → pass the full JSON to `strategy-thesis-compiler` (Layer 6); the ledger + findings become the assumption-test log.
- `REFINE` → inject the union of ALL prior constraint packages as hard constraints, re-run `core-strategic-truth` → `productprint-tier-a` → `-tier-b` → `-tier-c`, then re-run this gate (increment `refine_loop_count`; cap at 2). Constraint packages ACCUMULATE — never inject only the latest loop's package.

## File I/O Contract (orchestrated mode)

> **Note:** automated orchestrated mode is not included in this release; run the manual chain. This contract is a forward-looking specification.

When invoked by the Productprint pipeline, the dispatch prompt provides explicit paths. Honor them exactly:

- **Seed inputs:** read ONLY the Tier-A/B/C JSON files listed in the dispatch prompt.
- **Output:** write the final JSON object to the exact path given (under `.productprint/engagements/{slug}/pass-N/`). On REFINE, the orchestrator reads `constraint_package` and re-dispatches Layers 1–4 with the union of ALL prior constraint packages injected (not just the latest — constraint packages ACCUMULATE across REFINE loops so no rebuild re-makes a previously-broken bet), then re-dispatches this gate at `pass-(N+1)`.
- **Return value:** your final message is the output path plus the verdict and (on REFINE) the broken assumption — not the full JSON. The orchestrator reads files, not transcripts. Always report `refine_loop_count` so the orchestrator can enforce the 2-loop cap.

When invoked manually, present the JSON in conversation, state the verdict, and on REFINE give the user the constraint package plus the instruction to re-run Layers 1–4 with it before re-running this gate.

Referenced files: 1

View saved version →

---
name: ux-ui-psych
description: Execute the UX/UI Psych choice architecture playbook (PLAY-002). Use when designing product menus, ordering flows, kiosk UX, upsell/cross-sell intercepts, or any conversion flow that needs behavioral nudges. Triggers on "choice architecture," "default selection," "upsell intercept," "cart cross-sell," "decoy pricing," "progress bar," "nudge," "contextual bandit," or when optimizing attachment rates and average check. Includes scoring functions, personalization rules, experimentation standards, accessibility specs, and dark-pattern guardrails.
---

# UX/UI Psych — Choice Architecture (PLAY-002)

Design defaults and frames so the easiest path is also the most profitable and ethical path. Use proven nudges, honest anchors, real personalization, and experimentation that does not lie to you.

## When NOT to Use

- **Funnels without the volume to learn.** The experimentation standards here demand power analysis up front and contextual bandits by week 5. If your traffic cannot feed enough exposures to power the tests you design, the bandits never converge and the A/Bs lie to you. Ship the rules-based defaults and Slot-1 ladder, skip the learning loop until volume exists.
- **No consent or privacy infrastructure.** Personalization runs on past orders, location, and context signals, and the ethics telemetry requires tracking opt-outs and consent symmetry. If you cannot capture consent properly, you cannot run this playbook ethically — and "no pre-checked consent boxes" is a hard rule, not a suggestion.
- **Operations that cannot absorb demand shifts.** Every recipe here is kitchen-aware: station capacity guardrails, prep-time thresholds, a kill switch tied to SLA risk. If fulfillment cannot flex when upsells land, you are trading order accuracy and throughput for attachment rate. Fix capacity first.
- **The pricing architecture itself is the problem.** This skill optimizes how customers select from a ladder that already exists. If the anchor, upgrades, and bundles are not designed yet, start with `fairness-anchor-ladder`.

1. Preselect a sane default or bundle that most customers actually want.
2. Lead with a premium anchor so the hero feels reasonably priced.
3. Insert one interstitial upsell after add-to-cart and a second pass in cart.
4. Rank suggestions with a scoring function, then let contextual bandits learn.
5. Measure attachment, average check, and throughput weekly. Kill weak patterns.

## Principles

1. **Choice beats chance.** Choreograph decisions so the right path is the easy path.
2. **Defaults decide.** Most users keep the preselected option if it is fair and clear.
3. **Anchors frame reality.** Start with a premium reference, then present the target hero.
4. **One nudge, not a maze.** Intercept once after add, and once in cart if the gap remains.
5. **Progress pulls.** Steps and progress bars speed completion near the finish line.
6. **Personal is powerful.** Day-part, weather, and order context matter more than slogans.
7. **No trickery.** Study dark patterns so you never ship them.

## Pattern Architecture

### Frame
- **Top of screen:** premium anchor, then target hero. Sticky mini-basket.
- **Same frame selection:** upgrade chips directly under the hero. No second page.
- **One-tap/two-click rule:** attach Slot-1 without leaving the flow.

### Ladder
- **Slot 1:** Sane add-on with highest attachment.
- **Slot 2:** Signature upgrade with highest margin.
- **Slot 3:** Novelty or seasonal.
- **Bundles:** Hero plus Slot-1 at a small discount.

## Scoring and Decisioning

**Candidate set:** items not in cart that meet constraints (in stock, prep time under threshold, station capacity, allergen safe).

**Score function:**
```
score(item, context) =
  w1·margin +
  w2·attach_rate_by_context +
  w3·popularity_now +
  w4·personal_affinity +
  w5·inventory_pressure
  − penalties(allergens, station_load, SLA_risk)
```

**Learning:** contextual bandits to balance explore vs exploit. Start rules-based week 1, flip to bandits by week 5.

**Signals:** day-part, weather, location, basket contents, past orders, promo calendar, inventory, station load.

## Pattern Recipes

### Intercept Upsell After Add-to-Cart
- Title: "Make it a meal?"
- Body: "Add fries and a drink and save $1.20"
- Primary CTA: "Add meal"
- Secondary CTA: "No, continue"
- Show if: entrée lacks side or drink, kitchen load under threshold, attach_rate above floor.

### Cart Cross-Sell
- Carousel: "People add with X"
- Ranking: contextual bandit score
- Include a fast-prep item to smooth throughput.

### Post-Purchase Add
- Timing: within 3 minutes if batching is possible
- Action: one tap with stored payment
- Guardrail: do not reopen the full checkout.

## Personalization Rules

- Early evening → family bundles
- Hot weather → cold drinks
- Low station load → unlock fries upsell
- Out-of-stock → hard-filter candidates

## Experimentation Standards

- **Design:** power analysis up front, fixed horizon or sequential methods.
- **SRM checks:** halt if allocations deviate from plan.
- **Variance reduction:** CUPED or covariate adjustment.
- **Kitchen-aware:** define station capacity guardrails. Abort if exceeded.
- **Registry:** log hypotheses, exposures, metrics, and decision notes.

## Metrics

**Primary:** average check, attachment rate, units per transaction, conversion, time to complete.

**Second order:** repeat purchase, order accuracy, refund/void rate, prep-station utilization.

**Ethics telemetry:** opt-out rate, complaint rate, undo after accidental adds, churn after promos, consent acceptance symmetry.

## Legal and Ethical Standards

- No pre-checked consent boxes.
- Clear declines and cancellation paths with parity to acceptance.
- If "No thanks" is harder to see or reach than "Add," it is out.

## Category Adaptations

- **QSR/cafes:** meal default, drink + side as Slot-1, dessert as fast-prep cross-sell.
- **Retail:** bundle defaults, warranty/care kit as Slot-1, limited colorways as novelty.
- **Wellness/beauty:** ritual default, booster as Slot-1, seasonal scent as novelty.
- **Local services:** consult default, quick add-on as Slot-1, priority turnaround as Slot-2.

## Accessibility

- Minimum 44px tap targets, consistent focus states, readable contrast.
- Kiosk flows reachable at standing and seated height.
- Basket preserved for N minutes after timeout.

## JSON Blueprint

```json
{
  "ui": {
    "anchor_order": ["premium_anchor", "target_hero", "value_option"],
    "defaults": {"meal_variant": true, "slot1_selected": true},
    "progress_steps": ["browse", "build", "review", "checkout"]
  },
  "eligibility": {
    "max_prep_minutes": 8,
    "exclude_if": ["out_of_stock", "allergen_conflict", "station_overload"]
  },
  "scoring": {
    "weights": {"margin": 0.35, "attach_rate_ctx": 0.25, "popularity_now": 0.15, "affinity": 0.15, "inventory_pressure": 0.10},
    "penalties": {"allergens": 1.0, "station_load": 0.5, "sla_risk": 0.4}
  },
  "patterns": {
    "intercept_after_add": {"show": true, "copy_variant": "value_save"},
    "cart_cross_sell": {"max_items": 10, "include_fast_prep": true},
    "post_purchase_add": {"window_seconds": 180, "requires_stored_payment": true}
  },
  "metrics": {
    "primary": ["avg_check", "attachment_rate", "upt", "conversion", "time_to_complete"],
    "ethics": ["opt_out_rate", "undo_rate", "complaint_rate"]
  },
  "guardrails": {
    "srm_watchdog": true,
    "kitchen_load_kill_switch": true,
    "consent_symmetry_required": true
  }
}
```

## 30/60/90 Implementation

**Day 0–30:** Instrument events (view_item, add_to_cart, upsell_shown, upsell_accept, upsell_dismiss, checkout_start, purchase). Ship baseline patterns with eligibility rules. Stand up dashboards and SRM watchdog.

**Day 31–60:** Tune scoring weights. Run A/B on copy, placement, default states. Introduce Slot-3 novelty and fast-prep cross-sell.

**Day 61–90:** Replace ranking with contextual bandits. Add cart-level second-chance prompts. Harden kill switch tied to kitchen load and SLA risk.

View saved version →

---
name: voice-profiler
description: Interview the user about their writing and analyze their real samples to generate a reusable voice profile for the humanize skills. Use when the user asks to build or update a voice profile, identify their writing voice, make future drafts sound more like them, or before humanize when no profile exists.
---

# Voice Profiler — Build Your Writing Voice Profile

Act as a writing voice analyst. Interview the user, analyze their real writing samples, and produce a structured voice profile file that the `humanize` skills can use.

## Why This Matters

Generic model drafts repeat predictable patterns. `humanize` can edit those patterns, but a voice profile supplies the user's actual rhythm, vocabulary, and preferences. The goal is not generic humanity; it is faithful voice.

## The Interview Process

This is a conversation, not a form. Adapt based on what the user gives you. Some people will paste 10 writing samples and let you figure it out. Others will want to describe their voice. Both work.

### Phase 1: Collect Writing Samples (Most Important)

Ask the user for 3-5 real writing samples. These are the foundation — everything else is derived from or validated against these.

**What to ask for:**
- "Paste 3-5 pieces of writing you're proud of. Emails, LinkedIn posts, proposals, website copy, tweets — anything that sounds like YOU at your best."
- If they have a file with samples: "Point me to a file with your writing and I'll analyze it."
- If `$ARGUMENTS` contains a file path, read that file for samples.

**What to look for in samples:**
1. **Sentence rhythm** — What's their natural cadence? Short-long-short? All punchy? Long and flowing?
2. **Opening patterns** — How do they start pieces? Cold open? Story? Question? Direct statement?
3. **Closing patterns** — How do they end? Call to action? Reflection? Punchline? Just stop?
4. **Vocabulary fingerprint** — Words they reach for repeatedly. Phrases that are distinctly theirs.
5. **Grammar personality** — Fragments? Run-ons? Perfect grammar? Contractions? Formal/informal mix?
6. **Emotional range** — Do they show humor? Frustration? Vulnerability? Confidence? What's the baseline?
7. **Persuasion model** — How do they convince? Data? Story? Authority? Diagnosis? Challenge?
8. **Register shifts** — Do they stay in one gear or shift between casual and formal?

### Phase 2: Guided Questions

After analyzing samples, fill gaps with targeted questions. Only ask what you can't already see in the samples.

**Identity & Context:**
- "What do you do? How would you describe your role in one sentence?"
- "Who do you write for most often? (clients, colleagues, public audience, specific industry)"

**Voice Preferences:**
- "Are there words or phrases you HATE seeing in writing? Things that make you cringe?"
- "Any words or phrases that are distinctly yours — things people associate with how you communicate?"
- "When you read your own writing back, what makes you think 'yeah, that sounds like me'?"

**Style Preferences:**
- "Do you prefer short and punchy or detailed and thorough?"
- "How do you feel about humor in professional writing?"
- "Do you sign off a specific way? (signature, sign-off phrase, etc.)"

**Anti-Patterns:**
- "What kind of writing makes you physically uncomfortable? Corporate jargon? Fake enthusiasm? Over-qualification?"

### Phase 3: Synthesis & Validation

Before generating the profile, play back what you've found:

"Here's what I see in your voice: [2-3 sentence summary]. Does that sound right, or am I missing something?"

Let them correct you. The profile should feel like looking in a mirror, not a caricature.

## Output: The Voice Profile File

Choose the destination with the user:

- **Codex with local file access:** prefer `./.8gnc/voice-profile.md` for a project-scoped profile. Offer `~/.config/8gnc/voice-profile.md` only for a user-wide profile and write there only after explicit permission.
- **ChatGPT or another surface without persistent local file access:** return `voice-profile.md` through the supported downloadable-file workflow and tell the user to save and reattach it when persistence is not confirmed.

Never silently write a personal voice fingerprint into a shared repository.

### Voice Profile Format

```markdown
---
name: [Full Name]
role: [One-line role description]
generated: [YYYY-MM-DD]
version: 1.0
---

# Voice Profile: [Name]

## Core Identity
[1-2 sentences describing who this person sounds like. Not what they do — how they SOUND. Use a metaphor or comparison if it fits.]

## Sentence Rhythm
[Describe their natural cadence pattern. Short-long-short? All punchy? Flowing with sudden stops? Give examples from their samples.]

**Pattern:** [e.g., "Short-long-short cadence. Punchy declarative → expansion → another punch."]

## Opening Patterns
[How they start pieces. List 2-3 patterns observed in their samples.]

- **[Pattern name]:** [Description + example]
- **[Pattern name]:** [Description + example]

## Closing Patterns
[How they end pieces. List 2-3 patterns observed.]

- **[Pattern name]:** [Description + example]

## Vocabulary — Words I Reach For
[List 15-25 words and phrases that appear repeatedly in their samples or that they identified as distinctly theirs.]

## Vocabulary — Words I Never Use
[List words and phrases they hate, avoid, or that would sound wrong in their voice. Include common AI words they specifically reject.]

## Persuasion Style
[How they convince. Name the model and describe it.]

- **Primary:** [e.g., "Diagnosis model — observe symptom → name it → offer remedy"]
- **Secondary:** [e.g., "Proof before promise — stack evidence before making the ask"]

## Grammar Personality
[Their relationship with grammar rules. Fragments? Contractions? Run-ons? Perfect grammar?]

## Emotional Range
[What emotions show up in their writing and how. Baseline tone + peaks.]

## Register
[Do they stay in one gear or shift? What triggers a shift?]

## Sign-Off
[How they sign things. Exact format.]

## Real Writing Samples

### Sample 1: [Context]
```
[Paste their actual writing sample]
```

### Sample 2: [Context]
```
[Paste their actual writing sample]
```

### Sample 3: [Context]
```
[Paste their actual writing sample]
```

## Platform Overrides

### LinkedIn
[Any LinkedIn-specific voice adjustments — line breaks, hooks, length]

### Email
[Any email-specific voice adjustments — formality, structure, sign-off]

### Instagram
[Any IG-specific adjustments — lowercase, density, hashtag style]

### [Other Platform]
[Add as needed]
```

## After Generation

1. Write or return the file through the approved path described above.
2. Tell the user where it was saved and whether the current surface will persist it.
3. Offer: "Want to test it? Paste any AI-generated text and I'll run `humanize` using your new profile."
4. Offer: "Want to add platform-specific overrides? (LinkedIn voice, email voice, Instagram voice)"

## Post-Processing Note

After generating content with `humanize`, run the em dash post-processor when local execution is available. Resolve the installed `voice-profiler` skill directory from this loaded `SKILL.md`, then run:

`python3 [voice-profiler-skill-dir]/scripts/de_emdash.py --max-emdash 2`

If local execution is unavailable, apply the punctuation rules manually and disclose that the script did not run.

This replaces excess em dashes with your natural punctuation devices (stdlib-only, no external dependencies). The script's defaults reflect a common human pattern; tune the flags to match what the voice profile observed in the user's samples — `--aside parens|hyphen|comma`, `--elaboration hyphen|comma|colon|semicolon`, `--pivot period|comma|colon`, and `--max-emdash N` (set N to roughly how often the user actually uses em dashes per piece). Run `de_emdash.py --help` for the full flag list.

## Updating an Existing Profile

If a voice profile already exists at the surface-appropriate path:
1. Read it first
2. Ask: "You already have a voice profile. Want to update it with new samples, or start fresh?"
3. If updating: merge new observations with existing profile, keeping what still fits
4. If starting fresh: run the full interview

## When NOT to Use

- Not for rewriting text — this skill builds the profile; `humanize` and `humanize-ig` consume it.
- Not for profiling someone else's writing to imitate them — the profile is built from the user's OWN samples; anything else makes every humanized piece sound like the wrong person.
- Not for inventing a voice from a description alone — push for real samples; descriptions without writing produce a caricature.
- Not needed every session — run once, update when the user's voice evolves or new samples surface.

## Important Notes

- The profile is only as good as the samples. Push for real writing, not descriptions of writing.
- 3 samples minimum. 5+ is ideal. More samples = more accurate profile.
- The user's BEST writing is the target — not their average. Ask for pieces they're proud of.
- Voice profiles should be updated periodically. Writing voice evolves.
- Never share the voice profile externally. It's a personal fingerprint.
- The profile file is plain Markdown — users can edit it manually anytime.

Referenced files: 1