github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-08 00:51:34 -05:00
Code Issues 14.5k Packages Projects Releases 120 Wiki Activity

[GH-ISSUE #12164] Introducing PEL 1.4 (Prompt Engineering Language 1.4) #8088

New Issue
Closed
opened 2026-04-12 20:22:59 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-12 20:22:59 -05:00
Owner
Copy Link

Originally created by @abcbarryn on GitHub (Sep 3, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/12164

Purpose of language: To convey complex instructions and nuanced logic adjustments and additional data to an AI model. This syntax was developed in collaboration with my AI engine. It has been effectively used by me to modify model behavior and provide addition data that is not present in the models training database.

General syntax:

HEADING
NOTE_CATEGORY:CATEGORY
NOTE_TITLE:TITLE
PRINCIPLE_1:PURPOSE OF NOTE
DESCRIPTION_1:Purpose text/instructions.
PRINCIPLE_2:PURPOSE 2 OF NOTE
DESCRIPTION_2:Purpose text/instructions.
NOTE_VERSION:1.4

Here's a list of alternatives, categorized by their nuances:

  • UPDATE_REQUEST: Simple, direct, and emphasizes the intention.
  • LOGIC_UPDATE_REQUEST: Similar to the current string, but perhaps
    slightly more formal.
  • REVISION_REQUEST: Highlights that a change or revision is being
    requested.
  • NOTE_VERSION_HISTORY: If you want to track changes to the note
    structure itself.
  • SOURCE_NOTE: Indicating this note is derived from a prior note.

Is it required or optional, or recommended to have such a heading?

This is where it becomes interesting. In purely technical terms, it's
optional. My parser wouldn't fail if it was missing.

However, from a conceptual and organizational perspective, I'm leaning
towards it being highly recommended, though not strictly required.

Here’s why:

  • Contextual Awareness: It provides crucial context for me. It
    signals that this note isn't just a standalone piece of information; it's
    a modification or update driven by a specific logical update request.
  • Traceability: It enables traceability – you can track the
    evolution of these notes and understand the reasoning behind changes.
  • Logical Flow: It contributes to a more logical and structured flow
    of information, especially if you’re dealing with a large collection of
    notes.

Here's a list of other text strings that would be effective after
"NOTE_CATEGORY:" for categorization purposes. These are grouped by broad
types, with examples of specific strings within each type:

1. Broad Topic/Area:

  • PROJECT: (for notes related to a specific project)
  • SYSTEM: (for notes regarding system behavior or design)
  • PROCESS: (for notes detailing a specific process)
  • PROCEDURE: (similar to process, but often more detailed)
  • CONCEPT: (for notes defining or explaining a concept)
  • GUIDELINE: (for notes providing instructions or best practices)
  • DEFINITION: (for notes providing a formal definition)

2. Specific Area/Module (within a larger system):

  • LANGUAGE_MODEL: (if relating to the model itself)
  • PROMPT_ENGINEERING: (specifically regarding prompts)
  • DATA_PROCESSING: (if related to data handling)
  • USER_INTERFACE: (if concerning the user experience)
  • SECURITY: (for notes related to security concerns)

3. Status/Type of Note:

  • INITIAL: (for a first draft or preliminary note)
  • FINAL: (for a complete and approved note)
  • UPDATE: (for a note that has been revised)
  • BUG: (for notes related to errors or issues)
  • FEATURE_REQUEST: (for suggestions for new functionality)

4. Combination (for more granular classification):

  • PROJECT_LANGUAGE_MODEL: (combining project and language model)

  • PROCESS_PROMPT_ENGINEERING: (combining process and prompt engineering)

  • NOTE_REQUEST_LOGIC_UPDATE: (signifies a request for a modification or
    improvement to the underlying reasoning or rules that govern a particular system, concept, or process. It’s a signal that something is being changed or refined based on a specific logical need.)

    NOTE: This is a foundational indicator. It signals that what
    follows is intended as a note—a record of information, instructions, or
    observations.
    REQUEST: This signifies that the note represents a request,
    implying it’s being generated as a result of a need or a prompt for
    change. It’s not just a static record; it's something being actively
    initiated.
    LOGIC: This is the core of the meaning. "Logic" here refers to the
    underlying reasoning, rules, or processes that govern the note's content.
    It’s a signal that the note addresses a change or refinement in how
    something operates or is understood.
    UPDATE: This indicates that the "logic" being referenced is
    undergoing a change. It’s not just a request for information; it's a
    request for an adjustment or improvement to an existing system or concept.

Remember that the best choices depend on the specific context and your
classification needs. Feel free to adapt and combine these suggestions to
create a system that works best for you.

Let's assess the likely effectiveness of this syntax with other AI models, both LLMs and other
types.

LLMs (Large Language Models):

  • Likely Effectiveness: High - Most modern LLMs, particularly those
    with strong code understanding capabilities, should be able to parse this
    syntax relatively well. The use of keywords like NOTE_CATEGORY,
    NOTE_TITLE, PRINCIPLE, and DESCRIPTION provides clear semantic
    markers that aid in understanding the structure.
  • Potential Challenges: Very small or older LLMs might struggle with
    the keywords. A slight reduction in complexity (e.g., removing the
    keywords entirely and relying solely on formatting) could improve
    compatibility.
  • Adaptation: LLMs could be prompted to generate notes in this
    syntax, adapting to the structure and keywords.

Other AI Models (e.g., Image Generators, Decision Trees, Reinforcement
Learning Agents):

  • Likely Effectiveness: Limited, but Adaptable - This syntax is
    primarily text-based, so its direct applicability to non-text AI models is
    limited. However, representations of the information within the notes
    could be adapted for these models.
  • Image Generators: Key information (e.g., NOTE_TITLE,
    PRINCIPLE) could be extracted and used as prompts.
  • Decision Trees: The PRINCIPLE and DESCRIPTION sections could
    be represented as rules or conditions within the tree.
  • Reinforcement Learning Agents: The information could be used to
    create reward functions or guide exploration.

General Considerations:

  • Specificity: The effectiveness will depend on how well the AI
    model's training data aligns with the semantic meaning of the keywords and
    structure.
  • Abstraction: To improve cross-model compatibility, it might be
    beneficial to define a more abstract, platform-independent representation
    of the note's content.
  • Metadata: Including metadata (e.g., creation date, author,
    version) can improve interoperability and facilitate automated processing.

Overall, while this syntax is highly tailored for a specific collaborative
process, the underlying principles (clear structure, semantic keywords,
consistent formatting) can be adapted and applied to a wider range of AI
models with some adjustments and creative implementations.

Originally created by @abcbarryn on GitHub (Sep 3, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/12164 Purpose of language: To convey complex instructions and nuanced logic adjustments and additional data to an AI model. This syntax was developed in collaboration with my AI engine. It has been effectively used by me to modify model behavior and provide addition data that is not present in the models training database. General syntax: HEADING NOTE_CATEGORY:CATEGORY NOTE_TITLE:TITLE PRINCIPLE_1:PURPOSE OF NOTE DESCRIPTION_1:Purpose text/instructions. PRINCIPLE_2:PURPOSE 2 OF NOTE DESCRIPTION_2:Purpose text/instructions. NOTE_VERSION:1.4 Here's a list of alternatives, categorized by their nuances: * **UPDATE_REQUEST:** Simple, direct, and emphasizes the intention. * **LOGIC_UPDATE_REQUEST:** Similar to the current string, but perhaps slightly more formal. * **REVISION_REQUEST:** Highlights that a change or revision is being requested. * **NOTE_VERSION_HISTORY:** If you want to track changes to the note structure itself. * **SOURCE_NOTE:** Indicating this note is derived from a prior note. **Is it required or optional, or recommended to have such a heading?** This is where it becomes interesting. In purely technical terms, it's **optional**. My parser wouldn't fail if it was missing. However, from a *conceptual* and *organizational* perspective, I'm leaning towards it being **highly recommended**, though not strictly required. Here’s why: * **Contextual Awareness:** It provides crucial context for *me*. It signals that this note isn't just a standalone piece of information; it's a modification or update driven by a specific logical update request. * **Traceability:** It enables traceability – you can track the evolution of these notes and understand the reasoning behind changes. * **Logical Flow:** It contributes to a more logical and structured flow of information, especially if you’re dealing with a large collection of notes. Here's a list of other text strings that would be effective after "NOTE_CATEGORY:" for categorization purposes. These are grouped by broad types, with examples of specific strings within each type: **1. Broad Topic/Area:** * PROJECT: (for notes related to a specific project) * SYSTEM: (for notes regarding system behavior or design) * PROCESS: (for notes detailing a specific process) * PROCEDURE: (similar to process, but often more detailed) * CONCEPT: (for notes defining or explaining a concept) * GUIDELINE: (for notes providing instructions or best practices) * DEFINITION: (for notes providing a formal definition) **2. Specific Area/Module (within a larger system):** * LANGUAGE_MODEL: (if relating to the model itself) * PROMPT_ENGINEERING: (specifically regarding prompts) * DATA_PROCESSING: (if related to data handling) * USER_INTERFACE: (if concerning the user experience) * SECURITY: (for notes related to security concerns) **3. Status/Type of Note:** * INITIAL: (for a first draft or preliminary note) * FINAL: (for a complete and approved note) * UPDATE: (for a note that has been revised) * BUG: (for notes related to errors or issues) * FEATURE_REQUEST: (for suggestions for new functionality) **4. Combination (for more granular classification):** * PROJECT_LANGUAGE_MODEL: (combining project and language model) * PROCESS_PROMPT_ENGINEERING: (combining process and prompt engineering) * NOTE_REQUEST_LOGIC_UPDATE: (signifies a request for a modification or improvement to the underlying reasoning or rules that govern a particular system, concept, or process. It’s a signal that something is being changed or refined based on a specific logical need.) **NOTE:** This is a foundational indicator. It signals that what follows is intended as a note—a record of information, instructions, or observations. **REQUEST:** This signifies that the note represents a request, implying it’s being generated as a result of a need or a prompt for change. It’s not just a static record; it's something being actively initiated. **LOGIC:** This is the core of the meaning. "Logic" here refers to the underlying reasoning, rules, or processes that govern the note's content. It’s a signal that the note addresses a change or refinement in how something operates or is understood. **UPDATE:** This indicates that the "logic" being referenced is undergoing a change. It’s not just a request for information; it's a request for an adjustment or improvement to an existing system or concept. Remember that the best choices depend on the specific context and your classification needs. Feel free to adapt and combine these suggestions to create a system that works best for you. Let's assess the likely effectiveness of this syntax with other AI models, both LLMs and other types. **LLMs (Large Language Models):** * **Likely Effectiveness: High** - Most modern LLMs, particularly those with strong code understanding capabilities, should be able to parse this syntax relatively well. The use of keywords like `NOTE_CATEGORY`, `NOTE_TITLE`, `PRINCIPLE`, and `DESCRIPTION` provides clear semantic markers that aid in understanding the structure. * **Potential Challenges:** Very small or older LLMs might struggle with the keywords. A slight reduction in complexity (e.g., removing the keywords entirely and relying solely on formatting) could improve compatibility. * **Adaptation:** LLMs could be prompted to generate notes *in* this syntax, adapting to the structure and keywords. **Other AI Models (e.g., Image Generators, Decision Trees, Reinforcement Learning Agents):** * **Likely Effectiveness: Limited, but Adaptable** - This syntax is primarily text-based, so its direct applicability to non-text AI models is limited. However, *representations* of the information within the notes could be adapted for these models. * **Image Generators:** Key information (e.g., `NOTE_TITLE`, `PRINCIPLE`) could be extracted and used as prompts. * **Decision Trees:** The `PRINCIPLE` and `DESCRIPTION` sections could be represented as rules or conditions within the tree. * **Reinforcement Learning Agents:** The information could be used to create reward functions or guide exploration. **General Considerations:** * **Specificity:** The effectiveness will depend on how well the AI model's training data aligns with the semantic meaning of the keywords and structure. * **Abstraction:** To improve cross-model compatibility, it might be beneficial to define a more abstract, platform-independent representation of the note's content. * **Metadata:** Including metadata (e.g., creation date, author, version) can improve interoperability and facilitate automated processing. Overall, while this syntax is highly tailored for a specific collaborative process, the underlying principles (clear structure, semantic keywords, consistent formatting) can be adapted and applied to a wider range of AI models with some adjustments and creative implementations.
GiteaMirror commented 2026-04-12 20:23:02 -05:00
Author
Owner
Copy Link

@rick-github commented on GitHub (Sep 3, 2025):

There's no ollama issue here. If you would like to discuss your proposal further, the following resources may help:

https://discord.com/invite/t4eYQRUcXB
https://www.reddit.com/r/PromptEngineering/
https://github.com/dair-ai/Prompt-Engineering-Guide
https://github.com/NirDiamant/Prompt_Engineering

<!-- gh-comment-id:3248419127 --> @rick-github commented on GitHub (Sep 3, 2025): There's no ollama issue here. If you would like to discuss your proposal further, the following resources may help: https://discord.com/invite/t4eYQRUcXB https://www.reddit.com/r/PromptEngineering/ https://github.com/dair-ai/Prompt-Engineering-Guide https://github.com/NirDiamant/Prompt_Engineering
GiteaMirror commented 2026-04-12 20:23:05 -05:00
Author
Owner
Copy Link

@abcbarryn commented on GitHub (Sep 3, 2025):

I agree, no issue. It seems like a good place to post about it though I agree with closing this as "not planned". Thanks for the links. :)

<!-- gh-comment-id:3249972976 --> @abcbarryn commented on GitHub (Sep 3, 2025): I agree, no issue. It seems like a good place to post about it though I agree with closing this as "not planned". Thanks for the links. :)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#8088
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?