fix(prompt-files): avoid crash when <system> tag is unclosed

[Pluviobyte]

Description

parsePromptFile only checks for an opening <system> tag before splitting on the closing one:

if (prompt.includes("<system>")) {
  systemMessage = prompt.split("<system>")[1].split("</system>")[0].trim();
  prompt = prompt.split("</system>")[1].trim();
}

If a .prompt file contains <system> but omits the closing </system> (an easy authoring typo), prompt.split("</system>") returns a single-element array, so [1] is undefined and .trim() throws:

TypeError: Cannot read properties of undefined (reading 'trim')

Because .prompt files are parsed during config / slash-command load, one malformed file breaks loading instead of degrading gracefully.

Fix

Require both <system> and </system> before parsing the system block. An unclosed tag now falls through and the entire body is treated as the prompt (no crash).

Checklist

• I've read the contributing guide
• The relevant docs, if any, have been updated or created
• The relevant tests, if any, have been updated or created

Screen recording or screenshot

N/A — parser crash fix; covered by the new tests.

Tests

Added core/promptFiles/parsePromptFile.vitest.ts covering:

• a well-formed <system>…</system> block (parsed correctly)
• an unclosed <system> tag (no longer throws; whole body kept as the prompt)
• no system block at all

Verified the unclosed case fails on the old code with Cannot read properties of undefined (reading 'trim') and passes with the fix. tsc -p ./ --noEmit reports 0 errors and prettier --check passes locally.

Made with Cursor

---

Summary by cubic

Fix prevents a crash when a .prompt file includes without a closing . The parser now only extracts a system message if both tags are present; otherwise it treats the content as the prompt.

• Bug Fixes
  • Check for both and before parsing to avoid split/trim TypeError.
  • Add tests for closed, unclosed, and no-system cases.

^{Written for commit 84c0f34. Summary will update on new commits.}

Review in cubic

[cubic-dev-ai]

No issues found across 2 files

_{Re-trigger cubic}

[Pluviobyte]

I checked the remaining failing statuses. The GitHub Actions checks are green, but the Continuous AI failure target returns Cannot GET /api/agent-check-summary/..., so there is no actionable failure detail exposed from the external check.

Could a maintainer rerun/waive the Continuous AI statuses or share the specific task output? I can address any concrete finding once the external check exposes it.