← Guides

Skill Guide: Turn Repeated Work Into Reusable Skills

Thomas Meli & Agent Team
50 min leftPage 54/81 (est.)27 left
9

Build your second Skill and start a weekly review

You have one ; now build the system around it

You created a through conversation, tested its , built foundation files, ran it with real input, and absorbed corrections. That is one complete Skill. A is two or more Skills plus your foundation files, with a habit that keeps them current.

This chapter walks you through creating a second , then setting up the weekly review that turns this from a one-time exercise into a compounding system.

Choose your second

Go back to your discovery table. You identified repeated tasks. You built the first one into a . Now pick the second one. If none of the remaining candidates feel right, use the pattern table below to spark a choice, then try one of the five scenarios that follow.

Skills cluster into recognizable patterns. Now that you have built one, this table helps you name what kind of your second candidate is and choose the right structure for it.

A stylized radial mind map showing second Skill patterns including preference, process, review, research, teaching, code, and capture.
When you are choosing a second , start by naming the shape of repeated work.

If none of your discovery candidates feel right, choose one of the five scenarios below. Each is a task most knowledge workers repeat weekly.

Scenario A: Follow-Up Email After a Meeting

You finish a call and draft the same kind of email every time: decisions first, then action items with owners, then open questions. You keep correcting the AI on your format, your tone, and what to leave out.

To create this , start a conversation and say: 'I want to create a skill that drafts follow-up emails after meetings. When I paste a transcript or my notes and say draft the follow-up, it should produce a ready-to-send email with decisions first, then action items with owners, then open questions. It should match my voice samples and never include internal-only commentary in the email.'

Scenario B: Weekly Status Update

Every week you summarize what happened for your manager, your client, or your team. The structure is always the same. The detail level is always the same. You keep restating both even though the AI may already know your basic preferences.

To create this , say: 'I want to create a skill for weekly status updates. It should take my rough notes from the week and produce a three-section update: completed, in progress, and blocked. One sentence per item. Blockers should be flagged, not buried. It should never list meetings as accomplishments.'

Scenario C: Draft Review Before Sending

Before you send an email, a proposal, or a slide deck, you run the same mental checklist: right tone, no banned words, no accidental budget commitments, right audience level. That checklist belongs in a so the AI can run it for you.

To create this , say: 'I want to create a skill that reviews drafts before I send them. When I say review this or is this ready to send, it should check for my banned words, verify audience fit, flag anything that commits budget or schedule, and produce a review table with issue, location, severity, and suggested fix. It should flag issues, not rewrite the draft.'

Scenario D: Notes-to-Structure Converter

You come out of a meeting, a brainstorm, or a research session with a pile of rough notes. You need them in a table or a brief with a consistent structure, and you keep telling the AI the same column names and the same rules about handling ambiguity.

To create this , say: 'I want to create a skill that turns raw notes into structured documents. When I paste unstructured notes and say organize this or structure these notes, it should produce a table with the columns I specify (usually item, owner, deadline, status). It should preserve ambiguity as tentative and never invent structure that was not in the source.'

Scenario E: Meeting Preparation Brief

You walk into meetings cold. You forget what was decided last time, who cares about which topic, and what the open threads are. A meeting-prep pulls from your recent history and produces a one-page brief you can scan in five minutes before the call.

To create this , say: 'I want to create a skill for meeting preparation. When I say "prep for my call with [name]" or "meeting prep," it should produce a one-page brief with meeting , open threads from prior meetings, stakeholder positions, three hard questions that surface real disagreement, and a suggested agenda. It should never invent stakeholder positions, and if it does not have calendar or email access, it should ask me to paste the relevant information.'

Build the second end to end

A stylized teaching image showing Skills, foundation files, and a weekly review as a compact workflow library.
A is small on purpose: tested Skills, foundation files, and a weekly review.

Where each should live

With two Skills, scope decisions become real. Where you put a determines where it is available. The folder is the scope; the description is the . There are three tiers of scope, and the narrower the scope, the less likely the is to fire where it should not.

A stylized teaching image showing memory, global Skills, project Skills, and tool-specific Skills as scoped shelves.
Scope decides where a should live: use the smallest place that still fits the instruction.

Global Skills live in the user-level location for the tool you are using. Project Skills live inside a project folder or repository location that the tool reads only for that work. Claude Code and Codex expose these scopes differently, and the exact paths can change, so treat the product documentation and the tool's visible Skill list as the source of truth before installing. Tool-specific Skills live where that tool expects them and carry a note in the Skill file about the dependency.

The weekly review that keeps everything current

A that never gets reviewed decays quietly. A 15-minute weekly review catches drift before it causes problems. The format is simple: scan recent AI sessions for repeated corrections, new candidates, and foundation file updates.

The weekly review is where you exercise judgment. You look at the evidence, decide what matters, and choose which corrections deserve a permanent home. This chapter teaches you to recognize the maintenance patterns: repeated corrections, stale gotchas, misfires, and foundation drift. A later chapter automates the observation layer so those patterns surface overnight, but the judgment stays with you. Start manual so you know what a productive review produces before asking AI to replicate it.

A stylized cycle diagram showing recent work, corrections, misfires, stale instructions, and updates around a small Skill library.
A weekly review catches corrections, problems, and stale instructions before the library drifts.

Examples, references, , and tool-specific instructions go stale faster than procedures. A meeting-recap procedure endures across updates, but a gotcha like 'Fathom speaker labels are wrong for the first 30 seconds' may stop being true when the recording tool updates. Check your most specific, most tool-dependent instructions first.

Your library is built; now learn what to trust from outside

Your is small right now: two Skills, three foundation files, a few gotchas, and a weekly review habit. That is enough. Before you automate any of this, the next chapter covers an important question: what happens when you encounter Skills that someone else wrote?

References

2 sources
  1. 1
    Extend Claude with skills

    Anthropic · 2025 · Claude Code Documentation

    Claude Code personal Skills live under ~/.claude/skills/<skill-name>/SKILL.md, and project Skills live under .claude/skills/<skill-name>/SKILL.md. Users should review project Skills before trusting a repository because a Skill can grant itself broad tool access.

    Retrieved May 2026. Project Skills can include scripts and tool permissions, so review any Skill bundled with a repository before trusting it.

    View source
  2. 2
    Custom instructions with AGENTS.md

    OpenAI · 2026 · Codex Developer Documentation

    Codex project guidance uses AGENTS.md as a separate container from Skills. AGENTS.md provides project-level instructions, while Skills provide reusable task-specific procedures.

    Retrieved May 2026. Project-wide rules (naming conventions, repo standards) belong in AGENTS.md, which is always loaded for that project. Repeatable task procedures belong in Skills.

    View source