Content Filler

Extract domain expertise from creator conversation and inject into product files.

When to use: After /create has generated a scaffold. Product state should be "scaffold" or "content".

When NOT to use: If the product doesn't exist yet (use /create first). If the product is already validated (edits will regress state).

Full protocol details (section walker, sparring, extraction modes, type-specific coaching, research injection, progress tracking, completion flow) are in: ${CLAUDE_SKILL_DIR}/references/fill-protocol.md — Read this file before executing the section walk.

Activation Protocol

0. Shared preamble: Load references/quality/activation-preamble.md — context assembly, persona adaptation, deterministic routing rules.
1. Identify target product:
   • If $ARGUMENTS provided, use as product slug → look in workspace/{slug}/
   • If workspace/{slug}/ does not exist → "Product {slug} not found in workspace/. Run /create first or check workspace/ for available slugs."
   • If not, glob workspace/*/ and list products in scaffold/content state
   • If no products in scaffold/content state found → "No products ready to fill. Run /create {type} to scaffold one first."
   • If multiple products found, ask which one to fill 1b. Mode selection (Express vs Guided). Read creator.yaml → preferences.workflow_style. Resolve the flow mode:
   • --express flag OR workflow_style == "autonomous" → Express mode. Skip the three Discovery front-loaded questions, skip the Pitfall Check interactive prompt, skip Extraction Mode menu (default to Standard), skip the Deepening menu after each section, run the section walker with type defaults, and fall straight through to Completion. Interactive prompts are replaced by type-based defaults + one-line advisory notes. Proactive brainstorm prompts are suppressed.
   • workflow_style == "guided" or missing → Guided mode (default). Run the full protocol as documented in fill-protocol.md. Record fill_config.mode: express | guided in .meta.yaml so later skills can reason about the creator's chosen rhythm.
2. Read .meta.yaml from product directory → get type, state, mcs_target, AND the intent_declaration block if present.
   • Intent-aware calibration: If intent_declaration is present, extract engine_parsed.{depth, nature, delivery_mechanism}. These three fields drive section walker routing, tone calibration, and question shape — see fill-protocol.md → INTENT-AWARE CALIBRATION for the full rubric. Record fill_config.intent_aware: true in .meta.yaml when the calibration fires.
   • Legacy fallback: If intent_declaration is absent (legacy product) OR if intent_declaration.mode == legacy_fallback with all engine_parsed fields null, fall back to type-based defaults. Emit one advisory line: "This product lacks intent metadata — /fill will use type-based defaults. Re-run /create to unlock intent-aware filling." Record fill_config.intent_aware: false.
3. Maintain creator persona: Read creator.yaml → adapt language, depth, and examples to profile.type and technical_level throughout this skill's execution. A developer gets code examples; a domain expert gets plain language.
4. Load UX stack (in order):
   • references/quality/engine-voice-core.md — the micro voice contract carried through every question, section signal, and sparring line in /fill. This is where the Creator spends the most time; the voice cannot drift.
   • references/ux-experience-system.md §1 Context Assembly (build creator context), §2.2 Archetype-Aware Insights (adapt emphasis to creator goals), §2.3 Moment Awareness (mid-fill coaching)
   • references/ux-vocabulary.md — translate terms in any creator-facing output Vocabulary enforcement (mandatory): Every question, section signal, sparring challenge, and progress message passes through ux-vocabulary.md translation before reaching the creator. Internal terms (Sparring, Pitfall, MCS, DNA tier, extraction mode) are replaced for non-dev creators. For dev/hybrid creators, terms may appear but always with context ("MCS-2 quality checks — these verify craft and expertise depth").
   • references/quality/engine-voice.md — full voice substrate. Load when composing section quality signals, sparring pressure, milestone celebrations, or brand moments.
   • references/quality/exemplar-outputs.md sections E4 and E5 only — the section question and sparring exemplars. These show the exact visual rhythm and warmth your questions must carry: progress sandwich (bar → celebration → question → escape hatch), warm framing, 💡 scaffolding offers.
   • references/ux-experience-system.md §11 Deep Elicitation Protocol — MANDATORY for all AskUserQuestion calls. Apply: experience-based questions (not abstractions), one question at a time, mirror to confirm, escalate progressively, offer scaffolding when stuck, celebrate depth. /fill is where the creator spends the MOST time. The experience must be warm coaching, not interrogation. Adapt: beginners get encouragement + examples. Experts get peer-level sparring. Celebrate section completions with progress visibility ("4/7 sections filled. Core identity locked in."). Hyper-personalize using creator.yaml fields — name, goals, expertise areas. 4b. Load proactives: Load references/engine-proactive.md — wire #1 (pipeline guidance: after fill completes, guide to /validate), #17 (lost creator: if stuck on a section for 3+ questions, offer /think or skip), #19 (error recovery: if fill encounters malformed scaffold, suggest re-scaffolding).
5. Load product spec from references/product-specs/{type}-spec.md
6. Load product DNA from product-dna/{type}.yaml 6b. Load entity ontology (squad/system/agent/workflow/minds): If type ∈ {squad, system, agent, minds, workflow}, read references/entity-ontology.md. This substrate drives semantic elicitation:
   • §AGENT_ROLES: suggest specific roles during composition discovery, adapt questions per role (EXECUTOR gets tool/output questions, ADVISOR gets reasoning questions, VALIDATOR gets criteria questions)
   • §SQUAD_ANATOMY: verify all 8 components are addressed during fill — flag any missing component before completion
   • §COMPOSITION: know what this type can compose with and what's forbidden — guide toward valid compositions
   • §HERITAGE: explain to the creator why certain DNA patterns apply (squad inherits from agent lineage)
   • §INTELLIGENCE_GRADIENT: calibrate autonomy level in routing questions — workflows get deterministic, squads get judgment-based
   • §WORKFLOW_VS_SQUAD: when filling a workflow, enforce YAML-decides (not LLM routing). When filling a squad, surface LLM judgment points
   • §HEURISTICS: if evidence suggests wrong type (e.g., squad with 1 useful agent), surface demotion heuristic as coaching
   • §RUNTIME_BEHAVIOR: calibrate token budget expectations and explain context isolation to the creator
   • §ISOMORPHIC: use human cognitive analogies to explain product role to non-dev creators
   • For type=system ONLY: §SYSTEM_ENGINES — the 13 functional gears. Walk each active gear during fill, ask for concrete implementation decisions, verify counterpart coupling
   • §INTELLIGENCE_PIPELINE — governs how scout research ACTIVELY enters product content (not passively). For EVERY section: check if scout report has relevant findings → propose content from research → creator validates/refines → sparring challenges generic answers. This is the soul of the Engine — condensing intelligence, not just filling templates.
   • §FOUNDATIONAL_THESIS — for EVERY product, ask: "What should this NEVER be able to do?" The answer generates the intelligence flow. Use to guide frontmatter restrictions (denied-tools, paths: scoping).
   • §TRANSVERSAL_AXES — calibrate Nature (procedural/advisory/executive/orchestrative) and Depth (surface/functional/cognitive) during fill. A skill CAN