If you re-send the same request to AI every week, this article is for you.
For example, every Friday, you tell Codex:
First organize this week's results, refine problems and experiences, and finally list next week's actions. Don't fabricate data, every action must have completion standards.
This is the first time I wrote it like this, called a prompt word.
But if you write this every week, there is already a fixed workflow behind it.
Organize this set of workflows into a folder so that Codex will know when encountering similar tasks in the future:
- When should I take over;
- What steps should be followed;
- What standards the output needs to meet.
This is Skill.
The essence of Skill is to condense the methods of doing things in your mind into a system that can be implemented repeatedly.
This article will use "Weekly Review" as an example to take you through the complete process:
Find the workflow → disassemble the workflow → create a Skill → test → upload GitHub
You don't need to know programming first.
1. Understand first: What exactly is Skill?
You can think of Codex as a very capable new colleague.
It can write code, organize data, and analyze data, but it doesn't know your work habits:
- Under what circumstances to initiate a task;
- What you usually do first, then what you do;
- Which rules cannot be violated;
- What kind of result is completed.
Skills are like the copy you gave this new colleague:
Job description + standard process + tool kit
A Skill usually solves four things:
- when to useWhich tasks should trigger it.
- how to implementWhat process should be followed after receiving the task?
- What can I call?Whether scripts, templates, and reference materials are needed.
- What is completed?What criteria must the final output meet?
Ordinary prompt words only solve the task once.
Skill fixes a type of task.
Prompt words tell AI:
Help me do this time.
Skill told AI:
What should you do if you encounter this kind of thing in the future?
2. What tasks are worth completing skills?
Don't immediately do skills when you see a prompt.
Ask yourself four questions first:
- Will this happen again?
- Are the inputs and outputs relatively stable?
- Are there fixed steps in the middle?
- Changing AI, does it need to be reinterpreted?
If three answers are "yes", it is usually worth settling down.
Suitable tasks for skills:
- Organize reviews and plans every week;
- Write X long texts according to fixed rules;
- Implement a checklist before releasing a product;
- Review risk items in the contract;
- Reply to customer service according to brand specifications;
- Convert meeting minutes into task lists;
- Batch processing fixed format data.
Not suitable for skills:
- One-time temporary tasks;
- Problems that can be described in one sentence;
- Creation that relies entirely on inspiration;
- The borderless goal of "helping me handle everything".
Many people want to do the first Skill:
Content operations assistant.
This is the easiest way to fail.
The larger the range, the more blurred the trigger and the more unstable the result.
A good Skill is not about being omnipotent, but doing a specific thing stably and well.
3. Don't create files first, disassemble your workflow first
Before creating a Skill, write a workflow card:
工作流名称：
什么时候启动：
用户会提供什么：
执行步骤：
1.
2.
3.
最后输出什么：
什么结果算合格：
信息不足时怎么办：
For example:
工作流名称：
把一周零散记录整理成复盘
什么时候启动：
用户提出周报、每周复盘、一周总结、工作回顾时
用户会提供什么：
完成事项、问题、数据、下周计划
执行步骤：
1. 提取事实和数据
2. 分类成果、问题、经验
3. 合并重复信息
4. 转换成下周行动
5. 检查是否存在编造
最后输出什么：
结构化周复盘和行动计划
什么结果算合格：
不虚构数据，每个行动都有完成标准
信息不足时怎么办：
标记待补充，最多提出3个问题，不猜测
This step is very important.
Because the description, execution process and quality standards of the Skill basically come from this card.
If you can't even write this card clearly, your workflow is not stable yet.
Don't wrap chaos into skills.
Think clearly about your own method first.
4. Creating Skills: Start with the smallest version
The simplest Skill only needs:
weekly-review/
└── SKILL.md
Complete it:
weekly-review/
├── SKILL.md
├── agents/
│ └── openai.yaml
├── scripts/
├── references/
└── assets/
Each directory is responsible for different things:
SKILL.md: Write trigger conditions, processes and standards;agents/openai.yaml: Define display information;scripts/: Store code that is repeatedly executed;references/: Maintain background information;assets/: Save templates and materials.
Don't create a bunch of empty directories in the first place.
Skill takes up context.
Keep only what you really need.
5. Let Codex help you generate skills
Recommended Skill names:
- Lower case English;
- Numbers;
- Hyphen.
For example:
weekly-review
x-article-writer
release-checker
contract-risk-check
Then ask Codex to use skill-creator:
请使用 skill-creator，把下面的工作流制作成一个 Skill。
Skill 名称：
weekly-review
工作流：
[粘贴工作流卡片]
要求：
1. 创建在当前项目中；
2. 只生成必要文件；
3. 完成后验证；
4. 告诉我如何测试和安装。
After generation:
weekly-review/
├── SKILL.md
└── agents/
└── openai.yaml
Note:
Generating files is just the beginning.
It is SKILL.md that really determines whether Skill is easy to use.
6. Write SKILL.md well: The focus is not on introduction, but on specifying implementation methods
SKILL.md is usually divided into two parts:
1. YAML header: Decide when to trigger
For example:
---
name: weekly-review
description: 将一周零散记录整理成结构化复盘和下周行动计划。当用户提到周报、每周复盘、一周总结、工作回顾，或要求从流水账中提炼成果、问题、经验和下一步行动时使用。
---
Description is important.
It must answer:
Two questions:
- What does this Skill do?
- When should users use it?
Don't just write:
帮助用户复盘
Too vague.
You should write:
当用户需要整理周报、复盘、总结流水账时使用
2. Markdown text: Tell AI how to perform
Recommended structure:
# Skill名称
目标说明
## 工作流程
1. 收集输入
2. 提取事实
3. 分类整理
4. 输出结果
## 信息不足时
- 不允许猜测
- 缺少数据时标记待补充
## 输出格式
固定栏目
## 质量标准
- 必须包含什么
- 禁止出现什么
For example:
## 工作流程
1. 提取事实：识别完成事项、数据、问题。
2. 分类整理：归入成果、问题、经验。
3. 制定行动：转换成下一步任务。
4. 检查输出：避免空话和虚构。
## 质量标准
- 区分事实和推断。
- 每个行动必须有完成标准。
- 避免“持续优化”等无意义表达。
Remember:
Skills are not a knowledge base.
It is an execution manual.
If you can explain clearly in 30 lines, don't write 300 lines.
7. Verification, testing, and installation
Verify first:
请使用 skill-creator 验证 ./weekly-review。
如果发现格式问题，请直接修复。
Main inspections for verification:
- Document structure;
- YAML format;
- Whether name exists;
- Whether description exists;
- Whether the naming conforms to the rules.
However, passing the verification does not mean that Skill is easy to use.
Real testing requires three types of cases:
1. explicit invocation
请使用 $weekly-review 整理下面的记录。
Whether the test was performed correctly.
2. natural expression
帮我把这些流水账整理成周报。
Test whether description can trigger.
3. insufficient information
这周主要做支付功能，帮我复盘一下。
Test whether it will be fabricated.
Good Skill is not just about completing tasks.
It also knows when to say:
There is insufficient information and needs to be supplemented.
8. Upload GitHub to make Skill your long-term asset
Skills are essentially code assets.
Uploading GitHub can:
- Save the version;
- Multiple device synchronization;
- Share with the team;
- Continuous optimization.
Inspection before submission:
Do not upload:
- API Key;
- Token;
- Password;
- customer information;
- Internal company rules.
Then:
git init -b main
git add .
git commit -m "feat: add weekly review skill"
git remote add origin <仓库地址>
git push -u origin main
Modify later:
git add .
git commit -m "improve skill workflow"
git push
Finally: Make your first Skill today
Open your chat history.
Find a task that you have explained to the AI more than twice in the past month.
Don't write code first.
First complete a workflow card:
- When to start;
- What users provide;
- Implementation steps;
- What to export;
- What is completed;
- What to do if there is insufficient information?
Then hand it over to the skill-creator.
The first edition does not need to be perfect.
Let it run first and optimize it based on the real results.
There is only one sentence at the core of Skill:
Change "I have to reinterpret it every time" to "It will know what to do later."