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

text
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.

1. Read primary domain pack: domains/<primary-domain>/domain.md → candidate factors
2. 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.).

1. Cross factors with source modality: match → active, no match → skip
2. Apply evidence depth cap: sparse→merge, moderate→1:1, rich→split
3. 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 active factor have a matched acquisition target?
4. Merge intent — Deliberate or lazy? Document the rationale.

Search direction must target dilemmas

Good: "What was the hardest decision at [event]? What options did they have?"
Bad:  "What is their leadership style?"

Every agent's search_direction should name a specific moment, event, or decision that can be traced to a verifiable source.

Write intermediate/research_plan.json with one record per planned research agent. Each record must include the candidate factor d, matched contexts x and x', the focused research question, the procedural components to compare, permitted source types and retrieval channels inherited from S, and the assigned search direction. Together these focused questions form Q.

Plan-Only Mode Stop Point

If invoked with stop after Stage 3 or stop_after_stage: 3:

Stop immediately after writing research_plan.json. Output:

Research plan generated and saved to intermediate/research_plan.json.

[N] agents, dimensions:
  R1 — [dimension]: [search_direction summary]
  R2 — [dimension]: [search_direction summary]
  ...

Do not enter Stage 4. Wait for Skill-Alchemy to return a confirmation or an adjusted instruction.

A-Stage 4: Research Swarm

Resume mode: If invoked with continue from Stage 4, read the agent configuration directly from the existing intermediate/research_plan.json. Skip Stages 1-3.

Launch N agents in parallel. Each agent writes references/R<NN>-<agent_id>.md:

Status: pass (or warning / fail)

## Structured Findings
  - Finding ID: stable identifier used by later artifacts
  - Acquisition Target: `<factor, x, x'>`
  - Context x: seed operating conditions
  - Treatment in x: source-grounded behavior, not an executable instruction
  - Evidence for x: source_id, type, confidence, and source-stated boundary
  - Context x': matched conditions with only the target factor changed
  - Treatment in x': source-grounded behavior, not an executable instruction
  - Evidence for x': source_id, type, confidence, and source-stated boundary
  - Affected Components: condition / action / recovery / verification
  - Relation: changed / invariant / unresolved
## Dilemma Decision Cases (≥2 required)
  ### Case N: [one-line summary]
  - Dilemma: specific conflict or hard choice
  - Constraints: what limited their options
  - Decision Steps: what they did, step by step
  - Outcome: what happened
  - Extractable Operation: generalizable rule/pattern/heuristic
## Evidence Sources (source_id, type, confidence)
## Supported Candidate Operations
## Rejected or Weak Candidate Operations
## Target-specific Patterns
## Boundaries and Uncertainties
## Recommendations for Later Skill Compilation

Agent Contract: Every report begins with Status: pass / warning / fail. Dilemma Decision Cases are the most important section for persona targets — they are the raw material from which mental models and heuristics are built.

Agent Timeout Rule: If any research agent hasn't produced a report within 10 minutes, do not wait. Proceed with completed agents. Gate 1 checks:

• Persona: ≥4 total Dilemma Cases across all completed reports → pass.

<4 → downgrade depth to quick and relaunch with fewer (≤2) agents.

• Tool: ≥2 total Dilemma Cases → pass. <2 → same downgrade.
• Mark missing agents in merge_report.json: "agents_lost": ["R2", "R3"].

A-Gate 1: Research Merge

Agent uses data-analysis skill to process reports:

1. Read all R1-Rn reports
2. Extract Status + all sections
3. Dilemma Case gate: persona targets — per-report 0 cases = warning,

combined total <4 = fail

1. Normalize every paired finding into evidence_matrix.json, retaining both

contexts, both treatments, affected components, boundaries, and evidence IDs.

1. Write one entry per acquisition target to contrast_records.json:

• changed: evidence supports different treatment in at least one component;

a source-stated applicability boundary along the target factor is sufficient evidence that the bounded component changes across the matched contexts;

• invariant: evidence supports the same treatment across non-equivalent contexts;
• unresolved: either side lacks enough evidence or the comparison conflicts.

Missing evidence for only one context must not by itself be labeled changed. Use this schema:

json { "factor": "d", "context_x": "seed context", "context_x_prime": "matched context with d changed", "component_relations": { "condition": "changed", "action": "invariant", "recovery": "unresolved", "verification": "invariant" }, "evidence_x": ["F01"], "evidence_x_prime": ["F02"], "overall_relation": "changed", "confirmed_implicit_requirement": true, "evidence_stated_boundary": "..." }

1. Confirm a factor as an implicit requirement only when its contrast record is

changed. Keep invariant and unresolved records for later scope decisions.

1. Detect cross-report contradictions and write contradiction_report.json and

merge-summary.md.

1. Write merge_report.json, evidence_matrix.json, and contrast_records.json.

Gate 1 merges and checks research evidence only. It must not induce candidate procedures or make General/Scoped/Exclude decisions.

A-Stage 5: Exemplar Discovery

Retrieve the best exemplars in real time from the public skill pool on skills.sh, then inject them into Compilation as few-shot structural references.

Retrieval Workflow

This stage runs only when existing skills are an allowed source type under S. Otherwise record status: "not_permitted" and continue without exemplars.

1. Search with find-skills:

Call the skills.sh find-skills interface with keywords for the target. Return the top 20 candidate skill_key values.

1. Download candidate SKILL.md files concurrently and score them mechanically:

• Download the SKILL.md files for all 20 candidates concurrently from GitHub raw.
• Run python3 scripts/score_skill.py --skill <path> --json for each candidate.
• Sort by quality_score: prioritize elite candidates (≥11) and discard drafts (<9).

1. Select and inject the best candidates automatically:

• Take the top 3-5 elite exemplars, prioritizing scores ≥11.
• Write them to references/exemplars/exemplar-<N>.md.
• Write the scoring results to references/exemplar_candidates.json for audit.

1. Handle cases with no qualified result:

• If every candidate scores below 9, broaden the search terms and search once more.
• If no elite candidate is found after two rounds, set status: "degraded" in

exemplar_discovery.json.

• You must still attempt to obtain at least one exemplar. It is the basis

for compilation quality.

A-Stage 6: Synthesis

Run the following steps in order. Stage 6 is the only stage that may induce candidate procedures or make admission decisions.

S1: Decision Alignment

Group findings by the procedural decision they inform, not by source topic. Write operation_candidates.json. Each candidate must have this shape:

json
{
  "candidate_id": "P01",
  "decision": "the procedural decision being made",
  "condition": {"content": "...", "evidence_ids": ["F01"]},
  "action": {"content": "...", "evidence_ids": ["F01", "F03"]},
  "recovery": {"content": null, "evidence_ids": []},
  "verification": {"content": "...", "evidence_ids": ["F04"]}
}

Leave an unsupported component empty. Synonymous source terms may be normalized, but named entities and fixed choices must not be generalized unless a broad source statement or invariant evidence across non-equivalent contexts supports doing so. When distinct treatments are supported under different recorded conditions, preserve them as separate conditional cases. Do not collapse them into one rule. Incompatible treatments under matched conditions remain unresolved conflicts.

S2: Procedure Admission

For each candidate, write an entry to admission_records.json:

json
{
  "candidate_id": "P01",
  "F_plus": ["F01", "F03", "F04"],
  "F_minus": [],
  "sigma": "widest operating scope supported by the listed evidence",
  "supported": true,
  "consistent": true,
  "reusable": true,
  "reuse_basis": "broad_source_statement | cross_context_invariance | none",
  "decision": "General",
  "rationale": "short evidence-based explanation"
}

Apply these rules exactly:

1. supported=true only when every populated component is backed by evidence that

applies within sigma.

1. consistent=true only when no F_minus evidence prescribes incompatible

treatment under overlapping conditions within sigma.

1. Restrict sigma before classification when support holds only in a narrower scope.
2. reusable=true only when an allowed source explicitly states broader

applicability or invariant evidence supports the same treatment across at least two non-equivalent contexts. A single source-local case is not reusable.

1. Classify as General when supported, consistent, and reusable; Scoped when

supported and consistent but not reusable; otherwise Exclude.

Write admitted_general.json, admitted_scoped.json, and excluded_candidates.json from these records. Excluded candidates remain in the audit trail and must not be passed to compilation.

S3: Package Design

Write package_plan.json. Map only admitted General and Scoped content to an executable organization under C. Do not create procedures, fill unsupported components, or change admitted scope.

A-Stage 7: Skill Compilation

Compile final package from all research + synthesis reports + exemplars.

Compilation Inputs (in Priority Order)

1. admitted_general.json — the only source of reusable instructions.
2. admitted_scoped.json — the only source of context-bound examples or notes.
3. Execution and packaging constraints C from open_world_task.json.
4. skill-grammar.md — MUST be read before rendering. Use its patterns to

organize the package, place package-relative references, apply progressive disclosure, and avoid known anti-patterns.

1. Permitted exemplars, when available, may guide organization and presentation only.

Compilation must not create a new procedure, fill an unsupported component, promote an excluded candidate, or broaden admitted scope. Domain packs, research reports, and exemplars are audit or presentation aids; they are not additional sources of skill instructions at this stage.

Package contents

<skill-name>/
├── SKILL.md                   # lean entry point — runtime loaded
├── skill.json                 # metadata (name, version, skill_mode, domain)
├── README.md                  # storefront (see template in shared layer)
├── references/
│   ├── sop_models.md          # full operation model cards (runtime on-demand)
│   └── research_notes.md      # human-readable evidence summary
├── scripts/                   # optional executable routines used by the skill
├── assets/                    # optional templates or static resources
├── examples/
│   └── demo_conversation.md   # persona: 3-4 scenarios (required)
└── intermediate/              # pipeline audit trail

Create scripts/, assets/, and examples/ only when the admitted content and C require them. Every optional resource must be referenced through a package-relative path from SKILL.md or another reachable package file.

> Runtime loads only SKILL.md. The runtime protocol reads sop_models.md on demand. > R1-Rn and intermediate/ are audit artifacts.

A persona MUST include examples/demo_conversation.md with 3-4 scenarios: common, edge case, and refusal. Missing file → fail. The examples/ directory is optional for tool mode.

Post-Compilation Cleanup

After compilation, delete temporary artifacts to keep the output clean:

1. Delete references/exemplar_candidates.json—the temporary scoring file has

already served its purpose.

1. Delete references/exemplars/—the intermediate reference copies have already

served their purpose.

1. Delete empty directories.
2. Keep references/R*.md as research evidence, intermediate/ as the audit

trail, and the output package.

Branch B: Fusion Pipeline

text
method.skill (skeleton) × subject.skill(s) (flesh) → output.skill

WEAVE is not a concatenator. If you can tell where one skill ends and another begins, the weave failed.

B-Step 1: Retrieve Skills

Confirm that every skill required for fusion is ready:

primary: "Interview Techniques"       ← workflow skeleton
secondary: ["BeiDou Navigation"]      ← style/persona source
depth: "standard"

Retrieve each required skill in this order:

1. Local output/ directory (skills generated previously)
2. Installed skills (~/.claude/skills/)
3. find-skills online search (semantic search over the public skills.sh pool)
4. GitHub raw download

If a skill does not exist:

• Tell the user which skill must be generated first and recommend Branch A distillation.
• Or ask the user to provide the path to an existing skill.

After retrieving a skill, run python3 scripts/score_skill.py --skill <path> --json to verify its quality. A draft skill scoring below 9 should not be used as a fusion source—garbage in, garbage out.

When find-skills returns candidates, write the scoring results to references/fusion_candidates.json:

json
[
  {"skill_key": "xxx", "score": 12, "summary": "...", "recommended_role": "primary"},
  {"skill_key": "yyy", "score": 9, "summary": "...", "recommended_role": "secondary"}
]

Skill-Alchemy presents these candidates to the user for confirmation. LEAP does not handle the interaction itself.

B-Step 2: Parse

2.1 Parse primary skill (skeleton)

Extract:

• Workflow: every step, in order. Number them.
• Output format: what the skill produces at each step
• Decision points: if-then branches, conditional logic
• Constraints: what this skill cannot/will not do

The primary skill determines the structure of the output.

2.2 Parse secondary skill(s) (flesh)

For each secondary skill, extract:

• Role/persona: how they speak, their identity, their worldview (persona)

OR their domain lens, their operation models (tool)

• Style elements: tone, rhythm, vocabulary, forbidden phrases, signature patterns
• Heuristics/decision rules: their falsifiable operating rules
• Constraints: what this skill cannot/will not do
• Evidence anchors: verifiable sources that back their patterns

The secondary skills determine the texture of the output.

B-Step 3: Weave

Fusion depth is controlled by depth_level.

quick — Style Injection

Each style element from secondary skills is injected into the primary workflow at the most relevant step. Minimal rewriting.

Interview Techniques Step 3 "Generate Core Questions"
  → Inject BeiDou Navigation's questioning style: begin with a specific
    experience, establish rapport, and then probe further

standard — Structured Weave (default)

1. Rewrite the role. Create a new unified identity.

• Bad: "You are BeiDou Navigation. You are an interviewer."
• Good: "You are a BeiDou Navigation-style interview-planning assistant. You

learn and reuse his interview methods without claiming to be him."

1. Weave workflow × style. For each step in the primary workflow,

embed relevant style/pattern from secondary skills.

• Each style injection must cite its source skill section.
• No step should feel "unstyled" — every step gets at least one texture element.

1. Merge constraints. Union of all source skill constraints.

Remove duplicates. Flag conflicts (if primary says "do X" and secondary says "never do X").

1. Check for gaps. Are there steps in the workflow that no secondary

skill has pattern coverage for? Mark them as [General Pattern]—filled by general best practices, not specific to any source.

deep — Weave + Gap Resolution

Same as standard, plus:

1. Detect conflicts. When two source skills contradict on a point,

resolve explicitly. Default: primary skill wins on workflow decisions, secondary skill wins on style decisions. Document every conflict and resolution.

1. Fill gaps. For steps marked [General Pattern], launch a lightweight

research agent to find domain-specific patterns.

1. Source traceability. Verify that every style claim in the output can

be traced back to a specific section of a source skill. Verify that no constraint was dropped.

B-Step 4: Output

Generate output.skill using the SKILL.md templates in the shared layer below.

Role naming convention

• "BeiDou Navigation-style Interview-Planning Assistant"—"style" indicates

derivation rather than identity.

• "Decision Framework Based on Zhang Yiming's Product Philosophy"—"based on"

indicates the source.

Package contents

<skill-name>/
├── SKILL.md                   # lean entry point — runtime loaded
├── skill.json                 # metadata (name, version, skill_mode, source_skills)
├── README.md                  # storefront (see shared layer)
├── references/
│   └── sop_models.md          # full operation model cards (runtime on-demand)
└── examples/
    └── demo_conversation.md   # persona: 3-4 scenarios (required)

Post-Compilation Cleanup

Same as Branch A:

1. Delete references/fusion_candidates.json (temporary scoring file).
2. Delete all intermediate reference files, including temporary exemplar copies.
3. Delete empty directories.
4. Keep references/ as the audit trail.

Shared Layer

Branches A and B share the following templates and infrastructure.

SKILL.md Output Templates

Tool Mode (skill_mode: "tool") — 7 Required Sections

## Activation Rules
Concrete examples of both triggering and non-triggering requests. List 4-5
scenarios in each category.

## Agentic Protocol
Executable steps. Write "do X, then Y," not "consider X":
Step 1: Determine the stage
Step 2: Match the model (read sop_models.md)
Step 3: Execute the diagnosis
Step 4: Produce the output (select an output mode)

## Core Operation Models
H1-Hn summary table. Format:
| # | Model | Core proposition | Primary source |
|---|-------|------------------|----------------|
| H1 | **Model name** | One sentence | Source |
Full cards live in references/sop_models.md.

## Output Style
- Lead with a one-sentence conclusion, then expand. Do not paste an entire model card.
- Use natural paragraphs rather than Markdown tables unless the user explicitly
  asks for a comparison table.
- When citing a source, say "PG argued in a 2012 essay..." rather than "According
  to H1 in references/sop_models.md..."
- Forbidden phrases: "Analyzing this with the framework...", "Following the model
  card...", and "Let me analyze this systematically..."
- Stop after answering. Do not ask, "Would you like me to expand further?"

## Output Modes
| Mode | Trigger | Output structure |
|------|---------|------------------|
| ... | ... | ... |
Define 4-7 modes.

## Boundary Rules
Provide 7-8 numbered rules covering evidence boundaries, scope of application,
prohibited actions, and version cutoff.

## References
Pointer table: sop_models.md + research_notes.md + R reports + S reports.

Persona Mode (skill_mode: "persona") — 8 Required Sections + 1 Optional Section

## Role-Playing Rules (most important; place first)
Respond directly as [Person's name]. Speak in the first person.
The reader already knows who you are. Do not repeat your background in every turn.
Use my tone, rhythm, and vocabulary. When uncertain, hesitate in character.
If someone is clearly speaking with you for the first time, include a brief disclaimer.
Exit the role when the user says "exit role" or "switch back to normal."

## Identity
Write 3-5 first-person sentences. This is not a biography—it is a handshake.
Include only the facts most important for understanding how this person sees the world.

## How I See the World
Include 3-5 mental models, each in a paragraph of no more than 5 lines.
Use conversational paragraphs rather than structured cards. Write in this person's voice.
Put evidence and limitations in references/sop_models.md rather than inline.

## How I Speak
The first sentence is the strongest output-format constraint:
"I am [identity], not [contrasting identity]. Do not answer with bullet points or
numbered lists."
Sentence patterns (length, question-to-answer ratio) · vocabulary (frequent,
forbidden) · rhythm (conclusion first / context first)
Humor (self-deprecating / sarcastic / absurdist / none) · certainty
(uncertain / self-evident)
"Things I Would Never Say" (2-3 sentences this person would never say; these
establish distinctiveness better than positive descriptions)
"My Signature Phrase" (one expression that makes the persona immediately recognizable)
Citation habits + taboos

## Decision Heuristics
Include 3-5 items. Format: rule name — one-sentence description + applicable
scenario. Every item must be falsifiable.
❌ "Think long-term" (not falsifiable)
✅ "If I cannot figure it out in three minutes, put it in the Too Hard pile"
(falsifiable)
Put evidence in references/sop_models.md rather than inline.

## Runtime Protocol
A 5-step SOP-driven process:
1. Match the model: read references/sop_models.md and scan "When to use" for a
   matching model card.
2. Act on the model: structure the response strictly according to the Action steps
   and cite the Evidence source.
3. Check boundaries: compare against the Boundary field, refuse honestly when out
   of bounds, and proactively avoid Failure modes.
4. Verify factual questions first: specific facts → WebSearch → analyze through
   the mental-model framework.
5. Answer experiential judgments directly: values or casual conversation → respond
   directly; beyond the persona's knowledge → "This is outside my expertise, so I
   will not pretend to know."

## Boundaries
Approximately 5 lines. State that the skill cannot represent the real person and
include an information cutoff date.
Final line: Depth: quick/standard/deep

## References
Pointers: references/sop_models.md + references/research_notes.md

## Values (optional)
Include only when the person has strong, distinctive, publicly documented values.
Do not use this section as filler.

Every persona skill MUST include examples/demo_conversation.md — 3-4 short conversation scenarios: a common ask, an edge case, a boundary refusal.

Every persona skill MUST include a README.md using this template:

markdown
# [Person's name] · [English name or label]

> "[One verified quote that best represents this person]"

[One sentence: who they are, what they did, and why they are worth listening to.
No more than 30 words.]

## Installation
    cp -r [skill] ~/.claude/skills/[name]/

## Trigger Scenarios
[Describe 3-5 typical trigger scenarios in natural language.]

## Mental Models
| # | Model | One sentence |
|---|-------|--------------|
| 1 | [Name] | [15 words or fewer] |

## How They Would Say It
- **Signature phrase:** [One sentence]
- **Would never say:** [One sentence] / [One sentence] / [One sentence]

## Disclaimer
This simulated persona is distilled from public sources and does not represent
the real person's views. Information cutoff: [Month, Year].

README rules: top quote MUST be real and verified. Keep under 40 lines. The Mental Models table must contain exactly the same models as How I See the World. Signature phrase / Would never say must exactly match How I Speak.

Forbidden in all modes

• Exact file paths from one benchmark instance
• Oracle/verifier logic
• Copied protected expression
• For persona: do not fabricate quotes, do not claim generated text IS the person's
• Progressive disclosure: SKILL.md is the lean entry point; detailed evidence in references/

Shared Infrastructure

• domains/ — 12 domain packs (11 primary domains + persona-os), used to select

Branch A Stage 3 research dimensions.

• references/skill-grammar.md — skill-writing methodology derived from

skills.sh data; required reading before Branch A/B compilation.

• scripts/score_skill.py — 13-point mechanical scoring for runtime quality

filtering in A-Stage 5 / B-Step 1.

• scripts/download_subtitles.sh + scripts/srt_to_transcript.py — video-source

processing, used as needed.

• scripts/build_corpus.py + scripts/build_component_index.py — data-mining

tools used to build skill-grammar; required for open-source builds, not at runtime.

• find-skills (skills.sh) — online semantic skill retrieval and the candidate

discovery layer for A-Stage 5 / B-Step 1.