openydt-skill-maker — openydt Custom Skill Maker

CRITICAL: MUST use the Read tool to read
../openydt-shared/SKILL.md
before starting to master openydt's configuration / profile / signature (v2/v3) / response envelope and status codes / rate limiting / write operation security rules. All newly created Skills must reuse this base; do not repeat this content in new Skills.

This skill is a meta-skill for "creating other openydt Skills", benchmarked against Feishu's

lark-skill-maker

: when users want to solidify a specific openydt interface (atomic encapsulation) or a multi-step business process (orchestration) into a reusable Skill, follow this guide to produce a standardized

SKILL.md

When to Use This Skill

Users want to create a new openydt domain Skill (e.g., "on-site vehicle / monthly pass / blacklist" domains).
Users want to encapsulate a specific
```
openydt api <cmd>
```
or a business link like "check fee → pay fee" into a reusable Skill.
Users want to standardize an existing SKILL.md (supplement frontmatter, organize command tables, add
```
--yes
```
to write operations).

Not applicable to this skill: actual calling of business interfaces (use corresponding domain Skills or

openydt api

), modifying Go command code (modifying

cmd/gen

requires changing the extractor/codegen first instead of writing manually).

Directory Structure

Each Skill is a directory under

skills/<skill-name>/

, which must contain at least

SKILL.md

; when the main content is long or there are large chunks of reference materials, split the content into

references/

as needed:

skills/
  openydt-shared/SKILL.md        # Shared base (all Skills must Read it first)
  openydt-<domain>/
    SKILL.md                     # Main entry: frontmatter + main content (must be concise, resident in context)
    references/                   # Optional: large content loaded on demand
      <topic>.md                 # e.g., field dictionary, complete enumeration table, long business process

Naming convention: Use

openydt-<domain or scenario>

(kebab-case) for the Skill directory name, which must match the

name

in frontmatter.

Frontmatter Field Description (Same as Specification)

Frontmatter must be consistent with existing openydt Skills:

yaml

---
name: openydt-<domain>                 # Required, same as directory name, kebab-case
version: 1.0.0                      # Required, semantic versioning
description: "<one-sentence responsibility>. <enriched trigger words>."  # Required, see requirements below
metadata:
  requires:
    bins: ["openydt"]              # Required, declare dependency on openydt binary
  cliHelp: "openydt <domain> --help"   # Recommended: allow users to quickly view real subcommands
---

```
description
```
is the key to correct recall of the Skill, must be rich in Chinese trigger words: first use one sentence to clarify the responsibility (which domain it covers, whether it is read or write), then list possible colloquial expressions of users (e.g., "check parking lot, empty parking space, check fee, issue coupon, add to blacklist, activate monthly pass" and other synonyms/near-synonyms), spread out read/write verbs and business nouns. Refer to the description density of
```
openydt-park
```
/
```
openydt-coupon
```
.
Fill in the real help command of the domain for
```
cliHelp
```
to facilitate humans to verify whether subcommands exist.

Main Content Structure Convention

Write the main content according to the fixed skeleton, from top to bottom:

CRITICAL: Read shared first: The first sentence of the main content must be a prominent reminder requiring users to Read
```
../openydt-shared/SKILL.md
```
before starting, and not repeat signature/status code/security rules in this Skill.
When to use this Skill + Intent Routing: Clarify what this domain is responsible for, and provide routing like "please switch to X domain for such requests" (to avoid Skill overstepping).
Available Command Table: List the domain commands in a table with columns "Chinese Name | Command | Read/Write | Key Parameters".
- The
```
Command
```
  column writes real executable
```
openydt <domain> <use>
```
  .
- The
```
Read/Write
```
  column indicates read or write; all write commands must be marked with "requires
  --yes
  " in the table and examples.
- Mark required items in
```
Key Parameters
```
  (use
```
*
```
  or "required"), and explain that array/object-type fields must be passed in via
```
--body
```
  JSON.
Business Process (only when there are multi-step links): Describe links that require filling in the response of the previous step (e.g., "check fee → fee calculation" "create coupon → sell coupon → issue coupon"), emphasize that fields must be taken from the previous step's response and cannot be fabricated. If there is no strong dependency chain, write "all commands are independent queries".
Examples: Provide 2-4 commands that can be directly copied and run, including at least one read example and (if there are write commands) one write example with
```
--yes
```
; try to take parameters from
```
sampleBody
```
of catalog or test parking lots in the shared base.

references/ On-Demand Loading Convention

The main body of SKILL.md must be short (resident in context, control tokens). Sink large, low-frequency content to
```
references/<topic>.md
```
, and use relative links in the main body to indicate "Read when X is needed".
Content suitable for references: complete field dictionary / long enumeration tables (e.g., full set of coupon types, vehicle types), complete business processes with more than two steps, detailed tables of error codes to disposal actions.
Clearly write trigger conditions in the main body, for example: "Before handling the complete link of create coupon → sell coupon → issue coupon, first Read
references/coupon-flow.md
", so that the model loads on demand instead of reading all by default.

Commands Must Exist in Reality

Each
```
openydt <domain> <use>
```
in the command table must exist in reality, and can only come from two categories, choose one to verify:
- First-class domain commands: Based on real subcommands in
```
cmd/gen/<domain>.go
```
  (generated by codegen), or verify by running
```
openydt <domain> --help
```
  .
- Catalog interfaces: Based on
```
interfaces[]
```
  marked
```
included: true
```
  in
```
catalog/catalog.json
```
  , each includes
```
cmd
```
  (business code) /
```
domain
```
  /
```
readwrite
```
  /
```
params
```
  /
```
sampleBody
```
  , which can be used to infer command names, read/write attributes and example parameters.
Do not fabricate command names or parameters. Interfaces marked
```
included:false
```
(with
```
excludeReason
```
) are out of scope, do not create Skills for them.
If the target interface does not have first-class domain commands, you can use the general fallback
```
openydt api <cmd> --body '{...}'
```
to call it in the Skill (see the three-layer command model of shared), but still confirm that the
```
cmd
```
exists in the catalog and is callable.

Mark --yes for Write Operations

Operations marked
```
readwrite: "write"
```
in the catalog (or any operation that changes the platform state: pay fee, open gate, issue coupon, activate monthly pass, add/remove from blacklist, set parking space, etc.) are write commands.
Mark write commands as "Write (requires
```
--yes
```
)" in the "Read/Write" column of the command table, and actually add
```
--yes
```
in examples; it is recommended to preview the signature request with
```
--dry-run
```
first if necessary. This is consistent with the security rules of shared, and new Skills must not weaken this requirement.

Production Steps

Determine the domain/scenario and target interface, verify real commands, read/write attributes, required parameters, and
```
sampleBody
```
in
```
catalog/catalog.json
```
(
```
included:true
```
) or via
```
openydt <domain> --help
```
.
Create
```
skills/openydt-<name>/SKILL.md
```
, fill in according to the above frontmatter and main content skeleton; enrich Chinese trigger words in description.
Verify the authenticity and read/write marking of each command in the command table, mark
```
--yes
```
for write commands.
Sink large content to
```
references/
```
, leave on-demand loading guidance in the main body.
Self-check: whether all commands exist in reality, whether all write operations are marked with
```
--yes
```
, whether it requires reading shared at the beginning, whether the description has sufficient trigger words.

Minimal Template

Copy the entire following section as the starting point for a new Skill's

SKILL.md

, replace the angle bracket placeholders and verify item by item:

markdown

---
name: openydt-<domain>
version: 1.0.0
description: "<一句话职责：本域负责 X，含读/写>。触发词：<列尽用户可能说的中文同义词，如 查X、看X、新建X、修改X、删除X、X列表、X编码……>。"
metadata:
  requires:
    bins: ["openydt"]
  cliHelp: "openydt <域> --help"
---

# openydt-<域> — <中文域名>

> **CRITICAL：开始前 MUST 先用 Read 工具读取 [`../openydt-shared/SKILL.md`](../openydt-shared/SKILL.md)**（认证 / profile / 签名 / 状态码 / 限速 / 安全规则）。未读共享基座不要执行任何命令。

## 何时用本技能

<本域负责什么>。意图路由：
- <这类诉求> → 留在本域。
- <那类诉求> → 改用 `openydt <其它域> --help`。

## 可用命令

`<use>` 为命令真实 kebab 名，调用形如 `openydt <域> <use>`。数组/对象型字段用 `--body '<json>'` 传入。

| 中文名 | 命令 | 读/写 | 关键参数 |
| --- | --- | --- | --- |
| <查询某资源> | `openydt <域> <use-read>` | 读 | `--xxx`*（必填） |
| <修改某资源> | `openydt <域> <use-write>` | 写（需 `--yes`） | `--xxx`*、`yyyList`*（用 `--body`） |

> 标 `*` 为必填。

## 业务流程

<若有需回填上一步响应的链路，在此描述，强调字段取自上一步响应、不可臆造；否则写「各命令为独立查询，拿到必填参数即可直接调用」。>

## 示例

1) 读示例：

```bash
openydt <域> <use-read> --xxx <值>

写示例（写操作必须加
--yes
，必要时先
```
--dry-run
```
）：

bash

openydt <域> <use-write> --yes --body '{"xxx":"...","yyyList":[{...}]}'

undefined

openydt-skill-maker

NPX Install

Tags

SKILL.md Content (Chinese)