---
name: skill-repository-curator
description: "Semantically curate an Agent Skills portfolio: audit native name/description triggers, false negatives and collisions, recurring jobs and artifacts, package boundaries, progressive-disclosure thickness, ownership, consolidation, recovery, and retirement. Use when creating, cleaning, splitting, merging, or reviewing a complete skills repository. Do not use to author one skill from one source, evaluate runtime behavior experimentally, or build a router or marketplace."
---

# Skill Repository Curator

Make a skills repository more useful by improving the skills themselves. The
primary unit is a recurring user job with an independently useful artifact—not
a folder, topic, governance mechanism, or generated catalog row.

## Workflow

1. Establish the repository boundary, intended users, public/private
   visibility, supported format, canonical owner map, and publication policy.
   Treat visibility and validation tooling as support surfaces, not the product.
2. Read the repository curation patterns reference. Reconstruct the complete
   corpus from installable entries, active investigations, retirement records,
   default-branch history, and closed unmerged proposals. Classify sensitivity,
   audience, license, and publication authority before reuse; presence in
   history is not authority to republish. Do not wait for the owner to remember
   a hidden name.
3. For every capability, judge four facts separately: value of the recurring
   job, quality of the current package, need for a separate route, and current
   evidence state. A weak old implementation does not make its job worthless;
   absent benchmarks do not make its procedure generic.
4. Inspect the portable `name` and `description` plus each target runtime's
   documented discovery contract, listing budget, omission/truncation behavior,
   realistic user phrasings, exclusions, and nearest neighbours. On
   metadata-selecting runtimes such as Codex and Claude, the body cannot repair
   a false-negative route because it loads after selection. Then inspect the
   body, references, helpers, original source, requested intent, accepted
   artifact, unique mechanisms, authority, failure modes, and collisions.
   Metadata, counts, demand labels, hashes, and authored scores are inputs
   rather than verdicts.
5. Compare neighbouring skills by recurring requestable job and independently
   accepted artifact. Keep both when their deliverables differ. Absorb only
   when one canonical owner accepts the full job; map every unique rule, state,
   failure mode, example, and evaluation to its destination before removing the
   old route. Put subordinate techniques and medium-specific depth in the
   owner's references instead of publishing a route for every topic.
6. Run a false-negative review before any broad consolidation. Give a fresh
   reviewer the rejected or hidden material and proposed target without the
   preferred verdict; ask what useful capability, owner knowledge, or distinct
   artifact would be lost. Resolve material disagreement through more source
   inspection or forward tests, not a batch label.
7. Choose `keep`, `rewrite`, `absorb`, `transfer`, `investigate`, or
   `archive-implementation`. Give every decision a semantic reason, canonical
   owner, exact content action, and confidence. Important jobs with shallow
   generated bytes become rebuild leads rather than restored shells.
8. Improve concise front-loaded descriptions, content and realistic routing
   examples, then forward-test material changes on fresh native runtimes. Test
   positive, near-neighbour, abstention, compound, multilingual, ambiguous,
   correction, and misleading-keyword cases under realistic catalog pressure.
   Run the repository's existing hygiene and delivery checks afterward. Do not
   build a meta-router merely to make a semantic judgment look deterministic.

## Resource guide

- Read references/repository-curation-patterns.md for the value test, content
  smells, collision decisions, and absorption method.
- Run scripts/check_skill_folder.py only for a quick folder/frontmatter check;
  it is not behavior, demand, or quality proof.

## When not to use

- Use source-to-skill-distiller when one bounded source needs to become one
  skill package.
- Use skill-eval-designer when the primary artifact is a falsifiable routing or
  behavior evaluation for an existing skill.
- Use a runtime/plugin architecture when the product executes tools, APIs,
  credentials, billing, or permissioned actions; a skill is procedural content.

## Guardrails

- Do not optimize for skill count, folder symmetry, line count, or topic coverage.
- Do not assume every description is visible merely because every package is
  installed. Codex/Claude listing budgets may shorten descriptions or omit
  entries, while other runtimes may expose different semantics; record the
  actual state and prove important routes in each supported native runtime.
- Do not stuff synonyms into descriptions as a keyword list. Front-load the
  concrete job, artifact, material contexts, and nearby exclusions in natural
  language so model-mediated implicit selection has discriminating evidence.
- A thick method is acceptable when progressive disclosure keeps the entry
  procedure focused and moves optional depth to references. Split only when a
  sub-job is independently requested and produces an independently accepted
  artifact; merge when job, artifact and acceptance authority are materially
  the same.
- Do not delegate semantic value, atomicity, or absorption decisions to CI,
  schemas, hashes, demand counters, or lifecycle labels.
- Do not require the owner to recall or nominate hidden work. The owner sets
  strategy and protected experience; curator agents own portfolio discovery,
  comparison, rewriting, and routine reversible decisions.
- Do not merge skills merely because they mention the same domain; compare the
  requested job, artifact, acceptance authority, and unique mechanisms.
- Do not keep generic wrappers that add no procedure beyond ordinary reasoning.
- Do not turn a normal public/private repository into a control-plane project
  unless the user explicitly asks for that infrastructure and it is necessary.
- Do not claim current demand, behavior, adoption, or superiority from authored
  examples, local installation, or repository presence.
- Do not call a job low-value merely because its old package is shallow or its
  current proof is absent. Distinguish job value, package value, route value,
  and evidence state.
- Do not delete unique knowledge before its destination is explicit and checked.
- A public package must not reproduce secrets, customer/personal data, raw
  telemetry, private topology/process/migration state, control knobs,
  security-sensitive detail, or hidden identifiers. Preserve a useful method
  only through authorized, non-reconstructable generalization or redaction.

## Output format

Repository boundary and users:

Audience, sensitivity, and publication authority:

Portfolio verdict:

Skill decisions:

| Capability | Job value | Package value | Route value | Evidence | Owner | Decision | Exact change |
| --- | --- | --- | --- | --- | --- | --- | --- |

Absorption map:

- old mechanism or test -> canonical destination

Missing or weak capabilities:

False-negative review and disagreements:

Validation run:

Delivery state and unresolved evidence: