simbiot-harness/skills/meta-skill-factory/SKILL.md

---
name: meta-skill-factory
description: Use whenever recurring work is noticed (the same kind of task 2+ times — product visuals, presale landing pages, UI audits, digests of a given type, etc.) and the next repetition would again be done BY HAND. Instead of a hand run: capture the work as a full repo skill (SKILL.md with steps, checklists, quality gates), register it, and apply it to one live task immediately. Converts one-off knowledge into a repeatable, reviewable asset.
metadata:
  origin: idea by Alex (TG, 2026-10-02), task t-261002151630-8f2ce6
  scope: simbiot-harness, works for any cooperative repo
---

# Meta-skill factory: recurring work → repo skill

A skill is written once so that any agent (including future ticks of this
harness with zero memory) does the work correctly the first time and
provably well. It turns "I'll do it again by hand" into "load SKILL.md —
follow the steps — check the criteria."

## Trigger rule (when to run this skill)

Notice the trigger during a task. A skill is worth creating when **all** of:

- [ ] This is the **2nd+ time** you are doing the same kind of work this sprint
- [ ] The work has a **checkable end result** (file, page, list, metric —
  not "communicated with someone")
- [ ] The next time, someone fresh can get **within ~5% of the desired
  quality** based on the paper alone (the paper carries the decisions,
  not the hand skills)
- [ ] The work is stable — the format won't change tomorrow

In between: "recurring by eye" without a result → not yet. A one-off task →
don't invent a skill.

## Skill format (repo pattern, template copied from ui-skills)

One skill = a directory in `<repo>/skills/<kebab-case-name>/` with:

```
skills/<name>/
├── SKILL.md        # required: frontmatter + body per the template
└── reference/      # optional: templates, checklists, examples
```

`SKILL.md` — structure (headmatter + 6 sections):

```markdown
---
name: <kebab-case-name>
description: <When to load, as an action verb. This is the "when to use" line —
  write it first, and it should make sense without the body of the file.>
metadata:
  origin: <source of the skill: task/idea, date>
  scope: <which repo/products>
---

# <Name>

<1–2 lines: what it turns into and what outcome.>

## Trigger rule
[checklist — when the skill can/can't be used (see above for the sample length)]

## Steps
[numbered steps; each = action + specific commands/files, like improve-ui]

## Quality criteria
[checkbox list — what output is accepted. Vague words ("good", "beautiful")
 are forbidden: each item must have a verification method — file, grep,
 measurement, reviewer list]

## Common mistakes
[3–5 items: what agents usually get wrong in this work]

## Done when
[final checklist + in which task format to close (task id, artifact path)]
```

Requirements:

- The skill is **read-friendly in 2 minutes**: no history of how you got to it,
  no internal jargon without explanation.
- Quality criteria are phrased as **proof** («there exists», «measured», «there
  are no more than N of»), not as wishes.
- SKILL.md is self-sufficient: executor without context from the conversation.
- If the skill is bigger than ~200 lines — split it out: the main process in
  SKILL.md, references/templates in `reference/`.

## Steps

1. **Catch the repetition.** During a task, notice: "I have already done this
   2+ times". If all trigger rules check out — this is a skill candidate.
2. **Freeze the decisions.** List what was done in those iterations «by hand»:
   sources (files/links), tools, pipeline steps, what was corrected and why.
3. **Write the skill.** Create the dir `skills/<name>/`, follow the section
   template, keep it within ~2 minutes of reading. Copy checklists and specific
   paths/commands into the steps, don't write «make it beautiful».
4. **Register.** Add an entry to `skills/README.md` (or the index file if there
   is one): name + description. If there is no index — create it with the same file.
5. **Combat test run.** Take the nearest live task of that same kind and go
   through the skill as if reading it for the first time:
   - the executor agent (or you) opens only SKILL.md (without conversation memory);
   - walk through the steps → get the result;
   - fix everything that had to be «remembered from memory» — write it into the
   skill right away.
6. **Done when** see the final checklist

## Quality criteria

- [ ] Directory `skills/<name>/SKILL.md` exists, frontmatter has `name` and `description`
- [ ] All 6 template sections: Trigger rule, Steps, Quality criteria, Common mistakes, Done when
- [ ] Quality criteria are verifiable (they name a verification method, not a mood)
- [ ] The skill mentions specific paths/templates/tools — not abstract words
- [ ] Entry in `skills/README.md` (or an existing one updated)
- [ ] Combat test run: applied to a live task; changes if something was missing — noted in the history

## Common mistakes

- Writing a skill «for show», in the form of a memo: no concrete steps/criteria
  — future agent can't repeat it.
- Quality criteria without a verification method: «the design is good» — not a criterion.
- Registering without a combat test run: SKILL.md untested on a live task can
  break on the first real one.
- Inflating SKILL.md with conversation history («Alex wanted it that way»),
  instead of decisions: the executor doesn't need history, they need the how.
- Several skills from one repetition: first «catch» the repetition, don't invent
  skills for one-off work.

## Done when

- [ ] Skill file in the repo (skills/<name>/SKILL.md), registered in the index
- [ ] Combat test run completed on a live task of that same kind
- [ ] Closed in the task format (task id + artifact path) in the tick summary

## Related skills

- `presale-landing` — production of presale/product landings (first skill from the factory).