fill

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

1. Shared preamble: Load references/quality/activation-preamble.md — context assembly, persona adaptation, deterministic routing rules.
2. 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.
3. 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.
4. 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.
5. 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).
6. Load product spec from references/product-specs/{type}-spec.md
7. 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 be cognitive-depth. Don't assume type=depth.
   • §CONSTITUTIONAL_PRIMITIVES — for agents and minds, suggest criticalSystemReminder when the product must maintain identity over long conversations (50+ turns). Especially for cognitive minds.
   • §COMPOSITION_PRINCIPLES — when filling a squad or system, apply convergence-by-independence (specialists don't see each other's work until synthesis) and symbiosis rules.
8. Load domain-map.md if it exists (from /map) → use as knowledge source
9. Load scout report if .meta.yaml has intent_declaration.scout_source field (canonical location) OR .meta.yaml root-level scout_source field (legacy fallback) → read workspace/{scout_source} for research context. Extract: baseline (Section 1), gaps (Section 2), research findings (Section 4). This intelligence drives research injection in the section walk. 8b. Domain intelligence back-reference: Read STATE.yaml → workspace.products[]. Find products in the same intelligence.domain as the current product. If any exist with intelligence.value_score populated:
   • Read the most recent sibling's .meta.yaml → intelligence and state.overall_score
   • If sibling substance_score < 50: "Your last product in {domain} scored {substance}% substance. Focus on depth and real examples this time."
   • If sibling substance_score >= 70: "Your {domain} products have strong substance ({substance}%). Maintain this depth."
   • This closes the feed-back loop: /validate's output informs /fill's approach.
10. Scan product files for template placeholders and WHY comments
11. Intelligence gap check: If .meta.yaml has NO scout_source AND product targets MCS-2+:
    • Show: "No scout report found. Without baseline intelligence, /fill works in creator-knowledge-only mode — no research proposals, no baseline comparison."
    • Suggest: "Run /scout {inferred_domain} first for research-backed filling. Or continue with your expertise."
    • Record fill_config.scout_available: false in .meta.yaml
    • If creator continues without scout, skip research injection steps in section walker
12. Structured input for choices: If creator.yaml → preferences.workflow_style = guided, use AskUserQuestion for all choice points (enhance/replace/skip, deepening method selection, continue/save progress). Use plain text only for open-ended domain knowledge extraction.
13. Read fill-protocol.md: Read ${CLAUDE_SKILL_DIR}/references/fill-protocol.md now — it contains the full execution protocol for all phases below. 12b. SELF-CLONE branch (cognitive minds with sub_type=self only). If .meta.yaml.type == "minds" AND .meta.yaml.minds_sub_type == "self":
    • Load the SELF-CLONE content pack: Read references/fill-content-packs/self-clone.md
    • The content pack replaces the standard Discovery, Extraction Mode, and generic Section Walk phases
    • Follow the content pack's walker entry point (§1) which handles:
      • Mode selection (distillation vs elicitation based on corpus density)
      • Distillation pass (if applicable) with creator confirm/refine/reject per entry
      • Gap elicitation with the ordered question sequences per dimension
      • Dimensional routing (primary + secondary tagging)
      • Typology mirror (post-elicitation, three-step protocol)
      • Coherence diff generation
      • Honesty floor gates (counter-proofs, signed incaptable list, uncapturable decisions)
      • Writing populated content into the cognitive mind layer files
    • After the SELF-CLONE walker completes, skip to Completion (step 13 standard flow is bypassed)
    • The Sparring, Checkpointing, and Progress phases from the standard flow still apply during the walker — checkpoint after every two dimensions
    • Record fill_config.self_clone: true in .meta.yaml
    • Do not run this branch for non-SELF cognitive minds or non-minds products — all other types continue to step 12c or 13 12c. SQUAD ORGANISM branch (type=squad only). If .meta.yaml.product.type == "squad":
    • This branch replaces the standard section walker. Squads are organism-level products — the standard single-file walk is insufficient. The squad walker iterates across the full directory tree.
    • Phase 1 — Composition Discovery (if not already answered in /create):
      • Ask archetype if not in .meta.yaml: Sequential Pipeline / Parallel Fan-Out / Conditional Router / Iterative Refinement / Hierarchical Delegation
      • Role-aware composition (entity-ontology.md §AGENT_ROLES): Instead of generic "how many specialists?", present the 7 functional roles: "Each specialist has a functional ROLE that determines tools and output. Select from: EXECUTOR (acts on files), SPECIALIST (deep analysis, read-only), ORCHESTRATOR (coordinates agents), ROUTER (classifies + directs), ADVISOR (thinks, never acts), VALIDATOR (checks quality), TRANSFORMER (converts formats)." Ask: "Name each specialist, their domain, and their role. Example: 'researcher=SPECIALIST, strategist=ADVISOR, executor=EXECUTOR, reviewer=VALIDATOR'." Record role assignment per agent for Phase 3 frontmatter generation.
      • Ask entity lifecycles: "What objects flow through this squad? (e.g., a CAMPAIGN, a LEAD, an EXPERIMENT). Describe the lifecycle stages."
    • Phase 2 — Orchestrator Layer (kernel/):
      • Walk kernel/orchestration.md — fill orchestration protocol. Ask: "How does the coordinator decide what to do? Describe its decision cycle step by step."
      • Walk kernel/elicitation-engine.yaml — fill progressive elicitation rules. Ask: "What questions does the squad ask the user before acting? How does it adapt based on answers?"
      • Walk kernel/intelligence-matrix.yaml — fill scoring/routing intelligence. Ask: "How does the squad score which agents are most relevant for a given request?"
    • Phase 3 — Specialist Agents (agents/):
      • For EACH agent file in agents/*.md:
        • Walk identity, role, tools, escalation rules
        • Map to AGENT ROLE from entity-ontology.md §AGENT_ROLES. The role assigned in Phase 1 determines:
          • Tool boundary: EXECUTOR=Write/Edit/Bash, SPECIALIST/VALIDATOR=Read-only, ORCHESTRATOR=Agent-only (no Write/Edit), ADVISOR=denied-tools
          • Handoff format: EXECUTOR→artifacts, ADVISOR→judgment, ORCHESTRATOR→routing decisions, VALIDATOR→score+verdict, TRANSFORMER→converted output
          • Frontmatter: set allowed-tools or denied-tools per role mapping in the agent .md file
          • Question shape: EXECUTOR→"What does it produce?", ADVISOR→"What reasoning framework?", VALIDATOR→"What criteria?", TRANSFORMER→"What's the input/output format?"
        • If agent has a mind-clone source in minds/: load minds/{name}/cognitive-model.md and use as knowledge substrate
        • Apply D1 (activation protocol), D2 (anti-patterns ≥5), D14 (graceful degradation) per agent
        • Sparring: "What would this specialist REFUSE to do? What's outside its boundary?"
    • Phase 4 — Task Registry (tasks/):
      • Walk tasks/task-registry.yaml — for each specialist, define 3-10 granular tasks with:
        • task_id, description, assigned_agent, input_schema, output_schema, quality_gate
      • Ask per agent: "What are the 3-5 most important things {agent_name} does? For each, what input does it need and what output does it produce?"
    • Phase 5 — Chains & Workflows (chains/, workflows/):
      • Walk chains/chain-registry.yaml — define micro-workflows (2-4 agent sequences with cadences)
      • Walk workflows/*.md — define full pipelines mapping lifecycle stages to agents
      • Ask: "Walk me through the main workflow from start to finish. Which agent handles each step? What passes between them?"
    • Phase 6 — Routing & Handoff (config/):
      • Walk config/routing-table.md — fill declarative routing rules (IF intent → agent)
      • Calibrate routing per §WORKFLOW_VS_SQUAD: Squad routing involves LLM judgment — the orchestrator reads rules BUT interprets contextually. Ensure routing questions surface the judgment points: "When the input is ambiguous, how does the orchestrator decide?" This is what makes it a squad, not a workflow.
      • Use §INTELLIGENCE_GRADIENT to calibrate autonomy: "How much should the orchestrator decide autonomously vs. escalate to the human? Where on the deterministic↔autonomous spectrum should routing sit?"
      • Walk config/handoff-protocol.md — define handoff envelope format (XML or structured)
      • Sparring: "What happens when the input doesn't match any route? What's the fallback?"
    • Phase 7 — Quality & Testing (tests/):
      • Walk test scenarios: happy path, edge case, adversarial, agent failure recovery
    • Anatomy completeness check (entity-ontology.md §SQUAD_ANATOMY): Before transitioning to content state, verify all 8 squad anatomy components have been addressed:
      1. Agent Roster — at least 2 agent files in agents/ with substantive content
      2. Routing Table — config/routing-table.md has routing rules (not just placeholder)
      3. Handoff Protocols — config/handoff-protocol.md has envelope format
      4. Workflows — at least 1 workflow with steps defined in workflows/
      5. Skills-as-Instruments — skills/ directory exists (advisory — some squads don't need shared skills)
      6. Checklists — SQUAD.md has quality/checklist section with ≥2 items
      7. Templates — kernel/ has output format standards
      8. Escalation — SQUAD.md has escalation section with confidence thresholds If any component is missing, flag it: "Your squad is missing {component}. Without it, {consequence}. Want to add it now or defer?"
    • Completion: After all phases, update .meta.yaml with fill_metrics and transition state to content.
    • Record fill_config.squad_organism: true in .meta.yaml 12d. Agent ontology-aware elicitation (type=agent only, non-squad). If type == "agent" AND branch 12c did NOT fire:
    • Entity ontology already loaded at step 6b
    • At the START of the section walk, ask the role question: "What functional role does this agent fill? EXECUTOR (acts on files), SPECIALIST (analysis only), ADVISOR (thinks, never acts), VALIDATOR (checks quality), TRANSFORMER (converts formats)?"
    • Use the selected role to determine:
      • Which tools to suggest in the frontmatter section (EXECUTOR→Write/Edit/Bash, SPECIALIST→Read-only, ADVISOR→denied-tools)
      • What output to expect (artifacts vs reports vs reasoning)
      • What questions to emphasize (EXECUTOR→"What does it produce?", ADVISOR→"What reasoning framework?", VALIDATOR→"What criteria does it check?")
    • Record role in .meta.yaml → agent_role for /validate consumption 12e. Workflow ontology-aware elicitation (type=workflow only). If type == "workflow":
    • Entity ontology already loaded at step 6b
    • Enforce §WORKFLOW_VS_SQUAD: workflows use SKILLS (not agents), have FIXED sequences (not LLM routing), are DETERMINISTIC (same input → same execution path)
    • During the section walk, ask:
      • "What skills does each step invoke?" (NOT "what agents" — workflows don't use agents)
      • "Is the sequence always the same regardless of input?" (If answer is "it depends" → suggest squad: "This sounds like it needs contextual routing — that's a squad, not a workflow. Want to switch?")
      • "What are the gate conditions between steps?" (pass/fail criteria for proceeding)
    • If evidence suggests LLM judgment needed → surface heuristic from §HEURISTICS as coaching
14. Begin section-by-section guided extraction (see fill-protocol.md → DISCOVERY PHASE)