curate-skill-repositorylisted

# Curate Skill Repository 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. ## When to use - A skills repository needs portfolio review: merge/split, collisions, retirement, or package repair - Catalog decisions must be grounded in recurring jobs and accepted artifacts, not folder counts - Not for authoring one new skill (`author-skill`) or distilling source into a package (`distill-source-to-skill`) ## 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 p