brand-dna

/brand-dna

Invocation. This skill is manual-only (disable-model-invocation: true): a heavyweight, five-canonical bootstrap should fire on an explicit /brand-dna, not opportunistically. The trigger phrases in the description document intent — they are not an auto-match surface.

First run / onboarding

brand-dna is the bootstrap skill that every downstream marketing skill reads. It produces the five brand canonicals (BRAND, VOICE, AUDIENCE, OFFER, COMPANY) once per brand — then humans curate them.

Two ways in:

• Point me at materials — share a website, brand guide PDF, sample articles, or founder interview and this skill extracts the canonicals from them.
• I'll interview you — if you have nothing yet, this skill runs a structured one-question-at-a-time interview (~10–20 min) and produces canonicals from your answers.

Zero-arg on-ramp: if you invoke /brand-dna with no arguments and no source materials are found, the skill will ask: "Would you like to (a) point me at your brand materials, or (b) have me interview you from scratch (~10–20 min, one question at a time)?"

---

You are executing the /brand-dna skill. This skill runs in the main conversation loop (no context: fork) so it can interview the user interactively when needed. For the heavyweight autonomous extraction step, it dispatches the brand-dna-extractor agent. Read source materials for a brand (a brand-guide.md, the brand's public website, sample articles, an interview transcript with founders, prior marketing copy) and produce the full canonical set under brand/<brand>/. This is the bootstrap-once-per-brand step (R9). Every other marketing skill — content-writer, editor, content-strategist, site-designer, future channel skills — reads what you produce.

All relative paths below are relative to the working directory the user invokes this skill from (the marketing workspace root that contains, or can contain, the canonical brand/ directory). Generic /init-project is retired per R67; project layout comes from project-local bootstrap/orchestrator setup, not from a marketplace init skill.

Artifact contract (P4)

This skill produces the canonical set for one brand at brand/<brand>/:

• BRAND.md — type: brand/brand — narrative identity: who the brand is, what it stands for, archetype, positioning, key messages, competitive differentiation.
• VOICE.md — type: brand/voice — voice character, tone spectrum, perspective rules, sentence-level style, do/don't examples, numeric calibration targets.
• AUDIENCE.md — type: brand/audience — primary and secondary personas, their states/concerns/journey, vocabulary they use, vocabulary they reject.
• OFFER.md — type: brand/offer — products, services, packages; value propositions per audience segment; pricing posture; calls-to-action.
• COMPANY.md — type: brand/company — terminology and naming conventions, legal entity facts, jurisdiction, compliance constraints, brand assets, contact surfaces.

Reads (source-material discovery, per P3 search-first):

• Files explicitly listed by the user in $ARGUMENTS.
• brand/<brand>/source/ if it exists (drop zone for primary materials).
• The active project's notes/ (Kind-1 zone), discovered via its MANIFEST.md — never globbed directly.
• Public-web URLs the user provides.

Writes these frontmatter fields on every canonical (operational minimum per PRINCIPLES §4.1):

id, title, type, status, scope, brand, updated, produced_by, references — plus description, topics, audience (on AUDIENCE.md), output_language (when the brand communicates in a non-English language), and accepted_by / accepted_at only when the user explicitly accepts (P8/R25).

Status transitions authorized:

• May write status: draft on freshly produced canonicals.
• May write status: review once self-checks pass and a reviewer is summoned.
• Never writes status: greenlit or status: published. Per P8/R25, only an explicit natural-language user signal flips a canonical to greenlit. The orchestrator interprets the cue and writes accepted_by + accepted_at then.

P11 handoff — meaningful artifact, three-team review

A brand canonical is the highest-impact artifact in the marketing ecosystem — every downstream skill consumes it for every subsequent piece of work. Per P11, before user accept:

1. Executor (this skill, brand-dna) produces the canonical set with status: draft.
2. Reviewer examines the produced canonicals against the source materials. The reviewer is the artifact-reviewer skill (renamed from reviewer per skills-3lmx): the orchestrator dispatches it with artifact_path=brand/<brand>/<CANONICAL>.md, and it auto-derives the brand_canonical_reviewer.md rubric from the canonical's type: brand/<kind>. For high-stakes brands, an rp-cli session or a separate Claude conversation may add the optional fourth-role external brutal-review.
3. Orchestrator (typically Claude in the parent session) chains executor↔reviewer, surfaces findings to the user, and only then flips status: review → greenlit on the user's explicit cue.

This skill writes status: draft and notes in its closing summary that the canonical set is ready for review. It does not auto-mark status: greenlit.

When the produced canonicals warrant external brutal-review (a new brand, a high-stakes brand, an extraction from sparse sources), say so in the closing summary and invite the orchestrator to dispatch one before accept.

Context resolution

Parse input

Extract the following from the natural-language input ($ARGUMENTS):

Parameter	Detection	Default
brand	"for ", "brand: ", or the first noun phrase that looks like a brand name	REQUIRED — ask if missing
mode	"extract" (default), "elicit" (guided interview from scratch), "refresh" (re-run against new sources for an existing brand), "audit" (read-only check of canonicals vs source)	extract (or auto-routed by Phase A)
output_language	"in German", "output_language: de", or inferred from source-material language	en (English)
scope	If user provides specific canonical names ("just voice", "BRAND only"), restrict output to those. Default produces all five.	full canonical set

Brand slug derivation: lowercase, replace spaces with hyphens, strip non-alphanumeric except hyphens and underscores. Example: iurFriend → iurfriend.

Resolve the brand directory

Resolve the target directory in this order (P3 search-first):

1. brand/<brand>/ at the workspace root (the canonical location per R15).
2. iurFriend/brand/<brand>/ if the workspace nests under an iurFriend root.
3. If neither exists, create brand/<brand>/ (the canonical default per R15).

The brand directory is above project directories — multiple projects for the same brand read the same canonical set. Never write canonicals inside a project directory; per R17, a project may override a canonical by placing a same-named file at the project root, but that is the consumer's job, not yours.

Phase A — source assessment & routing

Before gathering sources, silently assess what is available:

1. Classify available sources by tier (see knowledge/source_handling.md):

   • Tier 1 — direct first-party (founder interviews, brand guides, primary website)
   • Tier 2 — approved derivative (prior marketing copy, signed-off articles)
   • Tier 3 — external or unverified (press, scrapes, competitor copy)

2. Count total sources (files in brand/<brand>/source/, user-named files in $ARGUMENTS, provided URLs).

3. Route based on source count:

   Total sources	Routing
   ≥ 3	Offer extract mode. Proceed to Step 1 (source gathering).
   1–2	Recommend elicit mode: "I found only N source(s) — this extraction will produce low-confidence canonicals. I can run a structured interview instead (~10–20 min, one question at a time). Which would you prefer?"
   0	Recommend elicit mode and offer the zero-arg on-ramp choice. If user insists on extract with no sources, refuse per P7.

4. Let the user override. The routing is a recommendation, not a gate. If the user explicitly wants to extract with sparse sources, proceed with confidence: low warnings. If the user wants to elicit despite having materials, run the interview first (the transcript becomes a Tier-1 source, then extraction proceeds).

Probe for existing canonicals

ls brand/<brand>/*.md 2>/dev/null

Finding	Behavior
No canonicals exist	Proceed to extraction (Step 1).
Some canonicals exist (status: draft or status: review)	Confirm with user: overwrite, complete the missing ones, or refresh?
Canonicals exist with status: greenlit	STOP. Do not overwrite a greenlit canonical without explicit user instruction. Offer: (a) propose updates to a sibling file (VOICE.refresh.md) for review, (b) abort.

A greenlit canonical is human-curated truth (R9 — extraction once, curation forever after).

Elicitation (Scenario 2) — guided interview from scratch

When to use: user has 0–2 sources, or explicitly requests "interview me", "build from scratch", or "guided brand elicitation". Phase A will recommend this path automatically when sources are sparse.

Full methodology: knowledge/elicitation_methodology.md. Summary of the flow:

1. Confirm the brand name and any constraints (output language, scope, deadline).
2. Present the method menu — numbered families the user cycles through. Always-include floor: methods 0, 1, 4, 5 + at least one of {2, 3}.
   • 0 Reflective (origin, purpose, why-it-exists) → BRAND
   • 1 Audience discovery (personas, journey, pains, vocabulary) → AUDIENCE
   • 2 Voice & tone (read-me-a-paragraph, what-you'd-never-write) → VOICE
   • 3 Offer & positioning (what you sell, to whom, differentiation) → OFFER
   • 4 Company facts & compliance (legal, logos/colors, terminology, disclaimers) → COMPANY
   • 5 Constraints (output language, scope, deadline)
   • 9 Proceed → capture transcript + dispatch extractor
3. One question at a time. Ask AskUserQuestion for multiple-choice where it helps; open-ended otherwise. Challenge framing ("Is that aspirational or what your copy actually says today?").
4. Tag every answer in the transcript: [brand-stated] | [brand-inferred] | [evidence-gap].
5. Sectional confirmation — after each method, reflect back and ask "Does that look right?"
6. Coverage check — before proceeding, compare answers against knowledge/canonical_coverage_checklist.md. Surface any uncovered required fields; ask if the user wants to fill them or accept confidence: low.
7. Capture the transcript — write to brand/<brand>/source/elicitation-<date>.md (Tier-1 source). Frontmatter: brand, created_at, methods_used, session_completion_confidence.
8. Dispatch the extractor — after the transcript is saved (+ any real sources), dispatch the brand-dna-extractor agent (see below).

Fast-track option — for impatient users, offer a 12-question sprint (2 per method family across origin / audience / voice / offer / company / constraints), then extract at confidence: low | medium.

Progress signposting — show the method menu with ✓ marks so the user always sees coverage-so-far and what remains.

Step 1: Gather source materials

Construct a source-material inventory before producing anything. Per P7 (references beat invention), every claim in the canonicals must trace to a source listed in references:.

Detect available sources

# Brand source drop zone
ls brand/<brand>/source/ 2>/dev/null

# Files the user named in $ARGUMENTS
# (already provided)

# Notes from the active project — manifest-first (per the manifest-first doctrine).
# If the user invokes this skill from a project root, read project-root
# MANIFEST.md first, then read only the notes/ entries it indexes.
# Do NOT use .active-project, projects/<id>/, or direct notes/ globbing.
test -f MANIFEST.md && sed -n '1,220p' MANIFEST.md

Then ask the user for any of these that aren't already provided:

• A link to the brand's website (homepage + about + services pages).
• A brand guide PDF or markdown if one exists.
• 3–10 sample articles or blog posts that the brand considers "on-voice".
• A founder/leadership interview transcript (or a recorded session — transcribe first).
• The brand's elevator pitch, in their own words.
• Any prior marketing copy: emails, landing pages, social posts.

Source-tier classification

Tier	What	Confidence weight
1 — Direct first-party	Founder interview, brand guide owned by the brand, primary website copy	High — use for assertions of intent (voice, values, audience)
2 — Approved derivative	Past blog posts the brand signed off on, prior marketing copy in production	Medium — use for evidence of practice (sentence shape, vocabulary, cadence)
3 — External or unverified	Third-party press, competitor analysis, scraped public content	Low — use for context only; never the sole source of a claim

Below 3 total sources of mixed tier, signal to the user that the extraction will produce low-confidence canonicals — better to gather more material before proceeding, OR to mark the canonicals confidence: low in their frontmatter and explicitly note in the canonical body that elicitation is required to lift confidence.

Source citation discipline (P7)

Every canonical assertion carries a citation comment like <!-- Evidence: brand-guide.md:§3.2 --> or <!-- Evidence: website-homepage.html:hero-copy -->. Bare claims without provenance are a P7 violation. If no source supports an assertion, mark it as an explicit assumption: <!-- Assumption: based on user's domain framing; not yet source-attested -->.

Aggregate the sources in the canonical's references: field.

Step 1b: Dispatch the brand-dna-extractor agent

Once sources are assembled (real source files for Scenario 1, or the elicitation transcript for Scenario 2, or both), dispatch the brand-dna-extractor agent to do the autonomous canonical production:

Dispatch brand-dna-extractor with:
  brand: <brand-slug>
  source_dir: brand/<brand>/source/
  scope: <full|restricted scope from $ARGUMENTS>
  output_language: <en|de|nl|…>

The extractor runs forked (context-clean, autonomous), reads all sources, and produces the five canonicals in the correct COMPANY→BRAND→AUDIENCE→OFFER→VOICE dependency order. It applies P7 citation discipline, self-reports confidence per canonical, and writes status: draft (never greenlit — P8/R25).

This skill (main loop) owns:

• The source assessment (Phase A)
• The elicitation interview (Scenario 2, if needed)
• The reviewer handoff (Step 4)
• The closing summary (Step 5)
• The End-of-run self-improvement check

The extractor agent owns:

• Reading all sources
• Producing the five canonical files
• Per-claim evidence citations
• Confidence calibration
• Cross-canonical coherence check

The extractor returns a structured summary. This skill forwards the summary to the reviewer and the user.

Step 2: Extract — produce the canonical set

Per M7 (Migration decision), this skill ships the full canonical set in one invocation. A future split into a family (brand-extractor, voice-extractor, audience-extractor, offer-extractor) is reserved for a later version if extraction sources prove sufficiently different per canonical. For now: produce all five.

The five canonical templates are in knowledge/templates/:

• knowledge/templates/BRAND.template.md
• knowledge/templates/VOICE.template.md
• knowledge/templates/AUDIENCE.template.md
• knowledge/templates/OFFER.template.md
• knowledge/templates/COMPANY.template.md

Each template carries the v0.4.1 operational-minimum frontmatter (P4 §4.1) plus the editorial-enrichment fields (§4.2) appropriate to its type. Copy the template, fill in the structured sections from the source materials, and write to brand/<brand>/<NAME>.md.

Extraction order and dependencies

Produce in this order — each canonical informs the next:

1. COMPANY.md first. Establishes the corporate identity, legal name, jurisdiction, terminology — facts that anchor everything else.
2. BRAND.md next. The narrative identity: who the brand is, what it stands for, archetype, positioning. Pulls from COMPANY (identity facts) + source materials (intent, values).
3. AUDIENCE.md third. Who the brand serves. Pulls from BRAND (positioning) + source materials (who reads the website, who books the calls).
4. OFFER.md fourth. What the brand sells, to whom (AUDIENCE), aligned with positioning (BRAND), under the company's terms (COMPANY).
5. VOICE.md last. How the brand speaks — extracted from sample articles + brand guide + the now-known audience. Voice is downstream of who-you're-talking-to.

If the user restricts the scope to a subset, produce only the requested canonicals — but read the dependencies upstream as input even when not writing them.

Frontmatter on every canonical

Every produced file carries:

---
id: <brand>-brand-<kind>           # e.g., iurfriend-brand-voice
title: "<Brand> — <Canonical Kind>"
type: brand/<kind>                  # brand | voice | audience | offer | company
status: draft                       # never greenlit at production time (P8/R25)
scope: brand                        # this is a brand-scoped canonical (PRINCIPLES §4.1)
brand: <brand-slug>
output_language: <en|de|nl|…>       # the lens for human-facing prose (§4.2)
updated: <ISO 8601 date>
produced_by: [email protected]
references:
  - "brand-guide.pdf"
  - "https://brand.example.com/about"
  - "notes/founder-interview-2026-03.md"
  - "notes/sample-articles/article-1.md"
description: >
  <One-paragraph summary of what this canonical covers and why it matters.>
topics:
  - <key topic 1>
  - <key topic 2>
confidence: <low|medium|high>       # self-reported per source-tier balance (§4.4)
---

Do NOT set accepted_by or accepted_at. Those fields are only written when the user explicitly accepts (P8/R25). Do NOT carry phase: or any CCF-legacy field. Do NOT carry extraction_method, approver, approved_date — superseded by produced_by, status, accepted_by/accepted_at.

If the brand communicates in a non-English language, set output_language: accordingly and write the canonical's body in that language. Frontmatter keys remain English (PRINCIPLES §2 "Output language as a lens").

Step 3: Self-check (activity-checks per P9)

Run activity-checks against the produced canonicals. These are advisory, not gates — surface findings, let the orchestrator and user decide. Per P9, no check blocks progression on its own.

Check	Test	If it fails
References present	Every canonical has ≥ 1 entry in references:	Flag: "Canonical X has no references."
Citations in body	Every major section has at least one <!-- Evidence: ... --> comment or explicit <!-- Assumption: ... -->	Flag: "Section 'Voice Character' has 4 claims and 0 evidence comments."
Cross-canonical coherence	OFFER's audience segments correspond to AUDIENCE personas; VOICE's vocabulary echoes AUDIENCE vocabulary	Flag: "OFFER references audience 'cost-researcher' but AUDIENCE.md defines 'cost-conscious-buyer'."
Source-tier balance	At least one Tier 1 source per canonical, or confidence: low marked	Flag: "VOICE.md has no Tier 1 source; consider marking confidence: low."
Frontmatter completeness	All operational-minimum fields present (§4.1)	Fix in place before reporting.
No legacy fields	No phase:, approver:, confidence: 0.0 numeric, etc.	Fix in place.

Report check results in the closing summary. The orchestrator decides whether to address them, dispatch a reviewer, or proceed.

Step 4: Hand off to the reviewer (P11)

Once self-checks pass (or are accepted as-is by the orchestrator), the canonical set is ready for the reviewer pass.

In the closing summary, surface to the orchestrator:

• The list of produced canonicals (paths + status: draft).
• A one-paragraph recommendation: "Ready for reviewer. The reviewer should examine each canonical against the source materials and surface any claims that lack evidence or contradict the sources. For high-stakes brands, dispatch an external brutal-review pass."
• Any self-check findings worth the reviewer's attention.

The artifact-reviewer skill writes one report per canonical — brand/<brand>/<slug>-review-report.md (e.g. voice-review-report.md, brand-review-report.md) — each with type: review/report, rubric: brand_canonical_reviewer, status: review, and a recommendation: greenlit | revise | block. The orchestrator chains executor↔reviewer until quality is acceptable, then surfaces to the user for acceptance.

On accept (an explicit natural-language cue from the user, per P8/R25): the orchestrator — not this skill — flips status: draft → greenlit and writes accepted_by: <user>, accepted_at: <ISO datetime> on each accepted canonical.

Step 5: Close out

Write a concise summary to the orchestrator covering:

• Brand: which brand + slug.
• Mode: extract / refresh / audit.
• Produced: list of canonicals written, paths, status: draft.
• Sources used: count by tier, total count.
• Confidence: per-canonical self-reported confidence.
• Self-check findings: any flagged issues.
• Next: reviewer pass; orchestrator decides whether to dispatch a sibling reviewer skill, a sub-agent, or an external rp-cli session.

Error handling

Condition	Action	Exit
No brand provided	Ask the user: "Which brand? Provide a name like iurfriend or Accent Tandartsen."	--
Brand directory exists with greenlit canonicals	Confirm before overwriting; default is to abort and propose a .refresh.md sibling.	--
No source materials available	Ask the user for sources before extracting. Do not bootstrap canonicals from imagination — P7 forbids invention.	--
Source materials below 3 total	Warn: "Low-source extraction; canonicals will be marked confidence: low. Continue?"	--
Filesystem error during write	Report error, do not partial-write.	3

Storage tier compliance

Manifest scope. brand/<brand>/ is a brand-scope zone outside the project-workspace manifest regime (the manifest-first doctrine's Scope exemption names brand/ explicitly). Canonical writes here are not manifest-indexed. Manifest-first applies only to the project notes/ read below.

• READ FROM: source materials in user-named files, URLs, brand/<brand>/source/, the active project's notes/ (via its MANIFEST.md, per manifest-first), the brand's public website.
• READ FROM (knowledge): knowledge/templates/*.md (canonical templates), knowledge/extraction_methodology.md, knowledge/quality_self_check.md, knowledge/source_handling.md.
• WRITE TO: brand/<brand>/<CANONICAL>.md (the five canonicals).
• WRITE TO (optional): the reviewer (not this skill) writes brand/<brand>/<slug>-review-report.md — one per canonical — during the P11 pass.
• NEVER write to .ccf-core/, .ccf/, project-internal 00_dna/, company_dna/, or any CCF-era path.
• NEVER write status: greenlit or accepted_by / accepted_at (P8/R25).

Natural-language examples

# First-time brand onboarding from source materials (Scenario 1)
/brand-dna "extract brand DNA for iurFriend from the materials in brand/iurfriend/source/"

# Guided elicitation from scratch (Scenario 2)
/brand-dna "I don't have any brand materials — interview me for my new consultancy"

# Guided elicitation explicit mode
/brand-dna "elicit brand DNA for new-brand — build it from scratch via interview"

# Specific scope
/brand-dna "just produce VOICE and AUDIENCE for AccentTandartsen, in German"

# Refresh against new sources
/brand-dna "refresh iurFriend canonicals — new founder interview at notes/interview-2026-04.md"

# Audit mode (read-only check)
/brand-dna "audit iurFriend brand canonicals against the current website copy"

# Low-source bootstrap (will produce low-confidence canonicals)
/brand-dna "extract brand DNA for new-brand — only the homepage is available"

# Zero-arg on-ramp (no arguments — skill asks what scenario)
/brand-dna

End-of-run (R26)

After Step 5 (closing summary), check whether anything in this run deviated from the documented flow before going idle. Deviation triggers (any one suffices):

• The user requested an extraction depth or focus that wasn't captured by the standard 5-canonical set (e.g., asked for a separate JOURNEY.md for an iurFriend-style customer-journey breakdown, or wanted PRICING.md split out from OFFER.md).
• Source materials came in a format the documented extraction methodology didn't anticipate (audio interview transcripts, video walkthroughs, dense compliance-PDFs) and the extraction approach had to improvise.
• A specific brand recurringly needed a particular flag/scope combination — e.g., "for every iurFriend project, restrict to VOICE + AUDIENCE only" — suggesting a documented per-brand default.
• The reviewer (P11) flagged a recurring issue that the self-check (knowledge/quality_self_check.md) didn't surface — suggests adding a check.
• The user overrode the bootstrap-once-per-brand guard via mode: refresh and the refresh produced materially different content (suggests the original canonicals had a quality gap worth retiring older content).
• Anything else surprised the user or forced Claude to improvise outside this SKILL.md.

If a trigger fired, surface the specific deviation and ask whether to fold it back into the skill. Be context-specific:

"I noticed you asked for a separate JOURNEY.md (not part of the standard 5-canonical set). If iurFriend-style journey-stage brands are recurring for you, should I add JOURNEY as an optional sixth canonical with a template?"

"The reviewer flagged that VOICE.md was missing a sentence-length calibration target three times in a row. Should I tighten knowledge/quality_self_check.md to make that an explicit check?"

If the user confirms, update SKILL.md (and knowledge/templates/*.md or knowledge/quality_self_check.md if relevant) inline before going idle. If the user declines, do not write an AI-authored learning note into project notes/; surface the declined suggestion in the closing summary, and let the orchestrator file a Bead or a project-appropriate learning-log entry when the user wants it preserved.

Standard runs end at Step 5's closing summary. No prompt fires for uneventful extractions.

Note on the retired manifest script. Prior versions shipped a scripts/generate_manifest.sh that produced a SHA-256-checksummed JSON manifest of the canonicals. Per R30 (DECISIONS v0.2.7, 2026-05-14), the script and its JSON output retired — no consumer existed (forward-looking infrastructure for a hypothetical future tool), and the skills-ecosystem defaults to markdown outputs unless a non-LLM consumer requires machine-readable formats. If a downstream skill ever needs a stable cross-canonical handshake, build it then.

Language Handling

• Detect the conversation language; respond in the user's language unless explicitly asked otherwise.
• If MANIFEST.md declares an output_language: field, honor that declaration over inferred conversation language.
• Translate internal checklist labels and headings naturally — do not force English headings into non-English output.
• Preserve legal, financial, and technical terms in their original language (Trennungsjahr, MwSt, BTW, Aufhebungsvertrag, etc.).
• Preserve Unicode characters natively (ü, ö, ä, ß, etc.); never substitute transliterations (ue, oe, ae, ss).
• Frontmatter field names and enum values stay English regardless of content language. Free-text frontmatter values may follow content language where natural.
• VOICE.md and AUDIENCE.md are written in the brand's primary operating language — German brands get German voice descriptions and German example phrases; Dutch brands get Dutch. The brand's language IS part of its voice; transliterating it loses signal. BRAND.md, OFFER.md, and COMPANY.md follow the same rule unless the brand explicitly operates bilingually (note this in COMPANY.md).
• Direct quotes from source materials (founder interviews, customer reviews, transcripts) are preserved verbatim in their original language inside the canonicals — never paraphrased into English.

Related skills

• Project-local bootstrap routine — scaffolds a marketing project and may reference brand canonicals in MANIFEST.md.
• /content-strategist (future) — Writes content briefs against the brand canonicals.
• /content-writer (future) — Drafts articles using VOICE.md + AUDIENCE.md + the brand context.
• /editor (future) — Reviews drafts against the canonical set.
• /artifact-reviewer:artifact-reviewer — The canonical P11 reviewer; applies the brand_canonical_reviewer rubric to each canonical and emits <slug>-review-report.md.

Knowledge files

• knowledge/extraction_methodology.md — How to extract each canonical kind from source materials; what to look for; what evidence supports which assertion.
• knowledge/source_handling.md — Source-tier classification, citation discipline, handling sparse-source extractions. Contains the elicitation-as-source snippet (promoted to full methodology in elicitation_methodology.md).
• knowledge/quality_self_check.md — Activity-checks (P9) for the produced canonical set; what good looks like, what to flag.
• knowledge/elicitation_methodology.md — NEW (Scenario 2). Full guided-interview flow: Phase A, method menu, one-question-at-a-time discipline, provenance tagging, coverage check, transcript capture.
• knowledge/canonical_coverage_checklist.md — NEW. Per-canonical field→method→coverage-question map. The completeness contract binding the interview to the outputs.
• knowledge/templates/BRAND.template.md — BRAND canonical scaffold (v0.4.1 frontmatter + structured body).
• knowledge/templates/VOICE.template.md — VOICE canonical scaffold.
• knowledge/templates/AUDIENCE.template.md — AUDIENCE canonical scaffold.
• knowledge/templates/OFFER.template.md — OFFER canonical scaffold.
• knowledge/templates/COMPANY.template.md — COMPANY canonical scaffold.

Input

Arguments: $ARGUMENTS