---
name: skill-asset-management
description: "Treat skills as assets: audit what is original versus installed, compute the context holding cost, audit long-unused and overlapping skills, and decide keep/merge/archive/uninstall. Use when the skill library bloats, when every turn feels heavier, when you need to know 'which skills did I build myself', or when clearing out skills you do not use. Not for creating a single skill (that is skill-creator)."
---

> Original skill · commissioned by the user · English edition, 2026-11-12

# Skill Asset Management

**Thesis**: skills are assets, but **assets with a holding cost** — every skill's `description` enters the system prompt, so **you pay for it once per turn**. The management goal is therefore not "the more the better" but **"every one gets used, and is worth the lines it occupies"**.

> Measured in a past audit (illustrative numbers): the local `skills/` directory held **70-odd** skills, plus the plugin cache at roughly the same count after de-duplication — **well over a hundred skills** altogether; of those only **a handful** were confirmed original, while the `skills/` directory's **descriptions ran to tens of thousands of characters** — that is the per-turn overhead.
> (Method: plugins are de-duplicated by skill name; without de-duplication the count is higher, including duplicates across marketplaces.)

## 1. Classify first (criteria must be checkable, not felt)

**First thing: look for an explicit marker.** Hard rule: **every skill the user commissioned carries a marker on the first body line of `SKILL.md`**, and third-party skills that were installed or copied **must not** carry it. So "has the marker = original" is settled, and the timeline / content / directory-structure criteria below **apply only to skills without a marker** (legacy pieces, or ones where the marker was missed):

**Single exception**: when the marker collides with a **hash / upstream comparison**, **the facts win** — check upstream first, and if it turns out to be third-party, **revoke the marker** (in a past review, four markers were revoked this way). The marker is a claim of authorship; the hash is evidence. Evidence wins.

```powershell
Select-String -Path <SKILL_LIBRARY>\*\SKILL.md -Pattern '^> Original skill'
```

**Criteria must be used in pairs** (timeline reads the batch, description reads the content) — either one alone will misjudge:

| Priority | Criterion | Points to | Strength |
|---|---|---|---|
| **⓪ Explicit marker** | the first body line of `SKILL.md` carries `> Original skill · commissioned by the user · <date>` | **original** (unless a hash disproves it) | **decisive** |
| **① Creation timeline** | **≥5 created in one hour, in a batch** | **installed** (installs are always batched) | strong |
| **① Creation timeline** | **sporadic creation**, hours apart from each other | **original** (self-built skills arrive one at a time) | strong |
| ② Description content | contains a **personal project name** or a **personal prefix** (e.g. `<PROJECT_CODENAME>`, `<PERSONAL_PREFIX>`) | **original** | medium-strong |
| ② Description content | **Chinese**, describing the workflow of "the user / me" | possibly original | weak |
| ② Description content | English, generic-tool voice | possibly installed | weak |
| ③ Directory structure | has `LESSONS.md` / `tests/` | original (a feature of this library's own convention) | medium |

⚠️ **Timeline is not sufficient** (hit in practice): a batch of dozens created within one hour mixed self-built with installed skills (`video-editing` self-built; `agent-caption` / `clip-skills` / `wjs-*` were once judged self-built and were **re-judged installed after a hash review**; the installed `hyperframes-*` / `remotion-*` were created in the same batch) → **mixed batches must be split apart with content criteria plus hashes**.

⚠️ **The decisive criterion between self-built and installed is file-hash comparison**: the `*-upload` skill files all had identical timestamps, a Chinese voice and isomorphic structure, so they looked self-built — in reality they were byte-for-byte copies of the `skills/` directory of an upstream MIT repository. → **Run `Get-FileHash` against the candidate upstream first**, and only fall back to timeline / content fingerprints when that does not match; reversing the order guarantees a misjudgement.

⚠️ **Directory structure is not sufficient either**: a freshly built original has no `LESSONS.md` yet (misjudged as undetermined); an installed skill may ship its own `tests/` (misjudged as original).

**A known strong regularity (verified once)**: every skill created after the bulk installs, arriving one at a time hours apart, was **original** — **"sporadic vs. batch" is far more reliable than "Chinese vs. English"**.

⚠️ **The criteria have two known gaps**, so **the first audit must be walked through by hand**:
1. a freshly built original has no `LESSONS.md` yet (that needs accrued lessons) → it gets misjudged as undetermined;
2. an installed skill may ship its own `tests/` → it gets misjudged as original.

After tagging, store the conclusion in the ledger (see `references/asset_ledger.md`), and **read it next time instead of re-judging**.

**Once an explicit marker exists**: marked skills count as original directly, and the two old gaps in the ⚠️ notes (new builds without `LESSONS`, installed skills shipping `tests`) **only affect unmarked skills**; only unmarked skills with no upstream match need a human decision, and afterwards you **add the marker or add the ledger row**.

## 1.5 Fixed actions when creating a skill (not optional)

1. First line after the frontmatter of `SKILL.md`: `> Original skill · commissioned by the user · <YYYY-MM-DD>`
2. Add a row to the incremental table in the ledger `references/asset_ledger.md`: skill name / date / **original (explicit marker)**
3. Anything copied from an upstream repository or from someone else's skill: **strip the marker only**, never keep it — by the criteria it is third-party work, not original.

## 2. Audit (one command)

```powershell
python scripts/skill_audit.py --out review/skill_audit.md
```

Output: counts and classification, each skill's description length and last-modified time, and the **total description length (= context holding cost)**.

## 2.5 Four cuts for slimming down (ordered by "can judge / benefit / risk")

⚠️ **First kill a misconception**: "which skill has never been used" **cannot be measured** — Codex keeps no skill-invocation log, and a file timestamp only means "modified", not "used". **Do not start there**; you will get stuck.

What you can judge is **"is it loaded"**: **the skills listed in the system prompt are the ones actually paying context**; ones present on disk or in the plugin cache but not listed only occupy disk and **cost nothing**.

| Cut | What it removes | Criterion | Benefit | Risk |
|---|---|---|---|---|
| **First cut** | present on disk, **not loaded** (plugins in the cache that are not enabled) | diff against the skill list in the system prompt | saves disk only, **not context** | zero |
| **Second cut** | an **entire family** of domains you have decided not to do | look by batch / family (e.g. no 3D → the whole Blender family) | **large** (one family is a dozen descriptions) | low (can be reinstalled at any time) |
| **Third cut** | skills with **overlapping function** | both can do the same thing (e.g. two TTS stacks, two editing suites) | medium | medium (confirm nothing depends on them) |
| **Fourth cut** | a single skill with an **overlong description** | sort by `description` character count | medium (cost drops without dropping the count) | low |

**The one-sentence test for "keep it or not"**: **"Do I have a scenario for it next month?"** No answer → disable it. **"Maybe some day" is not a scenario** — that is collecting, not using.

## 2.6 Conflict scan (executable)

```powershell
python scripts/skill_conflict.py --write review/skill_conflicts.md
```

Scans 12 action classes (naming, delivery paths, covers, export, subtitles, voiceover, copy, publishing, QC, memory, topics, skill management) and finds cases where the same action is claimed by more than one skill.

**Reading rule**: `high` = two or more skills both claim it in their description; `medium` = only the body mentions it. ⚠️ The script only does keyword co-occurrence, **it makes no semantic ruling** — "subtitle generation / subtitle translation / subtitle burn-in" are three layers, not a conflict, and you must layer them by hand before deciding to merge.

A past first scan (a few dozen skills, five high-conflict classes) found only three places that genuinely needed consolidation:

1. **Two TTS stacks**: `local-audio` and `voice-generation` both synthesize speech → pick a single source of truth and keep the other as backup only.
2. **Two owners of naming / placement**: `workspace-hygiene` (session level) and `asset-management` (project level) → state the layer explicitly in each description.
3. **Three owners of cover images**: `video-editing` (video) / `xiaohongshu-material` (Xiaohongshu) / `wechat-material` (WeChat Official Account) → split by form, and each writes "X only".

The rest (subtitles, publishing, QC) are upstream / downstream layer differences and need no merge.

## 2.7 Pre-install gate (executable, mandatory before installing a third-party skill)

```powershell
pwsh -File scripts/preflight-install.ps1 -Path <STAGING_DIR>                # before install
pwsh -File scripts/preflight-install.ps1 -Path <SKILL_LIBRARY>\<name>       # re-scan after install
pwsh -File scripts/preflight-install.ps1 -SelfTest                          # rule self-test (generates samples in a temp dir; never keep malicious examples in the library)
```

Exit codes **0 PASS / 1 WARN / 2 FAIL**. **2 means do not install**; **1 means you must read every script-type file**, finish handling external links and dependencies, and only then write to disk; **0 is the only green light**. The order is fixed: **gate → SHA / byte alignment → write to disk → record the risk conclusion in the ledger**.

Criteria: FAIL = reads credentials or private keys, download-and-execute (`curl|sh`, `iwr|iex`), obfuscated payload (`atob` / `base64 -d` / `eval`), privilege-escalating prompt injection, destructive commands; WARN = script-type files (`.py/.js/.sh/.ps1` etc., which a human must read), external links `<script src=http…>`, installing dependencies, reading environment variables; INFO = `<script>` snippets inside documentation (usually template examples, just record them).

**Integrity ≠ safety**: a matching SHA only proves it was copied accurately, not that the content is harmless. A past install of three third-party skills verified only the SHA, and the fact that `scripts/` never entered the skill library was purely because the transfer channel could not move JS — **that was luck, not process**.

For gaps that remain after install, register them in `references/backfill_todo.md` and state what is missing in the "local installation notes" section of that skill's `SKILL.md`, so downstream does not treat it as a complete capability.

## 3. The four audit questions (ask them every audit)

1. **Which skills have never been triggered?** There is no trigger log; approximate it with "`LESSONS.md` has not grown for a long time".
2. **Which functions overlap?** Two skills can do the same thing → they should be merged, keeping one description.
3. **Which original skills are gathering dust?** No new lessons for three months = not in use.
4. **Has the total description length grown?** If it has, you must be able to say **which one** grew — if you cannot, it is out of control.

## 4. Disposition decisions (every action needs one line of reason)

| Action | When to use |
|---|---|
| **keep** | in use, or definitely will be used soon |
| **merge** | two skills overlap in scenario → merge into one, saving one description's worth of overhead |
| **archive** | useful but rarely used → move out of `skills/`, put it back when needed |
| **uninstall** | never used, and no use scenario can be identified |

**Write one line of reason for every action** (into the ledger), otherwise the same agonising comes back in six months.

## 5. Division of labour with other skills

- `skill-creator` handles **how to build** one skill; this skill handles **how to manage a pile** of skills.
- `asset-management` handles placement / naming / versioning of **file** assets; this skill handles **the skills themselves** as an asset.
- The "rules that never fired" produced by phase C (rule audit) of `project-retro` are one of this skill's inputs.