[FEATURE]: Optimize prompts using principle constraints and DSL compression

Feature hasn't been suggested before.

I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

OpenCode's prompts are verbose and sometimes contradictory, causing:

Unnecessary token consumption
Unpredictable LLM outputs
Difficulty maintaining consistency

Core Solution: Two Complementary Approaches

1. Principle-Based Constraints

Instead of describing behaviors explicitly, reference established design principles from LLM training data:

UNIX Philosophy (for modular, single-purpose components)
KISS Principle (for simplicity)
YAGNI (to avoid over-engineering)
SOLID (for object-oriented design)

Example:
Instead of: "Make it simple, don't add unnecessary features, focus on one thing..."
Use: "Apply KISS and YAGNI principles."

Benefits:

Reduces token count by 60-80%
Eliminates instruction conflicts via internally consistent frameworks
Leverages LLM's existing knowledge

2. DSL Context Compression

Create structured templates to filter noise in extended conversations:

[CONTEXT_SUMMARY]
CORE_ISSUE:: <main problem>
KEY_POINTS:: <bullet points>
ACTION_ITEMS:: <next steps>
[END_SUMMARY]

Information Theory Rationale:

Acts as entropy-reducing encoder
Implements lossy compression preserving semantic essence
Filters low-information noise

Why This Works

Both methods address root causes:

Principles compress complex concepts into single references
DSL templates enforce structure, eliminating ambiguity
Together they create concise, predictable prompts

Suggested First Steps

Audit current prompts for most redundant sections
Replace verbose descriptions with principle references
Design 2-3 DSL templates for common workflows
Test with critical paths

This approach transforms prompt engineering from art to science—reducing costs while improving output quality.

Additional Context

The specific principles, paradigms, or conventions mentioned are not exhaustive or exclusive—they are examples of a broader pattern. You can search for and adopt any well-established, widely recognized design principles, methodologies, or standards relevant to your domain (e.g., "separation of concerns," "immutable architecture," "12-factor app"). The key is leveraging consensus-based constraints that exist within the LLM's training corpus. This approach reduces rule conflicts inherent in human language and minimizes token waste caused by over-explanation.

Additionally, custom DSLs can be co-designed with the LLM itself. After several rounds of discussion, you can instruct the LLM to summarize the conversation using a mutually agreed-upon DSL format. This practice effectively filters noise and compresses context, saving tokens for subsequent interactions.

This issue might be a duplicate of existing issues. Please check:

[FEATURE]: update base prompt to remove obvious comments #6148: [FEATURE]: update base prompt to remove obvious comments
Excluding reasoning context to reduce token usage #4895: Excluding reasoning context to reduce token usage
prompt is too long #5360: prompt is too long
prompt is too long unrecoverable #4845: prompt is too long unrecoverable

These issues all address the same root problem: reducing token consumption through prompt optimization and context management. Feel free to ignore if your specific proposal addresses aspects not covered by these.

The following is a custom DSL I developed with an LLM. Typically, after multiple rounds of conversation about frontend UI design, I choose to use the ULD (UI Layout Description) below to have the LLM summarize the UI structural relationships we've designed. This summarized format, when shared with other LLMs, introduces significantly less information pollution, and the UI effects generated by the receiving LLM are noticeably improved. This type of custom DSL effectively acts as a noise filter.

The following is just an example or analogy

UI Layout Description (ULD) Specification

1. Language Overview

Definition

ULD (UI Layout Description) is a Domain Specific Language (DSL) designed to describe the topology and spatial relationships of user interfaces. It serves as a high-level Intermediate Representation (IR) that facilitates the exchange of design intent between stakeholders without coupling to specific implementation technologies like CSS or JavaScript frameworks.

Core Philosophy

The language prioritizes structural layout over visual styling. It enforces a strict separation of concerns where the ULD defines "where" and "what" an element is, while leaving the specific "how" (pixels, colors, fonts) to the implementation phase.

2. Core Syntax Elements

2.1 Container Scopes `[]`

A container defines a bounded rectangular region within the layout.

Syntax: Enclosed by square brackets [...].
Constraint: The first token within a container must be a Spatial Directive.
Nesting: Containers support recursive nesting to describe complex hierarchies.
Example: [Left [...] ]

2.2 Spatial Directives

These keywords define the spatial distribution of child elements within a container. They must be placed immediately preceding the content they control.

Generic: Item (Used for single elements without specific alignment).
Cardinal Directions: Top, Bottom, Left, Right.
Central Axis: Center.
Indexed Middle Segments: Mid1, Mid2, Mid3... (Used for multipart layouts).
Rule: The quantity of Spatial Directives must strictly match the quantity of child elements (N-to-N bijection).

2.3 Semantic Descriptors `()`

Descriptors define the functional role or component type of a layout node.

Syntax: Enclosed by parentheses (...).
Placement: Immediately following a Spatial Directive.
Content: Natural language descriptions focusing on business intent.
Example: (User Profile Panel)

2.4 Orthogonal Layers

Layers describe UI elements that exist outside the primary document flow, such as modals, toast notifications, or overlays.

Definition Syntax: LayerIdentifier: [ Layout ]
Reference Syntax: (goto: LayerIdentifier)
Constraint: Layer definitions must exist at the root scope or clearly separated from the main tree.

2.5 External References

References provide pointers to external visual specifications or existing implementations to augment the structural description.

Syntax: (link:<URL> Description)
Constraint: URLs must be absolute (including protocol).

3. Detailed Syntax Rules

3.1 Context Free Grammar (Informal)

Container: [ SpatialDirective ChildNode ... ]
ChildNode: Container | Descriptor
Descriptor: ( Text )

3.2 Cardinality and Direction Rules

The choice of Spatial Directives is determined by the number of child nodes in the container.

Condition: Single Child Node
The container should typically use the Center directive (implying the element occupies the central focus) or the generic Item directive.

Example: [ Center(Main Content) ]
Example: [ Item(Profile Card) ]

Condition: Two Child Nodes
The container must use an opposing pair of directives to define the axis.

Vertical Axis: Top and Bottom.
Horizontal Axis: Left and Right.

Condition: Three Child Nodes
The container must use a triplet that spans the axis, inclusive of the center.

Vertical Axis: Top, Center, and Bottom.
Horizontal Axis: Left, Center, and Right.

Condition: Four or More Child Nodes
The container must use indexed Mid directives to define the space between the extremities.

Example: Top, Mid1, Mid2, Bottom.
Example: Left, Mid1, Mid2, Mid3, Right.

Condition: Arbitrary N Nodes
Any combination is valid provided every child node is prefixed by a unique, spatially logical directive, and the sequence maintains topological order.

3.3 Layer Definition Rules

Identifier: Alphanumeric characters and underscores only. No whitespace.
Scope: A layer defined in the file can be referenced by any container using the goto operator.

4. Writing Guidelines

4.1 Hierarchical Indentation

Maintain strict indentation to visually represent the nesting depth of containers. Each nested [ should initiate a new indentation level.

4.2 Semantic Abstraction

Descriptions must remain technology-agnostic.

Correct: (User Search Input) describes the function.
Incorrect: (Blue Rounded Text Box) describes the style.
Incorrect: (React Input Component) describes the implementation.

4.3 Structural Decomposition

Complex interfaces should be broken down into sub-sections defined as named Layers or clearly commented blocks, rather than a single deeply nested structure.

5. Pattern Examples

5.1 Standard Three-Column Layout

[
  Left(Navigation Menu)
  Center(Main Content Area)
  Right(Advertisement Panel)
]

5.2 Dashboard Topology

Dashboard: [
  Top(KPI Metric Cards)
  Center[
    Left(Activity Chart)
    Center(Revenue Graph)
    Right(Geographic Heatmap)
  ]
  Bottom[
    Left(Recent Transactions)
    Right(System Health Status)
  ]
]

5.3 Mobile Adaptation Strategy

Describe responsive variations as distinct topology definitions if the structure changes significantly.

DesktopLayout: [
  Left(Sidebar)
  Center(Content)
]

MobileLayout: [
  Top(Header)
  Center(Content)
  Bottom(Tab Navigation)
]

6. Anti-Patterns and Corrections

Anti-Pattern: Directive Mismatch

Invalid: [Top(Header) Bottom(Content) Bottom(Footer)]
Reason: The directive Bottom is repeated illogically for a 3-element stack.
Correction: [Top(Header) Center(Content) Bottom(Footer)]

Anti-Pattern: Phantom References

Invalid: (goto: UndefinedModal)
Reason: Referencing a layer that has not been defined in the specification.
Correction: Define UndefinedModal: [...] before referencing it.

Anti-Pattern: Stylistic Coupling

Invalid: (Red Button 20px)
Reason: Leaks CSS implementation details into the structural definition.
Correction: (Delete Action Button)

7. Tooling Recommendations

7.1 Editor Configuration

Font: Monospaced (e.g., Fira Code).
Indentation: 2 spaces.
Highlighting: Enable Bracket Matching.

7.2 Validation Procedure

Verify every [ has a closing ].
Verify every ( has a closing ).
Verify the first token in every [] is a valid Spatial Directive.
Verify the number of Directives equals the number of Child Nodes.
Verify all goto targets are defined.

packages/opencode/src/session/prompt/beast.txt and packages/opencode/src/session/prompt/codex.txt are unnecessarily complex. Similar simplification opportunities exist in other areas.

To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.

[FEATURE]: Optimize prompts using principle constraints and DSL compression #6249

Description