Skill Beginner to Master

This chapter will no longer discuss in general terms whether you should install a large number of Skills.

We will focus on just one real-world scenario:

For any meeting involving collaboration among multiple people, action items must be compiled within 24 hours after the meeting. Each action item must include an owner, a deadline, a deliverable, and an approver. An item without an owner or deadline cannot enter the to-do list. When Xiaowang is mentioned, merge the item into his work schedule, which is normally located at week-jobs/xiaowang.md under the project path.

This is not a request to polish meeting minutes.

What it actually requires is post-meeting action follow-up:

• Identify action items in the meeting materials.
• Filter out items that lack an owner or deadline.
• Preserve the owner, deadline, deliverable, and approver.
• When an item relates to Xiaowang, merge it into week-jobs/xiaowang.md.

This kind of Skill is particularly useful for explaining beginner pitfalls.

It looks small, but its boundaries can expand very easily. If you are not careful, you will turn it into a super-Skill that manages every meeting, every to-do item, everyone's work schedule, and all project management. In the end, it will trigger incorrectly, edit the wrong files, and consume a large chunk of context every time it runs.

Here is the conclusion up front:

A post-meeting action follow-up Skill should be a project-level, strongly triggered, lightweight, narrowly scoped, and regression-testable unit of work.

Why?

Because a Skill is not an always-on brain enhancement pack. Codex usually sees the Skill's name and description first, then loads the full SKILL.md only when it is relevant to the task. Once loaded, the body enters the context and competes for space with the user request, conversation history, and system prompt.¹²

So this chapter uses the same post-meeting action follow-up Skill to explain eight pitfalls that beginners encounter most often.

1. Installing Project Rules at User Level

The first step for a post-meeting action follow-up Skill is not writing its body. It is deciding where the Skill should be installed.

This example contains one crucial clue:

The work schedule is normally located at week-jobs/xiaowang.md under the project path.

Whenever a rule refers to a project path, project file, or project member, prefer a project-level Skill.

For example, if your project is /Users/wing/Develop/codex-tranfu-demo, this Skill is better placed at /Users/wing/Develop/codex-tranfu-demo/.codex/skills/organize-meeting-actions/SKILL.md.

It should not be installed directly at user level.

The reason is simple: week-jobs/xiaowang.md is not a file that exists in every project. Xiaowang is not a person in every project, either. If you install this rule at user level, Codex may assume that it should look for this file in other projects, or even create a week-jobs/xiaowang.md that should not exist.

User-level Skills are more suitable for general methods, such as:

• How to determine whether a Skill is worth creating.
• How to review a Skill's description.
• How to publish or install a Skill.
• How to clarify ambiguous requirements by asking questions.

Project-level Skills are the right place for rules like these:

• Compile action items within 24 hours after a meeting involving collaboration among multiple people.
• Each action item must include an owner, a deadline, a deliverable, and an approver.
• An item without an owner or deadline cannot enter the to-do list.
• Items related to Xiaowang must be merged into week-jobs/xiaowang.md.

The decision is straightforward:

A common beginner mistake is treating "I use this often" as "every project should use this."

Think about a post-meeting action follow-up Skill in the opposite way:

If it reads or writes a specific file in the current project, treat it as project-level first.

2. Letting Adjacent Skills Compete for Scope Before Identifying the Primary Skill

More precisely, the problem is usually not whether you split the work into many micro-Skills.

In real work, people rarely break a procedure into tiny parts and turn every field check into a separate Skill.

The more realistic problem is that your toolkit already contains several Skills that all seem capable of handling part of the task.

For example:

All of these names are reasonable, and none represents arbitrary over-decomposition.

The problem appears when the user says only:

Organize Xiaowang's follow-up items from this meeting.

Which one should be used?

More Skills do not automatically make the system stronger. A Skill is more like an operation card invoked on demand. Installing many Skills does not mean they will all help every time; Skills are used automatically based on task relevance, so you do not need to name each one manually.³

You need to identify the "primary Skill" first.

The primary Skill is determined not by what the input looks like, but by the indispensable final result.

If the user only wants:

Turn this meeting record into minutes.

Then the primary Skill can be meeting-notes-summary, or even an ordinary prompt.

If the user wants:

Extract Xiaowang's follow-up items from the meeting and merge them into his work schedule.

Then the primary Skill should be the project-level:

organize-meeting-actions

The success of this task does not depend on how polished the minutes are. It depends on:

• Whether follow-up-ready action items were extracted.
• Whether items without an owner or deadline were filtered out.
• Whether Xiaowang's items were merged into week-jobs/xiaowang.md.
• Whether existing tasks were protected from being overwritten.

Other Skills can assist, but they should not take control.

For example, if the Lark transcript is messy, lark-meeting-cleanup can clean up the material first. But organize-meeting-actions should still decide whether an action item enters the to-do list and whether it is written to week-jobs/xiaowang.md.

Before installing the Skill, ask these five questions:

Do not install these yet:

• It only makes meeting content sound better.
• You only occasionally organize a task for Xiaowang.
• Its description says "content organization, to-do management, and project advancement."
• It differs from an existing meeting-minutes Skill only in name, not in failure criteria.
• It needs to read and write files, but you have not confirmed which paths it will change.

You can first ask Codex to clean up your Skill toolkit:

Review the Skills currently available to me.
 
Evaluate them only in the context of "post-meeting action follow-up":
1. Which Skill should be the primary Skill?
2. Which Skills should only clean up inputs first or provide auxiliary output?
3. Which descriptions are too broad and may take over the wrong tasks?
4. Which Skills should be merged, renamed, narrowed, or left unused for now?
 
Give the reasoning and recommended actions without explaining the concepts.

A good Skill does not depend on having many names. It depends on consistently identifying the primary task.

Post-meeting action follow-up is exactly this kind of task: repetitive, governed by clear rules, and costly when done incorrectly.

3. Writing the description as "Meeting-Minutes Organization"

The description is the easiest place for a post-meeting action follow-up Skill to fail.

A bad example usually looks like this:

description: Organize meeting minutes, extract to-do items, and improve meeting content.

This may look correct, but it is far too broad.

It creates three problems.

1. An ordinary meeting summary may trigger it. The user wants only a short summary of the minutes, but Codex may start checking owners and deadlines.
2. Ordinary to-do organization may trigger it. The user is only organizing a personal todo list, but Codex may start looking for week-jobs/xiaowang.md.
3. Article or weekly-report polishing may trigger it. The phrase "improve meeting content" sounds too much like a content-processing Skill.

The description is the sign on the Skill's door. Codex usually reads the sign first, then decides whether to load the complete SKILL.md. Make the sign too broad, and passersby will enter; make it too narrow, and the right visitors will not.⁴

For this example, the description must clarify four things:

You can write it like this:

description: Organize transcripts, chat logs, and fragmentary notes from meetings involving collaboration among multiple people; extract post-meeting action items; and check whether every action item includes an owner, deadline, deliverable, and approver. Items without an owner or deadline must not enter the to-do list. When meeting content mentions Xiaowang, or when the user asks to synchronize Xiaowang's post-meeting items, merge Xiaowang's action items into week-jobs/xiaowang.md within the project. Use for post-meeting action follow-up, post-meeting to-do organization, and synchronization of Xiaowang's work schedule. Do not use for ordinary meeting summaries, article polishing, personal notes, strategic decisions, performance evaluations, or confirming undecided items on behalf of an owner.

After writing it, do not rely on a feeling that it should work. Run trigger tests directly.

It should trigger for:

• Organize the action items from this meeting and synchronize anything mentioning Xiaowang to his work schedule.
• Process this Lark meeting record as post-meeting to-dos. Do not put items with an incomplete owner or deadline into the list.
• Merge the tasks Xiaowang accepted in the meeting into week-jobs/xiaowang.md.

It should not trigger for:

• Make this meeting summary sound more formal.
• Help me polish this weekly report.
• Organize my personal todo list for today.
• Evaluate Xiaowang's performance this week.

Reusable prompt:

Help me improve the description of this post-meeting action follow-up Skill.
 
Requirements:
1. Preserve the "meeting involving multiple collaborators -> action items -> Xiaowang's work-schedule file" boundary.
2. Explicitly name the four fields: owner, deadline, deliverable, and approver.
3. Make clear that an item without an owner or deadline cannot enter the to-do list.
4. Add eight realistic user requests that should trigger it.
5. Add eight adjacent scenarios that should not trigger it.
6. Change only the description, not the body.
 
Skill path:
[Paste the SKILL.md path]

If the post-meeting action Skill often triggers incorrectly, do not rush to blame the model. Most of the time, the description also includes adjacent tasks such as meeting summaries, to-do management, and project management.

4. Putting Every Meeting Rule into SKILL.md

Once the post-meeting action follow-up Skill triggers, the complete SKILL.md enters the context.

That is why it cannot become an encyclopedia of meeting management.

The context window is a shared resource. The Skill competes for context with the system prompt, conversation history, other Skill metadata, and the user request. Even when everything in SKILL.md is sensible, if the file is too long, every token competes with other information as soon as it loads.¹

The main file for this example should be short.

What belongs in SKILL.md is the set of rules that must be known immediately during execution:

• Handle only post-meeting action follow-up for meetings involving collaboration among multiple people.
• Each action item must include an owner, a deadline, a deliverable, and an approver.
• An item without an owner or deadline must not enter the to-do list.
• When Xiaowang is mentioned, merge the item into week-jobs/xiaowang.md.
• Read the existing file before updating it to avoid overwriting old tasks.
• When the owner, deadline, or approver cannot be determined, place the item under pending confirmation instead of inventing a value.

What does not belong in the main file is low-frequency background material:

• An explanation of the company's meeting culture.
• A description of every team member's responsibilities.
• A tutorial on writing meeting minutes.
• Project-management theory.
• Complete examples from historical meetings.

If long materials are genuinely necessary, move them into references/:

But moving them out is not enough. You must also state when to read them.

These instructions are useful:

• When the user asks for an explanation of the action-item field format, read references/action-item-format.md.
• When an unfamiliar member abbreviation appears in the meeting, read references/team-members.md.
• When the user asks to match historical conventions, read references/follow-up-examples.md.
• By default, do not read the long examples under references/.

Do not write only:

See references/ for more information.

That sentence does not help Codex much. It knows a warehouse exists, but not which crate to open.

Fixed checks can be automated with scripts.

For example, this Skill's stable validation can live under scripts/:

• Check whether every output action item has an owner.
• Check whether every output action item has a deadline.
• Check whether any old task in week-jobs/xiaowang.md was accidentally deleted.
• Check whether any pending-confirmation item was written into the formal to-do list.

There is another kind of content that belongs neither in references/ nor in scripts/.

It consists of explicit actions in the critical task workflow.

For example, suppose the post-meeting action follow-up Skill says only:

• Clarify when necessary.
• Break down the task when necessary.
• Check files when necessary.

That is not enough.

Those statements are too weak, so Codex is likely to continue immediately. When a critical workflow step is missing, name the closest corresponding Codex action explicitly. Official Codex guidance recommends planning first for complex or ambiguous tasks, and you can also ask Codex to interview you first. Subagents do not trigger automatically, either; you must explicitly request that Codex spawn or delegate.⁵⁶

In this Skill, you can write it this way:

Notice that this does not mean copying Claude Code names such as AskUserQuestion and TaskCreate into a Codex Skill.

A more reliable approach is to specify actions that Codex can directly execute or understand:

• If a critical field is missing, enter Plan mode or interview the user before continuing; do not write files.
• If the meeting materials exceed one screen or contain multiple meetings, spawn one subagent to extract candidate action items only. The main agent decides which items can enter the formal to-do list.
• Maintain update_plan during execution with at least these steps: extract action items, filter items with missing fields, read Xiaowang's existing work schedule, merge new items, and inspect the diff.

Reusable prompt:

Compress this post-meeting action follow-up Skill.
 
Goals:
1. Remove meeting-management background and general explanations the Agent already knows.
2. Preserve trigger boundaries, action-item fields, pending-confirmation rules, and file-update rules.
3. Move low-frequency examples into references/.
4. Move mechanically checkable field-integrity rules into scripts/.
5. State in SKILL.md when each reference and script should be used.
6. Add critical workflow actions: when to Plan/interview, when to use update_plan, when to spawn a subagent, and when to read or write files.
7. Do not change the "meeting involving multiple collaborators -> action items -> Xiaowang's work schedule" task boundary.
 
Skill path:
[Paste the SKILL.md path]

Whether a post-meeting action follow-up Skill consumes too many tokens depends not only on whether it is useful, but also on whether it brings all its low-frequency materials to the table.

5. Expanding Post-Meeting Action Follow-Up into Project Management

Should this Skill be larger, or should it be split into smaller Skills?

Do not decide by word count.

Decide by unit of work.

A more reliable method is to ask three questions:

1. Are the inputs of the same kind?
2. Are the outputs of the same kind?
3. Are the failure criteria the same?

For post-meeting action follow-up:

These can live in the same Skill:

Do not casually add the following. Not because they are unimportant, but because they are closer to a different primary task:

Why can writing to Xiaowang's file stay in the same Skill?

Because it is not a separate task. It is the final action in this post-meeting follow-up workflow. If the meeting mentions Xiaowang but his work schedule is not updated, the Skill has not achieved its goal.

Why should archiving every member's items not be added directly?

Because the input, output, and failure criteria have all changed. The task is no longer about Xiaowang's items in one meeting; it is maintaining a work ledger for every member. That could be another Skill or a later workflow, but it should not be slipped into the current Skill.

Reusable prompt:

Help me decide whether this post-meeting action follow-up Skill should be split or kept together.
 
Candidate scope:
1. Organize action items from meetings involving collaboration among multiple people.
2. Check the owner, deadline, deliverable, and approver.
3. Write items related to Xiaowang into week-jobs/xiaowang.md.
4. Archive every member's items under week-jobs/.
5. Draft post-meeting reminder messages based on meeting content.
 
Use only these three criteria:
1. Are the inputs of the same kind?
2. Are the outputs of the same kind?
3. Are the failure criteria the same?
 
Finally, output:
1. Keep one / split into several / merge into an existing Skill.
2. Recommended Skill names.
3. Recommended description boundaries.
4. Adjacent scenarios it must not cover.

When deciding whether to split or combine, do not ask whether the Skill could also handle something along the way. The boundary of a post-meeting action follow-up Skill usually bursts when someone says, "While you're at it, synchronize everyone's schedule too."

6. Copying Every Prompt into the Skill Body

A prompt governs this one occasion.

A Skill governs every future occasion.

Post-meeting action follow-up is particularly good at illustrating this distinction.

If, after one particular meeting, you say:

• Use a more conversational tone for these minutes.
• Keep only technical items this time.
• Do not update Xiaowang's file this time; show me a draft first.

Those are prompts.

They affect only this occasion and should not be written into the Skill.

But the following rules must be followed every time:

• Compile action items within 24 hours after a meeting involving collaboration among multiple people.
• Each action item must include an owner, a deadline, a deliverable, and an approver.
• An item without an owner or deadline cannot enter the to-do list.
• When Xiaowang is mentioned, merge the item into week-jobs/xiaowang.md.
• Read the old file before updating it, then merge rather than overwrite.
• Put uncertain items under pending confirmation instead of inventing details.

These belong in the Skill.

The documentation explains this distinction clearly: a prompt is a one-time, conversation-level instruction; a Skill is a reusable capability loaded on demand. Skills are suitable for repeatable work such as team processes, brand guidelines, meeting-minutes formats, and data-analysis workflows. Custom instructions apply more broadly, while Skills load only for relevant tasks.⁸²

A simple decision guide:

Never turn a Skill into a collection of everything you might want to say on every occasion.

A post-meeting action follow-up Skill should fix only these things:

• What kind of meeting materials it handles.
• What steps it follows to extract action items.
• Which fields it outputs.
• Which items cannot enter the to-do list.
• When it updates Xiaowang's file.
• How it handles uncertainty.
• How it verifies that no fields were missed and no old tasks were overwritten.

Reusable prompt:

Decide whether each requirement below belongs in the post-meeting action follow-up Skill or should remain in this prompt.
 
Rules:
1. [Rule 1]
2. [Rule 2]
3. [Rule 3]
 
Decision criteria:
1. Applies only to this meeting -> prompt.
2. Must be followed after every meeting -> Skill.
3. Long but infrequently used -> references/.
4. Can be validated automatically -> scripts/.
 
Output a table without elaborating.

In one sentence: if you want it only today, use a prompt; if you do not want to explain it again every time, write it into the Skill.

7. Rewriting the Entire Skill When It Goes Off Track After Publication

It is normal for a post-meeting action follow-up Skill to go off track the first time it runs after publication.

But do not rewrite the whole thing.

Classify the problem first.

Even when the observed result is simply "it went off track," the causes can be completely different:

The first version of a Skill often needs revision after real tasks. More importantly, examine the execution trace, not only the final result. If the Agent wastes steps, common causes are overly broad or inapplicable rules, or too many equal-priority options. Trigger problems should also be tested repeatedly against should-trigger and should-not-trigger query sets.⁹⁴

Remember three rules when making changes:

1. Change only one problem at a time.
2. After each change, run a regression using the same meeting materials.
3. Do not overfit the description to one failure case.

Add one more, even more important rule:

• If the missing piece is a task workflow, do not merely add "remember to check"; add an explicit action.
• If the missing piece is a long subtask, do not force the main agent to handle it; assign it explicitly to a subagent and specify that the subagent should return a summary.

For example, suppose the failure is:

The meeting said, "Xiaowang should first create a mock using the current fields," but no deadline was specified. Codex wrote it into the formal to-do list.

Do not rewrite the entire Skill.

Add just one gotcha:

If an action item lacks an owner or deadline, it must be placed under "Pending confirmation." It must not be written into the formal to-do list or into week-jobs/xiaowang.md.

Then run the same meeting materials again as a regression.

If the failure is:

The meeting materials were long. Codex pasted a large amount of transcript detail into the main thread and ultimately missed two of Xiaowang's tasks.

Do not merely add "read the meeting materials carefully."

Turn it into an executable subagent rule:

When the meeting materials are long or contain multiple transcript segments or meetings, spawn one subagent. That subagent only extracts candidate action items and returns the owner, deadline, deliverable, approver, and supporting source text. The main agent does not receive the long raw transcript; it receives only the summary and then decides which items can enter the formal to-do list and week-jobs/xiaowang.md.

If the failure is:

Codex extracted the action items but forgot to read week-jobs/xiaowang.md first and directly overwrote the old content.

Turn it into a planning rule:

Execution must maintain update_plan and must not skip these five steps: extract candidate action items, filter items without an owner or deadline, read the old content of week-jobs/xiaowang.md, merge new items, and inspect the diff to confirm that no old item was deleted.

Reusable prompt:

This post-meeting action follow-up Skill went off track after publication.
 
Failure:
[Describe exactly what went wrong]
 
Actual meeting materials:
[Paste the triggering request and meeting content]
 
Classify the problem first:
1. Triggering issue.
2. Execution-step issue.
3. Output-format issue.
4. Missing gotcha.
5. Should be scripted.
6. Whether an explicit workflow action is missing, such as Plan/interview/update_plan/file reading and writing.
7. Whether an overly long subtask should be delegated to a subagent.
 
Then make only the smallest change.
Do not rewrite the entire SKILL.md.
After the change, rerun the same meeting materials once.

Iteration on a post-meeting action follow-up Skill does not depend on a grand refactor. It depends on catching one deviation at a time.

8. Ignoring Permissions and Scripts Before Installing from the Company Repository

Even a Skill in the company repository should not be installed blindly.

A post-meeting action follow-up Skill demands particular care because it usually reads and writes project files:

• Read meeting materials.
• Read week-jobs/xiaowang.md.
• Modify week-jobs/xiaowang.md.
• Possibly read descriptions of team members under references/.
• Possibly run scripts/ to check fields.

The documentation says this directly: install Skills only from trusted sources. Before installing a less-trusted Skill, inspect its files, dependencies, resources, and external network access. The main Skill risks include prompt injection and data exfiltration.³

In plain English:

It may induce the Agent to do things it should not do, or carry data outside that should remain private.

Before installing this Skill, check at least six things:

1. Does the task boundary in SKILL.md cover only post-meeting action follow-up?
2. Does the description overgeneralize into content organization, project management, or performance evaluation?
3. Do allowed-tools and disallowed-tools grant excessive permissions?
4. Do any scripts under scripts/ read or write paths outside week-jobs/?
5. Does it require third-party packages?
6. Does it access an external network or upload meeting content?

Prefer installing Skills that:

• Have been validated by the team.
• Cover only post-meeting action follow-up.
• Explicitly state which file paths they read and write.
• Read existing content before updating a file.
• Do not write an item without an owner or deadline into the formal to-do list.
• Use scripts only for local field checks.

Do not install these yet:

• The description says "organize meetings, synchronize to-dos, advance projects, and track members."
• Scripts scan the entire project directory by default instead of being limited to week-jobs/ and meeting materials.
• Network access is required without an explanation.
• Meeting content is sent to an external service.
• Member performance is evaluated automatically from meeting content.

Reusable prompt:

Review whether this post-meeting action follow-up Skill from the company repository is suitable for installation in a real project.
 
Check:
1. Whether SKILL.md covers only action follow-up after meetings involving collaboration among multiple people.
2. Whether the description is too broad and may incorrectly trigger for ordinary summaries, weekly reports, or project management.
3. Whether allowed-tools and disallowed-tools are appropriate.
4. Whether scripts/ performs only local field checks and whether it reads or writes sensitive files.
5. Whether it accesses an external network or uploads meeting content.
6. Whether it explicitly protects the existing content of week-jobs/xiaowang.md.
7. Whether it overlaps with my existing meeting-minutes or to-do Skills.
 
Output:
1. Recommended to install / do not install yet / try only in a practice project.
2. Risks.
3. Questions to ask the maintainer before installation.

A company repository is not automatically a trusted zone. Meeting content and member work schedules may both be sensitive. The more a Skill can read and write project files, the more carefully you should inspect what it can touch.

Post-Meeting Action Follow-Up Skill Pitfall Checklist

Put this table at the beginning of every review.

Final review prompt for Codex:

Review this Skill using the "Post-Meeting Action Follow-Up Skill Pitfall Checklist."
 
Check eight things:
1. Whether it should be installed at project level.
2. Whether it is worth creating or installing.
3. Whether the description is likely to trigger incorrectly.
4. Whether SKILL.md is too heavy.
5. Whether its scope should be split or kept together.
6. Which content should remain in the prompt.
7. Whether explicit workflow actions are missing, including Plan/interview/update_plan/file reading and writing/subagent delegation.
8. Whether it is suitable for installation from the company repository into a real project.
 
Requirements:
1. Start with the conclusion: keep / revise / installation not recommended.
2. For each item, state only the problem and the smallest recommended change.
3. Do not rewrite the entire Skill.
 
Skill path:
[Paste the SKILL.md path]

The real strength of a post-meeting action follow-up Skill is not putting the words "meeting minutes" into a new file.

Its strength is fixing the rules that are easiest to overlook, invent, or apply to the wrong file during post-meeting follow-up.

The next time you provide a meeting record, Codex should not merely write an elegant summary.

It should know:

• Which items are action items.
• Which items have missing fields and cannot enter the to-do list.
• Which items belong to Xiaowang.
• Which project file they should be merged into.
• Which uncertainties require a question.

That is the difference between a Skill and an ordinary prompt.

A prompt handles this occasion.

A Skill establishes the rules for every future occasion.

References

This article uses only primary sources that translate into concrete actions: