setlist-enroll-project

name

setlist-enroll-project

description

Onboard a project into the setlist registry — the four-step workflow (register_project, enrich_project, write_fields, refresh_project_digest) plus capability declaration. Use when the user asks to "register a project", "add this to setlist", "enroll this in the registry", or when an unfamiliar working directory should be brought into the user's portfolio. Reads the working directory, infers fields, confirms inferences with the user, then runs the four MCP calls.

Setlist: enroll a project

Walk a project through setlist's four-step onboarding so the registry holds canonical identity, structured profile, extended fields, and an essence digest. After enrollment, declare integration surfaces.

Required: the setlist MCP server must be connected

This skill is a thin orchestrator over MCP tools. Verify the setlist MCP server is reachable (the tools register_project, enrich_project, write_fields, refresh_project_digest, register_capabilities, inspect_workspace_candidate should be visible). If the server is not connected, stop and ask the user to install or start it.

Step 0 — Look before you write

Always check whether the project is already registered before proposing a registration:

1. Call search_projects with a slug derived from the working-directory name.
2. Call get_project with that name if a candidate appears.
3. If the project exists, stop and tell the user. Offer to enrich what's there with enrich_project and write_fields instead of re-registering.

If the working directory looks like a code project but identity is unclear, call inspect_workspace_candidate (the workspace inspector) — its report carries the directory's structural signals (manager files, framework hints, port literals, gaps). Use the report to draft a registration payload.

Step 1 — register_project

Claim the project's canonical name. The minimum useful registration is { name }. Include what you can infer with confidence:

• name (required) — slug-style identifier the registry uses for every lookup (lowercase, hyphenated). Default to the working-directory basename.
• display_name — human-readable label. Defaults to name if absent.
• type — code for repos with a manager file, non-code otherwise.
• area — Work, Personal, Infrastructure, etc. Ask the user if unclear; the area drives portfolio routing.
• status — active for live work, idea for not-yet-started, paused, archived, etc.
• description — one paragraph. Lead with what it is, then what it does, then how.
• goals — what the project is trying to achieve (array of strings).
• email_account — optional. Set if the project has a dedicated mailbox.
• parent_project — optional. Set for sub-projects.

Show the user the drafted payload before calling. The user can correct any inferred field.

register_project returns a next_steps array pointing at the calls below. Honor it — these calls are sequential, not optional.

Step 2 — enrich_project

Add structured profile data (union semantics — repeated calls merge):

• goals — what the project is trying to achieve.
• topics — searchable tags (e.g., electron, mcp, vector-search, sqlite).
• entities — other projects, services, or tools this depends on or integrates with.
• concerns — cross-cutting issues to keep in mind.

Before writing values for any open-vocabulary field (topics, tech_stack, patterns, capability_type), call vocab(field) to see the canonical set and existing in-use values. Prefer existing canonical slugs over inventing variants.

Step 3 — write_fields

Write extended fields under a producer identity. Pass producer (e.g., "enrollment-skill") so the registry tracks who wrote which field.

Required tier:

• short_description — one line (~10 words). Used in portfolio briefs and search results.
• medium_description — one paragraph for code projects. The default description shown to agent consumers.

Code-project optional tier:

• readme_description — 3-5 sentences. Full context for deep reasoning.
• tech_stack — languages, frameworks, databases, APIs.
• patterns — architectural patterns and approaches.

Non-code projects only need short_description.

Step 4 — refresh_project_digest

Generate the project's essence digest — a derived one-screen summary used as compact cross-project context. The CLI generator usually owns this, but call it directly with { project, producer } to bootstrap an initial digest. The per-kind token ceiling rejects oversized writes with a trim-and-retry error.

Step 5 — Declare integration surfaces (when applicable)

If the project exposes MCP tools, CLI commands, library exports, API endpoints, or other integration surfaces, call register_capabilities with the complete capability set. Each capability is an object with three required fields plus five optional fields:

Required:

• name
• capability_type — tool, cli-command, library-export, api-endpoint, database, etc. Use vocab("capability_type") to align.
• description

Optional:

• inputs
• outputs
• requires_auth
• invocation_model
• audience

register_capabilities uses replace semantics — the call replaces the project's previous capability set entirely. Include all capabilities in a single call, not one-by-one.

On re-enrollment (or any later touch-up), prefer upsert_capabilities for incremental updates — it adds or overwrites only the capabilities you name and leaves the rest of the set untouched; remove_capability drops a single one. Reach for register_capabilities only when you genuinely mean "this is now the complete set." If the project already has 10+ capabilities and your register_capabilities call would drop the count by more than half, the registry rejects it as a likely accidental wipe — pass confirm_replace: true only when the shrink is intentional.

Step 6 — Confirm

Call get_project_brief with the new project name to confirm enrollment landed. Show the user the brief so they can see what got captured.

Hard rules

• Do not invent capabilities the project does not actually expose.
• Do not bypass the four-step order — each step depends on the prior writes existing.
• Do not silently overwrite existing user-authored fields on re-enrollment. If a field is already populated, ask before changing it.
• Open-vocabulary values are normalized at the write boundary; novel terms pass through, but vocab(field) should be consulted to avoid creating near-duplicates.
• The full onboarding guide lives at setlist://docs/onboarding (read via the MCP resource read handler) — defer to it for any field-semantic question this skill does not answer.