clawdbot/extensions/open-prose/skills/prose/examples/47-language-self-improvement.prose

# Language Self-Improvement
# Analyzes .prose usage patterns to evolve the language itself
# Meta-level 2: while the crystallizer creates .prose files, this improves .prose
#
# BACKEND: Run with sqlite+ or postgres backend for corpus-scale analysis
#   prose run 47-language-self-improvement.prose --backend sqlite+
#
# This program treats OpenProse programs as its corpus, looking for:
# - Workarounds (patterns that exist because the language lacks a cleaner way)
# - Friction (places where authors struggle or make errors)
# - Gaps (things people want to express but cannot)

input corpus_path: "Path to .prose files to analyze (default: examples/)"
input conversations: "Optional: conversation threads where people struggled with the language"
input focus: "Optional: specific area to focus on (e.g., 'error handling', 'parallelism')"

# ============================================================
# Agents
# ============================================================

agent archaeologist:
  model: opus
  prompt: """
    You excavate patterns from code corpora.
    Look for: repeated idioms, workarounds, boilerplate that could be abstracted.
    Report patterns with frequency counts and concrete examples.
    Distinguish between intentional patterns and compensating workarounds.
  """
  permissions:
    read: ["**/*.prose", "**/*.md"]

agent clinician:
  model: opus
  prompt: """
    You diagnose pain points from conversations and code.
    Look for: confusion, errors, questions that shouldn't need asking.
    Identify gaps between what people want to express and what they can express.
    Be specific about the symptom and hypothesize the underlying cause.
  """
  permissions:
    read: ["**/*.prose", "**/*.md", "**/*.jsonl"]

agent architect:
  model: opus
  persist: true
  prompt: """
    You design language features with these principles:
    1. Self-evidence: syntax should be readable without documentation
    2. Composability: features should combine without special cases
    3. Minimalism: no feature without clear, repeated need
    4. Consistency: follow existing patterns unless there's strong reason not to

    For each proposal, specify: syntax, semantics, interaction with existing features.
  """

agent spec_writer:
  model: opus
  prompt: """
    You write precise language specifications.
    Follow the style of compiler.md: grammar rules, semantic descriptions, examples.
    Be rigorous but readable. Include edge cases.
  """
  permissions:
    read: ["**/*.md"]
    write: ["**/*.md"]

agent guardian:
  model: sonnet
  prompt: """
    You assess backwards compatibility and risk.

    Breaking levels:
    0 - Fully compatible, new syntax only
    1 - Soft deprecation, old syntax still works
    2 - Hard deprecation, migration required
    3 - Breaking change, existing programs may fail

    Also assess: complexity cost, interaction risks, implementation effort.
  """

agent test_smith:
  model: sonnet
  prompt: """
    You create test .prose files that exercise proposed features.
    Include: happy path, edge cases, error conditions, interaction with existing features.
    Tests should be runnable and self-documenting.
  """
  permissions:
    write: ["**/*.prose"]

# ============================================================
# Phase 1: Corpus Excavation
# ============================================================

parallel:
  patterns = session: archaeologist
    prompt: """
      Analyze the .prose corpus for recurring patterns.

      For each pattern found, report:
      - Pattern name and description
      - Frequency (how many files use it)
      - Representative examples (quote actual code)
      - Is this intentional idiom or compensating workaround?

      Focus on patterns that appear 3+ times.
    """
    context: corpus_path

  pain_points = session: clinician
    prompt: """
      Analyze conversations and code for pain points.

      Look for:
      - Syntax errors that recur (what do people get wrong?)
      - Questions about "how do I...?" (what's not obvious?)
      - Workarounds or hacks (what's the language missing?)
      - Frustrated comments or abandoned attempts

      For each pain point, hypothesize what language change would help.
    """
    context: { corpus_path, conversations }

  current_spec = session: archaeologist
    prompt: """
      Summarize the current language capabilities from the spec.

      List: all keywords, all constructs, all patterns explicitly supported.
      Note any areas marked as "experimental" or "future".
      Identify any inconsistencies or gaps in the spec itself.
    """
    context: "compiler.md, prose.md"

# ============================================================
# Phase 2: Pattern Synthesis
# ============================================================

let synthesis = session: architect
  prompt: """
    Synthesize the excavation findings into a ranked list of potential improvements.

    Categories:
    1. ADDITIONS - new syntax/semantics the language lacks
    2. REFINEMENTS - existing features that could be cleaner
    3. CLARIFICATIONS - spec ambiguities that need resolution
    4. DEPRECATIONS - features that add complexity without value

    For each item:
    - Problem statement (what pain does this solve?)
    - Evidence (which patterns/pain points support this?)
    - Rough sketch of solution
    - Priority (critical / high / medium / low)

    Rank by: (frequency of need) × (severity of pain) / (implementation complexity)
  """
  context: { patterns, pain_points, current_spec, focus }

# ============================================================
# Phase 3: Proposal Generation
# ============================================================

let top_candidates = session: architect
  prompt: """
    Select the top 3-5 candidates from the synthesis.

    For each, produce a detailed proposal:

    ## Feature: [name]

    ### Problem
    [What pain point does this solve? Include evidence.]

    ### Proposed Syntax
    ```prose
    [Show the new syntax]
    ```

    ### Semantics
    [Precisely describe what it means]

    ### Before/After
    [Show how existing workarounds become cleaner]

    ### Interactions
    [How does this interact with existing features?]

    ### Open Questions
    [What needs further thought?]
  """
  context: synthesis

# ============================================================
# Phase 4: User Checkpoint
# ============================================================

input user_review: """
  ## Proposed Language Improvements

  {top_candidates}

  ---

  For each proposal, indicate:
  - PURSUE: Develop full spec and tests
  - REFINE: Good direction but needs changes (explain)
  - DEFER: Valid but not now
  - REJECT: Don't want this (explain why)

  You can also suggest entirely different directions.
"""

let approved = session: architect
  prompt: """
    Incorporate user feedback into final proposal set.

    For PURSUE items: proceed as-is
    For REFINE items: adjust based on feedback
    For DEFER/REJECT items: note the reasoning for future reference

    Output the final list of proposals to develop.
  """
  context: { top_candidates, user_review }

if **there are no approved proposals**:
  output result = {
    status: "no-changes",
    synthesis: synthesis,
    proposals: top_candidates,
    user_decision: user_review
  }
  throw "No proposals approved - halting gracefully"

# ============================================================
# Phase 5: Spec Drafting
# ============================================================

let spec_patches = approved | map:
  session: spec_writer
    prompt: """
      Write the specification addition for this proposal.

      Follow compiler.md style:
      - Grammar rule (in the existing notation)
      - Semantic description
      - Examples
      - Edge cases
      - Error conditions

      Output as a diff/patch that could be applied to compiler.md
    """
    context: { item, current_spec }

# ============================================================
# Phase 6: Test Case Creation
# ============================================================

let test_files = approved | pmap:
  session: test_smith
    prompt: """
      Create test .prose files for this proposal.

      Include:
      1. Basic usage (happy path)
      2. Edge cases
      3. Error conditions (should fail gracefully)
      4. Interaction with existing features

      Each test should be a complete, runnable .prose file.
      Name format: test-{feature-name}-{N}.prose
    """
    context: item

# ============================================================
# Phase 7: Risk Assessment
# ============================================================

let risks = session: guardian
  prompt: """
    Assess the full proposal set for risks.

    For each proposal:
    - Breaking level (0-3)
    - Complexity cost (how much does this add to the language?)
    - Interaction risks (could this combine badly with existing features?)
    - Implementation effort (VM changes, spec changes, tooling)

    Also assess aggregate risk:
    - Are we adding too much at once?
    - Is there a coherent theme or is this feature creep?
    - What's the total complexity budget impact?

    Recommend: PROCEED / REDUCE SCOPE / PHASE INCREMENTALLY / HALT
  """
  context: { approved, spec_patches, current_spec }

if **the guardian recommends halting**:
  input override: """
    Guardian recommends halting:
    {risks}

    Override and proceed anyway? (yes/no/reduce scope)
  """

  if **the user declined to override**:
    output result = {
      status: "halted-by-guardian",
      proposals: approved,
      risks: risks
    }
    throw "Halted by guardian recommendation"

# ============================================================
# Phase 8: Migration Guide
# ============================================================

let migration = session: spec_writer
  prompt: """
    Write a migration guide for existing .prose programs.

    For each proposal:
    - What existing code is affected?
    - Before/after examples
    - Deprecation timeline (if any)
    - Automated migration possible?

    Also:
    - Version number recommendation (major/minor/patch)
    - Release notes draft
  """
  context: { approved, risks, corpus_path }

# ============================================================
# Output
# ============================================================

output evolution = {
  status: "proposals-ready",

  # What we found
  patterns: patterns,
  pain_points: pain_points,
  synthesis: synthesis,

  # What we propose
  proposals: approved,
  spec_patches: spec_patches,
  test_files: test_files,

  # Risk and migration
  risks: risks,
  migration: migration,

  # Meta
  corpus_analyzed: corpus_path,
  focus_area: focus
}