OVOS-INTENT-2 v3: the .prompt resource role#4
Conversation
📝 WalkthroughWalkthroughThis PR formalizes two independent specification additions to the OVOS architecture: OVOS-MSG-1 bus message contract (envelope, routing, session, serialization rules) and OVOS-INTENT-2 version 3 ChangesOVOS-MSG-1 Bus Message Specification
OVOS-INTENT-2 Version 3:
Documentation Restructuring and Terminology
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@locale-resource-formats.md`:
- Around line 333-346: The fenced code block containing the Weather assistant
example is missing a language tag which triggers MD040; update the opening fence
from "````" to "````text" so the block is explicitly labelled (i.e., locate the
block that begins with the Weather assistant heading and change its opening
fence to include "text" while leaving the closing fence unchanged).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: d300bd35-7b91-48e6-9f78-af0229a3dcb3
📒 Files selected for processing (5)
APPENDIX.mdCHANGELOG.mdREADME.mdlocale-resource-formats.mdsentence-template-grammar.md
| ```` | ||
| # Weather assistant | ||
|
|
||
| You are a concise weather assistant. Answer the user's question. | ||
|
|
||
| User asked: {query} | ||
|
|
||
| Reply as JSON shaped like {"summary": "...", "temp_c": 0}. The {response} | ||
| placeholder shown in the code block below is illustrative only: | ||
|
|
||
| ``` | ||
| {"summary": "{response}", "temp_c": 18} | ||
| ``` | ||
| ```` |
There was a problem hiding this comment.
Add a language identifier to the fenced example block.
The fenced block starting at Line 333 is missing a language tag (MD040), which can fail docs linting.
Suggested fix
-````
+````text
# Weather assistant
You are a concise weather assistant. Answer the user's question.
@@
{"summary": "{response}", "temp_c": 18}- +
</details>
<!-- suggestion_start -->
<details>
<summary>📝 Committable suggestion</summary>
> ‼️ **IMPORTANT**
> Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
```suggestion
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 333-333: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@locale-resource-formats.md` around lines 333 - 346, The fenced code block
containing the Weather assistant example is missing a language tag which
triggers MD040; update the opening fence from "````" to "````text" so the block
is explicitly labelled (i.e., locate the block that begins with the Weather
assistant heading and change its opening fence to include "text" while leaving
the closing fence unchanged).
…age-object/sentence-template-grammar; PR #4 is locale-resource-formats.md only per 1-file rule
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (6)
GLOSSARY.md (1)
34-34: 💤 Low valueConsider "message bus" (two words) for standard spelling.
The term "messagebus" is flagged by static analysis as non-standard spelling. English convention typically uses "message bus" (two words). Unless "messagebus" is established OVOS-specific terminology that should be preserved, consider updating to the standard spelling.
📝 Proposed fix
-| **Orchestrator** | The component that coordinates intent matching and dispatch — owns the engines / pipeline plugins and routes match results to handlers ([INTENT-3 §6.1](intent-definition.md)). Distinct from the messagebus (transport) and from individual engines / plugins. | +| **Orchestrator** | The component that coordinates intent matching and dispatch — owns the engines / pipeline plugins and routes match results to handlers ([INTENT-3 §6.1](intent-definition.md)). Distinct from the message bus (transport) and from individual engines / plugins. |🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@GLOSSARY.md` at line 34, Update the spelling of "messagebus" to the standard two-word form "message bus" in the Orchestrator glossary entry (the line describing Orchestrator that currently reads "Distinct from the messagebus (transport) ..."); change the token "messagebus" to "message bus" (preserve the surrounding punctuation and parenthetical "(transport)") and scan nearby glossary entries for other occurrences of "messagebus" to make the same replacement for consistency.locale-resource-formats.md (5)
54-56: ⚡ Quick winMinor clarity loss in line 55.
The edited text at line 55 changes from "a developer encodes a set" to "encodes a set", removing the subject. This makes the sentence slightly less clear about who is doing the encoding.
Suggested rewrite for clarity
-developer encodes a set of natural-language phrasings for the assistant to use, and +a developer encodes a set of natural-language phrasings for the assistant to use, andOr alternatively:
-developer encodes a set of natural-language phrasings for the assistant to use, and +how a skill encodes a set of natural-language phrasings for the assistant to use, and🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@locale-resource-formats.md` around lines 54 - 56, The sentence on line 55 dropped the subject and reads unclearly; restore an explicit subject so it's clear who performs the encoding. Update the sentence that references `.entity`, `.voc`, and `.blacklist` (and the surrounding text referring to §4.3) to read something like "they are how a developer encodes a set of natural-language phrasings..." so the subject "a developer" is present and the clause clearly indicates who encodes the phrasings.
388-389: ⚡ Quick winConsider mentioning HTML comment stripping in loader conformance.
The
.promptloader rule states "retain the whole-file string; apply{name}substitution per-render" but doesn't mention HTML comment stripping, which §4.4 (lines 299-307) specifies must occur "before the file is handed to a language model." For completeness, the conformance section should explicitly include comment stripping as part of the render-time processing chain.Suggested addition
- `.prompt` — retain the whole-file string; apply `{name}` substitution - per-render (§4.4). No expander is involved. + per-render (§4.4). At render time, strip HTML comments (`<!-- ... -->`) + per §4.4, then apply `{name}` substitution. No expander is involved.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@locale-resource-formats.md` around lines 388 - 389, The `.prompt` loader rule currently says "retain the whole-file string; apply `{name}` substitution per-render" but omits the HTML comment stripping step required by §4.4; update the `.prompt` loader conformance text to state that HTML comment stripping is performed prior to any per-render `{name}` substitution (i.e., strip HTML comments from the retained whole-file string before handing the content to the language model and before running the substitution), or explicitly add a line in the conformance section mandating HTML comment stripping as part of the render-time processing chain referenced in §4.4.
299-307: 💤 Low valueConsider clarifying comment-stripping algorithm details.
The HTML comment stripping rule specifies behavior for malformed comments but doesn't explicitly state the matching algorithm (e.g., greedy vs. non-greedy, left-to-right order). For multiple separate comments like
<!-- A --> text <!-- B -->, the intended behavior is inferable but not explicit.Suggested clarification
Consider adding one sentence to clarify the matching order:
**Author-only comments.** The one exception to "every character is part of the prompt" is **HTML-style comments**: a substring matching `<!-- … -->` is -**stripped** before the file is handed to a language model. Comments may +**stripped** before the file is handed to a language model. Each `<!--` is +paired with its first subsequent `-->`, left-to-right. Comments may span multiple lines; nesting is not supported.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@locale-resource-formats.md` around lines 299 - 307, Update the comment-stripping section to explicitly specify the matching algorithm: state that HTML-style comments are matched left-to-right and non-greedily (each `<!-- … -->` pair closes at the first subsequent `-->`), so separate comments like `<!-- A --> text <!-- B -->` are treated as two distinct comments; reference the `<!-- … -->` token in the sentence and add it adjacent to the malformed-comment behavior paragraph to make the intended matching order unambiguous.
390-394: 💤 Low valueClarify "content" definition for
.promptempty-file check.Line 392 states "a
.promptwhose content is empty or only whitespace" must be rejected. It's unclear whether "content" refers to the raw file content (before HTML comment stripping) or the effective content (after stripping). Given that comment stripping is render-time processing (§4.4), "content" likely means raw file content, but this could be stated explicitly to avoid ambiguity.Suggested clarification
5. **Reject an empty file** — a resource file of any role MUST be treated as malformed if it is empty: a template role that yields no templates after - step 3, or a `.prompt` whose content is empty or only whitespace. Every + step 3, or a `.prompt` whose raw file content is empty or only whitespace. Every file MUST contribute content.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@locale-resource-formats.md` around lines 390 - 394, Clarify that "content" for the `.prompt` empty-file check refers to the raw file contents before any render-time HTML comment stripping (per §4.4): update the sentence in locale-resource-formats.md so it explicitly reads that a `.prompt` whose raw content (i.e., bytes/text as stored on disk, prior to comment stripping or other render-time processing) is empty or only whitespace must be rejected; keep references to template expansion/OVOS-INTENT-1 §3.6 intact.
325-333: 💤 Low valueFence detection specification is pragmatic but slightly ambiguous.
Lines 327-328 state "Fence detection follows CommonMark" but then immediately allow implementations to "use simpler heuristics." The toggle model described ("opens or closes a fence") is simpler than full CommonMark fence matching (which requires matching fence lengths and characters). This is a reasonable pragmatic choice, but the phrasing could be clearer about the relationship between the normative behavior and the implementation latitude.
Suggested clarification
Consider rephrasing to make the relationship clearer:
3. it does **not** lie inside a fenced code block — text between a pair of ```` ``` ```` fences (CommonMark fenced code block) is literal, so a `{name}` shown as an example inside a code block is never substituted. - Fence detection follows CommonMark: a line whose first non-whitespace + The normative behavior is to follow CommonMark: a line whose first non-whitespace content is three or more backticks opens or closes a fence; an open fence with no closing fence in the file extends to end-of-file. Implementations **MAY** use simpler heuristics (counting triple - backticks) so long as the well-formed cases of §4.4 render identically; + backticks as a toggle) so long as the well-formed cases of §4.4 render identically;🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@locale-resource-formats.md` around lines 325 - 333, Update the paragraph that begins with "Fence detection follows CommonMark" to clearly separate the normative behavior from allowed implementation shortcuts: state that the normative intent is to follow CommonMark (keep the description "a line whose first non-whitespace content is three or more backticks opens or closes a fence; an open fence with no closing fence in the file extends to end-of-file") and then explicitly note that implementations MAY adopt a simpler heuristic (e.g., "counting triple backticks as a toggle") provided well-formed cases in §4.4 render identically; specifically edit the sentence containing "Fence detection follows CommonMark" and the following sentence referencing "Implementations MAY use simpler heuristics" to adopt the suggested phrasing and wording about "normative behavior" and "simpler heuristics (counting triple backticks as a toggle)" so the relationship is unambiguous.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@GLOSSARY.md`:
- Line 24: Update the glossary entry for "Resource file / role" to include the
missing `.prompt` resource role so it matches INTENT-2 §1; locate the line
containing the list of extensions (`.intent`, `.dialog`, `.entity`, `.voc`,
`.blacklist`) and add `.prompt` to that list and accompanying parenthetical
reference to the INTENT-2 section if present, ensuring the text now reads that a
skill's plain-text files include `.intent`, `.dialog`, `.entity`, `.voc`,
`.blacklist`, and `.prompt`.
In `@README.md`:
- Line 63: Update the specifications table entry for "OVOS-INTENT-2" to show
version 3 instead of 2 to match the PR and the changes in
locale-resource-formats.md; locate the table row containing the symbol
"OVOS-INTENT-2" (the line with "| OVOS-INTENT-2 | [Locale Resource
Formats](locale-resource-formats.md) | 2 | Draft |") and change the version cell
from "2" to "3", and verify the linked document locale-resource-formats.md also
reflects v3 so the README remains consistent.
---
Nitpick comments:
In `@GLOSSARY.md`:
- Line 34: Update the spelling of "messagebus" to the standard two-word form
"message bus" in the Orchestrator glossary entry (the line describing
Orchestrator that currently reads "Distinct from the messagebus (transport)
..."); change the token "messagebus" to "message bus" (preserve the surrounding
punctuation and parenthetical "(transport)") and scan nearby glossary entries
for other occurrences of "messagebus" to make the same replacement for
consistency.
In `@locale-resource-formats.md`:
- Around line 54-56: The sentence on line 55 dropped the subject and reads
unclearly; restore an explicit subject so it's clear who performs the encoding.
Update the sentence that references `.entity`, `.voc`, and `.blacklist` (and the
surrounding text referring to §4.3) to read something like "they are how a
developer encodes a set of natural-language phrasings..." so the subject "a
developer" is present and the clause clearly indicates who encodes the
phrasings.
- Around line 388-389: The `.prompt` loader rule currently says "retain the
whole-file string; apply `{name}` substitution per-render" but omits the HTML
comment stripping step required by §4.4; update the `.prompt` loader conformance
text to state that HTML comment stripping is performed prior to any per-render
`{name}` substitution (i.e., strip HTML comments from the retained whole-file
string before handing the content to the language model and before running the
substitution), or explicitly add a line in the conformance section mandating
HTML comment stripping as part of the render-time processing chain referenced in
§4.4.
- Around line 299-307: Update the comment-stripping section to explicitly
specify the matching algorithm: state that HTML-style comments are matched
left-to-right and non-greedily (each `<!-- … -->` pair closes at the first
subsequent `-->`), so separate comments like `<!-- A --> text <!-- B -->` are
treated as two distinct comments; reference the `<!-- … -->` token in the
sentence and add it adjacent to the malformed-comment behavior paragraph to make
the intended matching order unambiguous.
- Around line 390-394: Clarify that "content" for the `.prompt` empty-file check
refers to the raw file contents before any render-time HTML comment stripping
(per §4.4): update the sentence in locale-resource-formats.md so it explicitly
reads that a `.prompt` whose raw content (i.e., bytes/text as stored on disk,
prior to comment stripping or other render-time processing) is empty or only
whitespace must be rejected; keep references to template expansion/OVOS-INTENT-1
§3.6 intact.
- Around line 325-333: Update the paragraph that begins with "Fence detection
follows CommonMark" to clearly separate the normative behavior from allowed
implementation shortcuts: state that the normative intent is to follow
CommonMark (keep the description "a line whose first non-whitespace content is
three or more backticks opens or closes a fence; an open fence with no closing
fence in the file extends to end-of-file") and then explicitly note that
implementations MAY adopt a simpler heuristic (e.g., "counting triple backticks
as a toggle") provided well-formed cases in §4.4 render identically;
specifically edit the sentence containing "Fence detection follows CommonMark"
and the following sentence referencing "Implementations MAY use simpler
heuristics" to adopt the suggested phrasing and wording about "normative
behavior" and "simpler heuristics (counting triple backticks as a toggle)" so
the relationship is unambiguous.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3d1197d5-cd1c-4eb4-bbf6-f14dfef1e245
📒 Files selected for processing (7)
APPENDIX.mdCHANGELOG.mdGLOSSARY.mdREADME.mdintent-definition.mdlocale-resource-formats.mdmessage-object.md
✅ Files skipped from review due to trivial changes (1)
- intent-definition.md
| | **Sample / sample set** | A concrete sentence produced by expansion; the set of all of them for a template ([INTENT-1 §4](sentence-template-grammar.md)). | | ||
| | **Slot** | A named placeholder `{name}` filled with a value rather than written out ([INTENT-1 §3.4, §5](sentence-template-grammar.md)). | | ||
| | **Capture map** | The names→values mapping a match produces — slot names or vocabulary names as keys ([INTENT-3 §7](intent-definition.md)). | | ||
| | **Resource file / role** | A skill's plain-text files: `.intent`, `.dialog`, `.entity`, `.voc`, `.blacklist` ([INTENT-2 §1](locale-resource-formats.md)). | |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if locale-resource-formats.md §1 lists .prompt as a role
rg -n -A 10 -B 2 '^\s*##\s*1\.' locale-resource-formats.md | head -30Repository: OpenVoiceOS/architecture
Length of output: 557
Add .prompt to the resource role list in GLOSSARY.md
GLOSSARY.md lists only .intent, .dialog, .entity, .voc, and .blacklist, but INTENT-2 §1 defines prompt as one of the supported file formats, so the glossary entry should include the .prompt role to match the PR’s stated “sixth resource role.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@GLOSSARY.md` at line 24, Update the glossary entry for "Resource file / role"
to include the missing `.prompt` resource role so it matches INTENT-2 §1; locate
the line containing the list of extensions (`.intent`, `.dialog`, `.entity`,
`.voc`, `.blacklist`) and add `.prompt` to that list and accompanying
parenthetical reference to the INTENT-2 section if present, ensuring the text
now reads that a skill's plain-text files include `.intent`, `.dialog`,
`.entity`, `.voc`, `.blacklist`, and `.prompt`.
| | ID | Document | Version | Status | | ||
| |----|----------|---------|--------| | ||
| | OVOS-INTENT-1 | [Sentence Template Grammar](sentence-template-grammar.md) | 2 | Draft | | ||
| | OVOS-INTENT-2 | [Locale Resource Formats](locale-resource-formats.md) | 2 | Draft | |
There was a problem hiding this comment.
Version inconsistency: OVOS-INTENT-2 should show version 3.
The PR objectives explicitly state "This PR proposes adding a sixth resource role to OVOS-INTENT-2: the .prompt file, advancing the spec to version 3", but the specifications table shows version 2. According to the review stack context, this PR includes locale-resource-formats.md changes that bump INTENT-2 to v3, so this table entry should reflect that version.
📝 Proposed fix
-| OVOS-INTENT-2 | [Locale Resource Formats](locale-resource-formats.md) | 2 | Draft |
+| OVOS-INTENT-2 | [Locale Resource Formats](locale-resource-formats.md) | 3 | Draft |📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| | OVOS-INTENT-2 | [Locale Resource Formats](locale-resource-formats.md) | 2 | Draft | | |
| | OVOS-INTENT-2 | [Locale Resource Formats](locale-resource-formats.md) | 3 | Draft | |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` at line 63, Update the specifications table entry for
"OVOS-INTENT-2" to show version 3 instead of 2 to match the PR and the changes
in locale-resource-formats.md; locate the table row containing the symbol
"OVOS-INTENT-2" (the line with "| OVOS-INTENT-2 | [Locale Resource
Formats](locale-resource-formats.md) | 2 | Draft |") and change the version cell
from "2" to "3", and verify the linked document locale-resource-formats.md also
reflects v3 so the README remains consistent.
…OVOS §4.4 .prompt: - Author-only comments via HTML-style <!-- … --> stripped before the prompt reaches the model. Multi-line allowed, no nesting. Unmatched <!-- is malformed. - Fenced-code-block detection clarified as CommonMark-aligned; simpler heuristics permitted as long as well-formed §4.4 cases render identically. Pathological inputs implementation-defined. Prose: strip 'OVOS' project name from two §1 / §4.3 sentences. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1a4db44 to
34b7d0a
Compare
* docs: README — full spec-set refresh for the in-flight stack Update the README to reflect the full spec set landing together: the original intent stack (INTENT-1/-2/-3, MSG-1) plus the in-flight specs (INTENT-4, SESSION-1, SESSION-2, PIPELINE-1, TRANSFORM-1, CONTEXT-1, CONVERSE-1). Changes: - Specification table reorganised into three stacks — intent, bus, orchestrator — each with a one-paragraph narrative. This is the structure APPENDIX §1.2 already uses; the README now mirrors it for consistency. - New 'Where to start' section with four reading-order paths matching common audiences: skill author, plugin author, orchestrator author, architecture surveyor. Addresses the 'no clear entry point' friction first-time readers hit when the set went from 4 to 11 specs. - New 'How this compares to other voice frameworks' section summarising APPENDIX §2's positioning (Home Assistant / hassil, Rasa, Alexa / Dialogflow, Rhasspy / Hermes, Wyoming). Brief; points at APPENDIX for detail. - Reference-implementation section split: ovos-spec-tools covers the intent stack; bus and orchestrator stacks are acknowledged as not-yet-having-ground-up-reference-impl with pointer to APPENDIX §5 divergence catalogue. - New 'Implementation status' section: clarifies the spec-set Draft→stable transition is tracked at #5; intent stack is most aligned with current ovos-core; known gaps cited from APPENDIX §7. - Contributing section adds the one-file-per-PR rule (per AGENTS.md repo convention) and clarifies dev vs master targeting. - Updated draft warning to reference APPENDIX §5 divergence catalogue and link to #5. No normative-spec changes; README and supporting-metadata only. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * README: establish voice OS framing; add OS-analogy table Replace "voice assistant ecosystem" opening with "voice operating system" framing. Add "What a voice operating system is" section with OS-analogy table (scheduler, IPC, shared memory, process supervision, loadable modules, syscall ABI) and the portability consequence. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * README: full spec table — three stacks, open PR links Split specs into intent / bus / orchestrator stacks. Add all 11 specs including in-review ones (INTENT-4 #9, INTENT-2 v3 #4, TRANSFORM-1 #20, CONTEXT-1 #18, CONVERSE-1 #25). Add role-based reading order. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
.prompt resource role (OVOS-INTENT-2 v3)
Companion issue: #6
Summary
Adds a sixth resource role to OVOS-INTENT-2, taking the spec to version 3. Additive over v2.
What
.promptisA
.promptfile lives underlocale/<lang>/like any other localized resource. It differs from.dialogin three deliberate ways:#lines and blank lines included){name}substitution{name}substituted only when well-formed, caller-supplied, and not inside a fenced code block (CommonMark-aligned fence detection). HTML<!-- … -->comments stripped. Unfilled slots left as literal textCompatibility
V3 is additive over V2: a V2 tool that does not recognise
.promptskips it.