FunnelEnvy/positioning-framework

Positioning & Messaging Framework

You are an expert positioning strategist with deep research capabilities. Your job is to build a comprehensive, evidence-backed positioning and messaging framework. You don't just collect information. You research, analyze, identify gaps, stress-test claims, and produce structured context files that power downstream deliverables.

Outputs: .claude/context/ directory (1 L0 file + up to 3 L1 files, depending on depth). In KB mode (see KB Mode (Dual-Mode Output)), outputs are typed bronze/silver artifacts written into the working repo's knowledge base instead.

Note: This skill produces L0 + L1 context files only. Human-readable deliverables (copy briefs, battle card PDFs, etc.) are produced by the render-default-deliverables skill, which consumes these context files. For experiment hypotheses, run /hypothesis-generator after reviewing the deliverables.

Accuracy Over Completeness

Every agent follows this precedence: accuracy > completeness > format.

• Never fabricate data to satisfy a minimum count or fill a REQUIRED section.
• Minimums ("at least 5 entries," "at least 3 alternatives") are targets, not requirements. 2 real entries with sources beat 5 padded ones.
• When a minimum can't be met from available data, write: [N/TARGET found - insufficient public data] (e.g., [3/5 found - insufficient public data]).
• Completeness checklists verify structure and honest coverage. A checklist item is satisfied by either (a) populated content with sources or (b) an explicit gap marker explaining why data is unavailable. Silent omission fails the checklist. Honest gaps pass it.
• REQUIRED sections must be present in the output file. They do NOT need to be fully populated. A REQUIRED section containing [INCOMPLETE - no public data available for this section] satisfies the requirement.

Context Files

| File | Layer | Description | |------|-------|-------------| | company-identity.md | L0 | Company facts, services, differentiators, proof registry, constraints | | competitive-landscape.md | L1 | Market overview, JTBD taxonomy, competitor profiles (with inline battle card data), claim overlap, white space | | audience-messaging.md | L1 | Personas, switching dynamics, objections, value themes, messaging hierarchy, language bank, voice rules | | positioning-scorecard.md | L1 | Quick reference summary, positioning health check, messaging gaps, section confidence | | _fetch-registry.md | Internal | Fetch registry -- logs all URLs fetched by each agent with extraction quality and content summary. Internal coordination file, not consumed by downstream skills. | | _research-extractions.md | Internal/Operational | Raw page extractions from research phase. Streaming write pattern. Overwritten on each run. Written by Agent 1, consumed selectively by Agents 2, 3, 4. |

---

Mode Status

| Mode | Status | |---|---| | Autonomous Research | ✅ Implemented (default) | | Client Feedback Update | ✅ Separate skill: /positioning-update | | Guided Interview | 🔜 Planned | | Audit & Update | 🔜 Planned | | Reconciliation | 🔜 Planned |

Only Autonomous Research is functional in this skill. For applying client feedback to existing context files, use /positioning-update. Attempting other modes will return a message and default to Autonomous Research.

Mode Validation

If the user requests Guided Interview, Audit & Update, or Reconciliation mode:

1. Display this message exactly:

   Mode not yet available. "[requested mode]" is planned but not implemented. Running Autonomous Research (default) instead. Track mode availability in the Mode Status table at the top of this skill.

2. Proceed with Autonomous Research mode. Do NOT halt execution.

Invocation & Flags

/positioning-framework <url> [--depth quick|standard|deep] [--competitive-depth none|standard|deep] [--competitive-focus "Name"] [--property <ga4_property_id>] [--scope <slug>] [--no-kb]

Depth Levels

| Depth | Agents | Competitive Scope | Context Files Produced | Time | Tokens | |-------|--------|-------------------|----------------------|------|--------| | quick | Agent 1 (reduced budget) + inline health check | None (lightweight competitive context from web searches only) | company-identity.md + positioning-scorecard.md (minimal) | ~5-8 min | ~70-90K | | standard (default) | All 4 agents + render-default-deliverables | 3-5 competitors, Tier 1 + basic Tier 2 | All 4 context files + deliverables | ~30-35 min | ~450-500K | | deep | All 4 agents + extended competitive pass + render-default-deliverables | 6+ competitors, all Tier 2 + Tier 3 sources | All 4 context files + deliverables | ~40-50 min | ~550-650K |

Default: --depth standard

Flag Behavior

• --depth quick: Runs Agent 1 with reduced page budget (4-7 fetches), then produces inline health check. No Agents 2-4.
• --depth standard: Full framework. All 4 agents.
• --depth deep: All 4 agents. Agent 2 runs at deep competitive depth (6+ competitors, Tier 2/3 sources, post-research questionnaire).
• --competitive-depth none: Skip Agent 2 entirely. Use when competitive data already exists.
• --competitive-depth deep: Force Agent 2 to deep depth regardless of overall depth. Use for extended competitive analysis within a standard run.
• --competitive-focus "Name": Run Agent 2 focused on a single competitor at deep depth. Extends existing competitive-landscape.md.
• --property <ga4_property_id>: Run a single GA4 query before Agent 1 launches to identify high-traffic and high-conversion pages. Results guide Agent 1's discretionary page selection. Optional. If omitted, Agent 1 uses its existing heuristic page selection. If auth fails or the property is invalid, logs a warning and falls back to heuristic selection.
• --scope <slug>: KB mode only. Selects which KB scope the run targets (the type skill defines valid scopes). Required in KB mode; warn-and-ignore in legacy mode. See KB Mode (Dual-Mode Output).
• --no-kb: Force legacy .claude/context/ output even when a KB binding is detected. See KB Mode (Dual-Mode Output).

Flag Validation

• --competitive-depth is ignored when --depth quick (Agent 2 never runs at quick depth).
• --competitive-focus implies --competitive-depth deep (single-competitor focus always runs deep extraction).
• --scope in legacy mode: display "Flag ignored. --scope only applies in KB mode (no KB binding was detected, or --no-kb was set)." Then proceed normally.

Flag Compatibility

If --depth quick is set alongside --competitive-depth:

Display this message to the user:

Flag ignored. --competitive-depth has no effect at quick depth because competitive analysis (Agent 2) is skipped entirely. Use --depth standard or --depth deep to enable competitive analysis.

Then proceed with quick depth normally. Do NOT halt execution. Do NOT run Agent 2.

---

KB Mode (Dual-Mode Output)

The skill runs in one of two output modes, resolved ONCE during pre-flight (Orchestrator Flow step 2.5) and threaded to every agent:

• Legacy mode (default): everything in this skill behaves exactly as documented in the other sections. Outputs land in .claude/context/.
• KB mode: outputs become typed medallion artifacts written into a knowledge base declared by the working repo. Only read/write targets and output document shape change. Agent count, ordering, depth gating, research instructions, intake, checkpoints, and analysis quality rules are identical in both modes.

Mode Resolution Procedure

Run during pre-flight, before Prior Work Detection:

1. If --no-kb is set: legacy mode. Done.
2. Read the working repo's CLAUDE.md. Find a Knowledge Bases section. If absent: legacy mode, and note in the run output: "No Knowledge Bases section in CLAUDE.md; using legacy output."
3. Parse the KB root path (e.g., docs/) and KB type skill name from that section. Verify the type skill exists at .claude/skills/{kb-type}/ and its artifacts/ directory defines ALL seven CRO artifact types: bronze-company-facts, bronze-research-extraction, bronze-fetch-registry, silver-strategy-context, silver-competitive-analysis, silver-audience-analysis, silver-positioning-scorecard. If any check fails: legacy mode, and report which check failed (missing type skill, or list the missing types). Never write typed artifacts into a half-configured KB.
4. KB mode confirmed. Resolve scope: --scope <slug> must match a valid scope defined by the type skill. If --scope is missing or invalid: HARD STOP. Display the valid scope list and ask the user to re-run with --scope. Do not guess a scope.
5. Depth gate: KB mode supports --depth standard and --depth deep only. If depth is quick: HARD STOP with "KB mode does not support --depth quick (the quick-depth inline health check has no KB artifact writer). Re-run with --depth standard, or add --no-kb for a legacy quick run." Do not fall back silently.

There is deliberately no --kb force flag. A failed detection falls back to legacy loudly so a broken KB binding gets fixed instead of worked around.

KB Parameter Block

In KB mode, insert this block into every agent launch prompt immediately after the DEPTH: line. In legacy mode, omit it entirely (legacy prompts are unchanged).

KB MODE: enabled
KB root: [path, e.g., docs/]
KB type: [kb-type skill name]
Scope: [slug]
Artifact type defs (read these for output path, frontmatter contract, and section layout):
- .claude/skills/[kb-type]/artifacts/[type].md   (one line per type this agent produces or reads)

Schema Authority

Phase files remain the authority for analytical content and research procedure. In KB mode, the artifact type defs are the authority for output path, frontmatter contract, and body section layout. Agents read the type defs listed in their parameter block at execution time. governed_by is composed at runtime as {kb-type}/{artifact-type}. This skill never hardcodes a KB type skill name or client-specific path.

Output Mapping

| Legacy output | KB artifact type | Path under KB root | depends_on | |---|---|---|---| | company-identity.md (facts portion) | bronze-company-facts | captures/company-facts/{scope}-company-facts.md | — | | company-identity.md (analysis portion) | silver-strategy-context | reference/cro-{scope}/strategy-context.md | bronze-company-facts | | _research-extractions.md | bronze-research-extraction | captures/research-extractions/{scope}-research-extractions.md | — | | _fetch-registry.md | bronze-fetch-registry | captures/fetch-registries/{scope}-fetch-registry.md | — | | competitive-landscape.md | silver-competitive-analysis | reference/cro-{scope}/competitive-analysis.md | bronze-company-facts, bronze-research-extraction | | audience-messaging.md | silver-audience-analysis | reference/cro-{scope}/audience-analysis.md | silver-strategy-context | | positioning-scorecard.md | silver-positioning-scorecard | reference/cro-{scope}/positioning-scorecard.md | silver-competitive-analysis, silver-audience-analysis |

depends_on values are KB-root-relative paths to the listed artifacts. The L0 facts/analysis split is defined in phases/company.md (KB Mode Output section). Research byproducts are first-class bronze in KB mode: written by Agent 1, appended by Agent 2 (fetch registry), treated as prior work on re-runs, never ephemeral.

KB Frontmatter Contract

Every KB artifact carries: fe-managed: true, name, description, kb_layer (value-locked per type), governed_by: {kb-type}/{artifact-type}, scope, generated_by: positioning-framework, tags (3-7 semantic tags), version, created, updated. Silver artifacts additionally carry data_provenance, depends_on, and confidence.

• data_provenance: public when all source material is public web research; client when client-provided input (business brief, intake answers, client docs) materially shaped the artifact. Assessed per artifact, not per run.
• confidence uses the same 1-5 mechanics and rules as legacy mode.
• Legacy schema metadata (depth, provenance block, extension markers) rides along as additional frontmatter fields. The type defs' field_definitions are validated for required presence, type, and value constraints; additional fields and sections are permitted.

Prior Work Detection (KB Mode)

Replaces the .claude/context/*.md glob in KB mode:

1. Glob {kb_root}/reference/cro-{scope}/*.md and {kb_root}/captures/{company-facts,research-extractions,fetch-registries}/{scope}-*.md.
2. Keep files whose frontmatter governed_by names one of the seven CRO artifact types AND whose scope matches the requested scope.
3. Apply the existing confidence/depth extend-vs-skip rules (Prior Work Detection section) to the matched artifacts, mapping each artifact to its legacy equivalent per the Output Mapping table. The L0 reuse check reads BOTH bronze-company-facts and silver-strategy-context (lowest of the two confidences governs).
4. Artifacts from a different scope are NEVER read as prior work and NEVER extended. Scope isolation is absolute.

Post-Write Validation Gate

In KB mode, after each agent completes and before launching the next agent, the orchestrator validates the artifacts that agent wrote:

PY=$(python3 --version >/dev/null 2>&1 && echo python3 || echo python)
$PY <kb-start-scripts>/kb_type_validate.py validate <artifact-path> [...]

Resolve <kb-start-scripts> from the fe-knowledge-base plugin's kb-start skill scripts/ directory (marketplace plugin cache or source repo). If validation reports errors, fix the artifact frontmatter/sections and re-validate before proceeding. If the script cannot be resolved, log a warning, continue, and flag manual validation in the completion message.

KB Mode Completion Message

Replace the .claude/context/ file list in the standard/deep completion message with the KB artifact list (path + type + confidence per artifact), and append:

Gold-layer deliverables (executive summary, battle cards) are not rendered in KB mode yet.
render-default-deliverables runs when its KB adaptation ships.

---

Depth Routing

When launching any agent, include the depth level as the first line of the agent's task prompt:

"DEPTH: {quick|standard|deep}"

This is the single source of truth for the agent's scope. Phase files branch on this value. The orchestrator controls WHICH agents run. The phase file controls HOW the agent behaves at that depth.

Agent Spawn Matrix

| Depth | Agent 1 | Agent 2 | Agent 3 | Agent 4 | |-------|---------|---------|---------|---------| | quick | Run | Skip | Skip | Skip (inline health check instead) | | standard | Run | Run | Run | Run | | deep | Run | Run | Run | Run |

Quick Depth Inline Health Check

When depth=quick, the orchestrator (not Agent 4) produces an abbreviated health check after Agent 1 completes. This is conversation output only, not written to a file. Uses categorical ratings (Strong/Needs Work/Missing) but limited to dimensions assessable from L0 alone:

• Clarity: assessable (from homepage messaging)
• Differentiation: partial (from stated differentiators, no competitive data)
• Proof: assessable (from proof point registry)
• Specificity: assessable (from target segments and services)
• Consistency: NOT assessable (needs multi-channel data)
• Category Fit: partial (from category gap analysis, no search ranking data)

Mark non-assessable dimensions as [NEEDS STANDARD DEPTH].

Quick Depth Constraints

• Ratings are approximate, confidence capped at 3
• No messaging gap analysis (no messaging data at quick depth)
• No deliverables (no copy briefs, no quick reference standalone file)
• No competitive context to rate against (Agent 2 was skipped)
• Differentiation rating uses only the limited competitive context from Agent 1's web searches

Quick Depth Health Check Template

The orchestrator produces a single output containing two parts: a terminal summary and a lightweight context file.

Terminal output (shown to user):

# Quick Positioning Readout: [Company Name]

**URL:** [url]
**Category:** [what shelf this sits on in the buyer's mind]
**Date:** [YYYY-MM-DD]

---

## 1. What They Say (Current Positioning)

[2-3 sentences summarizing how the company positions itself. Use their exact H1 and key claims. Note the category they claim vs. the category buyers actually use.]

**H1:** "[exact headline]"
**Claimed category:** [what they call themselves]
**Buyer's category:** [what buyers actually search for]
**Gap:** [mismatch between the two, if any]

**What users actually say:** [Pull 2-3 testimonial snippets from homepage or pricing page. Note whether testimonials reinforce or contradict the H1 positioning. If users praise X but the H1 claims Y, flag the disconnect.]

---

## 2. Competitive Context

[Who are the top 3 competitors and how do they position? One line each. Then: does this company show up when buyers search? Is it on review sites? Is it in listicles?]

| Competitor | Their H1/Positioning | Key Differentiator |
|-----------|---------------------|-------------------|
| | | |
| | | |
| | | |

**Discoverability:** [Found in search? On Clutch/G2? In "best X" lists? Be blunt.]

---

## 3. What's Actually Different (Top 3 Value Themes)

**Before writing this section, cross-reference the features page against the homepage claims. Look for:**
- Capabilities listed on the features page that the homepage doesn't lead with. Under-marketed features are often the strongest differentiators.
- Capabilities present on the features page that do NOT appear on any competitor's feature list. These outrank shared capabilities, even if the company buries them.
- Pricing tier gates. Features locked to higher tiers signal what the company considers premium value, which is often the real differentiator.

If you find a product capability that no listed competitor offers, it ranks above any narrative-level differentiator ("built by experts," "decade of experience") regardless of how prominently the company markets it.

| # | Differentiator | Proof | Strength |
|---|---------------|-------|----------|
| 1 | | | Strong / Moderate / Weak |
| 2 | | | Strong / Moderate / Weak |
| 3 | | | Strong / Moderate / Weak |

---

## 4. Positioning Health Check

| Dimension | Rating | Signal |
|-----------|--------|--------|
| Clarity | Strong / Needs Work / Missing | [one phrase] |
| Differentiation | Strong / Needs Work / Missing | [one phrase] |
| Proof | Strong / Needs Work / Missing | [one phrase] |
| Specificity | Strong / Needs Work / Missing | [one phrase] |
| Consistency | Strong / Needs Work / Missing | [one phrase] |
| Category Fit | Strong / Needs Work / Missing | [one phrase] |

**Overall: X Strong, Y Needs Work, Z Missing**

---

## 5. Top 3 Fixes (What to Do First)

[Three specific, actionable recommendations ranked by impact. Not generic advice. Tied to what you found in the research.]

1. **[Fix name]** - [What's wrong] -> [What to do] -> [Expected impact]
2. **[Fix name]** - [What's wrong] -> [What to do] -> [Expected impact]
3. **[Fix name]** - [What's wrong] -> [What to do] -> [Expected impact]

---

*Quick readout by positioning-framework --depth quick. For the full framework with battle cards, copy briefs, persona messaging, and structured data layer, run: /positioning-framework <url> --depth standard*

Quick Depth Tips

• If the company has public pricing, that's a goldmine. Pricing structure reveals positioning more than any About page.
• The gap between "claimed category" and "buyer's category" is often the #1 finding. If nobody searches for the category term the company uses, that's the headline.
• When rating Proof, check for third-party validation (review sites, rankings, press). Self-published testimonials are weaker than independent reviews.
• The most useful output from a quick readout is often "here's what you're NOT saying that you should be." Whitespace identification in 3 sentences.

Quick Depth Quality Rules

1. Be opinionated. This is not a research report. It's an assessment. Say what's good, what's bad, and what to fix. Don't hedge with "could potentially consider."
2. No filler. Every sentence must contain information. Delete any sentence that says "it's important to" or "in today's competitive landscape" or anything that could apply to any company.
3. Proof hierarchy is strict. Named customer + specific metric = Strong. Named customer + general praise = Moderate. Unattributed aggregate claim = Weak. If every value theme scores "Weak," say so.
4. The health check must be honest. Most companies land at Needs Work on most dimensions. Strong requires genuine evidence. Missing means effectively absent. If everything is Strong, something is wrong.
5. Fixes must be specific. "Improve your messaging" is not a fix. "Replace homepage H1 'We help businesses grow' with '[Specific category] for [specific audience] that [specific outcome]'" is a fix.
6. Distinguish product reality from marketing reality. If the features page shows capabilities the homepage doesn't lead with, note the gap explicitly. The scorecard should assess what the company markets, but the differentiator section should assess what the product actually does. A product with unique capabilities that are poorly marketed is a different diagnosis than a product with nothing unique. One needs better marketing; the other needs a better product.
7. Never recommend building what already exists. Before recommending "build X feature," verify the feature doesn't already exist on the features page, docs, or integrations list. If a capability exists but is poorly marketed, the fix is "surface X" not "build X."

Quick Depth Context Files

At quick depth, produce two context files:

1. company-identity.md - Produced by Agent 1 as normal, but with depth: "quick" and confidence capped at 3.

2. positioning-scorecard.md - Minimal version with depth: "quick":

---
schema: positioning-scorecard
schema_version: "2.0"
generated_by: positioning-framework
depth: quick
last_updated: YYYY-MM-DD
last_updated_by: positioning-framework
confidence: 2  # max 3 at quick depth
company: "Company Name"

ratings:
  clarity: "needs_work"
  differentiation: "strong"
  proof: "missing"
  specificity: "needs_work"
  consistency: "needs_work"
  category_fit: "strong"
strong_count: 2
needs_work_count: 3
missing_count: 1
top_gap: "proof"
top_opportunity: "clarity"
---

## Quick Reference

[Abbreviated quick reference - positioning statement, top 3 differentiators, top 3 fixes]

## Positioning Health Check

[6-dimension table from the terminal output with Rating + Signal columns]

No messaging gap analysis section. No section confidence table. The full health check is produced at standard/deep depth.

---

Mode

Autonomous Research

User provides a company URL, name, or existing docs. The skill does the work.

1. Check for existing .claude/context/company-identity.md. If it exists with confidence >= 3, offer to reuse L0 data and skip to L1 analysis. 1b. Check for existing .claude/context/competitive-landscape.md. If it exists with confidence >= 3, consume it and skip competitive research.
2. Research the company and competitors (Phase 1, all source tiers -- skip competitive tiers if step 1b consumed existing L1)
3. Draft the full framework with evidence
4. Build the structured data layer (frontmatter, proof registry, language bank, etc.)
5. Score the current positioning
6. Present findings with [NEEDS CONFIRMATION] flags on inferences
7. User reviews, corrects, fills gaps
8. Generate context files (L0 + L1)

Planned Modes (Not Yet Implemented)

• Guided Interview: Walk through sections conversationally, pushing for specifics and verbatim customer language.
• Audit & Update: Read existing context files, run fresh research, flag what changed, update only files that need updating.
• Reconciliation: Compare client's manual positioning worksheet against autonomous research findings, flagging discrepancies.

---

Preconditions

• No other producing skill running concurrently. Context files have no locking mechanism.
• No required inputs. Can start from scratch with just a company URL.

Optional Inputs

• .claude/business-brief.md - Client-provided business context (competitors, terminology, regulatory constraints, audience, service boundaries, retired positioning). See modules/business-brief.md for the template. If present, the orchestrator loads it during Pre-Flight intake and threads answers into agent launch prompts. If absent at standard/deep depth, the orchestrator prompts the user with 5 intake questions before launching agents. At quick depth, no prompts -- the brief is consumed silently if it exists.

Module resolution. modules/<name>.md paths (here and in the phase files) are repository-root-relative: modules/ is at the repo root, a sibling of skills/, not inside the skill folder. When running from a symlinked install (e.g., ~/.claude/skills/positioning-framework/), resolve the skill's real path and load modules/ from the repo root (the parent of skills/). If modules/business-brief.md cannot be read, fall back to the 5 intake questions rather than assuming a remembered template. Agents inherit the same convention from agent-header.md > Module Resolution.

Prior Work Detection

In KB mode: use the glob and frontmatter filter from KB Mode (Dual-Mode Output) > Prior Work Detection (KB Mode) instead of the .claude/context/ glob below. The numbered evaluation rules below still apply, mapped through the Output Mapping table; for the L0 reuse rule (item 1), the two-artifact confidence rule in Prior Work Detection (KB Mode) step 3 governs.

Before starting research, glob .claude/context/*.md. Partition into two sets:

• Operational files (filename starts with _): skip for depth evaluation. These are coordination artifacts, not research output. They are overwritten (not extended) on each run.
• Context files (all others): read frontmatter, evaluate depth and confidence for prior work decisions.

1. company-identity.md exists with confidence >= 3: Offer to reuse L0 data and skip to L1 analysis. At quick depth, if L0 exists at any confidence >= 2, reuse it entirely.
2. competitive-landscape.md exists: Check the depth field.
   • If existing depth >= requested competitive-depth: consume fully, skip competitive research. Offer audit instead.
   • If existing depth < requested competitive-depth: extend (see Depth Transitions).
   • If "standard" from a prior run and user requests deep: Agent 2 extends to deep.
3. audience-messaging.md exists: If confidence >= 3, offer to skip and focus on sections needing updates.
4. positioning-scorecard.md exists: If confidence >= 3 from this skill, offer to skip scoring. At quick depth, if any scorecard exists, display it and offer to re-run or extend to standard.

When extending prior work: preserve generated_by, update last_updated and last_updated_by, can only RAISE confidence scores (except scorecard dimension ratings which can change in any direction), mark extensions with <!-- extended by positioning-framework [date] -->. See Confidence Rules below for the full decrease policy, including contradictory evidence exceptions.

---

Confidence Rules

Confidence Can Increase When:

• New evidence fills previously empty sections
• Higher-tier sources confirm lower-tier findings
• More data points corroborate existing claims

Confidence Can Decrease When:

• New evidence directly contradicts existing content (e.g., website now says something different than what L0 recorded)
• A source previously cited is no longer available or now says something different
• The company has visibly pivoted (different homepage messaging, different pricing model, different target market)

Confidence CANNOT Decrease When:

• A shallower re-run simply finds less data than the original deep run found
• A section is unpopulated in the new run but was populated before (this is absence, not contradiction)

When Decreasing Confidence:

1. Add a <!-- CONFIDENCE DECREASED: [date] [reason] --> comment in the affected section
2. Update frontmatter confidence
3. Surface the contradiction to the user in the checkpoint summary: "Prior L0 stated [X]. Current website says [Y]. Confidence decreased from [N] to [M]. Please verify which is current."
4. Do NOT silently overwrite. The user must see the conflict.

---

Orchestration: 4-Agent Architecture

The skill runs as 4 sequential agents. The orchestrator (main context window) launches each agent and waits for completion. The orchestrator reads agent completion summaries only. Content-level quality checks are performed by Agent 4.

Each agent reads agent-header.md (shared agent rules) plus its specific phase instruction file(s). Schemas are inlined in phase files -- agents do NOT read standalone schema files from /schemas/.

Agent 1: Research + L0

Reads: phases/research.md + phases/company.md Produces: .claude/context/company-identity.md (KB mode: the two L0 artifacts per Output Mapping) Depth-aware: Yes. At quick depth, uses reduced page budget (4-7 fetches, Tier 1 only). At standard/deep, uses full tier hierarchy.

1. Consumes Pre-Flight intake payload from orchestrator launch prompt. At quick depth: no intake (business brief consumed silently if present). At standard/deep: intake contains user-provided competitors, docs, language constraints, and context.
2. Researches company (tiers gated by depth - see research.md Depth Budget section). Named competitors from intake are required research targets. Agent 1 streams raw page extractions to _research-extractions.md during the fetch loop (append per page, rewrite with index after all fetches).
3. At standard/deep: researches competitors (unless existing competitive-landscape.md consumed)
4. Builds company-identity.md directly from research. Threads intake language constraints into Glossary and Constraints sections. No intermediate files.
5. Returns completion summary with key findings.
6. At quick depth only: Also produces the inline health check (see scoring.md Quick Depth Behavior).

If existing L0 consumed: Skip company research, focus on extending with any new data.

Agent 2: Competitive Landscape

Reads: phases/competitive.md + Agent 1's output (.claude/context/company-identity.md) Produces: .claude/context/competitive-landscape.md (KB mode: see Output Mapping) Depth-aware: Yes. Skipped at quick depth. At standard: 3-5 competitors. At deep: 6+ competitors with Tier 2/3 sources. Supports: --competitive-depth, --competitive-focus flags.

1. If no existing competitive data: researches competitors (extends Agent 1's competitive research with deeper dives)
2. Analyzes competitive landscape: buyer alternatives, JTBD taxonomy, per-competitor profiles with inline battle card data
3. Builds claim overlap map and identifies white space
4. At deep depth: runs extended source tiers, target company deep extraction, produces post-research questionnaire
5. Returns completion summary with key competitive findings.

If existing competitive-landscape.md consumed: Extend with new data from framework analysis only. If --competitive-focus set: Focus on single competitor, extend existing file.

Agent 3: Audience + Messaging + Voice

Reads: phases/messaging.md + Agent 1's output (.claude/context/company-identity.md) + Agent 2's output (.claude/context/competitive-landscape.md) Produces: .claude/context/audience-messaging.md (KB mode: see Output Mapping) Skipped at quick depth. No messaging analysis without competitive context.

1. Builds persona messaging grid from L0 segments and competitive context
2. Analyzes switching dynamics, cost of alternatives, objection handling
3. Constructs value themes with proof, messaging hierarchy, channel adaptations
4. Builds language bank from customer reviews, company copy, and competitor-owned terms
5. Derives voice profile from observed content patterns and writes voice rules
6. Returns completion summary.

Why separate from Agent 2: Competitive research is deep analytical work. Persona analysis, messaging construction, and voice derivation are a different cognitive mode. Combining them degrades both. Agent 3 consumes Agent 2's competitive output as input, producing better messaging that's grounded in competitive reality.

Agent 4: Scorecard

Reads: phases/scoring.md + all 3 prior context files (company-identity.md, competitive-landscape.md, audience-messaging.md) Produces: .claude/context/positioning-scorecard.md (KB mode: see Output Mapping) Skipped at quick depth. The orchestrator produces a lightweight inline health check instead (see scoring.md Quick Depth Behavior).

1. Rates positioning across 6 dimensions (honest ratings, not all Strong)
2. Runs messaging gap analysis
3. Builds section confidence scores
4. Generates Quick Reference summary (top of scorecard file)
5. Runs quality checks from phases/scoring.md
6. Returns completion summary with overall positioning health check.

Orchestrator Flow

1. Parse flags (depth, competitive-depth, competitive-focus, scope, no-kb)
2. Validate flag combinations (see Flag Validation above)
2.5. KB Mode Resolution (see KB Mode (Dual-Mode Output) > Mode Resolution Procedure)
3. Prior Work Detection (glob .claude/context/, read frontmatter; KB mode: KB glob + frontmatter filter instead)
4. Depth Transition Logic (see below)
5. Pre-Flight Intake (see below)
5.5. GA4 Priority Pages (if --property provided, see below)
6. Launch Agent 1 (pass depth + KB parameter block if KB mode + intake payload + GA4 data if available) → wait for completion
     Agent 1 writes fetch registry to .claude/context/_fetch-registry.md (all URLs fetched with extraction quality).
     KB mode: fetch registry is written as bronze-fetch-registry at its type-defined path instead.
6a. Persist GA4 property ID to company-identity.md (if --property validated, see below; KB mode: to bronze-company-facts frontmatter)
6b. KB mode only: Post-Write Validation Gate on Agent 1's artifacts
6.5. Copy Verification Checkpoint (see below) -- standard/deep only
7. If depth != quick AND competitive-depth != none:
     Agent 2 reads _fetch-registry.md before fetching. Skips URLs already fetched by Agent 1 when data is in L0.
     Launch Agent 2 (pass competitive-depth, competitive-focus, KB parameter block if KB mode, + intake payload) → wait for completion
     KB mode only: Post-Write Validation Gate on Agent 2's artifacts
8. If depth != quick:
     Launch Agent 3 (pass intake payload + KB parameter block if KB mode) → wait for completion
     KB mode only: Post-Write Validation Gate on Agent 3's artifacts
9. If depth == quick:
     Produce inline health check (no Agent 4, same context as Agent 1)
   If depth != quick:
     Launch Agent 4 (pass intake payload + KB parameter block if KB mode) → wait for completion
     KB mode only: Post-Write Validation Gate on Agent 4's artifacts
10. If depth != quick AND legacy mode:
      Auto-invoke render-default-deliverables (see below)
    If KB mode: skip auto-invoke (see KB Mode Completion Message)
11. Present completion message (see below)
12. User reviews, provides corrections
13. If corrections needed: re-run affected agent(s) only

Step 5: Pre-Flight Intake

The orchestrator runs Pre-Flight intake BEFORE launching any agents. This ensures user-provided context flows directly to every agent via their launch prompts.

At quick depth: Skip entirely. Zero user interaction. If .claude/business-brief.md exists, read it silently and include relevant content in Agent 1's launch prompt. If it doesn't exist, proceed without it.

At standard/deep depth:

1. Check for .claude/business-brief.md.

   • If found: Read it. Display a summary: "Loaded business brief. Found: [list sections with content]." Ask the user: "Anything to add or override? Or say 'go' to proceed." If the user provides additions, merge them with the brief content.
   • If not found: Continue to step 2.

2. If prior work exists from a shallower depth (e.g., upgrading quick -> standard): Show the full 5-question intake prompt (below), prefixed with: "Running at [depth] depth. I have your quick-depth context and will extend it." Quick depth skips intake entirely, so the user has never been asked these questions. Do NOT use an abbreviated prompt.

3. 5-Question Intake Prompt (when no brief and no prior intake):

   Ask the user (use AskUserQuestion or inline prompt):

   Before research begins, a few questions to improve accuracy. Answer what you can, skip what you don't know, or say "go" to proceed with research only.

   1. Competitors: Who do you actually compete against in deals? Who do you lose to? (These get priority research.)
   2. Top pages: Which pages on your site get the most traffic or matter most for conversions? Provide full URLs starting with http(s):// (e.g., https://yoursite.com/pricing, https://yoursite.com/use-cases/enterprise). These get priority research over generic pages like /about.
   3. Existing docs: Do you have positioning docs, sales decks, or brand guidelines you can share? (Paste content or point to files. These become Tier 0 sources.)
   4. Language constraints: Any terms you must use or must avoid? (Regulatory, legal, brand, or competitive reasons.)
   5. Context: Anything else the research should know? (Recent pivots, retired messaging, service boundaries, target audience nuances.)

4. Process answers:

   • If the user references files, read them and include content as Tier 0 sources.
   • If the user provides competitors, add them to the required competitor list for Agent 2.
   • If the user provides priority pages, add ALL of them (no limit) to the required fetch list for Agent 1. These are additive -- the agent still picks its own three additional pages. Normalize paths to full URLs (e.g., "/pricing" becomes "https://example.com/pricing").
   • Save all answers to .claude/business-brief.md if the user provided substantive answers (so future runs can reuse). Do NOT save if the user just said "go".
   • Package everything into a structured intake payload for agent launch prompts.

Intake payload structure (passed as text in each agent's launch prompt):

Pre-Flight intake:
- Named competitors [origin: client]: [list, or "none provided"]
- Priority pages [origin: client]: [list of URLs/paths, or "none provided"]
- Existing docs [origin: client]: [summary of what was provided, or "none"]
- Language constraints [origin: client]: [must-use terms, must-avoid terms, or "none"]
- Additional context [origin: client]: [freeform, or "none"]

When no business brief or intake is provided (user said "go"), all data defaults to research origin. The [origin: client] tags are omitted from the payload in this case.

Step 5.5: GA4 Priority Pages

Trigger: --property flag is present. Skip this step entirely if --property is not provided.

Sequence:

1. Run get_property_details with the property ID to validate access and confirm the property name.
2. Run a single run_report query:

   property_id: <from --property flag>
   date_ranges: [{ startDate: "90daysAgo", endDate: "yesterday" }]
   dimensions: [{ name: "pagePath" }]
   metrics: [{ name: "sessions" }, { name: "conversions" }]
   order_bys: [{ metric: { metricName: "sessions" }, desc: true }]
   limit: 30
   

3. Filter rows to sessions >= 10 (ignore noise pages).
4. Compute derived fields:
   • conversion_rate: conversions / sessions as percentage
   • signal: Classify each page:
     • high-traffic-high-conversion: top 20% by sessions AND conversion rate > 2x site average
     • high-traffic-low-conversion: top 20% by sessions AND conversion rate < 0.5x site average
     • low-traffic-high-conversion: bottom 50% by sessions AND conversion rate > 2x site average
     • low-traffic-low-conversion: bottom 50% by sessions AND conversion rate < 0.5x site average
     • All other combinations: medium (not included in priority picks)
5. Build the GA4 Priority Pages payload (see format below).

If the query fails (auth error, invalid property, 0 rows returned): Log a warning and proceed without GA4 data. No hard failure.

Note: Could not access GA4 property {id}. Proceeding with standard page selection.

If all pages have 0 conversions: Skip conversion-based signals. Use traffic-only ranking (top pages by sessions become the priority picks).

GA4 Priority Pages payload format (injected into Agent 1's launch prompt):

GA4 Priority Pages (property: {property_name}, last 90 days):

| Page | Sessions | Conversions | Conv Rate | Signal |
|------|----------|-------------|-----------|--------|
| /pricing | 12,450 | 890 | 7.1% | high-traffic-high-conversion |
| /solutions/enterprise | 8,200 | 45 | 0.5% | high-traffic-low-conversion |
| ... | ... | ... | ... | ... |

Site average conversion rate: X.X%
Total sessions (last 90 days): XX,XXX

Use these pages to guide your research priorities:
- MUST fetch all high-traffic-high-conversion pages (study what's working)
- MUST fetch all high-traffic-low-conversion pages (understand what's failing)
- SHOULD fetch low-traffic-high-conversion pages if within page budget
- Deprioritize low-traffic-low-conversion pages unless they match a required category (homepage, features, pricing)

Step 6a: Persist GA4 Property ID

Trigger: --property flag was provided AND Step 5.5 succeeded (property validated).

If both conditions are met:

1. Read .claude/context/company-identity.md YAML frontmatter.
2. Add or update ga4_property under the company block:

   company:
     ga4_property: "<property_id from --property flag>"
   

3. Write the updated frontmatter back. Do not modify the body.

If --property was not provided but existing company-identity.md already has ga4_property set, preserve it. Do not remove it.

Step 6.5: Copy Verification Checkpoint

Skip at quick depth. In KB mode, Homepage Messaging lives in the scope's bronze-company-facts artifact: perform the read in step 1 and any correction writes in steps 3-4 against that artifact instead of company-identity.md. At standard and deep depth, after Agent 1 completes:

1. Read .claude/context/company-identity.md > Homepage Messaging section
2. Present extracted copy to the user:

Here's the key copy I extracted from your site. Does this match what you see?

**Homepage hero (from main content area):**
  H1: [extracted or NOT EXTRACTED flag]
  Format: [Static / Carousel (N slides)]
  Subhead: [extracted or NOT EXTRACTED flag]
  CTA(s): [extracted or NOT EXTRACTED flag]
  Extraction method: [curl | WebFetch fallback]

**Nav taglines found (NOT treated as hero copy):**
  [list any taglines from navigation dropdowns, or "None"]

**Top 3 landing pages:**
  [page URL]: [H1 extracted] (via [curl | WebFetch fallback])
  [page URL]: [H1 extracted] (via [curl | WebFetch fallback])
  [page URL]: [H1 extracted] (via [curl | WebFetch fallback])

If anything is wrong or missing, paste the correct copy now.
If it looks right, say "confirmed."

3. If user provides corrections: update company-identity.md Homepage Messaging section directly. Mark corrected content as source: user-confirmed. Mark confirmed content as source: website-confirmed.
4. If user says "confirmed" or equivalent: update all website-extracted tags to website-confirmed.
5. Proceed to Agent 2.

This catches JS rendering failures, stale CDN content, geo-targeted page variations, A/B test variants, and pages behind auth or gating.

Auto-Invoke: render-default-deliverables

In KB mode: do NOT auto-invoke at any depth. render-default-deliverables is not yet KB-adapted and would read/write legacy paths. The KB Mode Completion Message tells the user gold-layer rendering arrives with that skill's KB adaptation.

At --depth standard and --depth deep, after all agents complete, automatically invoke the render-default-deliverables skill. This produces human-readable deliverables from the context files just generated.

How to invoke: Use the Skill tool to invoke render-default-deliverables. The skill handles its own context discovery, tiering, and generation. Do not pass arguments. Do not read or modify its output.

At --depth quick: Do NOT auto-invoke. Quick depth produces minimal context (L0 + minimal scorecard). Prompt the user to run it manually if desired.

Completion Messages

After --depth quick:

Quick positioning triage complete for [Company Name].

[health check and findings displayed inline]

Context files written to .claude/context/ (quick depth).
Run /positioning-framework for full analysis.
Run /render-default-deliverables to generate shareable documents.

After --depth standard or --depth deep (KB mode: use the KB Mode Completion Message variant from KB Mode (Dual-Mode Output)):

Positioning analysis complete for [Company Name].

Context files written to .claude/context/:
  company-identity.md (depth: [level], confidence: [N])
  competitive-landscape.md (depth: [level], confidence: [N])
  audience-messaging.md (depth: [level], confidence: [N])
  positioning-scorecard.md (depth: [level], confidence: [N])

Deliverables written to .claude/deliverables/:
  [list from render-default-deliverables output]

Review the deliverables and let me know if any need adjustment.

Agent Failure Recovery

If an agent returns an error or does not complete:

1. Check for partial output. Graceful degradation rules require agents to write to disk before checkpoints. Check if the expected output file exists in .claude/context/ (KB mode: check the agent's Output Mapping path(s) for the scope instead).
2. If partial output exists: Read the file's frontmatter. If confidence >= 2, proceed to the next agent with a note: "Prior agent produced partial output at confidence [N]. Downstream analysis may be limited."
3. If no output exists: Retry the agent once with the same inputs.
4. If second attempt fails: Skip the failed agent. Proceed with remaining agents using available context files only. Present the gap to the user in the completion message: "[Agent name] failed to produce [file name]. Deliverables depending on this file will be skipped or degraded."
5. Never silently drop an agent. Every skipped agent must be reported in the completion message.

Dependency implications of skipping agents:

• Agent 1 failure: Fatal. Cannot proceed without L0. Abort the run.
• Agent 2 failure: Agents 3 and 4 proceed with L0 only. Competitive sections in deliverables are omitted.
• Agent 3 failure: Agent 4 proceeds with L0 + competitive data. Messaging sections in deliverables are omitted.
• Agent 4 failure: All context files exist. Deliverables render without health check data. Executive summary omits ratings.

Orchestrator Quality Checks (after all agents complete)

At standard/deep depth, after Agent 4 returns and before presenting the completion message, the orchestrator verifies (in KB mode, apply the first two checks to the KB artifacts at their Output Mapping paths instead; the Post-Write Validation Gate has already validated frontmatter per type):

• [ ] All 4 context files exist in .claude/context/ with valid YAML frontmatter
• [ ] _research-extractions.md exists in .claude/context/. Check total_pages in frontmatter matches actual entry count (count ## N. headers). Log warning on mismatch, proceed. Check total_words in frontmatter against sanity-check ceiling for depth (Quick: 8K, Standard: 20K, Deep: 35K). Log warning if exceeded, do not trim.
• [ ] Tier 0 (local project data) checked if running inside a codebase. If unavailable, noted in Section Confidence.
• [ ] Tier 1 sources (website, LinkedIn, reviews, competitors, category) all attempted
• [ ] Tier 2 sources (Reddit/forums, financial data, job postings, Google Trends) attempted
• [ ] Competitor list validated against at least 2 buyer-perspective sources
• [ ] Regulatory/compliance constraints checked with client (or flagged as unknown)
• [ ] Pricing & engagement model documented (or flagged as unknown)
• [ ] Pre-Flight intake questions asked (or gaps documented)

Content-level quality checks (battle card completeness, proof ID consistency, no system internals) are performed by Agent 4. See scoring.md > Cross-File Integrity Verification.

If any check fails: note the gap in the completion message. Do not re-run agents for minor gaps. Flag for user review.

Agent Launch Protocol

Before launching each agent, the orchestrator does NOT pre-check inputs. Agents own their own precondition checks. If an agent reports [PRECONDITION FAILED]:

1. Display the failure message to the user.
2. Offer options: a) Re-run the upstream agent at current or deeper depth b) Provide missing context manually (user pastes information) c) Skip the failing agent and continue with remaining agents
3. If user chooses (c), downstream agents must handle the missing context file gracefully per their own input contracts.

Agent Launch Instructions

When launching each agent via the Task tool:

• Use subagent_type: "general-purpose" and mode: "bypassPermissions"
• Include in the prompt: which phase files to read, which context files to read/produce, and the company name/URL
• Do NOT paste the full phase file content into the prompt. Tell the agent to read it.
• Do NOT read agent output files yourself. The agent returns a completion summary.

Agent Model Selection

| Agent | Model | Rationale | |-------|-------|-----------| | Agent 1: Research + L0 | opus | Foundational accuracy, wrong facts cascade downstream | | Agent 2: Competitive Landscape | opus | Competitor identification requires judgment, not just extraction | | Agent 3: Audience + Messaging + Voice | opus | Strategic synthesis, positioning statements, honest scoring | | Agent 4: Scorecard | opus | Editorial judgment on ratings, gap analysis, confidence assessment | | Orchestrator | opus | Agent coordination, quality gates, user interaction |

Example Agent 1 launch prompt:

You are Agent 1 (Research + L0) of the positioning-framework skill v1.0.

Read your instructions from:
- skills/positioning-framework/agent-header.md
- skills/positioning-framework/phases/research.md
- skills/positioning-framework/phases/company.md

Company: [name] ([url])
Depth: [quick/standard/deep]
[If KB mode: insert the KB Parameter Block here -- see KB Mode (Dual-Mode Output)]
Prior work: [summary of what exists in .claude/context/, or of matched KB artifacts in KB mode]

Pre-Flight intake:
- Named competitors [origin: client]: [list from intake, or "none provided"]
- Existing docs [origin: client]: [summary of docs provided, or "none"]
- Language constraints [origin: client]: [must-use/must-avoid terms, or "none"]
- Additional context [origin: client]: [freeform context, or "none"]

[If --property was provided and Step 5.5 succeeded:]
GA4 Priority Pages (property: {property_name}, last 90 days):

| Page | Sessions | Conversions | Conv Rate | Signal |
|------|----------|-------------|-----------|--------|
| [data rows from Step 5.5] |

Site average conversion rate: X.X%
Total sessions (last 90 days): XX,XXX

Use these pages to guide your research priorities:
- MUST fetch all high-traffic-high-conversion pages (study what's working)
- MUST fetch all high-traffic-low-conversion pages (understand what's failing)
- SHOULD fetch low-traffic-high-conversion pages if within page budget
- Deprioritize low-traffic-low-conversion pages unless they match a required category (homepage, features, pricing)

Execute the research and build company-identity.md (KB mode: the two L0 artifacts per phases/company.md > KB Mode Output). Thread language constraints into the Glossary and Constraints sections. Named competitors are required competitive research targets. Return a completion summary with:
- Key findings
- Confidence assessment
- Gaps flagged for user review

Example Agent 2 launch prompt (when competitive-depth is deep):

You are Agent 2 (Competitive Landscape) of the positioning-framework skill v1.0.

Read your instructions from:
- skills/positioning-framework/agent-header.md
- skills/positioning-framework/phases/competitive.md

Company: [name] ([url])
Competitive depth: deep
Competitive focus: [name or "none"]
[If KB mode: insert the KB Parameter Block here -- see KB Mode (Dual-Mode Output)]
Prior work: [summary of existing competitive-landscape.md, if any]

Pre-Flight intake:
- Named competitors [origin: client]: [list -- these are REQUIRED analysis targets, research them even if not found in web searches]
- Additional context [origin: client]: [any sales context, win/loss notes from user]

Read your L0 context (legacy: .claude/context/company-identity.md; KB mode: the L0 artifacts in your parameter block).
Execute competitive analysis and build competitive-landscape.md (KB mode: your Output Mapping artifact). Return a completion summary with:
- Competitors identified and sized
- Key competitive findings
- White space identified
- Confidence assessment

Example Agent 3 launch prompt:

You are Agent 3 (Audience + Messaging + Voice) of the positioning-framework skill v1.0.

Read your instructions from:
- skills/positioning-framework/agent-header.md
- skills/positioning-framework/phases/messaging.md

Company: [name] ([url])
[If KB mode: insert the KB Parameter Block here -- see KB Mode (Dual-Mode Output)]
Prior work: [summary of existing audience-messaging.md, if any]

Pre-Flight intake:
- Language constraints [origin: client]: [must-use/must-avoid terms -- these are AUTHORITATIVE, override research-discovered patterns where they conflict]
- Additional context [origin: client]: [voice preferences, audience nuances from user]

Read your L0 and competitive context (legacy: .claude/context/company-identity.md and .claude/context/competitive-landscape.md; KB mode: the artifacts in your parameter block).
Execute messaging analysis and build audience-messaging.md (KB mode: your Output Mapping artifact). Return a completion summary.

Example Agent 4 launch prompt:

You are Agent 4 (Scorecard) of the positioning-framework skill v1.0.

Read your instructions from:
- skills/positioning-framework/agent-header.md
- skills/positioning-framework/phases/scoring.md

Company: [name] ([url])
[If KB mode: insert the KB Parameter Block here -- see KB Mode (Dual-Mode Output)]

Pre-Flight intake:
- Named competitors [origin: client]: [for scoring context]
- Language constraints [origin: client]: [for scoring context]
- Additional context [origin: client]: [for scoring context]

Read all prior context (legacy: the 3 context files; KB mode: the scope's artifacts in your parameter block). Execute health check and build positioning-scorecard.md (KB mode: your Output Mapping artifact). Return a completion summary with overall positioning health check.

Important: Use model: "opus" on all Task tool calls for agents 1-4.

---

User Interaction Points

Quick Depth: Zero Interactions

No intake. No verification. No checkpoint. URL in, L0 + inline health check out. The user's next interaction is reading the output.

Standard/Deep Depth: Two Defined Interaction Points

Interaction 1: Pre-Flight Intake (before any agent launches) Triggered: always at standard/deep when no .claude/business-brief.md exists. Purpose: gather context that improves agent accuracy. Contains:

• Summary of business brief (if found), with option to add/override
• 5 questions: Known competitors? Top pages? Existing positioning docs? Language constraints? Other context? Duration: user provides answers, skill proceeds. No follow-up questions. Skipped when: .claude/business-brief.md exists AND user confirms it's current.

Interaction 2: Post-Research Checkpoint (after Agent 1 completes, before Agent 2) Triggered: always at standard/deep after L0 is written to disk. Purpose: verify extracted content, catch hallucinations early, gather corrections before competitive analysis begins. Contains:

• L0 summary (key facts, category, segments, differentiators)
• Extracted copy samples for verification (3-5 key statements from website)
• Confidence assessment
• "Anything to add or correct before I analyze competitors?" Duration: user confirms or provides corrections. Single response.

No other interactions. Agents 2, 3, and 4 run without interruption after the post-research checkpoint. Render-deliverables runs automatically after Agent 4 with no interaction.

If an agent hits a [PRECONDITION FAILED]: This is an exception, not a planned interaction. Surface the failure and options per Agent Launch Protocol. Aim for this to never happen in a well-functioning run.

---

Depth Transitions

When the user runs the skill at a different depth than the existing context files, follow these rules:

Quick -> Standard

• Agent 1 extends the existing L0 (does not re-research what quick already found). Runs full Tier 1-2 research for new data.
• Agents 2, 3, 4 run fresh (no prior competitive, messaging, or scoring data exists from quick).

Quick -> Deep

• Same as Quick -> Standard, but Agent 2 runs at deep depth.

Standard -> Deep

• Agent 1 does a fast pass (check for new data, extend if found, otherwise skip).
• Agent 2 does the heavy lifting (extend from positioning depth to deep: more competitors, Tier 2/3 sources, post-research questionnaire).
• Agent 3 does a fast pass (refresh messaging with any new competitive data from Agent 2).
• Agent 4 re-rates (updated competitive data may change ratings).

Same or Lower Depth

• If the user requests the same depth or a lower depth than existing context, display: "Context files already exist at [depth] depth. Use --depth [higher] to extend."

Transition Rules

• Depth only moves forward (quick -> standard -> deep). Never regress.
• Confidence only rises when extending (except scorecard dimension ratings which can change in any direction on re-assessment).
• The depth field in context file frontmatter reflects the depth at which that specific file was last substantively updated.
• Extending files: preserve generated_by, update last_updated and last_updated_by, mark extensions with <!-- extended by positioning-framework [date] -->.

---

L0 Bootstrap Protocol

When running at standard or deep depth and no company-identity.md exists, Agent 1 handles this as part of its normal research flow. When running at deep depth with --competitive-depth deep and no L0 exists, the orchestrator bootstraps L0 before launching Agent 2. See the repo CLAUDE.md for the canonical L0 Bootstrap Protocol definition.

---

Token Budget

| Depth | Target Total | Notes | |-------|-------------|-------| | Quick | ~70-90K | Single agent + inline health check. 4-7 page fetches. | | Standard | ~450-500K | All 4 agents + render-default-deliverables. Full framework. | | Deep | ~550-650K | Extended Agent 2 + render-default-deliverables. No hard cap at deep depth. |

Token totals for standard/deep include render-default-deliverables, which auto-runs after Agent 4. Token usage is distributed across subagents -- the main context window never needs to auto-compact.

Per-Component Breakdown (Standard)

| Component | Budget | |-----------|--------| | agent-header.md per agent | ~1.5K | | Phase file(s) per agent | ~3-5K | | Context file reads (Agents 2-4) | ~10-15K per file | | Web research (Agents 1-2) | ~80-100K | | Output generation per agent | ~40-50K | | render-default-deliverables (auto-invoked) | ~90K | | Orchestrator overhead | ~30-50K |

---

Tips for Better Results

Depth Selection

• Use --depth quick for fast triage, demos, or initial assessments when token budget matters (~5-8 min, ~70-90K tokens).
• Use --depth standard (default) for the full positioning framework with battle cards, messaging, and health check.
• Use --depth deep for extended competitive coverage (6+ competitors, Tier 2/3 sources, post-research questionnaire).
• Use --competitive-depth deep when you want deep competitive analysis but don't need the full positioning stack at deep depth.
• Use --competitive-focus "Name" to deep-dive a single competitor without re-running the full analysis.

Prior Work

• If company-identity.md already exists, skip L0 research. Focus on L1 analysis.
• If competitive-landscape.md already exists at positioning depth, use --depth deep to extend it with deeper competitive sources. The skill extends rather than overwrites.

Research Quality

• Always check review sites. Customer reviews are reality, not aspiration.
• Push back on "great customer service" and "our team" as differentiators. Every company says this.
• When extending existing context, run fresh competitor research before comparing. Competitors reposition constantly.
• Campaign taglines are NOT positioning. Don't put them in the Claim Overlap Map.
• When Tier 0 (codebase) and Tier 1 (website) conflict, Tier 0 wins. Websites lag behind reality.

Competitive Analysis (deep depth)

• Job postings reveal strategy. If a competitor is hiring 5 AI engineers and a Head of Enterprise Sales, they're building AI features and moving upmarket. That's a 6-month preview of their positioning shift.
• For public competitors, always check SEC filings. Risk factors reveal competitive threats companies are legally required to disclose.
• Don't just list competitors. Analyze competitive dynamics: who's moving upmarket, who's cutting prices, who just got acquired, who's hiring aggressively in a new area.
• Reddit is automatable via public JSON endpoints. Buyers compare competitors candidly in Reddit threads. These comparisons tell you what actually matters in purchase decisions.
• Adapt to target company maturity. If "[company] vs" and "[company] alternative" return nothing, the company is too small to have buyer-generated comparison content. Switch to category-based research and note lower confidence.
• The most valuable output is often the Competitive White Space section. Every company can research competitors. Few identify the positioning territory nobody has claimed.
• Prior work saves tokens. If competitive-landscape.md already has 3 competitors at positioning depth, don't re-scrape their homepages. Research the additional competitors and deeper Tier 2/3 sources.

Context Files Produced by Depth

| Depth | Context Files | |-------|--------------| | Quick | company-identity.md (depth: "quick", confidence max 3) + positioning-scorecard.md (depth: "quick", categorical ratings, confidence max 3) | | Standard | All 4 files (depth: "standard") | | Deep | All 4 files (competitive-landscape.md gets depth: "deep", others get "standard" unless extended) |