Back to Details

skill-forge

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

skill-forge

skill-forge

Generate production-ready AbsolutelySkilled skills from any source - GitHub repos, documentation URLs, or pure domain knowledge (marketing, sales, TypeScript, design patterns, etc.). This is the bootstrapping tool for the registry.
从任意来源生成可投入生产的AbsolutelySkilled skill：GitHub仓库、文档URL或纯领域知识（如营销、销售、TypeScript、设计模式等）。这是注册表的引导工具。

Slash command

斜杠命令

Register as a slash command:
/skill-forge <url-or-topic>
Where 
<url-or-topic>
is a GitHub repo URL, docs site URL, or a domain topic (e.g. "marketing", "typescript", "sales", "design-patterns").
注册为斜杠命令：
/skill-forge <url-or-topic>
其中
<url-or-topic>
可以是GitHub仓库URL、文档站点URL，或是领域主题（例如"marketing"、"typescript"、"sales"、"design-patterns"）。

Step 0 - Detect input type

步骤0 - 检测输入类型

Classify the input to determine which Phase 1 path to follow:
  • URL input (starts with 
    http
    , 
    github.com
    , or looks like a domain) -> Phase 1A (doc crawl)
  • Domain topic (a word or phrase like "marketing", "sales strategy", "typescript best practices") -> Phase 1B (brainstorm discovery)
If ambiguous, ask the user: "Is this a URL I should crawl, or a domain topic I should brainstorm with you about?"
对输入进行分类，以确定要遵循的阶段1路径：
  • URL输入（以
    http
    、
    github.com
    开头，或类似域名格式）-> 阶段1A（文档爬取）
  • 领域主题（单个单词或短语，如"marketing"、"sales strategy"、"typescript best practices"）-> 阶段1B（头脑风暴探索）
若输入存在歧义，请询问用户：“这是我应该爬取的URL，还是我应该与你头脑风暴的领域主题？”

Phase 1A - Research (URL-based)

阶段1A - 调研（基于URL）

Before writing a single line of SKILL.md, do a thorough crawl. The quality of the skill is entirely determined by the depth of research here.
在编写任何SKILL.md内容之前，先进行全面爬取。skill的质量完全取决于此处的调研深度。

1A.1 Crawl order (priority high to low)

1A.1 爬取优先级（从高到低）

For every URL provided, attempt to fetch these in order. Stop fetching a category once you have good coverage - don't fetch 20 pages if 5 give you the full picture.
1. /llms.txt          - curated AI-readable doc map (gold if it exists)
2. /llms-full.txt     - extended version with full content
3. README.md          - top-level overview, install, quickstart
4. /docs or /docs/    - main documentation index
5. API reference      - endpoints, parameters, error codes
6. Guides / tutorials - real-world usage patterns
7. Changelog          - recent breaking changes, versioning info
8. GitHub repo        - if given a docs URL, find the repo too
对于每个提供的URL，尝试按以下顺序获取内容。一旦某类内容覆盖足够信息，就停止获取该类内容——如果5个页面就能完整呈现信息，无需获取20个页面。
1. /llms.txt          - 经过整理的AI可读文档映射（如果存在，就是黄金资源）
2. /llms-full.txt     - 包含完整内容的扩展版本
3. README.md          - 顶层概述、安装说明、快速入门
4. /docs 或 /docs/    - 主文档索引
5. API参考文档      - 端点、参数、错误码
6. 指南/教程 - 实际使用模式
7. 更新日志          - 近期重大变更、版本控制信息
8. GitHub仓库        - 如果提供的是文档URL，同时找到对应的仓库

1A.2 For GitHub repos specifically

1A.2 针对GitHub仓库的特殊处理

github.com/org/repo  ->  fetch in this order:
  /README.md
  /docs/ (index any .md files found)
  /CHANGELOG.md or /CHANGELOG
  Any file named llms.txt, llms-full.txt, or ai-docs.md at root
  Look for /docs/api/ or similar for API reference
github.com/org/repo  ->  按以下顺序获取：
  /README.md
  /docs/（索引所有找到的.md文件）
  /CHANGELOG.md 或 /CHANGELOG
  根目录下任何名为llms.txt、llms-full.txt或ai-docs.md的文件
  查找/docs/api/或类似路径获取API参考文档

1A.3 Discovery heuristics

1A.3 探索启发式规则

While crawling, build a mental model by answering these six questions:
  1. What does this tool do? (1 sentence)
  2. Who uses it? (developers, data scientists, devops, etc.)
  3. What are the 5-10 most common tasks someone would use an agent to do with this tool?
  4. What are the gotchas? (auth patterns, rate limits, pagination, SDK quirks, version differences)
  5. What's the install/auth story? (env vars, API keys, SDK vs REST)
  6. Are there multiple sub-domains? (e.g. Stripe has Payments, Billing, Connect, Radar - each might need a separate references/ file)
在爬取过程中，通过回答以下六个问题构建心智模型：
  1. 这个工具的功能是什么？（一句话概括）
  2. 谁会使用它？（开发者、数据科学家、DevOps等）
  3. 用户使用Agent借助该工具完成的5-10项最常见任务是什么？
  4. 有哪些注意事项？（认证模式、速率限制、分页、SDK特性、版本差异）
  5. 安装/认证流程是怎样的？（环境变量、API密钥、SDK vs REST）
  6. 是否存在多个子领域？（例如Stripe包含支付、账单、Connect、Radar——每个子领域可能需要单独的references/文件）

1A.4 Uncertainty handling

1A.4 不确定性处理

When the docs are ambiguous or missing detail, make a best guess and flag it with an inline comment. Never leave a section blank or skip it.
Use this comment syntax inside SKILL.md:
markdown
<!-- VERIFY: Could not confirm from official docs - best guess based on
     common SDK patterns. Source: https://... -->
Aim for < 5 flagged items per skill. If you're flagging more than 5, you haven't crawled enough - go back and fetch more pages.
当文档内容模糊或缺失细节时，做出合理猜测并使用内联注释标记。切勿留白或跳过任何章节。
在SKILL.md中使用以下注释语法：
markdown
<!-- VERIFY: 无法从官方文档确认 - 基于常见SDK模式的合理猜测。来源：https://... -->
每个skill的标记项应少于5个。如果标记项超过5个，说明爬取不够充分——返回去获取更多页面。

Phase 1B - Brainstorm Discovery (domain-based)

阶段1B - 头脑风暴探索（基于领域）

For domain topics without a single canonical URL, run an interactive brainstorm session with the user. Use the brainstorming skill's approach: ask questions one at a time, explore scope, then synthesize.
<HARD-GATE> Do NOT write any SKILL.md content until the brainstorm is complete and the user has approved the scope. Even "obvious" topics need scoping - "TypeScript" could mean best practices, advanced patterns, migration guides, or project setup. </HARD-GATE>
对于没有单一权威URL的领域主题，与用户开展交互式头脑风暴会话。采用头脑风暴skill的方法：逐个提问，探索范围，然后进行综合。
<HARD-GATE> 在头脑风暴完成且用户确认范围之前，**切勿**编写任何SKILL.md内容。即使是“显而易见”的主题也需要明确范围——“TypeScript”可能指最佳实践、高级模式、迁移指南或项目搭建。 </HARD-GATE>

1B.1 Scope the domain

1B.1 确定领域范围

Ask these questions one at a time (prefer multiple choice when possible):
  1. What's the target audience? Who will use this skill - beginners, senior engineers, marketers, sales reps, designers?
  2. What's the scope? Is this broad (all of marketing) or narrow (email marketing campaigns)? Offer 2-3 scope options with your recommendation.
  3. What are the 5-8 most important things an agent should know to be genuinely useful in this domain? Ask the user to list or confirm your proposal.
  4. What are the common mistakes people make in this domain that the skill should prevent?
  5. Are there sub-domains that deserve their own references/ files? E.g. "marketing" might split into content-marketing, paid-ads, analytics.
  6. What's the output format? Will the agent produce code, prose, templates, checklists, strategies, or a mix?
逐个提出以下问题（尽可能提供选择题选项）：
  1. 目标受众是谁？ 谁会使用这个skill——初学者、资深工程师、营销人员、销售代表、设计师？
  2. 范围是什么？ 是宽泛的（整个营销领域）还是狭窄的（电子邮件营销活动）？提供2-3个范围选项并给出你的推荐。
  3. Agent要真正在该领域发挥作用，必须了解的5-8项最重要内容是什么？ 请用户列出或确认你的提议。
  4. 人们在该领域常犯的错误有哪些？skill应如何避免这些错误？
  5. 是否存在值得单独创建references/文件的子领域？ 例如“营销”可能分为内容营销、付费广告、数据分析。
  6. 输出格式是什么？ Agent会生成代码、散文、模板、清单、策略，还是混合格式？

1B.2 Propose skill structure

1B.2 提出skill结构方案

After gathering answers, present a proposed skill outline to the user:
Proposed skill: <name>
Target audience: <who>
Scope: <what's in, what's out>

SKILL.md sections:
  1. Overview
  2. When to use
  3. Key principles (replaces "Setup & auth" for non-code skills)
  4. Core concepts / mental model
  5. Common tasks (5-8)
  6. Anti-patterns / common mistakes
  7. References

references/ files:
  - <topic-1>.md
  - <topic-2>.md
Wait for the user to approve or revise before proceeding.
收集答案后，向用户展示提议的skill大纲：
提议的skill：<名称>
目标受众：<人群>
范围：<包含内容，排除内容>

SKILL.md章节：
  1. 概述
  2. 使用场景
  3. 核心原则（替代非代码skill的“安装与认证”）
  4. 核心概念/心智模型
  5. 常见任务（5-8项）
  6. 反模式/常见错误
  7. 参考资料

references/文件：
  - <主题1>.md
  - <主题2>.md
等待用户批准或修改后再继续。

1B.3 Gather domain knowledge

1B.3 收集领域知识

Once scope is approved, build the skill content from:
  1. Your training knowledge - leverage what you know about the domain
  2. Web research (optional) - if the user points to specific articles, frameworks, or methodologies, fetch those URLs
  3. User expertise - ask follow-up questions on specifics where your knowledge might be generic or outdated
范围确认后，从以下来源构建skill内容：
  1. 你的训练知识 - 利用你对该领域的了解
  2. 网络调研（可选）- 如果用户指向特定文章、框架或方法论，获取这些URL的内容
  3. 用户专业知识 - 针对你的知识可能过于通用或过时的细节，提出后续问题

1B.4 Uncertainty handling

1B.4 不确定性处理

Same as 1A.4 - use 
<!-- VERIFY -->
comments for uncertain claims. For domain skills, flag things like:
markdown
<!-- VERIFY: This conversion rate benchmark (2-5% for email) is based on
     general industry data. May vary significantly by vertical. -->
与1A.4相同——对不确定的声明使用
<!-- VERIFY -->
注释。对于领域skill，标记如下内容：
markdown
<!-- VERIFY: 此转化率基准（电子邮件为2-5%）基于通用行业数据。不同垂直领域可能差异显著。 -->

Phase 2 - Write SKILL.md

阶段2 - 编写SKILL.md

Write the canonical SKILL.md using the required schema and structure. Every section is required unless marked optional.
使用要求的架构和结构编写标准SKILL.md。除非标记为可选，否则所有章节都是必填的。

Frontmatter

前置元数据

See 
references/frontmatter-schema.md
for the full YAML template, description writing guidelines, and category taxonomy.
Key rules:
  • name
    : kebab-case tool name
  • version
    : start at 
    0.1.0
  • description
    : one tight paragraph answering what triggers this skill, what the tool does, and the 3-5 most common agent tasks. This is the PRIMARY triggering mechanism - be specific. Include tool name, common synonyms, and key verbs.
  • All other fields: see the reference file for the complete list
查看
references/frontmatter-schema.md
获取完整YAML模板、描述撰写指南和分类体系。
关键规则：
  • name
    ：短横线命名法的工具名称
  • version
    ：从
    0.1.0
    开始
  • description
    ：一段简洁的文字，回答触发该skill的条件、工具功能，以及3-5项最常见的Agent任务。这是主要触发机制——请具体说明。包含工具名称、常见同义词和关键动词。
  • 所有其他字段：请查看参考文件获取完整列表

Recommended skills

推荐skill

After writing the core frontmatter, add companion skill recommendations:
  1. Read 
    references/skill-registry.md
    to find skills in the same or adjacent categories
  2. Pick 2-5 skills that a user of this skill would logically also benefit from
  3. Add the field after 
    tags
    : 
    recommended_skills: [skill-1, skill-2, ...]
  4. Only recommend skills that exist in the registry - never invent skill names
  5. Prefer skills that are complementary (not duplicative) - e.g. code-review pairs with clean-code, not with another review skill
编写核心前置元数据后，添加配套skill推荐：
  1. 阅读
    references/skill-registry.md
    找到相同或相邻分类的skill
  2. 挑选2-5个该skill用户可能也会受益的skill
  3. 在
    tags
    字段后添加：
    recommended_skills: [skill-1, skill-2, ...]
  4. 仅推荐注册表中已存在的skill——切勿自创skill名称
  5. 优先选择互补而非重复的skill——例如代码审查与简洁代码skill搭配，而非与另一个审查skill搭配

Body structure

主体结构

See 
references/body-structure-template.md
for the full markdown scaffold with target lengths per section.
Required sections in order (adapt based on skill type):
For URL-based / code skills:
  1. Title + overview paragraph (3-5 sentences, distinct from frontmatter description)
  2. When to use this skill (5-8 trigger bullets + 2 anti-triggers)
  3. Setup and authentication (env vars, install, basic init)
  4. Core concepts (2-5 paragraphs on the domain model)
  5. Common tasks (5-8 subsections with working code examples)
  6. Error handling (3-5 most common errors in a table)
  7. References (pointer to references/ folder with when-to-read guidance)
For domain-based / knowledge skills:
  1. Title + overview paragraph (3-5 sentences)
  2. When to use this skill (5-8 trigger bullets + 2 anti-triggers)
  3. Key principles (replaces "Setup & auth" - 3-5 foundational rules of the domain)
  4. Core concepts / mental model (the domain's key entities and how they relate)
  5. Common tasks (5-8 subsections - may use prose, templates, checklists, or frameworks instead of code examples)
  6. Anti-patterns / common mistakes (replaces "Error handling" - what to avoid)
  7. References (pointer to references/ folder with when-to-read guidance)
Principles:
  • For code skills: all code examples must be syntactically valid
  • For domain skills: all advice must be actionable, not generic platitudes
  • Use imperative/infinitive form throughout
  • Keep SKILL.md under 300 lines when possible (hard limit 500)
  • If approaching 300 lines, move detail to references/ files
  • Always append the shared footer from 
    references/skill-footer.md
    as the very last section of SKILL.md. Copy the footer block verbatim - do not modify it.
查看
references/body-structure-template.md
获取完整的Markdown框架，以及各章节的目标长度。
按顺序排列的必填章节（根据skill类型调整）：
基于URL/代码类skill：
  1. 标题+概述段落（3-5句话，与前置元数据描述区分开）
  2. 使用场景（5-8个触发项+2个非触发项）
  3. 安装与认证（环境变量、安装说明、基础初始化）
  4. 核心概念（2-5段关于领域模型的内容）
  5. 常见任务（5-8个子章节，包含可运行的代码示例）
  6. 错误处理（3-5个最常见错误，以表格形式呈现）
  7. 参考资料（指向references/文件夹，并说明何时需要阅读）
基于领域/知识类skill：
  1. 标题+概述段落（3-5句话）
  2. 使用场景（5-8个触发项+2个非触发项）
  3. 核心原则（替代“安装与认证”——3-5项该领域的基础规则）
  4. 核心概念/心智模型（领域的关键实体及其关联）
  5. 常见任务（5-8个子章节——可使用散文、模板、清单或框架，而非代码示例）
  6. 反模式/常见错误（替代“错误处理”——需要避免的内容）
  7. 参考资料（指向references/文件夹，并说明何时需要阅读）
原则：
  • 对于代码类skill：所有代码示例必须语法有效
  • 对于领域类skill：所有建议必须可执行，而非通用陈词滥调
  • 全程使用祈使/不定式形式
  • 尽可能将SKILL.md控制在300行以内（硬限制为500行）
  • 如果接近300行，将细节移至references/文件
  • 始终将
    references/skill-footer.md
    中的共享页脚作为SKILL.md的最后一个章节。直接复制页脚内容——请勿修改。

Phase 3 - Write references/

阶段3 - 编写references/

For any sub-domain too detailed for the main SKILL.md body, create a focused file in 
references/
. Each file should be:
  • Under 400 lines
  • Focused on one topic (auth, webhooks, a specific API sub-section, etc.)
  • Fetched only when relevant (agent loads it on demand)
When to create a references/ file:
  • The topic has more than ~10 API endpoints
  • The topic requires its own mental model (e.g. Stripe Connect vs Stripe Payments)
  • It would bloat SKILL.md past 300 lines if included inline
Naming:
references/
  api.md          - core REST/GraphQL API reference
  webhooks.md     - event payloads and verification
  auth.md         - detailed auth flows (if complex)
  <feature>.md    - any major sub-feature
Header comment - every references file must start with:
markdown
<!-- Part of the <ToolName> AbsolutelySkilled skill. Load this file when
     working with <topic>. -->
对于任何过于详细、不适合放入主SKILL.md主体的子领域，在references/中创建聚焦的文件。每个文件应：
  • 少于400行
  • 聚焦单个主题（认证、Webhook、特定API子章节等）
  • 仅在相关时加载（Agent按需加载）
何时创建references/文件：
  • 主题包含超过约10个API端点
  • 主题需要自己的心智模型（例如Stripe Connect vs Stripe Payments）
  • 如果内联包含会使SKILL.md超过300行
命名规则：
references/
  api.md          - 核心REST/GraphQL API参考
  webhooks.md     - 事件负载与验证
  auth.md         - 详细认证流程（如果复杂）
  <功能>.md    - 任何主要子功能
头部注释 - 每个references文件必须以以下内容开头：
markdown
<!-- 属于<ToolName> AbsolutelySkilled skill。在处理<主题>时加载此文件。 -->

Phase 4 - Write evals.json

阶段4 - 编写evals.json

Write a test suite that validates the skill works correctly. Each eval tests whether an agent using this skill can answer a real question correctly.
See 
references/evals-schema.md
for the full JSON schema, assertion types, and a worked example eval entry.
Coverage targets - write 10-15 evals covering:
TypeCountWhat to test
Trigger test2-3Does the skill activate for on-topic prompts?
Core task4-5Can it produce correct code for the main tasks?
Gotcha / edge case2-3Does it handle auth errors, pagination, rate limits?
Anti-hallucination1-2Does it avoid inventing API methods that don't exist?
References load1Does it correctly reference a references/ file?
编写测试套件，验证skill是否正常工作。每个测试用例验证使用该skill的Agent能否正确回答真实问题。
查看
references/evals-schema.md
获取完整JSON架构、断言类型和示例测试用例。
覆盖目标 - 编写10-15个测试用例，涵盖：
类型数量测试内容
触发测试2-3skill是否针对相关提示激活？
核心任务4-5能否为主要任务生成正确代码？
注意事项/边缘情况2-3能否处理认证错误、分页、速率限制？
反幻觉1-2能否避免虚构不存在的API方法？
参考资料加载1能否正确引用references/文件？

Phase 5 - Write sources.yaml

阶段5 - 编写sources.yaml

Track crawl provenance so humans can verify and update the skill later.
See 
references/sources-schema.md
for the full YAML schema. Key rules:
  • All URLs must be from official documentation only
  • No Stack Overflow, blog posts, or community wikis
  • One entry per source crawled with 
    type
    , 
    description
    , and 
    accessed
    date
For domain-based skills: sources.yaml is optional. If you fetched specific URLs during Phase 1B.3, include them. If the skill is purely from training knowledge and user input, omit sources.yaml entirely.
跟踪爬取来源，以便后续人工验证和更新skill。
查看
references/sources-schema.md
获取完整YAML架构。关键规则：
  • 所有URL必须来自官方文档
  • 不包含Stack Overflow、博客文章或社区维基
  • 每个爬取来源对应一个条目，包含
    type
    、
    description
    和
    accessed
    日期
对于领域类skill： sources.yaml是可选的。如果在阶段1B.3中获取了特定URL，请包含它们。如果skill完全基于训练知识和用户输入，则可以省略sources.yaml。

Phase 6 - Output structure

阶段6 - 输出结构

Always write output to 
skills/<skill-name>/
in the project root. This is the canonical location for all skills - never use a temporary output directory.
skills/<skill-name>/
  SKILL.md           <- canonical skill (Phase 2)
  sources.yaml       <- crawl provenance (Phase 5, optional for domain skills)
  evals.json         <- test suite (Phase 4)
  references/        <- deep reference files (Phase 3, if needed)
    <topic>.md
Print a summary when done:
Skill generated: <tool-name>/

  SKILL.md          <N> lines
  sources.yaml      <N> sources crawled
  evals.json        <N> evals written
  references/       <N> files

Flagged items requiring human review:
  1. SKILL.md:47  - webhook signature verification method unconfirmed
  2. evals.json:23 - rate limit value (100 req/min) is a best guess

Recommendation graph updated:
  - api-design: added <tool-name>
  - microservices: added <tool-name> (replaced <old-skill>)
  - backend-engineering: skipped (already at 5 recommendations)

Next steps:
  1. Review flagged items above
  2. Open a PR to github.com/AbsolutelySkilled/skills
始终将输出写入项目根目录的
skills/<skill-name>/
。这是所有skill的标准位置——切勿使用临时输出目录。
skills/<skill-name>/
  SKILL.md           <- 标准skill（阶段2）
  sources.yaml       <- 爬取来源（阶段5，领域类skill可选）
  evals.json         <- 测试套件（阶段4）
  references/        <- 深度参考文件（阶段3，如有需要）
    <主题>.md
完成后打印摘要：
已生成skill：<tool-name>/

  SKILL.md          <N>行
  sources.yaml      已爬取<N>个来源
  evals.json        已编写<N>个测试用例
  references/       <N>个文件

需要人工审核的标记项：
  1. SKILL.md:47  - Webhook签名验证方法未确认
  2. evals.json:23 - 速率限制值（100请求/分钟）为合理猜测

推荐关系图已更新：
  - api-design: 添加<tool-name>
  - microservices: 添加<tool-name>（替换<old-skill>）
  - backend-engineering: 跳过（已达5个推荐）

后续步骤：
  1. 审核上述标记项
  2. 向github.com/AbsolutelySkilled/skills提交PR

Phase 7 - Propagate recommended_skills

阶段7 - 同步推荐skill

After creating or heavily modifying a skill, update the recommendation graph so existing skills can also recommend the new/modified one.
创建或大幅修改skill后，更新推荐关系图，使现有skill也能推荐新/修改后的skill。

When to run

运行时机

  • New skill created: always run this phase
  • Major skill modification (renamed, merged, or scope changed significantly): run this phase to update any stale references
  • 创建新skill：始终运行此阶段
  • 大幅修改skill（重命名、合并或范围显著变更）：运行此阶段以更新任何过时的引用

Steps

步骤

  1. Read the new skill's 
    recommended_skills
    field to identify its companions
  2. For each companion skill listed, read that companion's SKILL.md
  3. If the companion's 
    recommended_skills
    does not already include the new skill, and the companion has fewer than 5 recommendations, add the new skill name
  4. If the companion already has 5 recommendations, evaluate whether the new skill is a better fit than an existing entry - if so, swap it in; if not, skip
  5. Only add reciprocal links where the relationship is genuinely complementary - do not force bidirectional links for every recommendation
  1. 读取新skill的
    recommended_skills
    字段，识别其配套skill
  2. 对于每个列出的配套skill，读取该skill的SKILL.md
  3. 如果配套skill的
    recommended_skills
    尚未包含新skill，且配套skill的推荐数少于5个，添加新skill名称
  4. 如果配套skill已有5个推荐，评估新skill是否比现有条目更合适——如果是，替换；否则，跳过
  5. 仅在关系真正互补时添加双向链接——切勿为每个推荐强制添加双向链接

Example

示例

If you create 
api-gateway
with 
recommended_skills: [api-design, microservices]
:
  • Read 
    skills/api-design/SKILL.md
    - if it doesn't list 
    api-gateway
    and has room, add it
  • Read 
    skills/microservices/SKILL.md
    - same check
如果你创建了
api-gateway
，其
recommended_skills: [api-design, microservices]
：
  • 读取
    skills/api-design/SKILL.md
    ——如果未列出
    api-gateway
    且有剩余名额，添加它
  • 读取
    skills/microservices/SKILL.md
    ——执行相同检查

Rules

规则

  • Never remove existing recommendations without a clear reason
  • Never exceed 5 recommendations per skill
  • Only add the new skill if it's genuinely complementary to the companion
  • Print which skills were updated in the output summary
  • 除非有明确理由，否则切勿删除现有推荐
  • 每个skill的推荐数切勿超过5个
  • 仅当新skill与配套skill真正互补时才添加
  • 在输出摘要中打印已更新的skill

Quality checklist

质量检查清单

Before outputting, verify all of these:
  • Every frontmatter field is populated (no empty strings)
  • Description is specific - includes skill name + 3 key task types
  • For URL skills: all sources in sources.yaml are from official docs only
  • For domain skills: user approved the scope before writing began
  • Code examples (if any) are syntactically valid; domain advice is actionable
  • Evals cover all 5 type categories (trigger, task, gotcha, anti-hallucination, reference)
  • Flagged items use the 
    <!-- VERIFY: -->
    comment format
  • references/ files each have the header comment
  • Output summary is printed
  • Recommended skills propagated to companion skills (Phase 7)
输出前，验证以下所有项：
  • 所有前置元数据字段已填充（无空字符串）
  • 描述具体——包含skill名称+3种关键任务类型
  • 对于URL类skill：sources.yaml中的所有来源均来自官方文档
  • 对于领域类skill：在开始编写前，用户已确认范围
  • 代码示例（如有）语法有效；领域建议可执行
  • 测试用例覆盖所有5类（触发、任务、注意事项、反幻觉、参考资料）
  • 标记项使用
    <!-- VERIFY: -->
    注释格式
  • references/文件均包含头部注释
  • 已打印输出摘要
  • 推荐skill已同步到配套skill（阶段7）

References

参考资料

Consult these files for detailed schemas and examples. Only load a file when you need it for the current phase.
  • references/frontmatter-schema.md
    - Full YAML template and category taxonomy (read during Phase 2)
  • references/body-structure-template.md
    - Complete markdown body scaffold (read during Phase 2)
  • references/evals-schema.md
    - JSON schema, assertion types, worked example (read during Phase 4)
  • references/sources-schema.md
    - YAML schema for sources.yaml (read during Phase 5)
  • references/worked-example.md
    - Resend end-to-end worked example (read for first-time orientation)
  • references/skill-registry.md
    - Full catalog of existing and planned skills by category (read when choosing what to build next or checking for duplicates)
如需详细架构和示例，请查阅以下文件。仅在当前阶段需要时加载文件。
  • references/frontmatter-schema.md
    - 完整YAML模板和分类体系（阶段2阅读）
  • references/body-structure-template.md
    - 完整Markdown主体框架（阶段2阅读）
  • references/evals-schema.md
    - JSON架构、断言类型、示例（阶段4阅读）
  • references/sources-schema.md
    - sources.yaml的YAML架构（阶段5阅读）
  • references/worked-example.md
    - Resend端到端示例（首次使用时阅读）
  • references/skill-registry.md
    - 按分类划分的所有现有和规划skill的完整目录（选择下一个要构建的skill或检查重复项时阅读）