What happened?
On a Windows checkout with core.autocrlf=true, the native skill-package validators fail for both newly added workbenches even though their SKILL.md frontmatter is valid:
demohouse/car-decision-assistant/scripts/validate-skill-package.mjsdemohouse/sales-intelligence-workbench/scripts/validate-skill-package.mjs
Both validators match the opening frontmatter with a literal LF-only expression (^---\nname: ...\n). Git converts the tracked LF files to CRLF in this checkout, so fs.readFileSync(..., "utf8") returns \r\n and the assertion fails.
How can we reproduce it?
- On Windows, enable Git's standard line-ending conversion:
git config --global core.autocrlf true.
- Clone the repository at current
main (b943185fae20853609fe41d433c73874a251d587).
- In each project, run
npm ci followed by npm run skill:validate.
Both commands fail at the frontmatter assertion. Byte-level checks show the working-tree files contain CRLF, while the Git blobs contain LF; the existing regex matches only the blobs.
What did you expect to happen?
The validators should accept valid frontmatter with either LF or CRLF line endings. Using \r?\n for the two asserted newlines keeps the current LF behavior and permits Windows checkouts without weakening the frontmatter requirement.
Which kind of issue is this?
Demohouse application
Environment
- Windows
- Git 2.51.2.windows.1,
core.autocrlf=true
- Node.js 24.14.1
- npm 11.11.0
What happened?
On a Windows checkout with
core.autocrlf=true, the native skill-package validators fail for both newly added workbenches even though theirSKILL.mdfrontmatter is valid:demohouse/car-decision-assistant/scripts/validate-skill-package.mjsdemohouse/sales-intelligence-workbench/scripts/validate-skill-package.mjsBoth validators match the opening frontmatter with a literal LF-only expression (
^---\nname: ...\n). Git converts the tracked LF files to CRLF in this checkout, sofs.readFileSync(..., "utf8")returns\r\nand the assertion fails.How can we reproduce it?
git config --global core.autocrlf true.main(b943185fae20853609fe41d433c73874a251d587).npm cifollowed bynpm run skill:validate.Both commands fail at the frontmatter assertion. Byte-level checks show the working-tree files contain CRLF, while the Git blobs contain LF; the existing regex matches only the blobs.
What did you expect to happen?
The validators should accept valid frontmatter with either LF or CRLF line endings. Using
\r?\nfor the two asserted newlines keeps the current LF behavior and permits Windows checkouts without weakening the frontmatter requirement.Which kind of issue is this?
Demohouse application
Environment
core.autocrlf=true