skill-repository-curator

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: