<!--
article-forge metadata (feed to publish.py as JSON: title, excerpt, category, body)
title: The Skill Factory: Teach Your AI a Task Once, Own It Forever
slug: skill-factory
excerpt: Stop re-explaining the same task to your AI every week. Turn it into a skill — one small file it owns forever — and build a compounding factory of them.
category: ai_tech
status: draft
-->


You re-explain the same task to your AI every week. That is the mistake. Teach it once and it becomes a skill — one small file your agent owns forever, triggered by a phrase, run without you re-explaining a thing.

Do that enough times and you have a FACTORY: every task you teach is a permanent worker that never quits, never forgets, and keeps getting sharper. The collection only grows. This is the whole method, plus the exact template the video held back.

What a skill actually is

A skill is a plain markdown file your agent reads at startup. For Claude Code the convention is ~/.claude/skills/<name>/SKILL.md (global) or .claude/skills/<name>/SKILL.md inside one project. There is nothing to install — the file is the skill.

It has three load-bearing parts:

The full step-by-step

  1. Pick a task you did more than once this week. Good first skills are small and repeatable: "draft my weekly status update", "turn this note into a checklist", "summarize this thread and pull the action items". Skip the huge one-off jobs.
  2. Make the folder and file: ~/.claude/skills/<your-skill-name>/SKILL.md.
  3. Paste the template below and fill the four fields.
  4. Start a fresh session (so the agent re-reads the skills folder) and say your trigger phrase. It matches your words against the description, loads the process, and runs.
  5. When it slips, don't argue in chat — fix the file. One edit to the steps, or one line in LEARNINGS.md, and it's fixed for every future run.

The exact template

This is the copy-paste skeleton the video gated. Save it as your SKILL.md and fill only the << FILL >> parts. Delete the top instructions when done. A good skill is one screen, not a manual.

---
name: << kebab-case-name, e.g. weekly-report >>
description: << one sentence: what it does + the literal phrases that should
  trigger it. Triggers matter more than prose. e.g. "Draft my weekly status
  report from this week's commits. Triggers 'weekly report', '/weekly'." >>
---

# << your-skill-name >>

<< one or two sentences: what this skill is for and when it fires. Write it to
a stranger who has zero context. >>

## Process
1. << the first concrete step — what to read or gather first. >>
2. << the next step. Keep steps as verbs. Name exact paths, commands, or tools
   where it matters — vagueness here is where skills fail. >>
3. << the output — what "done" looks like, and where the result goes. >>

## Boundaries
- << what this skill must NOT do (e.g. "draft only, never send"). This is what
  keeps an autonomous run safe. >>
- << when to stop and hand back to a human. >>


Here is the same skeleton filled in, so you can see the shape working:

---
name: weekly-report
description: Draft my weekly status report from this week's git commits and open
  tasks. Triggers "weekly report", "write my status update", "/weekly".
---

# weekly-report
Turn a week of scattered work into a 5-bullet status update I can paste into Slack.

## Process
1. List this week's commits across my active repos and my done tasks.
2. Group them into themes; write one bullet per theme, outcome-first.
3. Output 5 bullets max + one "next week" line. Draft only.

## Boundaries
- Draft only — never post to Slack automatically.
- If a repo has zero commits this week, skip it silently, don't invent work.


## The self-improving loop

This is the part that turns static files into workers that get better while you sleep. Each skill owns two files: SKILL.md (the clean, trusted recipe) and LEARNINGS.md (a running log of friction).

The loop is three moves:

  1. Run: the skill does its job.
  2. Log: if anything went sideways — you corrected it, it missed an edge case, a path had changed — append one dated line to LEARNINGS.md. Don't rewrite the skill mid-run; just capture the signal.
  3. Merge: later, read the log, fold the durable fixes into SKILL.md, and clear the merged lines. This is a deliberate, reviewed step — not an automatic live rewrite.

The rule of thumb: logging is automatic and cheap; merging is manual and reviewed. That keeps a self-editing file from drifting somewhere you never see. Add one line to the bottom of every skill so the habit is built in:

## Self-improvement
Friction or a correction during a run → append one dated line to this skill's
LEARNINGS.md. Merge the durable ones into the steps above during review.


## Why it compounds

TimeThe same skill
Day 1Mostly works
Week 4Minus the four mistakes it made, plus the four edge cases it learned
Month 6A worker that's been quietly hardening the whole time

Multiply that across every skill you build and the collection doesn't just grow in count — it grows in quality. That is the factory. Pay the thinking cost once; cash the check forever.

Tools & links

What most people get wrong

They write the process and forget the boundaries and the triggers. Without explicit trigger phrases in the description, the agent never picks the skill. Without the "never" lines in boundaries, an autonomous run eventually does something you didn't want. Both are one line each, and they are the difference between a skill you trust and one you babysit.

One step to take today

Open the task you re-explained to your AI most recently. Give it a name, write the four fields, save it as a SKILL.md. That is skill number one. Do it again tomorrow — the factory starts the day you stop re-explaining.

Includes a free download

Enter your email to read the full how-to

Confirm via the email link to unlock the full how-to and the free download inside. Free forever.

No spam. Unsubscribe anytime.