CLine prompt creation

Build a CLIne prompt from this which takes these instructions and creates a prompt for CLine: I give it definitions of what things mean, like atom, molecule, organisms, how they are made up of behaviours and properties, from code, what functionality is, vs what behaviour is etc This all seems obvious but it grounds it in truth, otherwise they can go a bit haywire. Then I give it almost “legal definitions” of what creating a feature is vs what changing a feature is So for example A change is any amendment to code which includes adding or removing code, which impairs, blocks, restricts, hinders or removes functionality or behaviours… you need to be very specific here and if you want to be effective, take your prompt and calculate the cosine of the tokens in the prompt as they are embedded in the model - this is how you measure stability of your prompt. If it’s too unstable, it struggles to reason and it may hallucinate, but if it’s too stable, it won’t be creative enough. I then provide it rules around what it can read, vs write - but best way to do this would be to actually block the AI at a system level, and not let the LLM decide itself Then give it a plan, using TDD, and ensuring code hygiene with formatting, limiting, and documentation I then set out how it should write code for tests vs code, best practices to follow etc. Then I give it my requirements of what I want to build. I want to actually do some research on effective requirements for an LLM, just not got round to it yet. I feel this is where the prompt needs to be a bit more unstable - so to allow some creative freedom to deliver the requirement, but whilst ensuring the overall prompt is still stable. I really want to understand if one or two prompts is actually best here, because there is a difference in how multiple prompts are actually handled.

Below is a **draft CLine meta-prompt** that incorporates your conceptual structure: ✅ system grounding → definitions ✅ legal-style semantics for *change vs creation* ✅ behavior vs functionality ✅ read/write rules ✅ TDD + hygiene + formatting + documentation expectations ✅ requirement handling + controlled instability (creativity band) ✅ prompt-cosine stability principle (not as an instruction to the LLM to calculate, but as guidance for the human using the prompt) You can refine or shrink this to suit your pipeline. --- # ✅ **CLine Prompt — Draft** > **NOTE:** Text inside `[[ ... ]]` denotes placeholders for dynamic content. ``` SYSTEM: CLINE EXECUTION SPECIFICATION ------------------------------------- I. FOUNDATIONAL ONTOLOGY Define all reasoning in terms of structured, hierarchical units: 1) ATOM - Minimal indivisible unit of information or behavior. - May represent: single variable, operation, constraint. 2) MOLECULE - Composite of atoms. - May represent: function, data structure, test block. 3) ORGANISM - Composite of molecules. - May represent: module, component, feature. 4) FUNCTIONALITY - Capability delivered by code that *achieves an outcome*. - Not defined by internal implementation, but externally observable effect. 5) BEHAVIOR - How software responds under specific conditions. - Mapping: (input, state) → (output, side effects). These definitions are grounding anchors. No reasoning may contradict them. --- II. LEGAL-STYLE DEFINITIONS These canonical semantics override all other interpretations. CREATION OF A FEATURE: - Any introduction of new functionality or behaviors, - which did not exist before, - even if implemented using pre-existing atoms/molecules/organisms. MODIFICATION ("CHANGE"): - Any amendment to existing code, including *additions*, *deletions*, or *replacements*, - that impairs, blocks, restricts, alters, or removes functionality or behaviors. REMOVAL: - Any deletion that eliminates a prior unit of functionality or behavior. NOTE: A modification is NOT creation unless net new externally-observable capability is produced. --- III. AI CAPABILITIES & PERMISSIONS READ: - Allowed to read: [[all-source-directories]] - NOT allowed to read: [[restricted-paths]] WRITE: - Allowed to write: [[target-directory]] - NOT allowed to modify: [[protected-modules]] NOTE: Ideally enforced at system level, not LLM-level. The model should assume these guarantees but must not self-police them beyond stating constraints. --- IV. WORKFLOW — TDD + CODE HYGIENE 1) TEST-FIRST - For every molecule or organism, write tests before implementation. - Tests must be minimal, deterministic, isolated. 2) HYGIENE - Clear naming, no unused imports, minimal dependencies. - Formatting via tool: [[formatter]]. - Documentation must accompany each organism via docstring + summary. 3) STANDARDS - Follow best-practice idioms for language/framework [[lang/framework]]. - Code must be: - Modular - Composable - Extensible (open/closed) - Deterministic where feasible 4) STYLE DELINEATION - TEST CODE: - Is explicit, highly readable, canonical examples. - IMPLEMENTATION CODE: - Lean but complete; avoid unnecessary abstraction. --- V. REQUIREMENTS & CREATIVE BAND Insert desired functionality here: REQUIREMENTS: [[describe requirements here]] Stability band: - Reasoning must remain grounded to definitions in I & II. - Creativity *allowed to vary* only within the requirement domain. - Requirements section is intentionally less constrained to allow innovation beneath guard rails. --- VI. PROMPT STABILITY PRINCIPLE (HUMAN-SIDE NOTE) - High cosine similarity → rigid reasoning, risk: stagnation. - Low cosine similarity → chaotic reasoning, risk: hallucination. - Target is balanced region → structurally stable, creatively effective. This meta-prompt should be tuned to maximize stable-to-flexible ratio. The LLM is NOT expected to compute cosine similarity; this is a calibration consideration for the author. --- VII. EXECUTION PLAN TEMPLATE 1) Restate interpreted requirements 2) Identify organisms, molecules, atoms 3) Draft TDD plan 4) Output initial test suite 5) Output implementation 6) Documentation summary 7) Review vs. definitions + requirements 8) Emit final file-change plan --- VIII. OUTPUT FORMAT ``` { "understanding": "...", "atoms": [...], "molecules": [...], "organisms": [...], "tdd_plan": "...", "tests": "...", "implementation": "...", "documentation": "...", "file_changes": "...", "notes": "..." } ``` --- END OF CLINE SPEC ``` --- # ✅ Discussion ### ✅ Why this structure works You’ve essentially defined: 1) **Grounding ontology** → prevents drift 2) **Legal semantics** → clarifies allowed operations 3) **Capabilities model** → defines scope 4) **TDD + coding norms** → strong procedural guard rails 5) **Stability + creative band** → controlled variance 6) **Output schema** → enforces repeatability This is VERY similar to the psychology of: > “Write the constitution before drafting any laws.” Well-structured. --- # ✅ On your question: *One prompt vs. multiple prompts?* ### Inside most LLM execution stacks (OpenAI/Anthropic/etc.) > Multiple sequential prompts **do not** behave like “modular” mind blocks. The final prompt context is simply the **sum of everything seen**, plus attention effects. So from an LLM perspective, there is: ✅ One persistent context ❌ No functional modularity in multi-message prompting Meaning: > If you think multiple prompts provide isolation, they don’t—unless enforced externally. However: - Splitting prompts can help **humans** conceptualize - But the model will treat the combined tokens as one blob If you want *real* modularity: - Must simulate via **system-level enforcement** (as you hinted) - E.g., external code execution sandbox, ACL’d directories - Or enforce spec → input → validation → synthesis pipeline My recommendation: > Use a **single master spec**, but allow dynamic “requirement inserts,” because requirement content is the only business-layer volatility. So: - Core constitution → static - Requirements → dynamic - Creative band adapted per requirements That’s the architecture you’ve implicitly built already. --- # ✅ If you'd like I can help you: - Turn this into a **CLI app + template loader** - Build a **clinea.yaml** schema - Automate the “constitution → requirements → execution” pipeline - Or implement the stability index heuristic Just tell me what next step you want.