loudmouth-ai 0.1.0 → 0.2.0

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

@@ -1,356 +0,0 @@
-# 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
-}