Skill Registry Builder

Guides the user through designing a skill or agent registry — internal or public.

Invocation: /registry on platforms that support slash commands, or natural-language phrasing (see the description in the frontmatter).

Output: a registry design document covering four pillars (Discovery, Evaluation, Installation & Use, Maintenance), plus an HTML version for sharing.

Dependency: uses the frontend-design skill to produce the HTML output. That skill should be available in the same environment.

When this skill applies

Use this skill when the user is:

• Scoping a new registry from a vague starting point
• Pressure-testing a partial list of pillars
• Benchmarking against an existing registry to separate standard patterns from genuine innovation
• Stuck on a specific decision: taxonomy, trust tiers, install UX, bundles, governance, ownership rotation

Core principle

Most of what a skill registry needs is the same as any other catalog of installable things: a list of items, metadata, search and browse, install, and ongoing upkeep. These patterns are well-understood. Copy them.

The real design work is in the decisions specific to the user's context: audience, how trust is signaled, how skills stay current, how people are pushed toward the registry. Focus there.

The biggest mistake in registry design is treating the registry as something you build once and finish. It needs ongoing work — things go out of date, skills stop being useful, owners leave. Plan for that, not just launch.

---

Step 1: Capture intent

Before proposing anything, get clear answers to these five questions. Ask conversationally, not as a form. If any are already answered in the conversation, do not re-ask.

1. Who is the audience? Developers, non-technical business users, or mixed. This changes most downstream decisions.
2. Internal or public? Internal registries lean on organizational signals (ownership, endorsement). Public registries lean on community signals (stars, reviews, downloads).
3. What platforms will the skills run on? One or several. Multiple platforms require compatibility info per skill.
4. Who publishes? Anyone, a central team, or gated by review. This determines contribution flow and governance.
5. What does success look like in six months? Number of skills, adoption per team, skills retired per quarter. This shapes what you instrument.

Batch the questions into one turn. Do not interview one at a time.

---

Step 2: Present the pillar framework

Once intent is clear, present the four pillars:

The four pillars

1. Discovery — how users find skills
2. Evaluation — how users decide whether a skill is worth using
3. Installation & Use — how users install, run, and update skills
4. Maintenance — how the registry stays healthy over time

Every feature should map to one of these. If it does not map, it is either out of scope or a pillar is missing.

Sub-components under each pillar

Discovery:

• Browse (categories, task-oriented entry points)
• Search and filter (by platform, team, tag)
• Trending / Featured / New
• Personalized defaults (by role or team)
• Bundles as discovery objects

Evaluation:

• Preview (what the skill does, at a glance)
• Try before install (playground, sample prompts)
• Trust signals (verification level, ownership, endorsement, last-updated)
• Reviews and ratings
• Security and review pipeline
• Curation levels as filters (e.g., Official, Team-Verified, Community, Experimental)

Installation & Use:

• Install flow (CLI, one-click, download-and-upload, multi-platform)
• Platform compatibility
• Updates and version management
• Team configuration (the current approved set of skills per team, not just per user)

Maintenance:

• Contribution flow (submit, review, publish)
• Ownership and freshness rules (each skill has an owner and a review cadence)
• Governance (review process, deprecation, sunset)
• Distribution (how the registry is pushed to users, not just waited on)
• Usage data (what gets used, by whom, what does not)

---

Step 3: Work through each pillar

Walk through the pillars one at a time. Do not dump all four at once. For each pillar:

1. Restate the pillar in one line.
2. Name the two or three sub-components that matter most for the user's context, based on their Step 1 answers.
3. Flag the one trap most relevant to their situation.
4. Ask one focused question to surface their constraints.

Template to follow:

"[Pillar] — [one-line restatement]. Given [audience] and [internal/public], the two or three things that matter most are [sub-components]. The trap to watch for is [trap]. [Focused question]?"

Fill in the brackets based on the user's actual situation. Do not default to a specific audience or registry type.

---

Step 4: Internal versus public differences

If the registry is internal, these are the key differences from public registries:

• Trust comes from ownership, not automation. Inside a company, "Owned by Legal Ops" matters more than a security scan score. Build verification around who in the organization vouches for the skill.
• Usage data should be team-specific. "12 people on your team use this" is more useful than global install counts.
• Deprecation needs to be planned. Internal registries do not self-maintain. Every skill needs an owner, a review schedule, and a way to flag skills that have gone stale.
• Distribution is push, not pull. Users will not find an internal registry on their own. Build in onboarding integration, team announcements, and periodic updates per function.
• You likely do not need a separate MCP server directory. Users want capabilities. The skill-vs-MCP distinction is usually plumbing.
• Pick one install method. Multiple install paths create confusion. Pick one and make it the default.

---

Step 5: Produce the deliverable

Ask the user which of the following they want. If they are unsure, pick the registry design doc.

• Registry design doc — the full pillar structure with sub-components, decisions made, and open questions. The default.
• Skill page template — the structure each skill's page will follow: sections, order, and what goes in each.
• Contribution and governance spec — submission flow, review levels, ownership rules, deprecation policy.
• Taxonomy proposal — category list, entry points, tag conventions.

Save the chosen deliverable as a markdown file and present it.

Step 6: Produce an HTML version

After the markdown deliverable is approved, produce an HTML version of it for sharing with stakeholders who would rather view than read markdown.

Use the html-builder skill to generate the HTML. Do not write styling from scratch. The html-builder skill handles visual design, typography, and layout — this skill just hands it the content and asks for a clean presentation.

Save the HTML file and present it alongside the markdown.

---

Verification: when the conversation is done

Do not wrap up until all six items are either done or the user has explicitly declined.

1. Intent captured. All five Step 1 questions answered or declined.
2. All four pillars discussed. Discovery, Evaluation, Installation & Use, Maintenance. None skipped without the user saying so.
3. Concrete recommendation per pillar. Not a list of sub-components — a specific suggestion.
4. Internal vs public differences covered if internal. Step 4 walked through. Skip only if the registry is confirmed public.
5. Markdown deliverable produced or declined.
6. HTML version produced or declined.

If the user wants to stop but an item is missing, name it: "We have not covered Maintenance yet — do it now or later?"