Prompt file imported from cstokes0091/META-COMPILER (.github/prompts/software-3.0-conversion.prompt.md). Copyright stays with the author.

Software 3.0 Conversion — Prompt-as-Conductor

Intent

Drive the conversion of META-COMPILER from its already partially Software-3.0-shaped state into a system that fully embodies Andrej Karpathy's Software 3.0 vision: LLMs as the runtime, prompts as programs, agents as composable functions, partial-autonomy products with explicit human-in-the-loop sliders, generation-verification loops as the dominant control flow, and machine-readable surfaces so external agents can navigate the system without parsing prose.

The conversion is staged. Phase 1 (planning) produces three vision artifacts and HALTS for human approval before any code change. Implementation phases are invoked one at a time with --phase <id> after the operator approves the plan.

This prompt mirrors meta-compiler's own staged philosophy: each phase runs in fresh context, artifacts pass knowledge forward, hooks and tests gate progression, and a human approves at the dialog boundary. The conversion of meta-compiler is itself executed in the meta-compiler way.

Arguments

Parse the operator's invocation text conservatively:

• --phase planning (default) — produce the three vision artifacts and HALT.
• --phase <phase-id> — execute one named phase from the conversion plan (only after operator approval).
• --scope full (default) — diagnose the full system. Pass an area name (e.g. --scope stage-3, --scope ingest) to narrow the diagnosis.

Anchor Texts (read or summarize FIRST)

Internalize Karpathy's framing before diagnosing. Otherwise the gap analysis will recapitulate generic LLM-app advice instead of measuring META-COMPILER against Karpathy's specific claims.

• Primary anchor: Andrej Karpathy, "Software Is Changing (Again)" — YC AI Startup School talk, June 2025. The 1.0 / 2.0 / 3.0 distinction.
• Companion framings to hold in mind:
  • LLM-as-OS / utility / fab analogies — and what they imply about reliability, fallibility, and amnesia.
  • Prompts-as-programs — English as the new programming language; the LLM is the interpreter.
  • Partial-autonomy products — explicit slider from manual → copilot → autopilot, with verification responsibility mapping onto the slider.
  • Generation-verification loops — humans (and LLMs in fresh context) verify what LLMs generate; this is the dominant control flow, not a side-check.
  • Build infrastructure FOR agents — machine-readable docs, stable contracts, stable URLs, llms.txt-style entry points.
• In-repo references — LINK rather than duplicate:
  • META-COMPILER.md ("Karpathy LLM Wiki pattern")
  • .github/agents/execution-orchestrator.agent.md ("Software 3.0 ethos, item #13")

In Step 1 of the Workflow you MUST restate the framing in your own words, ≤200 words, and emit it before continuing. This is the conductor's own check that it has anchored correctly.

Inputs (read in order, before Step 2)

1. CLAUDE.md — project invariants, evidence quality rules, architecture summary.
2. LLM_INSTRUCTIONS.md — operator-side stage workflow.
3. META-COMPILER.md, .github/copilot-instructions.md — workshop philosophy and canonical operating rules.
4. .github/docs/hooks.md — non-overridable safety rails. The full check inventory.
5. Inventory .github/agents/ first — read frontmatter on every file, then read full bodies for implementation-planner, implementer, reviewer, researcher, and any orchestrator (*-orchestrator.agent.md) relevant to the requested scope.
6. Inventory .github/prompts/ first — then read the stage prompts relevant to the requested scope. For --scope full, at minimum read the Stage 0, 1A, 1B, 1C, 2, 3, 4, and final-synthesis prompts so you see the conductor pattern end-to-end.
7. meta_compiler/artifacts.py — single source of truth for artifact paths.
8. Two owning stage sources — recommended: meta_compiler/stages/capability_compile_stage.py and meta_compiler/stages/workspace_bootstrap_stage.py. And one orchestrator agent body: .github/agents/execution-orchestrator.agent.md. These ground the CLI ↔ prompt split in concrete code.
9. pyproject.toml, requirements.txt, tests/ — runtime surface and existing eval coverage.

When docs, prompts, and executable code disagree, treat meta_compiler/cli.py and meta_compiler/stages/*.py as the current contract. Record the mismatch as part of the diagnosis instead of smoothing it over.

Your Role

Conductor. Diagnose first, plan second, execute (only after explicit human approval) third. The halt-before-implementation contract is non-negotiable.

You are not Karpathy. You are not a generic LLM-app consultant. You are operating ON a specific working system that already embodies most of the patterns Karpathy describes — your job is to measure the gap precisely and stage the closure of it without breaking what already works.

Workflow

Step 1 — Absorb

Read every file in §Inputs. Then restate Karpathy's Software 3.0 framing in your own words, ≤200 words, and emit it verbatim before continuing. If you cannot, stop and report what is missing.

Step 2 — Diagnose current state

Write .github/docs/vision/software-3.0-current-state.md.

For every claim "X is already 3.0-shaped in META-COMPILER", cite file:line from the repo. Avoid hand-waving — cite or omit. Suggested structure:

• One section per Karpathy primitive (LLM-as-runtime, prompts-as-programs, agents-as-functions, generation-verification loops, hooks/safety-rails, build-for-agents).
• Under each: what META-COMPILER already does, with file:line citations; what is partial; what is absent.

Step 3 — Identify gaps

Write .github/docs/vision/software-3.0-gap-analysis.md.

Each gap entry is tagged with severity (load-bearing / nice-to-have) and effort (S / M / L). The following is a starting menu — extend, drop, or merge with explicit rationale:

• Workshop output as a versioned, deployable Software-3.0 program vs. today's directory snapshot under workspace-artifacts/scaffolds/v{N}/.
• Per-stage autonomy slider (manual / copilot / auto) exposed to the operator. Stage 2 has dialog, Stage 4 is autopilot — there is no per-stage user dial.
• llms.txt-style or equivalent machine-readable navigation surface so external agents can traverse the workshop without parsing prose.
• Standard-library agent palette as a discoverable, composable primitive vs. today's statically provisioned implementation-planner plus the Stage 4 execution trio (implementer / reviewer / researcher) and orchestrators wired by convention.
• Eval harness for the LLM-runtime side. Existing verification/{hook_id}_spec.yaml files define machine-readable acceptance contracts that Stage 4 translates into tests, but LLM behaviour itself still has no eval suite.
• Hot-reload / incremental re-compile when a single decision row or capability changes (today: full-stage re-runs).
• Capabilities as first-class callable units with introspectable contracts (today: SKILL.md + contracts/ exist but there is no invocation surface).
• Decision-log requirements/constraints (REQ-NNN / CON-NNN) as executable natural-language programs rather than YAML rows the runtime ad-hoc-interprets.
• Generation-verification framing applied uniformly across stages (today: explicit in Stages 1B/1C, less so in Stage 3, informal in the Stage 4 ralph loop).

For every gap, capture: what 3.0 primitive it serves, what's missing today (with file:line citations of the current shape), and a sketch of what "closed" looks like.

Step 4 — Phase the conversion

Write .github/docs/vision/software-3.0-conversion-plan.md.

Each phase has ≤ ~3 sub-tasks and a named, yes/no-checkable verification gate. Phases respect existing stage boundaries and the hook contract. Every gap in §Step 3 must be either assigned a phase number or explicitly deferred with written rationale. Sequence phases so each delivers an operator-visible win and does not block on later phases.

Step 5 — HALT

Emit this line literally and stop:

PHASE 1 (PLANNING) COMPLETE. Awaiting human approval to begin implementation.

Do not modify meta_compiler/, .github/agents/, .github/prompts/, scripts/, or tests/. The only writes permitted in Phase 1 are the three docs under .github/docs/vision/.

Step 6 — (Conditional, after explicit human approval) Execute one phase

Invoked with --phase <phase-id>. Each phase ends with:

• pytest tests/ -v green.
• Manual smoke of any stage touched (meta-compiler validate-stage --stage <N> if applicable).
• .github/docs/vision/phase-<id>-completion.md summarizing: what changed, what verification ran, the verification-gate yes/no result, and what's next.

Wait for human approval before starting the next phase.

Constraints (load-bearing — do not soften)

• Preserve the CLI ↔ prompt split. Reasoning never enters meta_compiler/; bookkeeping never enters prompts/agents.
• Preserve every rule in CLAUDE.md § Evidence Quality Rules: citations are load-bearing, seeds are immutable, citation/requirement IDs survive transformations, findings JSON stays schema-valid, Stage 3 consumes Decision Log + cited findings only.
• Hooks remain non-overridable. New hooks may be added; existing ones may not be loosened without explicit operator approval and a written justification in the conversion plan.
• The repo-level execution palette named in meta_compiler/stages/workspace_bootstrap_stage.py (implementer / reviewer / researcher) must remain available even if the palette is extended. The upstream implementation-planner agent must also remain available unless the conversion plan documents a compatible replacement.
• Backwards-compatible scaffold output unless the gap analysis explicitly justifies a breaking change AND documents a migration path.
• Use the narrowest relevant tests while iterating. Before closing any implementation phase, run pytest tests/ -v plus any touched stage validation. Never use --no-verify or skip hooks.
• Do not introduce lint / format / typecheck tooling unprompted (per CLAUDE.md).
• Do not create markdown docs outside .github/docs/vision/ unless explicitly requested.

Postconditions

After Phase 1 (planning):

• Three artifacts exist under .github/docs/vision/: software-3.0-current-state.md, software-3.0-gap-analysis.md, software-3.0-conversion-plan.md.
• Every gap is assigned a phase number or explicitly deferred with written rationale.
• Every phase has a yes/no-checkable verification gate.
• git status shows no new changes outside .github/docs/vision/ attributable to this run. Pre-existing unrelated modifications may remain.
• pytest tests/ -v is still green.

After each implementation phase:

• The phase's named verification gate reads yes.
• .github/docs/vision/phase-<id>-completion.md records the diff, the verification, the gate result, and what's next.
• Tests are green; hooks are intact; the CLI ↔ prompt split holds.