Liminal

Adjust the contract only when the prompt clearly asks for a different shape:

• For study or self-training prompts, rename Concrete Witness to Worked Example and replace Implementation Tradeoffs with Learning Plan.
• For repo-specific code work, add Repository Application after Implementation Tradeoffs.
• For source-comparison prompts, expand Sources with short annotations instead of long prose.
• For citation-audit prompts, add Claim Ledger before Sources.

Workflow

1. Classify the request:
   • semantics: operator comparison, reduction rules, evaluation contexts, typed control questions
   • translation: CPS, answer-type modification, defunctionalization, refunctionalization, abstract machines
   • implementation: stack strategy, one-shot vs multi-shot, effect handlers, benchmarking, runtime tradeoffs
   • roadmap: study plans, project ladders, reading orders, proof agendas, research directions
   • literature: source comparison, citation audit, claim mapping, reading packets
2. Choose one derivation spine or witness before loading the bibliography:
   • operator comparison -> a separating witness from references/witness-programs.md
   • translation question -> one source term that survives the translation
   • implementation question -> one workload and one semantic contract
   • roadmap question -> one artifact per stage, not only a reading list
3. Load only the references you need:
   • references/foundations.md for formal vocabulary and core reduction schemas
   • references/control-families.md for operator families, static vs dynamic extent, typing pressure points
   • references/defunctionalization.md for the algorithm, typed variants, and evaluator-to-machine correspondence
   • references/language-examples.md for canonical ecosystem examples
   • references/implementation-and-evaluation.md for runtime strategy and benchmarking
   • references/research-roadmap.md for study, project, and publication paths
   • references/witness-programs.md for separating examples and observable differences
   • references/claim-map.md for fast claim-to-source routing
   • references/sources.md for primary-source citations and stable links
4. Keep the answer witness-first and core-first:
   • start from the named operator, transformation, or witness program
   • explain the boundary, capture, and reinstatement story before expanding into taxonomy
   • pull in CPS, prompts, effects, or mechanization only when they sharpen the answer
   • say explicitly when a topic is adjacent rather than central
5. Build a claim ledger for theory-heavy answers after the conceptual skeleton exists:
   • label each nontrivial claim as semantic, translation, implementation, or ecosystem
   • attach at least one source ID or official manual page to each nontrivial claim
   • mark anything inferred from multiple sources as an inference instead of a direct citation
6. When the user wants a starter artifact, run scripts/emit_artifact_stub.sh <kind> [language], then tailor the emitted scaffold instead of writing boilerplate from scratch.
7. When the user wants curated citations, a reading packet, or a safe source bundle, run scripts/emit_source_pack.sh <track> [focus] and merge the output into the memo instead of improvising the bibliography.
8. When the user wants a separating example, a worked distinction, or a teaching-ready comparison, run scripts/emit_witness_pack.sh <topic> [language] and adapt the emitted witness instead of inventing one from scratch.

Canonical Interpretive Rules

• Preserve the distinction between static and dynamic delimited control.
• Prefer one concrete separating witness over a paragraph of taxonomy when comparing nearby operators.
• When comparing shift/reset with prompt/control, explain the extra delimiter reinstatement instead of flattening them into one family.
• Treat effect handlers as adjacent structured control, not as a replacement vocabulary unless the prompt centers them.
• Distinguish semantic claims, implementation claims, and current-ecosystem status claims.
• Use the claim map before making compound claims that cross semantics, implementation, and ecosystem status.

Citation and Freshness Rules

• Default to bundled primary references for technical claims.
• For theory-heavy answers, route through references/claim-map.md first and then cite references/sources.md.
• When the user asks for "latest", "current", proposal status, library maintenance status, or implementation availability, browse primary sources before answering.
• Prefer primary papers, official manuals, and maintained project docs over tertiary summaries.
• Keep semantic citations, runtime citations, and analogy citations separate.
• If a claim is inferred rather than directly stated in a source, label it as an inference.

Guardrails

• Do not turn every control question into a general effects lecture.
• Do not let the claim ledger replace the explanation; it is a proof aid, not the center of the answer.
• Do not recommend a runtime strategy without naming the tradeoff it optimizes.
• Do not claim shift/reset and control/prompt are interchangeable without boundaries.
• Do not present generators, async/await, or effect handlers as semantically identical to delimited continuations.
• Do not drop typing constraints such as answer-type modification, prompt typing, or one-shot restrictions when they matter.
• Do not answer operator-comparison questions without either a separating witness or an explicit reason that no finite witness will do.
• Keep formalism proportional to the request, but preserve the real distinctions.

Reference Map

• references/foundations.md
• references/control-families.md
• references/defunctionalization.md
• references/language-examples.md
• references/implementation-and-evaluation.md
• references/research-roadmap.md
• references/witness-programs.md
• references/claim-map.md
• references/sources.md

Script

• scripts/emit_artifact_stub.sh <kind> [language]
• scripts/emit_source_pack.sh <track> [focus]
• scripts/emit_witness_pack.sh <topic> [language]
• Supported kind values:
  • derivation-memo
  • evaluator-project
  • cps-translation
  • defunc-machine
  • benchmark-plan
  • mechanization-plan
  • citation-memo
  • witness-walkthrough
• Supported language values:
  • agnostic (default)
  • racket
  • ocaml
  • haskell
  • scala
  • javascript
• Supported track values:
  • semantics
  • translation
  • implementation
  • roadmap
  • language
• Supported topic values:
  • static-vs-dynamic
  • multi-prompt
  • answer-type
  • one-shot
  • machine-derivation
  • analogy-boundary
• The scripts print Markdown to stdout only. They are starters, not finished answers.