SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsbuild-lib-skill

build-lib-skill

Coding & development

View repository

Updated 10-15 20:09

About this skill

Build Library Skill

Why

AI large models/agents are usually well trained on mainstream open-source libraries and have high accuracy when using them.

However, for enterprise private libraries or niche open-source projects, AI large models/agents often cannot use them accurately. This skill is used to guide agents/AI to generate efficient and accuratedocumentation-orientedskills for such libraries.

Goals

Createexclusively for agents/AI usea library operation manual to help them use the library accurately and efficiently.

Hard Constraints

  • Source of truth: APIs, signatures, constraints, and examples must come from public exports, type declarations, source code, tests, examples, README, CHANGELOG; it is forbidden to fill them in with training data or guesses.
  • Public API only: exclude internal、private, non-exported, and symbols marked @internal / @private .
  • Progressive disclosure：SKILL.md keep it concise; put details in references/ or a similar directory, loaded on demand.
  • Skill language: write in Chinese; proper nouns, API names, code identifiers, etc. may remain in English.
  • Documentation boundaries: it is forbidden to write internal implementation details of the library; focus only on the public API.

Directory Structure

Simple Library Example

<skill-name>/
├── SKILL.md
└── references/
    ├── index.md      # 入口：导航与概括说明，并引用 apis.md、examples.md
    ├── apis.md       # API 定义：签名、参数、返回值
    └── examples.md   # 使用示例

Monorepo Example

<skill-name>/
├── SKILL.md
└── packages/
    ├── package1/
    │   ├── index.md      # 入口：导航与概括说明，并引用 apis.md、examples.md
    │   ├── apis.md       # API 定义：签名、参数、返回值
    │   └── examples.md   # 使用示例
    └── package2/
        ├── module1/      # 模块分组
        │   ├── index.md
        │   ├── apis.md
        │   └── examples.md
        ├── module2/
        │   ├── index.md
        │   ├── apis.md
        │   └── examples.md
        └── .../

Workflow

First determine whether the workflow type is add, update, or consistency check, then execute according to the corresponding workflow below.

Note: for the operations mentioned below such as confirming with the user and asking questions, please use AskQuestion or a similar tool that provides options and custom input.

Add

  1. Analyze the target library's source code, tests, and documentation, determine the documentation granularity (if the library is very fine-grained, such as "one file per method", then classify at a coarser granularity), trigger scenarios, and existing examples, and confirm with the user.
  2. Confirm the skill name with the user.
  3. Take source code and tests as the first priority, with library documentation (if any) as a supplement; plan the skill directory structure and other vague or ambiguous details and confirm with the user; put progressively disclosed content in references/(for multi-package monorepos, prefer packages/）。
  4. Create the skill directory structure and generate the SKILL.md file.
  5. Run the validation workflow below to ensure the skill conforms to this skill specification.

Update

Step 1: First validate whether the current skill conforms to this skill specification; if not, confirm with the user whether to rewrite it.

  • If a rewrite is needed: execute the "Add" workflow.
  • If no rewrite is needed: proceed to Step 2.

Step 2：

  1. Read the target library's current version (package.json / each package's package.json / release configuration, etc.), and compare it with the "Version" section in the skill SKILL.md .
  2. Update the skill content as needed according to the library code updates and user feedback.
  3. Synchronously update the version: set the SKILL.mdRewrite the "Version" section to the library's current exact version; for multi-package repositories, each package must be aligned individually. As long as the skill content has changed, the version field must match the library's current version; retaining an old version number is prohibited.
  4. Run the verification process below to ensure the skill complies with this skill specification.

Consistency verification

  1. Perform a full check of the consistency between the source code and the skill content (using a subagent),must include version consistency(skill-declared version vs. the library's/each package's current version).
  2. If consistency passes, output a consistency report and inform the user that consistency passed.
  3. If consistency does not pass, output a diff report and let the user decide whether to update the skill (via the update process).

Output location

Unless the user explicitly specifies otherwise, companion skills are by default placed in the skills/ directory:skills/<skill-name>/。

SKILL.md template

Metadata field specification:

  • name: must use the kebab-case naming convention; no more than 32 characters.
  • description: use Chinese as much as possible except for technical terms; no more than 512 characters; must include both做什么and何时使用。
---
name: <skill-name>
description: <做什么>以及<何时使用>
---

# <技能名称>

{技能介绍说明}

## 版本

{精确版本, 如果是多包仓库, 则需要说明每个包的版本}

## 模块地图/分包地图

{若库较大或模块较多，在此对各包/模块做粗略介绍，便于初始路由决策}

## 路由决策

{用户意图 → 推荐工作流 / API}

## 检查清单

- 是否已安装
- 安装的依赖版本是否匹配
- ...

Automatic update

After the library code is updated, the companion skill must be updated in sync.

Update checklist:

  • Public API changes (added / modified / removed / deprecated) have been reflected in references/ or packages/
  • Examples and signatures are consistent with the current public API
  • Routing decisions and module map have been adjusted as needed
  • SKILL.md"Version" has been updated to the library's current exact version(for multiple packages, align each package individually)

Verification

  • SKILL.md is concise enough, must not exceed 500 lines, best within 200 lines
  • Check whether the description is specific and includes trigger words
  • Ensure that references/(or packages/) every file has a corresponding routing decision path
  • Examples and signatures use only the public API and are consistent with the current library version
  • SKILL.md"Version" is consistent with the library's (or each package's) current version
  • Test whether this Skill can be successfully discovered and applied

Best practices

  • Example documentation is very important; each example scenario should demonstrate the most comprehensive usage of that scenario with the most concise code possible.
  • Example documentation should be as comprehensive as possible, but do not show only a single usage in every example.
  • For API documentation files, type declarations are more efficient than table-style parameter output; the approach of embedding type declarations in code blocks should be preferred, for example:
### sum

对任意数字求和.

类型:

```ts
type sum = (...numbers: number[]) => number
```
  • SKILL.md must be within 500 lines, best within 200 lines.

Anti-patterns

  • Cramming an entire API manual into a single SKILL.md
  • Creating a separate Skill for each exported function
  • Listing references/(or packages/）
  • Examples using internal paths or non-exported symbols
  • Filling in "recommended APIs" using outdated training knowledge
  • Failing to update the companion skill when the library code has changed
  • Repeatedly confirming trivial matters with the user when the facts are already sufficient