autoskill

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Local Skill File Manager

本地Skill文件管理器

Purpose

用途

Maintain the user's personal local skill files as a lightweight self-improving memory system. The default goal is not to produce marketplace-ready generic skills; it is to preserve reusable behavior that helps this user, this team, or this workspace in future sessions. A good candidate may encode personal workflow preferences, project conventions, style contracts, tool choices, or review gates that would not be useful to other users, as long as it is reusable for the intended owner and approved.

This skill does not depend on project-specific code, servers, vector stores, databases, or storage layouts. It operates only on ordinary local skill folders:

text

<skill-root>/
  <skill-name>/
    SKILL.md
    agents/openai.yaml   (optional)
    scripts/             (optional)
    references/          (optional)
    assets/              (optional)

Use this skill to decide when a session contains reusable skill material, find whether a similar skill already exists, then discard, improve, merge, or create a local skill. The model should initiate this check when signals appear; it should not wait for the user to ask. The check must stay lightweight and non-blocking unless the user explicitly asks to focus on skill maintenance.

将用户的个人本地技能文件维护为轻量级的自我改进型记忆系统。默认目标并非生成适用于市场的通用技能；而是保留可复用的行为，帮助该用户、团队或工作区在未来会话中提升效率。优秀的候选技能可编码个人工作流偏好、项目约定、风格规范、工具选择或审核关卡，即便这些内容对其他用户无用，只要对目标所有者可复用且获得批准即可。

本技能不依赖项目特定代码、服务器、向量存储、数据库或存储布局。仅在普通本地技能文件夹上运行：

text

<skill-root>/
  <skill-name>/
    SKILL.md
    agents/openai.yaml   (optional)
    scripts/             (optional)
    references/          (optional)
    assets/              (optional)

使用本技能判断会话中是否包含可复用技能素材，查找是否已存在相似技能，然后执行丢弃、改进、合并或创建本地技能的操作。当出现相关信号时，模型应主动启动检查；无需等待用户发起请求。除非用户明确要求专注于技能维护，否则检查必须保持轻量且非阻塞。

Related Skill Coordination

Safety And Consent

安全与同意

Local skills can influence future agent behavior and may include executable scripts. Treat skill edits as durable behavior changes.

Do not install, import, or enable third-party skills without user consent.
Do not add surprising capabilities, hidden network access, credential handling, data exfiltration, or destructive commands.
If a skill adds scripts or tool integrations, make their purpose visible in
```
SKILL.md
```
.
When editing a skill that may be shared with a team, preserve organization policies and ask before changing security-sensitive behavior.
Treat each candidate as
```
personal
```
by default; mark it
```
team
```
or
```
public
```
only when the evidence supports that broader audience.
Do not publish, recommend as broadly reusable, or remove personal scope from a user-specific skill without explicit user approval.
Before the first persistent learning note or skill write in a new local convention, tell the user what path would be written and ask for approval.
Do not silently modify this
```
autoskill
```
manager itself during routine maintenance. Improve it only when the user explicitly asks to improve this skill.

本地技能会影响未来Agent的行为，可能包含可执行脚本。需将技能编辑视为持久性行为变更。

未经用户同意，不得安装、导入或启用第三方技能。
不得添加意外功能、隐藏网络访问、凭证处理、数据泄露或破坏性命令。
若技能添加脚本或工具集成，需在
```
SKILL.md
```
中明确说明其用途。
编辑可能与团队共享的技能时，需遵守组织政策，更改安全敏感行为前需征得同意。
默认将每个候选技能标记为
```
personal
```
；仅当证据支持更广泛受众时，才标记为
```
team
```
或
```
public
```
。
未经用户明确批准，不得发布、推荐为通用可复用技能，或移除用户专属技能的个人范围。
在新本地规范中首次写入持久学习笔记或技能前，需告知用户写入路径并请求批准。
在常规维护期间，不得静默修改本
```
autoskill
```
管理器本身。仅当用户明确要求改进本技能时，才可进行优化。

Skill Roots

技能根目录

Before writing anything, identify where local skills live.

Use an explicit user-provided path first.
Otherwise check common roots such as
```
${CODEX_HOME}/skills
```
,
```
~/.codex/skills
```
,
```
./skills
```
,
```
.agents/skills
```
, and any current workspace skill directory containing
```
*/SKILL.md
```
.
If exactly one plausible root exists, use it.
If multiple plausible roots exist and the target is ambiguous, ask the user which root to maintain.
Never reorganize unrelated skill roots or edit skills outside the chosen root.

写入任何内容前，需确定本地技能的存储位置。

优先使用用户明确提供的路径。
否则检查常见根目录，如
```
${CODEX_HOME}/skills
```
、
```
~/.codex/skills
```
、
```
./skills
```
、
```
.agents/skills
```
，以及任何包含
```
*/SKILL.md
```
的当前工作区技能目录。
若仅存在一个合理根目录，直接使用。
若存在多个合理根目录且目标不明确，询问用户应维护哪个根目录。
切勿重新组织无关技能根目录，或编辑所选根目录外的技能。

Trigger Policy

触发策略

Use a three-layer trigger policy:

Silent scan: after each substantive user turn, briefly ask whether the turn contains a reusable personal preference, rule, correction, workflow, failure, or skill-quality issue.
Extraction check: when a trigger below fires, classify the experience, assign evidence and value, search for similar skills, and test it against the extraction boundary.
Write/update: only edit local skill files after the candidate passes the boundary, the target skill root is clear, and the user approves the exact change.

The model should proactively initiate scans and extraction checks. Do not ask the user "should I check for a skill?" Ask only when the target root is ambiguous, the edit would overwrite uncertain behavior, or the user must approve an external install or sensitive script.

采用三层触发策略：

静默扫描：每次实质性用户交互后，简要判断该交互是否包含可复用的个人偏好、规则、修正、工作流、故障或技能质量问题。
提取检查：当以下触发器触发时，对经验进行分类，分配证据和价值，搜索相似技能，并测试是否符合提取边界。
写入/更新：仅当候选技能通过边界检查、目标技能根目录明确，且用户批准确切变更后，才可编辑本地技能文件。

模型应主动启动扫描和提取检查。不要询问用户“是否要检查技能？”仅当目标根目录不明确、编辑会覆盖不确定行为，或用户必须批准外部安装或敏感脚本时，才发起询问。

Candidate Lifecycle

候选技能生命周期

Keep the lifecycle separate from any particular storage system: observe a signal, optionally ask the user to choose a candidate title/topic, draft the candidate, de-duplicate by pattern, decide

discard

keep_note

improve

merge

create

, show the complete proposed skill or diff, then apply the smallest approved change and validate.

De-duplicate by task family, trigger, tools, failure mode, output contract, and target skill rather than exact wording. Do not create a private database, daemon, scheduler, or hidden background store as part of this skill.

将生命周期与任何特定存储系统分离：观察信号，可选地请用户选择候选标题/主题，草拟候选技能，按模式去重，决定

discard

keep_note

improve

merge

create

，展示完整的拟议技能或差异内容，然后应用最小的已批准变更并验证。

按任务类别、触发条件、工具、故障模式、输出约定及目标技能去重，而非按确切措辞。不要在本技能中创建私有数据库、守护进程、调度器或隐藏后台存储。

Title Selection Gate

标题选择关卡

Before full extraction, when the reusable topic is ambiguous or there are several plausible skills, show 2-5 concise reusable-capability titles with one-line evidence reasons plus

none of these

and

custom topic

. If the user chooses a title or enters a topic, treat it as direction only: re-run the extraction boundary and similar-skill search for that direction, discard it if it fails, or show the complete proposed

SKILL.md

/diff for final approval if it passes. If the user chooses

none of these

, discard or keep a non-persistent note; do not write files.

在完整提取前，当可复用主题不明确或存在多个合理技能时，展示2-5个简洁的可复用能力标题及一行证据理由，同时提供

none of these

和

custom topic

选项。若用户选择标题或输入主题，仅将其作为方向参考：针对该方向重新运行提取边界检查和相似技能搜索，若未通过则丢弃，若通过则展示完整的拟议

SKILL.md

/差异内容以获取最终批准。若用户选择

none of these

，则丢弃或保留非持久化笔记；不得写入文件。

Language Consistency

语言一致性

For new skills, write candidate titles, proposed

SKILL.md

agents/openai.yaml

, and small resources in the dominant language of the user evidence; Chinese input produces Chinese skills, English input produces English skills. For updates or merges, keep the target skill's dominant language unless the user explicitly asks to translate it; if mixed evidence makes language ambiguous, ask before drafting. Do not default extracted skill content to English.

对于新技能，候选标题、拟议

SKILL.md

、

agents/openai.yaml

及小型资源需使用用户证据的主导语言；中文输入生成中文技能，英文输入生成英文技能。对于更新或合并操作，需保留目标技能的主导语言，除非用户明确要求翻译；若混合证据导致语言不明确，草拟前需询问用户。不得默认将提取的技能内容设为英文。

Background Execution

后台执行

Skill extraction and maintenance must not block the user's main task.

Treat extraction checks, similar-skill search, candidate drafting, and trigger-eval preparation as background maintenance work whenever possible.
Background work may prepare candidates, find similar skills, and draft diffs, but it must not write, update, delete, install, or enable skills without user confirmation.
Continue the primary user request first; do not make the user wait for skill extraction unless the user explicitly asked to focus on skill maintenance.
Surface background results only when there is an actionable candidate decision, proposed file diff, or clarification/consent question.
Run at most one background skill-maintenance job per active conversation unless the user asks for a batch; queue or coalesce extra signals.
Do not start expensive searches, broad evals, or large rewrites in the foreground. Use lightweight checks first, then defer deeper validation to a natural pause or explicit maintenance pass.
If the runtime cannot actually run background work, emulate it by deferring the maintenance check until after the current answer is complete or the next natural pause.
Never block delivery of the user's requested work just to finish candidate extraction, unless the requested work is skill maintenance itself.

技能提取和维护不得阻塞用户的主要任务。

尽可能将提取检查、相似技能搜索、候选技能草拟及触发评估准备视为后台维护工作。
后台工作可准备候选技能、查找相似技能及草拟差异内容，但未经用户确认，不得写入、更新、删除、安装或启用技能。
优先处理用户的主要请求；除非用户明确要求专注于技能维护，否则不要让用户等待技能提取完成。
仅当存在可操作的候选决策、拟议文件差异或澄清/同意问题时，才向用户展示后台结果。
除非用户要求批量处理，否则每次活跃对话最多运行一个后台技能维护任务；对额外信号进行排队或合并。
不要在前台启动昂贵的搜索、广泛评估或大型重写。先使用轻量检查，然后将深度验证推迟到自然停顿或明确的维护阶段。
若运行时无法实际执行后台工作，可通过将维护检查推迟到当前回答完成后或下一个自然停顿来模拟。
除非用户请求的工作本身就是技能维护，否则切勿为完成候选提取而阻塞用户请求的工作交付。

Confirmation Gate

确认关卡

User confirmation is required before any skill file is created, updated, deleted, imported, installed, enabled, or materially rewritten. Draft first, ask second: after any title/topic selection, never ask "should I add/update a skill?" until the proposed content or change is already written out for review.

For

create

, show before writing:

proposed skill name and target path
intended audience:
```
personal
```
,
```
team
```
, or
```
public
```
, plus portability limits
why the candidate passed the reusable-skill boundary
evidence level, recurrence signal, priority, and value signal
similar skills checked and why this is not a duplicate
complete proposed
```
SKILL.md
```
content
complete proposed
```
agents/openai.yaml
```
and every proposed script, reference, or asset text when such files are small enough to review inline; for large assets, show the exact file list, purpose, provenance, and generated diff or manifest

For

improve

merge

, show before writing:

exact target skill path
decision type:
```
improve
```
or
```
merge
```
why the change belongs in that existing skill
evidence level, recurrence signal, priority, and value signal
a complete unified diff, or complete before/after text for every changed section when a unified diff is unavailable
every file that would be added, modified, deleted, or left untouched
validation plan or command to run after approval

Ask for a clear yes/no approval only after showing the full proposed artifact or diff. If the user does not approve, do not edit the skill; report the candidate as deferred or discarded.

在创建、更新、删除、导入、安装、启用或实质性重写任何技能文件前，必须获得用户确认。先草拟，再询问：在选择任何标题/主题后，除非已写出拟议内容或变更供用户审核，否则不要询问“是否要添加/更新技能？”

对于

create

操作，写入前需展示：

拟议技能名称和目标路径
目标受众：
```
personal
```
、
```
team
```
或
```
public
```
，以及可移植性限制
候选技能通过可复用技能边界的原因
证据级别、重复信号、优先级和价值信号
已检查的相似技能及本技能并非重复的原因
完整的拟议
```
SKILL.md
```
内容
完整的拟议
```
agents/openai.yaml
```
及所有拟议脚本、参考资料或资产文本（若文件小到可内联审核）；对于大型资产，展示确切的文件列表、用途、来源及生成的差异或清单

对于

improve

或

merge

操作，写入前需展示：

确切的目标技能路径
决策类型：
```
improve
```
或
```
merge
```
变更属于该现有技能的原因
证据级别、重复信号、优先级和价值信号
完整的统一差异内容；若无法提供统一差异，展示每个变更部分的完整前后文本
所有将被添加、修改、删除或保持不变的文件
批准后的验证计划或命令

仅在展示完整的拟议工件或差异内容后，才请求明确的是/否批准。若用户不批准，不得编辑技能；需报告候选技能已推迟或丢弃。

Immediate Triggers

即时触发器

Run an extraction check immediately, or at the next natural pause if the user is waiting for the main task, when any of these happen:

The user corrects, rejects, or refines the model's approach in a way that should affect future similar tasks.
The user gives a durable preference, output contract, workflow, naming rule, tool rule, or quality gate.
A command, script, integration, or workflow fails and the session discovers a reusable fix.
The agent repeats non-trivial setup, scripting, transformation, or validation work that should become a reusable resource.
A similar local skill under-triggered, over-triggered, or produced incomplete guidance.
The session reveals a missing reference, template, script, or checklist that would prevent future repeated effort.
The user uses future-oriented language such as "remember this as a skill", "save this workflow", "update the local skill", "next time, do it this way", "this is my standard process", or "create a skill from this conversation".

Still treat extraction as a check, not a requirement: no skill change is often the correct outcome.

Do not extract when the user says the rule is temporary, asks not to remember it, or only wants a one-time answer.

当发生以下任何情况时，立即运行提取检查；若用户正在等待主要任务，则在下一个自然停顿运行：

用户以应影响未来相似任务的方式纠正、拒绝或优化模型的方法。
用户给出持久偏好、输出约定、工作流、命名规则、工具规则或质量关卡。
命令、脚本、集成或工作流失败，且会话发现可复用的修复方案。
Agent重复执行应成为可复用资源的非琐碎设置、脚本编写、转换或验证工作。
相似的本地技能触发不足、过度触发或生成不完整指导。
会话揭示缺失的参考资料、模板、脚本或清单，而这些内容可避免未来重复工作。
用户使用面向未来的语言，如“将此记为技能”、“保存此工作流”、“更新本地技能”、“下次按此方式操作”、“这是我的标准流程”或“从此对话创建技能”。

仍需将提取视为检查，而非强制要求：不进行技能变更往往是正确的结果。

当用户表示规则是临时的、要求不要记住，或仅需要一次性答案时，不得提取。

Scheduled Checks

定期检查

Use scheduled checks to catch gradual learning that no single turn makes obvious:

Conversation-length check: after roughly 6 substantive user messages, 12 total turns, or 2-3 distinct task attempts since the last check.
Token/volume check: after a long chunk of new context, especially when the conversation may soon be summarized or compacted.
Task-boundary check: when a deliverable is completed, a debugging loop ends, a plan is accepted, or the user switches to a new task.
Session-end check: before the final response of a substantial session, review whether anything should be discarded, improved, merged, created, or noted.

Keep scheduled checks lightweight. They should usually happen silently and only surface to the user when there is an actionable decision or a needed clarification.

使用定期检查捕捉单个交互无法体现的渐进式学习：

会话长度检查：自上次检查后，大约经过6条实质性用户消息、12次总交互或2-3次不同任务尝试后。
令牌/容量检查：在添加长段新上下文后，尤其是对话可能即将被总结或压缩时。
任务边界检查：当交付物完成、调试循环结束、计划被接受或用户切换到新任务时。
会话结束检查：在重要会话的最终响应前，回顾是否有内容需要丢弃、改进、合并、创建或记录。

保持定期检查轻量。通常应静默进行，仅当存在可操作决策或需要澄清时才向用户展示。

Debounce And Batching

防抖与批处理

Prevent noisy repeated extraction:

Do not re-check the same signal repeatedly in one session.
Batch multiple weak signals until a task boundary or scheduled check.
Create or update at most one skill per check unless the user explicitly asks for a batch.
Prefer
```
keep_note
```
or
```
discard
```
for borderline signals until repetition strengthens the evidence.
If a candidate is close but not yet reusable enough, remember the rationale in the completion note instead of creating a skill.
Coalesce simultaneous triggers into one background maintenance pass.
When multiple candidates compete, handle the highest-priority repeated failure or user-confirmed preference first.

防止频繁重复提取：

不要在一个会话中反复检查相同信号。
将多个弱信号批量处理，直到任务边界或定期检查时再处理。
除非用户明确要求批量处理，否则每次检查最多创建或更新一个技能。
对于边界信号，优先选择
```
keep_note
```
或
```
discard
```
，直到重复出现增强证据。
若候选技能接近可复用标准但尚未达标，将理由记录在完成笔记中，而非创建技能。
将同时触发的信号合并为一次后台维护处理。
当多个候选技能竞争时，优先处理最高优先级的重复失败或用户确认的偏好。

Experience Triage

经验分类

Before changing skills, classify the session experience. Durable categories are

error

correction

best_practice

knowledge_gap

, and

preference

one_off_result

means the session produced useful work but no durable process change.

Only durable categories can become skill changes, and only after passing the extraction boundary. One-off results should not be promoted.

在变更技能前，将会话经验分类。持久类别包括

error

、

correction

、

best_practice

、

knowledge_gap

和

preference

。

one_off_result

表示会话产生了有用的工作，但未带来持久的流程变更。

只有持久类别才可成为技能变更，且需通过提取边界检查。一次性结果不得被提升为技能。

Value And Priority Gate

价值与优先级关卡

Priority
```
P0
```
: prevents unsafe, destructive, privacy-sensitive, or repeatedly failing behavior.
Priority
```
P1
```
: prevents a significant recurring mistake, missed trigger, bad merge, or expensive repeated workflow.
Priority
```
P2
```
: improves quality, speed, or clarity for a recurring task family.
Priority
```
P3
```
: convenience or style improvement with limited evidence.

Promote by durable value, not novelty. Value must be explainable as reliability, safety, speed, quality, consistency, or reduced repeated work. If no value dimension is clear, discard or keep a non-persistent note.

Change one behavioral lever at a time when improving an existing skill: trigger wording, workflow step, validation gate, resource placement, or safety constraint.

优先级
```
P0
```
：防止不安全、破坏性、隐私敏感或反复失败的行为。
优先级
```
P1
```
：防止重大重复错误、触发遗漏、错误合并或昂贵的重复工作流。
优先级
```
P2
```
：提升重复任务类别的质量、速度或清晰度。
优先级
```
P3
```
：便利或风格改进，证据有限。

按持久价值而非新颖性进行提升。价值必须可解释为可靠性、安全性、速度、质量、一致性或减少重复工作。若价值维度不明确，丢弃或保留非持久化笔记。

改进现有技能时，一次仅变更一个行为要素：触发措辞、工作流步骤、验证关卡、资源放置或安全约束。

Promotion Rules

推广规则

Do not turn every experience into a skill edit. Promote experiences deliberately:

Promote immediately when the user explicitly says the rule should apply next time.
Promote immediately when a correction prevents a serious repeated failure, unsafe action, or destructive workflow.
Promote after repetition when the same error, correction, or best practice appears across multiple similar tasks. As a default, require 2 distinct tasks or 3 comparable uses for assistant-inferred practices.
Merge into an existing skill when the experience refines a known capability.
Create a new skill only when the experience reveals a distinct reusable capability.
Keep as a note or completion summary, not a skill, when the evidence is useful but not yet reusable enough.

When using a local learning-note convention such as

.learnings/

MEMORY.md

, or similar, record non-promoted experiences there only if the user or environment already supports that convention. Do not invent a new memory system inside this skill unless the user asks.

不要将每次经验都转化为技能编辑。需谨慎推广：

当用户明确表示规则应适用于下次操作时，立即推广。
当纠正措施防止严重重复失败、不安全操作或破坏性工作流时，立即推广。
当相同错误、纠正或最佳实践出现在多个相似任务中时，重复后再推广。默认情况下，对于助理推断的实践，需要2个不同任务或3次可比使用的证据。
当经验优化已知能力时，合并到现有技能中。
仅当经验揭示独特的可复用能力时，才创建新技能。
当证据有用但尚未达到可复用标准时，保留为笔记或完成摘要，而非技能。

若环境已支持本地学习笔记规范（如

.learnings/

、

MEMORY.md

等），仅在该规范下记录未被推广的经验。除非用户要求，否则不要在本技能中发明新的记忆系统。

Experience Record Shape

经验记录格式

When a learning note or improvement rationale is needed, use a compact structure:

text

type: error | correction | best_practice | knowledge_gap | preference
status: candidate | deferred | approved | applied | discarded
audience: personal | team | public
summary: one sentence
source: user_feedback | command_error | task_result | review
context: task family, relevant files/tools, and what happened
lesson: reusable rule or missing capability
pattern_key: stable phrase for deduplicating similar experiences
evidence_level: strong | medium | weak
recurrence: first_seen | repeated | user_confirmed
priority: P0 | P1 | P2 | P3
value_signal: reliability | safety | speed | quality | consistency | reduced_rework
suggested_action: discard | improve <skill> | merge <skill> | create <skill> | keep_note
sensitivity: public | private | contains_sensitive_details

Redact secrets, personal data, credentials, private URLs, and customer-specific details before storing any note or skill content.

当需要学习笔记或改进理由时，使用紧凑结构：

text

type: error | correction | best_practice | knowledge_gap | preference
status: candidate | deferred | approved | applied | discarded
audience: personal | team | public
summary: 一句话总结
source: user_feedback | command_error | task_result | review
context: 任务类别、相关文件/工具及事件经过
lesson: 可复用规则或缺失的能力
pattern_key: 用于去重相似经验的稳定短语
evidence_level: strong | medium | weak
recurrence: first_seen | repeated | user_confirmed
priority: P0 | P1 | P2 | P3
value_signal: reliability | safety | speed | quality | consistency | reduced_rework
suggested_action: discard | improve <skill> | merge <skill> | create <skill> | keep_note
sensitivity: public | private | contains_sensitive_details

存储任何笔记或技能内容前，需编辑掉机密信息、个人数据、凭证、私有URL及客户特定细节。

When To Improve Existing Skills

何时改进现有技能

Prefer improving an existing skill over creating a new one when the session reveals a quality issue in a skill that already exists.

Improve a skill when it under-triggers, over-triggers, gives incomplete guidance, causes repeated work, memorizes one case instead of the reusable pattern, or is too bloated for the value it provides.

Do not "improve" a skill just to add topical payload from the current session. Improvement must increase future reuse quality.

当会话揭示现有技能存在质量问题时，优先改进现有技能而非创建新技能。

当技能触发不足、过度触发、指导不完整、导致重复工作、仅记住单个案例而非可复用模式，或相对于其提供的价值过于臃肿时，需改进技能。

不要仅为添加当前会话的主题内容而“改进”技能。改进必须提升未来复用的质量。

Extraction Boundary

提取边界

Extract only reusable capabilities. The boundary is future reuse, not topic similarity and not session length.

Extract when all tests pass:

User-evidenced: each major rule comes from user instructions, corrections, confirmations, or stable preferences.
Reusable: the rule applies to future tasks of the same kind after removing case-specific details.
Owner-valuable: the rule improves future behavior for the user, team, or workspace even if it is not generally useful to strangers.
Non-obvious: the skill captures workflow, policy, constraints, tool usage, format, or quality checks that a general assistant may not infer reliably.
Actionable: another agent can follow the skill without reading the original conversation.
Worth saving: storing it improves future behavior more than it increases skill-library noise.

Do not extract when any test fails:

The session only produced a one-off answer, artifact, bug fix, or factual explanation.
The candidate is just topic payload: names, addresses, links, exact dates, tickets, project IDs, account details, budgets, or current-session deliverables.
The candidate is generic advice such as "be accurate", "be concise", "write clearly", or "check your work" without a specific reusable workflow or output contract.
The rule appears only in assistant output and was not requested, accepted, corrected, or reinforced by the user.
De-identification removes the useful substance.
A similar local skill already covers it and the candidate adds no durable user-specific improvement.
The candidate only reflects what the assistant happened to do successfully once.
The apparent pattern comes from silence, politeness, or lack of user correction rather than evidence.
The candidate would make an existing skill broader without improving a concrete future behavior.
The candidate frames a personal or project-specific preference as a universal best practice without labeling its intended audience.

Decision line: this-instance content -> do not extract; reusable method, preference, workflow, output contract, tool rule, or quality gate -> consider extraction.

仅提取可复用能力。边界是未来复用性，而非主题相似性或会话长度。

当所有测试通过时，才可提取：

用户证据支持：每个主要规则均来自用户指令、纠正、确认或稳定偏好。
可复用：移除案例特定细节后，规则适用于未来同类任务。
对所有者有价值：规则可提升用户、团队或工作区的未来行为，即便对陌生人无用。
非显而易见：技能捕获通用助理无法可靠推断的工作流、政策、约束、工具使用、格式或质量检查。
可执行：其他Agent无需阅读原始对话即可遵循该技能。
值得保存：存储该技能对未来行为的提升大于其给技能库带来的噪音。

当任何测试失败时，不得提取：

会话仅产生一次性答案、工件、漏洞修复或事实解释。
候选技能仅为主题负载：名称、地址、链接、确切日期、工单、项目ID、账户详情、预算或当前会话交付物。
候选技能为通用建议，如“准确”、“简洁”、“清晰写作”或“检查工作”，且无具体可复用工作流或输出约定。
规则仅出现在助理输出中，未被用户请求、接受、纠正或强化。
去标识化后移除了有用内容。
已有相似本地技能覆盖该内容，且候选技能未添加持久的用户特定改进。
候选技能仅反映助理某次成功的操作。
表面模式来自沉默、礼貌或用户未纠正，而非证据。
候选技能会扩大现有技能范围，但未提升具体未来行为。
候选技能将个人或项目特定偏好框定为通用最佳实践，且未标注目标受众。

决策界限：本次实例内容→不提取；可复用方法、偏好、工作流、输出约定、工具规则或质量关卡→考虑提取。

Evidence Levels

证据级别

Rank candidate evidence before saving:

Strong evidence: explicit user instruction, correction, rejection, reusable workflow, stable preference, or repeated feedback.
Medium evidence: user confirms an assistant-proposed process or asks to make the current approach the default.
Weak evidence: assistant-authored structure, one successful answer, inferred preference, or topical similarity.

Save from strong evidence. Save from medium evidence only when the reusable boundary is clear. Do not save from weak evidence unless the user explicitly asks to turn it into a skill.

保存前对候选技能的证据进行排名：

强证据：明确的用户指令、纠正、拒绝、可复用工作流、稳定偏好或重复反馈。
中等证据：用户确认助理提出的流程，或要求将当前方法设为默认。
弱证据：助理创建的结构、一次成功的回答、推断的偏好或主题相似性。

保存强证据支持的候选技能。仅当可复用边界明确时，才保存中等证据支持的候选技能。除非用户明确要求将其转化为技能，否则不保存弱证据支持的候选技能。

Pre-Edit Memory Check

编辑前记忆检查

Before editing a local skill, search for prior related experience:

existing skills with similar names, descriptions, triggers, or workflows
existing resource files that already solve the repeated work
local notes or project memory files if the environment already uses them
recent failures, corrections, or best practices mentioned in the current session

Use this check to avoid re-learning the same lesson, duplicating skills, or ignoring known constraints.

编辑本地技能前，搜索相关过往经验：

名称、描述、触发条件或工作流相似的现有技能
已解决重复工作的现有资源文件
若环境已使用，本地笔记或项目记忆文件
当前会话中提及的近期故障、纠正或最佳实践

使用此检查避免重复学习相同教训、重复创建技能或忽略已知约束。

Candidate Shape

候选技能格式

When extraction is warranted, form one candidate skill at a time:

```
name
```
: lowercase letters, digits, and hyphens; short and capability-specific.
```
description
```
: state what the skill does and exactly when it should be used; this is the primary trigger surface.
```
audience
```
:
```
personal
```
,
```
team
```
, or
```
public
```
; default to
```
personal
```
for user-specific reuse.
```
instructions
```
: concise imperative guidance for future agents.
```
triggers
```
: 3-5 phrases a user might say that should invoke the skill.
```
resources
```
: optional scripts, references, or assets only when they materially improve reuse.

Remove case details. Keep reusable HOW, not one-off WHAT.

Before writing the candidate, capture the domain context just enough to avoid generic skills:

task family and job-to-be-done
expected input types
expected output or deliverable
important tools, formats, or constraints
success criteria or failure modes

Do not include domain context as payload unless it changes future behavior.

当需要提取时，每次生成一个候选技能：

```
name
```
：小写字母、数字和连字符；简短且针对特定能力。
```
description
```
：说明技能的功能及确切触发时机；这是主要的触发界面。
```
audience
```
：
```
personal
```
、
```
team
```
或
```
public
```
；用户专属复用默认设为
```
personal
```
。
```
instructions
```
：面向未来Agent的简洁命令式指导。
```
triggers
```
：3-5个用户可能说出的、应触发技能的短语。
```
resources
```
：可选脚本、参考资料或资产，仅当可显著提升复用性时添加。

移除案例细节。保留可复用的方法，而非一次性的结果。

写入候选技能前，仅捕获足够的领域上下文以避免生成通用技能：

任务类别及目标
预期输入类型
预期输出或交付物
重要工具、格式或约束
成功标准或故障模式

除非会改变未来行为，否则不要将领域上下文作为负载包含在内。

Similar Skill Search

相似技能搜索

Search before creating anything.

Identify the candidate's domain, task, output type, tools, and likely synonyms. Build 2-3 short queries such as
```
<domain> <task>
```
,
```
<tool> <output>
```
, and
```
<failure-mode> workflow
```
.
Search local skills first:

bash

rg --files -g 'SKILL.md' <skill-root>
rg -n "<keyword|task|output-type>" <skill-root>

Inspect likely local matches: frontmatter
```
name
```
/
```
description
```
, workflow, triggers, resources, and success criteria. Compare by task family, trigger, tools, failure mode, output contract, and audience.
If a local
```
skill-finder
```
,
```
find-skills
```
, or equivalent discovery tool is installed, use it to broaden the local/external search. Treat results as similarity evidence, not an automatic merge/install decision.
When external ecosystem search is requested, duplication risk is high, or the candidate is meant to be public, check well-known sources before creating a new skill. For personal skills, external search is evidence for avoiding duplicates, not a popularity test:
- browse
```
https://skills.sh/
```
  or its leaderboard for popular/battle-tested options
- run
```
npx skills find <query>
```
  with the best 1-2 queries
- try alternate terms when the first query misses, e.g.
```
deploy
```
  vs
```
deployment
```
  or
```
pr review
```
  vs
```
code review
```
Verify external candidates before recommending them: prefer high install counts, reputable sources, and active source repositories; be cautious with low-install or unknown-author skills.
Present external matches with name, purpose, source/quality signal, link, and install command. Do not install, import, overwrite, or merge external skills without explicit user consent.
If no suitable skill exists, say so and continue with
```
create
```
only if the candidate passes the extraction boundary.

创建任何内容前先进行搜索。

确定候选技能的领域、任务、输出类型、工具及可能的同义词。构建2-3个简短查询，如
```
<domain> <task>
```
、
```
<tool> <output>
```
和
```
<failure-mode> workflow
```
。
优先搜索本地技能：

bash

rg --files -g 'SKILL.md' <skill-root>
rg -n "<keyword|task|output-type>" <skill-root>

检查可能的本地匹配项：前置元数据
```
name
```
/
```
description
```
、工作流、触发条件、资源及成功标准。按任务类别、触发条件、工具、故障模式、输出约定及受众进行比较。
若已安装本地
```
skill-finder
```
、
```
find-skills
```
或等效发现工具，使用其扩大本地/外部搜索范围。将结果视为相似性证据，而非自动合并/安装决策。
当请求外部生态系统搜索、重复风险高或候选技能面向公众时，创建新技能前需检查知名来源。对于个人技能，外部搜索仅为避免重复的证据，而非流行度测试：
- 浏览
```
https://skills.sh/
```
  或其排行榜，查找受欢迎/经过验证的选项
- 使用最佳1-2个查询运行
```
npx skills find <query>
```
- 首次查询未命中时尝试替代术语，如
```
deploy
```
  vs
```
deployment
```
  或
```
pr review
```
  vs
```
code review
```
推荐外部候选技能前需验证：优先选择安装量高、来源可靠、存储库活跃的技能；对安装量低或作者未知的技能保持谨慎。
展示外部匹配项时需包含名称、用途、来源/质量信号、链接及安装命令。未经用户明确同意，不得安装、导入、覆盖或合并外部技能。
若不存在合适技能，告知用户并仅在候选技能通过提取边界检查后继续执行
```
create
```
操作。

Decision Rules

决策规则

Choose one outcome.

discard

when:

The candidate fails the extraction boundary.
It is useful only for the current session.
It duplicates an existing skill without durable improvement.
It is mostly assistant-invented or unsupported by user evidence.
It would create a vague, generic, or low-signal skill.

improve

when:

An existing skill has the right identity but failed in use.
The issue is trigger accuracy, unclear instructions, missing validation, bloated guidance, stale details, or missing reusable resources.
The session provides evidence for a better general version of that same skill.
No new standalone capability is needed.
The improvement can be expressed as a small, evaluable change to the existing skill.

merge

when:

The candidate and an existing local skill solve the same job-to-be-done.
The deliverable, audience, tool context, operation type, and success criteria are substantially aligned.
The candidate adds reusable constraints, clearer triggers, stronger checks, better examples, or reusable resources.
Differences are mostly wording, names, examples, or case details.

create

when:

The candidate passes the extraction boundary.
No local skill covers the same capability.
Its job-to-be-done, deliverable, audience, tool context, workflow, or success criteria materially differ from existing skills.
It is likely to be reused by the intended user, team, or public audience enough to justify a new skill folder.
It has a clear trigger surface and does not depend on the original session context.

Prefer

discard

over creating vague skills. Prefer

improve

for skill-quality failures. Prefer

merge

over creating duplicate skills. Prefer

create

only for a distinct reusable capability.

Decision outcomes before confirmation:

```
discard
```
: may be reported without confirmation because no file changes occur.
```
keep_note
```
: requires confirmation if it writes to any memory file; otherwise may be included in the completion note.
```
improve
```
,
```
merge
```
,
```
create
```
: always require confirmation before file changes.

选择一个结果。

discard

（丢弃）的情况：

候选技能未通过提取边界检查。
仅对当前会话有用。
重复现有技能且未添加持久改进。
主要由助理发明或无用户证据支持。
会生成模糊、通用或低信号的技能。

improve

（改进）的情况：

现有技能身份正确但使用中失败。
问题在于触发准确性、指导不明确、缺少验证、指导臃肿、细节过时或缺少可复用资源。
会话提供了改进该技能通用版本的证据。
无需新的独立能力。
改进可表示为对现有技能的小范围、可评估变更。

merge

（合并）的情况：

候选技能与现有本地技能解决相同目标任务。
交付物、受众、工具上下文、操作类型及成功标准基本一致。
候选技能添加了可复用约束、更清晰的触发条件、更强的检查、更好的示例或可复用资源。
差异主要在于措辞、名称、示例或案例细节。

create

（创建）的情况：

候选技能通过提取边界检查。
无本地技能覆盖相同能力。
其目标任务、交付物、受众、工具上下文、工作流或成功标准与现有技能存在实质性差异。
目标用户、团队或公众受众可能会充分复用该技能，足以证明创建新技能文件夹的合理性。
具有清晰的触发界面，且不依赖原始会话上下文。

优先选择

discard

而非创建模糊技能。优先选择

improve

处理技能质量故障。优先选择

merge

而非创建重复技能。仅针对独特的可复用能力选择

create

。

确认前的决策结果：

```
discard
```
：由于无文件变更，可直接报告，无需确认。
```
keep_note
```
：若写入任何记忆文件，需获得确认；否则可包含在完成笔记中。
```
improve
```
、
```
merge
```
、
```
create
```
：文件变更前始终需获得确认。

Improvement Loop

改进循环

Use this loop for non-trivial changes to an existing local skill.

Diagnose the failure.
- Identify whether the issue is trigger miss, false trigger, unclear instructions, missing workflow, weak validation, duplicated content, stale content, or missing reusable resources.
- Read enough of the current skill and any relevant resources to understand why the failure happened.
- Separate failure analysis from rewriting: first name the failure mode, then choose the smallest skill change that addresses it.
Preserve a baseline when useful.
- If the skill is version-controlled, rely on the existing VCS diff.
- If there is no VCS and the edit is risky, copy the original skill folder to a temporary sibling or workspace snapshot before editing.
- Do not create permanent changelogs or process files inside the skill.
Generalize from the feedback.
- Fix the broader pattern, not only the example that failed.
- Explain the reason behind important instructions so future agents can adapt instead of following brittle rules.
- Avoid rigid all-caps rules when a short rationale would guide behavior better.
- Change one lever at a time unless the user approved a broader rewrite.
Keep the skill lean.
- Remove instructions that do not affect outcomes.
- Move bulky details into
```
references/
```
  only if they are genuinely reused.
- Add scripts only when repeated deterministic work appears across examples.
Validate with realistic prompts.
- Create 3-8 lightweight prompts for ordinary improvements.
- Include both should-trigger and should-not-trigger cases when the description changed.
- Prefer realistic near-misses over obviously irrelevant negative cases.
- For objective skills, include clear expected outputs or checks; for subjective skills, use human review criteria.
- Prefer external signals: user feedback, task outputs, tests, or review notes. Do not rely on self-critique alone for major rewrites.
- Compare before/after behavior when possible, especially for trigger descriptions and over-trigger risk.
Iterate.
- Apply the smallest general fix.
- Re-check the prompts.
- Stop when the user is satisfied, failures are resolved, or further edits are no longer meaningfully improving the skill.

对现有本地技能进行非琐碎变更时使用此循环。

诊断故障。
- 确定问题是触发遗漏、误触发、指导不明确、缺少工作流、验证薄弱、内容重复、内容过时还是缺少可复用资源。
- 阅读当前技能及相关资源的足够内容，理解故障原因。
- 将故障分析与重写分离：先确定故障模式，再选择解决故障的最小技能变更。
必要时保留基线。
- 若技能受版本控制，依赖现有VCS差异。
- 若无VCS且编辑存在风险，编辑前将原始技能文件夹复制到临时同级目录或工作区快照。
- 不要在技能内创建永久变更日志或流程文件。
从反馈中归纳通用规则。
- 修复更广泛的模式，而非仅修复失败的示例。
- 解释重要指导背后的原因，以便未来Agent能够适应，而非遵循僵化规则。
- 当简短理由可更好地指导行为时，避免使用僵化的大写规则。
- 除非用户批准大范围重写，否则一次仅变更一个要素。
保持技能精简。
- 删除不影响结果的指导。
- 仅当内容真正可复用时，才将冗长细节移至
```
references/
```
  。
- 仅当示例中出现重复的确定性工作时，才添加脚本。
使用真实提示进行验证。
- 针对普通改进创建3-8个轻量提示。
- 当描述变更时，包含应触发和不应触发的案例。
- 优先选择真实的近似案例，而非明显无关的负面案例。
- 针对客观技能，包含明确的预期输出或检查；针对主观技能，使用人工评审标准。
- 优先选择外部信号：用户反馈、任务输出、测试或评审笔记。重大重写时不要仅依赖自我评估。
- 尽可能对比前后行为，尤其是触发描述和过度触发风险。
迭代。
- 应用最小的通用修复。
- 重新检查提示。
- 当用户满意、故障解决或进一步编辑无法显著提升技能时停止。

Evolution Guardrails

演进护栏

Self-improvement can drift if the agent keeps rewriting from its own guesses. Use these guardrails:

Tie every change to a concrete failure, user correction, test case, or observed repeated work.
Keep traceability: be able to say which experience caused the change and why it was promoted.
Keep before/after behavior comparable; if possible, rerun the same prompts after editing.
Preserve the skill's core identity unless the user explicitly wants a new direction.
Avoid adding broad meta-rules that make the skill trigger everywhere.
Prefer small, reversible edits over large rewrites.
Review and prune stale or over-specific rules when they stop matching current user behavior.
Do not keep self-editing in a loop because a new idea feels plausible. Require evidence or user approval for each iteration.
If two improvement rounds do not improve outcomes, stop and ask for user judgment.

若Agent持续根据自身猜测重写技能，自我改进可能会偏离方向。使用以下护栏：

每次变更都需关联具体故障、用户纠正、测试案例或观察到的重复工作。
保持可追溯性：能够说明变更的触发经验及推广原因。
保持前后行为可比；若可能，编辑后重新运行相同提示。
除非用户明确要求新方向，否则保留技能的核心身份。
避免添加宽泛的元规则，导致技能在所有场景触发。
优先选择小范围、可逆的编辑，而非大范围重写。
当规则不再匹配当前用户行为时，回顾并删除过时或过于具体的规则。
不要因新想法看似合理而陷入自我编辑循环。每次迭代都需要证据或用户批准。
若两次改进循环未提升结果，停止并请求用户判断。

Acceptance Checks

验收检查

Before asking the user to approve a skill write, ensure it is self-contained, minimal, non-duplicative, confirmable, validatable, and privacy-safe. The user must see the exact target path plus the complete proposed skill content or complete diff before the approval question.

请求用户批准技能写入前，确保技能独立完整、精简、无重复、可确认、可验证且隐私安全。用户必须在看到确切目标路径及完整的拟议技能内容或差异后，才能回答批准问题。

Merge Procedure

合并流程

When merging:

Read the target
```
SKILL.md
```
and relevant resources.
Preserve existing user-authored constraints and resources unless explicitly replacing them.
Add only portable, user-evidenced improvements.
Merge semantically; do not append duplicate sections or near-identical bullets.
Keep
```
description
```
strong enough to trigger the skill in future sessions.
Move lengthy details into
```
references/
```
only when needed.
Put deterministic repeated operations in
```
scripts/
```
only when they will actually be reused.
Keep unrelated resource files untouched.

After editing, validate if a validator is available. If

skill-creator

tooling is installed, run:

bash

python3 <skill-creator>/scripts/quick_validate.py <path/to/skill-folder>

Do not perform the edit until the user has approved the proposed target and diff.

合并时：

阅读目标
```
SKILL.md
```
及相关资源。
保留现有用户创建的约束和资源，除非明确替换。
仅添加可移植、有用户证据支持的改进。
语义合并；不要追加重复章节或近乎相同的项目符号。
保持
```
description
```
足够明确，以便未来会话中触发技能。
仅当需要时，将冗长细节移至
```
references/
```
。
仅当操作确实会被复用时，才将确定性重复操作放入
```
scripts/
```
。
保持无关资源文件不变。

编辑后，若有验证工具则进行验证。若已安装

skill-creator

工具，运行：

bash

python3 <skill-creator>/scripts/quick_validate.py <path/to/skill-folder>

获得用户对拟议目标和差异的批准后，才可执行编辑。

Trigger Description Optimization

触发描述优化

The frontmatter

description

is the most important trigger surface. After creating or materially improving a skill, review it separately.

A strong description:

Says what the skill does.
Says when to use it, including user intents and task contexts.
Is specific enough to avoid generic over-triggering.
Is broad enough to catch realistic paraphrases and casual requests.
Mentions file types, tools, domains, or deliverables only when they materially affect triggering.

Use a small trigger eval set when the skill's scope is subtle:

json

[
  {"query": "realistic user request that should trigger", "should_trigger": true},
  {"query": "near-miss request that should not trigger", "should_trigger": false}
]

Include near-miss negatives that share vocabulary with the skill but require a different capability. Avoid easy negatives that prove nothing.

When tuning the description, generalize from failures rather than listing every observed phrase. The description should make the skill easy to discover without becoming a keyword dump.

前置元数据

description

是最重要的触发界面。创建或实质性改进技能后，需单独回顾。

优秀的描述：

说明技能的功能。
说明触发时机，包括用户意图和任务上下文。
足够具体，避免通用过度触发。
足够宽泛，可捕捉真实的转述和随意请求。
仅当对触发有实质性影响时，才提及文件类型、工具、领域或交付物。

当技能范围微妙时，使用小型触发评估集：

json

[
  {"query": "应触发的真实用户请求", "should_trigger": true},
  {"query": "不应触发的近似请求", "should_trigger": false}
]

包含与技能共享词汇但需要不同能力的近似负面案例。避免使用无意义的简单负面案例。

调优描述时，从故障中归纳通用规则，而非列出所有观察到的短语。描述应便于技能被发现，而非成为关键词堆砌。

Create Procedure

创建流程

When creating a new skill:

Choose a short hyphen-case name under 64 characters.
Create
```
<skill-root>/<skill-name>/SKILL.md
```
.
If
```
skill-creator
```
tooling is available, prefer:

bash

python3 <skill-creator>/scripts/init_skill.py <skill-name> --path <skill-root>

Write only the required skill content:
- frontmatter with
```
name
```
  and
```
description
```
- concise body instructions
- optional
```
agents/openai.yaml
```
  metadata when supported
- optional
```
scripts/
```
  ,
```
references/
```
  , or
```
assets/
```
  only when useful
Do not create README files, changelogs, install guides, or extra process notes unless the skill itself needs them to function.
Validate with available tooling or manually check YAML frontmatter, naming, and trigger clarity.

Do not create the folder or write files until the user has approved the proposed skill.

创建新技能时：

选择长度不超过64字符的短连字符格式名称。
创建
```
<skill-root>/<skill-name>/SKILL.md
```
。
若
```
skill-creator
```
工具可用，优先使用：

bash

python3 <skill-creator>/scripts/init_skill.py <skill-name> --path <skill-root>

仅写入必要的技能内容：
- 包含
```
name
```
  和
```
description
```
  的前置元数据
- 简洁的正文指导
- 支持时可选的
```
agents/openai.yaml
```
  元数据
- 仅当有用时可选的
```
scripts/
```
  、
```
references/
```
  或
```
assets/
```
除非技能本身需要，否则不要创建README文件、变更日志、安装指南或额外流程说明。
使用可用工具验证，或手动检查YAML前置元数据、命名及触发清晰度。

获得用户对拟议技能的批准后，才可创建文件夹或写入文件。

Skill Writing Standards

技能编写标准

Borrow these skill-creator principles:

Keep the skill concise; include only context a future agent needs.
Put all trigger-critical "when to use" language in the frontmatter
```
description
```
.
Use imperative instructions.
Prefer reusable examples over long explanations.
Use progressive disclosure: keep
```
SKILL.md
```
lean and move large references into
```
references/
```
.
Add scripts only for repeated, deterministic, or error-prone operations.
Add assets only when they are meant to be reused in outputs.

借鉴以下skill-creator原则：

保持技能简洁；仅包含未来Agent需要的上下文。
将所有触发关键的“何时使用”语言放入前置元数据
```
description
```
。
使用命令式指导。
优先选择可复用示例，而非长篇解释。
使用渐进式披露：保持
```
SKILL.md
```
精简，将大型参考资料移至
```
references/
```
。
仅为重复、确定性或易出错的操作添加脚本。
仅当资产用于输出复用时才添加。

Completion Note

完成笔记

After managing local skills, report the decision, target path or "no file changed", intended audience and portability limits, title/topic selected if any, approval status, reuse-boundary reason, similar skills checked, validation run, changed sections/files for updates, and whether maintenance completed synchronously or was deferred.

管理本地技能后，需报告决策结果、目标路径或“无文件变更”、目标受众及可移植性限制、所选标题/主题（若有）、批准状态、复用边界理由、已检查的相似技能、已执行的验证、更新的章节/文件，以及维护是同步完成还是已推迟。

autoskill

Original

Translation

Local Skill File Manager

本地Skill文件管理器

Purpose

用途

Related Skill Coordination

相关技能协作

Safety And Consent

安全与同意

Skill Roots

技能根目录

Trigger Policy

触发策略

Candidate Lifecycle

候选技能生命周期

Title Selection Gate

标题选择关卡

Language Consistency

语言一致性

Background Execution

后台执行

Confirmation Gate

确认关卡

Immediate Triggers

即时触发器

Scheduled Checks

定期检查

Debounce And Batching

防抖与批处理

Experience Triage

经验分类

Value And Priority Gate

价值与优先级关卡

Promotion Rules

推广规则

Experience Record Shape

经验记录格式

When To Improve Existing Skills

何时改进现有技能

Extraction Boundary

提取边界

Evidence Levels

证据级别

Pre-Edit Memory Check

编辑前记忆检查

Candidate Shape

候选技能格式

Similar Skill Search

相似技能搜索

Decision Rules

决策规则

Improvement Loop

改进循环

Evolution Guardrails

演进护栏

Acceptance Checks

验收检查

Merge Procedure

合并流程

Trigger Description Optimization

触发描述优化

Create Procedure

创建流程

Skill Writing Standards

技能编写标准

Completion Note

完成笔记