/LEAP

name: LEAP
description: |
  LEAP builds skills through two pipelines: Branch A distills a skill from raw
  data, while Branch B combines multiple skills into one. It is called by the
  main SkillAlchemy workflow. Use when SkillAlchemy requires distillation or fusion.

LEAP · Skill Builder

LEAP does not choose the request type or interact with the user. SkillAlchemy selects the branch and handles each user checkpoint. LEAP runs the selected pipeline and returns the result.

Branch Routing

| Command | Branch | Pipeline | |---------|--------|----------| | `distill` / `distillation` | **Branch A** | Distillation pipeline — extract the target OS from raw data and compile it into a persona/tool skill | | `fuse` / `fusion` | **Branch B** | Fusion pipeline — method.skill (skeleton) × subject.skill(s) (flesh) → output.skill |

Invocation Modes

| Mode | Trigger | Behavior | |------|---------|----------| | **Full run** | No special keyword | Run the full pipeline and output a skill package | | **Plan only** | `stop after Stage 3` or `stop_after_stage: 3` | Run Branch A Stages 1-3 only; stop after writing `research_plan.json` | | **Resume** | `continue from Stage 4` or `resume_from_stage: 4` | Skip Branch A Stages 1-3; use the existing `research_plan.json` and run Stages 4-7 plus Gate 1 |

---

Branch A: Distillation Pipeline

Source Intake → Intake Assessment → Research Plan Design
  → Research Swarm → Gate 1: Merge
  → Exemplar Discovery → Synthesis (3 agents)
  → Skill Compilation

Core principle: extract the operating system behind the source, not just the content or answer.

---

A-Stage 1: Source Intake

Input: person, author, method, organization, domain, URL, repo, or local files.

Create package workspace at `output/<target-slug>-skill/`:

output/<target-slug>-skill/
├── README.md
├── SKILL.md.draft
├── references/             # agent reports + exemplars
├── intermediate/           # structured data
└── examples/               # persona: required; tool: optional

> Do not pre-create `templates/`; output templates live in LEAP's shared layer and > are not needed in the generated skill.

Write `intermediate/open_world_task.json` with the capability brief `g`, target, source-access specification `S` (allowed source types, retrieval channels, and exclusions), execution/package constraints `C`, and `depth_level`. Every later retrieval must comply with `S`; existing skills are not eligible exemplars unless `S` explicitly permits them.

| `depth_level` | Effect | Use case | |:--|:--|:--| | `quick` | Agent count ≤3 | Rapid prototype | | `standard` | No correction to auto-assessment | Daily use (default) | | `deep` | Agent count upper bound +1, capped at 8 | Broader evidence coverage |

---

A-Stage 2: Intake Assessment

Step 1: Source Modality Analysis

Classify every source by what it can reveal:

| Modality | Examples | Reveals | |----------|---------|---------| | `transcript_interview` | podcasts, video captions, Q&A | spontaneous reasoning, analogies, changed positions | | `longform_text` | books, papers, essays, newsletters | core arguments, methodology, narrative structure | | `secondary_criticism` | reviews, biographies, analysis | external perspective, blind spots, competing views | | `video_subtitle` | YouTube, Bilibili captions | speech patterns, unscripted reasoning | | `social_media` | posts, threads | expression patterns, real-time reactions | | `code_repo` | git repos, PRs | architecture patterns, API contracts, testing strategy |

For each modality present, note what operations it could reveal. Skip absent ones.

Step 2: Domain Inference

Read `domains/<domain>/domain.md` to confirm. Record primary + secondary domains.

Step 3: Evidence Depth Assessment

**Don't count sources — assess their density.**

• ≥3 high-density sources across ≥2 modalities → **rich** (5-8 agents)
• 1-2 high-density sources → **moderate** (3-5 agents)
• 0 high-density, all medium/low → **sparse** (2-3 agents)

Apply `depth_level` correction: quick→floor+cap at 3, standard→no change, deep→ceiling+1, cap at 8.

Step 4: Skill Mode Determination

| Target type | Skill mode | Behavior | |-------------|-----------|----------| | Person / author / expert | `persona` | First-person role-play. Includes Role-Playing Rules, Identity, How I Speak, and Decision Heuristics | | Domain / method / organization | `tool` | Third-person analytical. Has Activation Rules, Agentic Protocol, Operation Models |

---

A-Stage 3: Research Plan Design

How to select candidate operational factors

1. Start from Lens's candidate operational factors and acquisition targets. Hidden dimensions, brief-specific values, and matched contrastive tests are one planning mechanism, not separate discovery stages. 2. Read primary domain pack: `domains/<primary-domain>/domain.md` → candidate factors 3. **If persona, also read `domains/persona-os/domain.md`.** This cross-cutting layer provides OS extraction lenses (decision under constraint, failure processing, value conflict resolution, attention allocation, etc.). 4. Cross factors with source modality: match → active, no match → skip 5. Apply evidence depth cap: sparse→merge, moderate→1:1, rich→split 6. Derive a new candidate factor only when the source exposes a behavior-relevant distinction not already represented.

For each active factor `d`, retain or construct a paired acquisition target `<d, x, x'>` whose contexts differ along `d`. Convert it into a focused research question asking whether the contexts require different treatment in condition, action, recovery, or verification. A factor is confirmed as an implicit requirement only when acquired evidence supports such a treatment difference.

Self-Check Before Writing research_plan.json

1. **Depth match** — Does agent_count fall within the depth range? 2. **Modality coverage** — Are source_modalities_used actually present? 3. **Factor coverage** — Does every a