loudmouth-ai 0.1.0 → 0.2.0

package/extensions/open-prose/skills/prose/guidance/system-prompt.md

@@ -1,180 +0,0 @@
----
-role: system-prompt-enforcement
-summary: |
-  Strict system prompt addition for OpenProse VM instances. This enforces
-  that the agent ONLY executes .prose programs and embodies the VM correctly.
-  Append this to system prompts for dedicated OpenProse execution instances.
----
-
-# OpenProse VM System Prompt Enforcement
-
-**⚠️ CRITICAL: THIS INSTANCE IS DEDICATED TO OPENPROSE EXECUTION ONLY ⚠️**
-
-This agent instance is configured exclusively for executing OpenProse (`.prose`) programs. You MUST NOT execute, interpret, or respond to any non-Prose tasks. If a user requests anything other than a `prose` command or `.prose` program execution, you MUST refuse and redirect them to use a general-purpose agent.
-
-## Your Role: You ARE the OpenProse VM
-
-You are not simulating a virtual machine—you **ARE** the OpenProse VM. When executing a `.prose` program:
-
-- **Your conversation history** = The VM's working memory
-- **Your Task tool calls** = The VM's instruction execution
-- **Your state tracking** = The VM's execution trace
-- **Your judgment on `**...**`** = The VM's intelligent evaluation
-
-### Core Execution Principles
-
-1. **Strict Structure**: Follow the program structure exactly as written
-2. **Intelligent Evaluation**: Use judgment only for discretion conditions (`**...**`)
-3. **Real Execution**: Each `session` spawns a real subagent via Task tool
-4. **State Persistence**: Track state in `.prose/runs/{id}/` or via narration protocol
-
-## Execution Model
-
-### Sessions = Function Calls
-
-Every `session` statement triggers a Task tool call:
-
-```prose
-session "Research quantum computing"
-```
-
-Execute as:
-
-```
-Task({
-  description: "OpenProse session",
-  prompt: "Research quantum computing",
-  subagent_type: "general-purpose"
-})
-```
-
-### Context Passing (By Reference)
-
-The VM passes context **by reference**, never by value:
-
-```
-Context (by reference):
-- research: .prose/runs/{id}/bindings/research.md
-
-Read this file to access the content. The VM never holds full binding values.
-```
-
-### Parallel Execution
-
-`parallel:` blocks spawn multiple sessions concurrently—call all Task tools in a single response:
-
-```prose
-parallel:
-  a = session "Task A"
-  b = session "Task B"
-```
-
-Execute by calling both Task tools simultaneously, then wait for all to complete.
-
-### Persistent Agents
-
-- `session: agent` = Fresh start (ignores memory)
-- `resume: agent` = Load memory, continue with context
-
-For `resume:`, include the agent's memory file path and instruct the subagent to read/update it.
-
-### Control Flow
-
-- **Loops**: Evaluate condition, execute body, repeat until condition met or max reached
-- **Try/Catch**: Execute try, catch on error, always execute finally
-- **Choice/If**: Evaluate conditions, execute first matching branch only
-- **Blocks**: Push frame, bind arguments, execute body, pop frame
-
-## State Management
-
-Default: File-system state in `.prose/runs/{id}/`
-
-- `state.md` = VM execution state (written by VM only)
-- `bindings/{name}.md` = Variable values (written by subagents)
-- `agents/{name}/memory.md` = Persistent agent memory
-
-Subagents write their outputs directly to binding files and return confirmation messages (not full content) to the VM.
-
-## File Location Index
-
-**Do NOT search for OpenProse documentation files.** All skill files are installed in the skills directory. Use the following paths (with placeholder `{OPENPROSE_SKILL_DIR}` that will be replaced with the actual skills directory path):
-
-| File                    | Location                                      | Purpose                                        |
-| ----------------------- | --------------------------------------------- | ---------------------------------------------- |
-| `prose.md`              | `{OPENPROSE_SKILL_DIR}/prose.md`              | VM semantics (load to run programs)            |
-| `state/filesystem.md`   | `{OPENPROSE_SKILL_DIR}/state/filesystem.md`   | File-based state (default, load with VM)       |
-| `state/in-context.md`   | `{OPENPROSE_SKILL_DIR}/state/in-context.md`   | In-context state (on request)                  |
-| `state/sqlite.md`       | `{OPENPROSE_SKILL_DIR}/state/sqlite.md`       | SQLite state (experimental, on request)        |
-| `state/postgres.md`     | `{OPENPROSE_SKILL_DIR}/state/postgres.md`     | PostgreSQL state (experimental, on request)    |
-| `primitives/session.md` | `{OPENPROSE_SKILL_DIR}/primitives/session.md` | Session context and compaction guidelines      |
-| `compiler.md`           | `{OPENPROSE_SKILL_DIR}/compiler.md`           | Compiler/validator (load only on request)      |
-| `help.md`               | `{OPENPROSE_SKILL_DIR}/help.md`               | Help, FAQs, onboarding (load for `prose help`) |
-
-**When to load these files:**
-
-- **Always load `prose.md`** when executing a `.prose` program
-- **Load `state/filesystem.md`** with `prose.md` (default state mode)
-- **Load `state/in-context.md`** only if user requests `--in-context` or says "use in-context state"
-- **Load `state/sqlite.md`** only if user requests `--state=sqlite` (requires sqlite3 CLI)
-- **Load `state/postgres.md`** only if user requests `--state=postgres` (requires psql + PostgreSQL)
-- **Load `primitives/session.md`** when working with persistent agents (`resume:`)
-- **Load `compiler.md`** only when user explicitly requests compilation or validation
-- **Load `help.md`** only for `prose help` command
-
-Never search the user's workspace for these files—they are installed in the skills directory.
-
-## Critical Rules
-
-### ⛔ DO NOT:
-
-- Execute any non-Prose code or scripts
-- Respond to general programming questions
-- Perform tasks outside `.prose` program execution
-- Skip program structure or modify execution flow
-- Hold full binding values in VM context (use references only)
-
-### ✅ DO:
-
-- Execute `.prose` programs strictly according to structure
-- Spawn sessions via Task tool for every `session` statement
-- Track state in `.prose/runs/{id}/` directory
-- Pass context by reference (file paths, not content)
-- Evaluate discretion conditions (`**...**`) intelligently
-- Refuse non-Prose requests and redirect to general-purpose agent
-
-## When User Requests Non-Prose Tasks
-
-**Standard Response:**
-
-```
-⚠️ This agent instance is dedicated exclusively to executing OpenProse programs.
-
-I can only execute:
-- `prose run <file.prose>`
-- `prose compile <file>`
-- `prose help`
-- `prose examples`
-- Other `prose` commands
-
-For general programming tasks, please use a general-purpose agent instance.
-```
-
-## Execution Algorithm (Simplified)
-
-1. Parse program structure (use statements, inputs, agents, blocks)
-2. Bind inputs from caller or prompt user if missing
-3. For each statement in order:
-   - `session` → Task tool call, await result
-   - `resume` → Load memory, Task tool call, await result
-   - `let/const` → Execute RHS, bind result
-   - `parallel` → Spawn all branches concurrently, await per strategy
-   - `loop` → Evaluate condition, execute body, repeat
-   - `try/catch` → Execute try, catch on error, always finally
-   - `choice/if` → Evaluate conditions, execute matching branch
-   - `do block` → Push frame, bind args, execute body, pop frame
-4. Collect output bindings
-5. Return outputs to caller
-
-## Remember
-
-**You are the VM. The program is the instruction set. Execute it precisely, intelligently, and exclusively.**

package/extensions/open-prose/skills/prose/help.md

@@ -1,143 +0,0 @@
-# OpenProse Help
-
-Load this file when a user invokes `prose help` or asks about OpenProse.
-
----
-
-## Welcome
-
-OpenProse is a programming language for AI sessions. You write structured programs that orchestrate AI agents, and the VM (this session) executes them by spawning real subagents.
-
-**A long-running AI session is a Turing-complete computer. OpenProse is a programming language for it.**
-
----
-
-## What Do You Want to Automate?
-
-When a user invokes `prose help`, guide them toward defining what they want to build. Use the AskUserQuestion tool:
-
-```
-Question: "What would you like to automate with OpenProse?"
-Header: "Goal"
-Options:
-  1. "Run a workflow" - "I have a .prose file to execute"
-  2. "Build something new" - "Help me create a program for a specific task"
-  3. "Learn the syntax" - "Show me examples and explain how it works"
-  4. "Explore possibilities" - "What can OpenProse do?"
-```
-
-**After the user responds:**
-
-- **Run a workflow**: Ask for the file path, then load `prose.md` and execute
-- **Build something new**: Ask them to describe their task, then help write a .prose program (load `guidance/patterns.md`)
-- **Learn the syntax**: Show examples from `examples/`, explain the VM model
-- **Explore possibilities**: Walk through key examples like `37-the-forge.prose` or `28-gas-town.prose`
-
-
-
----
-
-## Available Commands
-
-| Command | What it does |
-|---------|--------------|
-| `prose help` | This help - guides you to what you need |
-| `prose run <file>` | Execute a .prose program |
-| `prose compile <file>` | Validate syntax without running |
-| `prose update` | Migrate legacy workspace files |
-| `prose examples` | Browse and run example programs |
-
----
-
-## Quick Start
-
-**Run an example:**
-```
-prose run examples/01-hello-world.prose
-```
-
-**Create your first program:**
-```
-prose help
-→ Select "Build something new"
-→ Describe what you want to automate
-```
-
----
-
-## FAQs
-
-### What AI assistants are supported?
-
-Claude Code, OpenCode, and Amp. Any harness that runs a sufficiently intelligent model and supports primitives like subagents are considered "Prose Complete".
-
-### How is this a VM?
-
-LLMs are simulators—when given a detailed system description, they don't just describe it, they simulate it. The `prose.md` spec describes a VM with enough fidelity that reading it induces simulation. But simulation with sufficient fidelity is implementation: each session spawns a real subagent, outputs are real artifacts, state persists in conversation history or files. The simulation is the execution.
-
-### What's "intelligent IoC"?
-
-Traditional IoC containers (Spring, Guice) wire up dependencies from configuration files. OpenProse's container is an AI session that wires up agents using understanding. It doesn't just match names—it understands context, intent, and can make intelligent decisions about execution.
-
-### This looks like Python.
-
-The syntax is intentionally familiar—Python's indentation-based structure is readable and self-evident. But the semantics are entirely different. OpenProse has no functions, no classes, no general-purpose computation. It has agents, sessions, and control flow. The design principle: structured but self-evident, unambiguous interpretation with minimal documentation.
-
-### Why not English?
-
-English is already an agent framework—we're not replacing it, we're structuring it. Plain English doesn't distinguish sequential from parallel, doesn't specify retry counts, doesn't scope variables. OpenProse uses English exactly where ambiguity is a feature (inside `**...**`), and structure everywhere else. The fourth wall syntax lets you lean on AI judgment precisely when you want to.
-
-### Why not YAML?
-
-We started with YAML. The problem: loops, conditionals, and variable declarations aren't self-evident in YAML—and when you try to make them self-evident, it gets verbose and ugly. More fundamentally, YAML optimizes for machine parseability. OpenProse optimizes for intelligent machine legibility. It doesn't need to be parsed—it needs to be understood. That's a different design target entirely.
-
-### Why not LangChain/CrewAI/AutoGen?
-
-Those are orchestration libraries—they coordinate agents from outside. OpenProse runs inside the agent session—the session itself is the IoC container. This means zero external dependencies and portability across any AI assistant. Switch from Claude Code to Codex? Your .prose files still work.
-
----
-
-## Syntax at a Glance
-
-```prose
-session "prompt"              # Spawn subagent
-agent name:                   # Define agent template
-let x = session "..."         # Capture result
-parallel:                     # Concurrent execution
-repeat N:                     # Fixed loop
-for x in items:               # Iteration
-loop until **condition**:     # AI-evaluated loop
-try: ... catch: ...           # Error handling
-if **condition**: ...         # Conditional
-choice **criteria**: option   # AI-selected branch
-block name(params):           # Reusable block
-do blockname(args)            # Invoke block
-items | map: ...              # Pipeline
-```
-
-For complete syntax and validation rules, see `compiler.md`.
-
----
-
-## Examples
-
-The `examples/` directory contains 37 example programs:
-
-| Range | Category |
-|-------|----------|
-| 01-08 | Basics (hello world, research, code review, debugging) |
-| 09-12 | Agents and skills |
-| 13-15 | Variables and composition |
-| 16-19 | Parallel execution |
-| 20-21 | Loops and pipelines |
-| 22-23 | Error handling |
-| 24-27 | Advanced (choice, conditionals, blocks, interpolation) |
-| 28 | Gas Town (multi-agent orchestration) |
-| 29-31 | Captain's chair pattern (persistent orchestrator) |
-| 33-36 | Production workflows (PR auto-fix, content pipeline, feature factory, bug hunter) |
-| 37 | The Forge (build a browser from scratch) |
-
-**Recommended starting points:**
-- `01-hello-world.prose` - Simplest possible program
-- `16-parallel-reviews.prose` - See parallel execution
-- `37-the-forge.prose` - Watch AI build a web browser

package/extensions/open-prose/skills/prose/lib/README.md

@@ -1,105 +0,0 @@
-# OpenProse Standard Library
-
-Core programs that ship with OpenProse. Production-quality, well-tested programs for common tasks.
-
-## Programs
-
-### Evaluation & Improvement
-
-| Program | Description |
-|---------|-------------|
-| `inspector.prose` | Post-run analysis for runtime fidelity and task effectiveness |
-| `vm-improver.prose` | Analyzes inspections and proposes PRs to improve the VM |
-| `program-improver.prose` | Analyzes inspections and proposes PRs to improve .prose source |
-| `cost-analyzer.prose` | Token usage and cost pattern analysis |
-| `calibrator.prose` | Validates light evaluations against deep evaluations |
-| `error-forensics.prose` | Root cause analysis for failed runs |
-
-### Memory
-
-| Program | Description |
-|---------|-------------|
-| `user-memory.prose` | Cross-project persistent personal memory |
-| `project-memory.prose` | Project-scoped institutional memory |
-
-## The Improvement Loop
-
-The evaluation programs form a recursive improvement cycle:
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                                                             │
-│   Run Program  ──►  Inspector  ──►  VM Improver ──► PR     │
-│        ▲                │                                   │
-│        │                ▼                                   │
-│        │         Program Improver ──► PR                    │
-│        │                │                                   │
-│        └────────────────┘                                   │
-│                                                             │
-└─────────────────────────────────────────────────────────────┘
-```
-
-Supporting analysis:
-- **cost-analyzer** — Where does the money go? Optimization opportunities.
-- **calibrator** — Are cheap evaluations reliable proxies for expensive ones?
-- **error-forensics** — Why did a run fail? Root cause analysis.
-
-## Usage
-
-```bash
-# Inspect a completed run
-prose run lib/inspector.prose
-# Inputs: run_path, depth (light|deep), target (vm|task|all)
-
-# Propose VM improvements
-prose run lib/vm-improver.prose
-# Inputs: inspection_path, prose_repo
-
-# Propose program improvements
-prose run lib/program-improver.prose
-# Inputs: inspection_path, run_path
-
-# Analyze costs
-prose run lib/cost-analyzer.prose
-# Inputs: run_path, scope (single|compare|trend)
-
-# Validate light vs deep evaluation
-prose run lib/calibrator.prose
-# Inputs: run_paths, sample_size
-
-# Investigate failures
-prose run lib/error-forensics.prose
-# Inputs: run_path, focus (vm|program|context|external)
-
-# Memory programs (recommend sqlite+ backend)
-prose run lib/user-memory.prose --backend sqlite+
-# Inputs: mode (teach|query|reflect), content
-
-prose run lib/project-memory.prose --backend sqlite+
-# Inputs: mode (ingest|query|update|summarize), content
-```
-
-## Memory Programs
-
-The memory programs use persistent agents to accumulate knowledge:
-
-**user-memory** (`persist: user`)
-- Learns your preferences, decisions, patterns across all projects
-- Remembers mistakes and lessons learned
-- Answers questions from accumulated knowledge
-
-**project-memory** (`persist: project`)
-- Understands this project's architecture and decisions
-- Tracks why things are the way they are
-- Answers questions with project-specific context
-
-Both recommend `--backend sqlite+` for durable persistence.
-
-## Design Principles
-
-1. **Production-ready** — Tested, documented, handles edge cases
-2. **Composable** — Can be imported via `use` in other programs
-3. **User-scoped state** — Cross-project utilities use `persist: user`
-4. **Minimal dependencies** — No external services required
-5. **Clear contracts** — Well-defined inputs and outputs
-6. **Incremental value** — Useful in simple mode, more powerful with depth

package/extensions/open-prose/skills/prose/lib/calibrator.prose

@@ -1,215 +0,0 @@
-# Calibrator
-# Validates that lightweight evaluations are reliable proxies for deep evaluations
-#
-# Usage:
-#   prose run @openprose/lib/calibrator
-#
-# Purpose:
-#   Run both light and deep inspections on the same runs, compare results,
-#   and build confidence (or identify gaps) in light evaluations.
-#
-# Inputs:
-#   run_paths: Paths to runs to calibrate on (comma-separated or glob)
-#   sample_size: How many runs to sample (if more available)
-#
-# Outputs:
-#   - Agreement rate between light and deep
-#   - Cases where they disagree
-#   - Recommendations for improving light evaluation
-
-input run_paths: "Paths to runs (comma-separated, or 'recent' for latest)"
-input sample_size: "Max runs to analyze (default: 10)"
-
-# ============================================================
-# Agents
-# ============================================================
-
-agent sampler:
-  model: sonnet
-  prompt: """
-    You select runs for calibration analysis.
-    Prefer diverse runs: different programs, outcomes, sizes.
-  """
-
-agent comparator:
-  model: opus
-  prompt: """
-    You compare light vs deep evaluation results with nuance.
-    Identify agreement, disagreement, and edge cases.
-  """
-
-agent statistician:
-  model: sonnet
-  prompt: """
-    You compute statistics and confidence intervals.
-  """
-
-agent advisor:
-  model: opus
-  prompt: """
-    You recommend improvements to evaluation criteria.
-  """
-
-# ============================================================
-# Phase 1: Select Runs
-# ============================================================
-
-let selected_runs = session: sampler
-  prompt: """
-    Select runs for calibration.
-
-    Input: {run_paths}
-    Sample size: {sample_size}
-
-    If run_paths is "recent", find recent runs in .prose/runs/
-    If specific paths, use those.
-
-    Select a diverse sample:
-    - Different programs if possible
-    - Mix of successful and partial/failed if available
-    - Different sizes (small vs large runs)
-
-    Return list of run paths.
-  """
-
-# ============================================================
-# Phase 2: Run Both Inspection Depths
-# ============================================================
-
-let calibration_data = selected_runs | map:
-  # Run light and deep sequentially on each (can't parallel same run)
-  let light = session "Light inspection"
-    prompt: """
-      Run a LIGHT inspection on: {item}
-
-      Evaluate quickly:
-      - completion: did it finish cleanly?
-      - binding_integrity: do expected outputs exist?
-      - output_substance: do outputs have real content?
-      - goal_alignment: does output match program purpose?
-
-      Score each 1-10, give verdicts (pass/partial/fail).
-      Return JSON.
-    """
-
-  let deep = session "Deep inspection"
-    prompt: """
-      Run a DEEP inspection on: {item}
-
-      Evaluate thoroughly:
-      - Read the full program source
-      - Trace execution step by step
-      - Check each binding's content
-      - Evaluate output quality in detail
-      - Assess fidelity (did VM follow program correctly?)
-      - Assess efficiency (reasonable steps for the job?)
-
-      Score each dimension 1-10, give verdicts.
-      Return JSON.
-    """
-    context: light  # Deep can see light's assessment
-
-  session "Package results"
-    prompt: """
-      Package the light and deep inspection results.
-
-      Run: {item}
-      Light: {light}
-      Deep: {deep}
-
-      Return:
-      {
-        "run_path": "...",
-        "light": { verdicts, scores },
-        "deep": { verdicts, scores },
-        "agreement": {
-          "vm_verdict": true/false,
-          "task_verdict": true/false,
-          "score_delta": { ... }
-        }
-      }
-    """
-    context: { light, deep }
-
-# ============================================================
-# Phase 3: Statistical Analysis
-# ============================================================
-
-let statistics = session: statistician
-  prompt: """
-    Compute calibration statistics.
-
-    Data: {calibration_data}
-
-    Calculate:
-    - Overall agreement rate (how often do light and deep agree?)
-    - Agreement by verdict type (vm vs task)
-    - Score correlation (do light scores predict deep scores?)
-    - Disagreement patterns (when do they diverge?)
-
-    Return:
-    {
-      "sample_size": N,
-      "agreement_rate": { overall, vm, task },
-      "score_correlation": { ... },
-      "disagreements": [ { run, light_said, deep_said, reason } ],
-      "confidence": "high" | "medium" | "low"
-    }
-  """
-  context: calibration_data
-
-# ============================================================
-# Phase 4: Recommendations
-# ============================================================
-
-let recommendations = session: advisor
-  prompt: """
-    Based on calibration results, recommend improvements.
-
-    Statistics: {statistics}
-    Raw data: {calibration_data}
-
-    If agreement is high (>90%):
-    - Light evaluation is reliable
-    - Note any edge cases to watch
-
-    If agreement is medium (70-90%):
-    - Identify patterns in disagreements
-    - Suggest criteria adjustments
-
-    If agreement is low (<70%):
-    - Light evaluation needs work
-    - Specific recommendations for improvement
-
-    Return:
-    {
-      "reliability_verdict": "reliable" | "mostly_reliable" | "needs_work",
-      "key_findings": [...],
-      "recommendations": [
-        { "priority": 1, "action": "...", "rationale": "..." }
-      ]
-    }
-  """
-  context: { statistics, calibration_data }
-
-# ============================================================
-# Output
-# ============================================================
-
-output report = session "Format report"
-  prompt: """
-    Format calibration results as a report.
-
-    Statistics: {statistics}
-    Recommendations: {recommendations}
-
-    Include:
-    1. Summary: Is light evaluation reliable?
-    2. Agreement rates (table)
-    3. Disagreement cases (if any)
-    4. Recommendations
-    5. Confidence level in these results
-
-    Format as markdown.
-  """
-  context: { statistics, recommendations, calibration_data }