Phase 2I-3: Compilation Skill Definition#

Note

Path update needed if rerun (2026-03-25, Phase 2I-3). This prompt was executed before the compiler directory was created. If this script is ever rerun, update the AHA doc path below.

Note

200K-token execution prompt. Copy-paste everything below the horizontal rule into a new Claude Code session.

Prerequisite: Phase 2I-2 (PoR field testing) must have completed. The testing report at source/matheology/vv/jub/oov2/llog/2I-por-field-testing.rst tells you which fields have content and which are stubs.

Token budget: ~95K estimated. Uses selective reads to stay well within the 200K window. Previous version (v1, preserved at prompts/deprecated/prompt_2I-3_v1.rst) exceeded context by reading all source files in full (~69K tokens in reads alone).

Changes from v1:

  • Step 0: Selective reads (saves ~50K tokens)

  • Step 1: Section references updated to current AHA numbering (Section 10 = Extraction Matrix, Section 12 = Compilation Skill)

  • Step 2: Section 14.2 corrected to Section 12.2


/clear /compact /effort max

You are executing Phase 2I-3 of the JUB OOv2 matheology project: defining the ``/compile-matheology`` skill for Claude Code. The skill will compile PoR source files into audience-specific downstream pages using the extraction matrix from the AHA design document.

This session produces a Claude Code skill definition file and a set of stub templates — no content compilation yet.

TOKEN BUDGET — SELECTIVE READ STRATEGY#

The AHA design doc is ~32K tokens. The PoR field testing report is ~17K tokens. PET axioms are ~8K, JUB axioms ~10K. Reading all four in full consumes ~69K tokens — over a third of the context window — leaving insufficient room for the extraction matrix, skill specification, 5 stub templates, and debug entry.

Strategy: Read only the sections needed for each step. The extraction matrix needs field definitions (AHA Section 9), the keyword vocabulary (AHA Section 10), and the depth codes (AHA Section 7). The skill definition needs the modes and user decisions (AHA Section 12). The stub templates need the PoR format (2 sample axioms from each model).

STEP 0 — READ REQUIRED FILES (SELECTIVE)#

ax1_A1. AHA DESIGN DOC — SELECTIVE READ: source/matheology/vv/jub/oov2/llog/aha-best-names-for-matheology-links.rst (New location: source/matheology/compiler/ww/5d-link-naming-matheology-aha.rst)

Read ONLY these sections (use offset/limit or grep to locate):

  • Section 7 (D4 — Depth/Audience): depth codes and audience definitions (~lines 740–840)

  • Section 9 (PoR Fields — Complete Registry): all 45 field names, brief codes, explicit names, and content examples (~lines 1008–1440)

  • Section 10 (Extraction Matrix): keyword vocabulary and toy example (~lines 1441–1525)

  • Section 12 (Compilation Skill): modes (12.1) and the 13 user decisions (12.2) (~lines 1655–1755)

Do NOT read the full file. Sections 1–6, 8, 11, 13–20 are not needed for this task (they cover naming grammar, registries, link stability, prose conventions, label examples, HELL, and design questions).

ax2_A2. PoR FIELD TESTING REPORT — SELECTIVE READ: source/matheology/vv/jub/oov2/llog/2I-por-field-testing.rst

Read ONLY:

  • Section 1.5 (Summary Statistics — All 45 Fields): the aggregate table showing F/P/S/N counts per field (~lines 448–515)

  • Section 3.1 (Critical Gaps): which fields are >50% stub (~lines 688–775)

Do NOT read the full coverage matrix (Sections 1.1–1.4) or the network dependency graph (Section 2). The summary statistics contain all the information needed to assign extraction keywords.

ax3_A3. PET AXIOMS — FORMAT SAMPLE ONLY: source/matheology/pet/axioms.rst

Read ONLY ax1_A1 and ax2_A2 (approximately lines 1–125) to understand the current PoR format: how fields are structured, how labels are defined, how scriptural support is organized.

Do NOT read all 14 axioms — the format is uniform.

ax4_A4. JUB AXIOMS — FORMAT SAMPLE ONLY: source/matheology/jub/axioms.rst

Read ONLY ax15_A15 and ax16_A16 (approximately lines 1–165) to understand the JUB format: domain definitions, formal statements, notes.

Do NOT read all 11 axioms — the format is uniform.

ax5_A5. EXISTING AXIOMS INDEX — READ IN FULL (small file): source/matheology/axioms/index.rst

ax6_A6. CLAUDE.md — already loaded in context (do not re-read).

ax7_A7. EXISTING PROMPTS INDEX — READ IN FULL (small file): source/matheology/vv/jub/oov2/prompts/index.rst

STEP 1 — DESIGN THE EXTRACTION MATRIX#

Build the full extraction matrix: a table mapping 45 PoR fields x 5 audience depths (expert, producer, easy, math, machine).

For each cell, specify one of the 8 extraction keywords from AHA Section 10 (Extraction Matrix):

full    --- include in full (field copied verbatim)
brief   --- first sentence only
top3    --- top 3 entries
top1    --- single best entry
drop    --- omit entirely
stub    --- heading only, mark [stub]
ref     --- cross-reference link to PoR
rewrite --- include, rewritten for audience

Guidelines for assignment:

  • Expert (default PoR): All fields full (this IS the PoR)

  • Producer (PoT): full for identity, brief for technical, top3 for sources, rewrite for intro, drop for machine

  • Easy (PoU): rewrite for identity/intro, drop for most technical, top1 for sources, ref for operational

  • Math (formal): full for latex/logic/proof, drop for sources/operational, ref for identity

  • Machine (API): full for id/latex/netout/netin, drop for prose, structured data for everything else

Use the field testing report (ax2_A2) to inform decisions: Fields that are >50% Stub across all elements should be drop at easy depth and stub at expert depth — there is no content to extract.

Present the matrix as an RST list-table and get my approval before proceeding.

STEP 2 — DEFINE THE SKILL#

Create a Claude Code skill definition. The skill should:

  1. Accept arguments matching the 13 user decisions from AHA Section 12.2:

    /compile-matheology [mode] [options]
    
    Modes: replace, append, archive, migrate
    Options:
      --output <folder>         (default: matheology/axioms/)
      --models <list>           (default: all)
      --depths <list>           (default: all)
      --views <list>            (default: all)
      --states <list>           (default: all)
      --stubs yes|no            (default: no)
      --version-increment <v|r|p>
      --archive-folder <path>
      --vvn <string>
      --stayc <code>
      --freeze-por yes|no       (default: no)
    
  2. For each mode, define the execution sequence:

    REPLACE mode:

    1. Read all PoR source files (pet/axioms.rst, jub/axioms.rst, jub/theorems.rst, jub/quest.rst)

    2. For each element x depth x view combination: - Apply extraction matrix to select/transform fields - Generate an RST page with the element’s BEST Names label - Write to the output folder

    3. Rebuild toctrees in affected index files

    4. Run make html to check

    APPEND mode:

    1. Read only NEW PoR elements (elements not yet in output)

    2. Generate pages for new elements only

    3. Add to existing toctrees

    4. Check build

    ARCHIVE mode:

    1. Run REPLACE first

    2. Copy output to vv/{version}/ (was vv/compiled/ — updated per DD-b12)

    3. Tag all labels with version suffix

    4. Update version registry in AHA doc

    5. Check build

    MIGRATE mode:

    1. Read old-format files

    2. Transform labels per migration table

    3. Update all cross-references

    4. Check build

  3. Stub policy: When --stubs no, if a field/page would contain only stub content (per the testing report), the page is NOT generated and no toctree entry is created. This prevents empty pages.

  4. Output format: Each generated page follows this template:

    .. _{label}:
    
    {title}
    ==================
    
    .. This page was generated by /compile-matheology on {date}.
    .. Source: {source_file}
    .. Do not edit manually. Re-run the skill to regenerate.
    
    {extracted fields per extraction matrix}
    

Write the skill definition to: source/matheology/vv/jub/oov2/llog/skill-compile-matheology.rst

This is an AHA-level specification document (not an executable script). It should be detailed enough that a future Claude session can implement it as an actual Claude Code skill.

STEP 3 — CREATE STUB TEMPLATES#

Create stub templates for the 5 audience depths at:

source/_templates/stubs/matheology-expert.rst
source/_templates/stubs/matheology-producer.rst
source/_templates/stubs/matheology-easy.rst
source/_templates/stubs/matheology-math.rst
source/_templates/stubs/matheology-machine.rst

Each stub contains:

  1. A label placeholder: .. _{label}:

  2. A title placeholder

  3. The field headings appropriate for that depth (from the extraction matrix — only fields NOT marked drop)

  4. Each field body marked [stub --- content pending]

  5. A generation comment with date and source

STEP 4 — CHECK BUILD#

Run make html and confirm:

  1. Zero new warnings from the skill definition file

  2. The stub templates parse as valid RST

  3. No broken cross-references

STEP 5 — APPEND TO DEBUG FILE#

APPEND a session entry to: source/matheology/vv/jub/oov2/llog/llog_2026m03d21_restructuring-phase1-prompts-reply-overviews-for-debugs.rst

Read only the LAST 50 LINES of this file for structural context before appending. Do NOT read the full file (~37K tokens).

With:

  1. Verbatim prompt (this entire prompt, in a code-block)

  2. The extraction matrix

  3. List of all files created/modified

  4. Build check result

CRITICAL RULES#

  1. llog files are APPEND-ONLY.

  2. NEVER delete content files.

  3. NEVER abbreviate prompts in llogs.

  4. The skill definition is a SPECIFICATION, not executable code. It documents what the skill should do so a future session can implement it.

  5. LANGUAGE RULES: a. NEVER use bare “Jubilee” as standalone noun. b. NEVER use “the” for unproven superlatives.

TELES migration report (2026m04d04)

Mechanical identifier migration applied to this file. All axiom/theorem text references were migrated from short form (e.g., A15) to compound form (e.g., ax15_A15) as part of the matheology compound naming operation. Both forms refer to the same formal object. The old form survives as the suffix to ensure consistency with the oldest records; the new form adds a temporary-status prefix. Forward-facing pages use brief form (ax15) only. See TELES Axiom/Theorem Compound Naming — Execution Prompt for the complete mapping table and DD b12 — Legacy Naming for PET/JUB Axioms and Theorems for the permanent reference.