Marketing Skills
Marketing Skills 源码分析：元数据提取器并非完整 YAML 解析器
通过独立 LF、CRLF 和多行样例检查 sync-skills.js，解释提取元数据与验证技能的区别。
你将学会
- 字面换行匹配使行结束符影响结果。
- 冒号拆分不能实现 YAML 块和嵌套语义。
- 元数据回退可能掩盖不完整解析。
开始前需要
- 基础 Markdown 与仓库导航知识
- 自有页面和事实型产品说明
解释本章流程边界，并核对证据或拟议验收任务。
先看结论
- 字面换行匹配使行结束符影响结果。
- 冒号拆分不能实现 YAML 块和嵌套语义。
- 元数据回退可能掩盖不完整解析。
追踪解析器真正支持的输入
parseFrontmatter 首先匹配起始分隔符和字面的换行，捕获到下一个换行与分隔符之间的文本，然后逐行拆分。遇到冒号就取前后两部分为键和值，修剪空白并移除配对外引号。它没有调用 YAML 库，没有跟踪缩进，也不会组合多行标量。
本次只把所查纯函数提取到独立 JavaScript 上下文执行，没有运行会写入文件的 main。简单 LF 样例按预期返回名称和描述；CRLF 样例返回空对象，因为起始正则不匹配这种换行序列。这描述的是函数输入边界，不是在宣称每个检出目录都会失败。
多行与嵌套暴露了能力边界
对于 description: | 后跟缩进文本的样例，返回的描述只是竖线字符。metadata 下方缩进的 version 变成了顶层 version 键，metadata 自己则变成空字符串。这些结果来自逐行冒号拆分，而合法 YAML 的语义明显比该实现更丰富。
getSkillsWithMetadata 在没有读到名称时使用目录名，没有描述时使用空字符串。因此，技能仍可能显示在生成表格里，但元数据并未被完整理解。README 表格看起来合理，不足以证明全部 frontmatter 都被正确解析；应测试贡献者实际使用的元数据结构。
先限定影响，再提出修复建议
一种更健壮的维护改进是先统一换行，再用支持明确数据结构的解析器，并测试块标量和嵌套元数据。这是拟议的上游改进，不是本次已经提交给外部仓库的修复。还应评估依赖成本与兼容性，而不是悄悄替所有用户修改安装内容。
下方记录保留了三个已观察案例。本地测试检查这些记录及成本章节的算术例子，并没有运行上游 CI、安装器或模型评测。明确这条边界，可以让小规模源码实验提供真实学习价值，而不被夸大成整个项目都经过运行验证。
实施步骤
- 1
在固定源码中定位 parseFrontmatter。
- 2
只隔离函数，不执行 main。
- 3
对比 LF、CRLF 和块标量样例。
- 4
同时检查生成元数据与表格存在性。
可复制示例
{"lf":{"name":"sample","description":"hello"},"crlf":{},"blockScalar":{"name":"sample","description":"|","metadata":"","version":"2.1.0"},"upstreamMainExecuted":false}常见问题
这证明所有安装的技能都坏了吗？
没有。它展示特定解析输入的行为，实际情况取决于文件内容、检出换行和是否运行维护脚本。
是否执行了重写仓库文件的脚本？
没有。仅使用虚构输入字符串执行了独立的 parseFrontmatter 函数。
资料来源
- README.md来源核查 2026-09-08
- LICENSE来源核查 2026-09-08
- .claude-plugin/plugin.json来源核查 2026-09-08
- .github/scripts/sync-skills.js来源核查 2026-09-08
- .github/workflows/sync-skills.yml来源核查 2026-09-08
- .github/workflows/validate-skill.yml来源核查 2026-09-08
- scripts/sync-partners.mjs来源核查 2026-09-08
- skills/product-marketing/SKILL.md来源核查 2026-09-08
- skills/ai-seo/SKILL.md来源核查 2026-09-08
- skills/seo-audit/SKILL.md来源核查 2026-09-08
- skills/programmatic-seo/SKILL.md来源核查 2026-09-08
- skills/ai-seo/evals/evals.json来源核查 2026-09-08
- tools/PARTNERS.md来源核查 2026-09-08