[deanrie]

Problem

Two defects in parseFrontmatter (apps/cursor/src/lib/github-plugin/parse.ts), the parser behind every rule, skill, command and agent imported from GitHub:

1. CRLF files are not parsed. The opening fence accepts ---\r\n, but the closing fence is searched as "\n---\n", which never occurs in a CRLF file ("\r\n---\r\n"). The function returns { data: {}, body: content }, so a Windows-authored component gets its filename as name, the first 200 characters of the raw file (starting with ---\r\nname: ...) as description, and the frontmatter inside its stored content.
2. author: blocks are never read. The key: line is matched by the array branch before the object branch (same regex, earlier in the loop), so data.author is always [] and the indented name:/url:/avatar: lines are dropped. The author_name/author_url/author_avatar metadata the rule importer reads from data.author has therefore never been populated.

Repro on main (function extracted and run with node):

LF  : {"name":"My Rule","description":"Does things","author":[],"tags":["a","b"]}
CRLF: {}   body starts: "---\r\nname: M"

Fix

• Strip the BOM, then normalise \r\n to \n once; everything after that works on LF.
• Accept a closing fence on the last line of the file with no trailing newline (a rule with an empty body).
• A bare key: opens a block; the first indented line decides whether it is a list ( - item) or a mapping ( sub: value). Scalars, quoted values and blank lines inside a block behave as before.

Same output for LF files with scalar and list keys, so existing imports are unchanged; content for CRLF files is now the LF-normalised body.

Verification

Extracted function, node with type stripping, cases: LF, CRLF, BOM + LF, fence on the last line, no frontmatter, empty block followed by a scalar, unterminated fence. CRLF now equals LF; author is { name, url }; tags is ["a","b"]; unterminated fence still returns the whole text as body. tsc --strict on the extracted function is clean and biome format is applied. No open PR changes parseFrontmatter; git merge-tree against #466, #467, #472, #476, #477 and #427 (the open PRs on this file) reports no conflicts.