| name | setlist-portfolio-graph |
| description | Render the user's portfolio as an area → project → capability tree using the setlist registry. Use when the user asks "what's in my portfolio?", "show me my projects", "what do I have under <area>?", "what tools does <project> expose?", or wants a read-only overview of the ecosystem's shape. Read-only — never writes to the registry. |
Setlist: portfolio graph
Render the area → project → capability shape of the user's ecosystem from the setlist registry. Read-only: this skill never writes to the registry.
Required: the setlist MCP server must be connected
The skill calls setlist MCP tools. Verify list_areas, list_projects, query_capabilities, and portfolio_brief are visible. If the server is not connected, stop and ask the user to install or start it.
The render pipeline
-
Top-level orientation — call portfolio_brief (no arguments needed). It returns a curated cross-project summary that reflects what the registry believes is salient now — recent activity, current focus, enrichment gaps. Use it to set the tone for the render.
-
List the areas — call list_areas. Returns the user-managed area set with labels, colors, and project counts. Each area is the top-level grouping in the graph.
-
List projects per area — call list_projects({ depth: "summary" }) once and group the result by area. Honor the user's preferences for visibility:
- Include archived projects only if the user explicitly asks. By default render
active, paused, draft, and idea.
- For each project, surface:
name, display_name, type (code / non-code), status, short_description, and the last-updated timestamp.
-
Capabilities per project — call query_capabilities({ project: <name> }) for each project the user wants drilled into, or query_capabilities({}) once for the full portfolio and bucket the result by project. Each capability surfaces:
name
capability_type
description
- audience hints (
requires_auth, invocation_model, audience)
-
Render. Default to a markdown tree in chat. Optionally render to a saved SVG via the desktop app's IPC bridge if the desktop app is reachable and the user asks for a visual.
Default render shape (markdown tree)
<Area label> (color: <hex>)
└─ <project-name> · <type> · <status>
<short_description>
Capabilities:
• <name> (<capability_type>) — <description>
• ...
└─ <project-name> · <type> · <status>
...
Projects without capabilities show Capabilities: none declared. Areas with zero projects show (no projects).
Drill-down patterns
The user often wants a narrower slice. Honor these patterns:
"show me Work" — render only the Work area.
"what does <project> do?" — call get_project_brief(<project>) and skip the area scaffolding.
"what tools are in my portfolio?" — call query_capabilities({ capability_type: "tool" }) across all projects and render a flat list.
"what's the status of my code projects?" — filter list_projects by type: "code" and render with status badges prominent.
Cross-project queries
When the user asks a question that spans projects (e.g., "which projects use better-sqlite3?", "which projects ship MCP servers?"), call cross_query rather than fanning out reads. It returns a single ranked result set with project provenance per hit.
Hard rules
- No writes. This skill calls only read tools —
list_areas, list_projects, query_capabilities, cross_query, portfolio_brief, get_project, get_project_brief. Never call register_project, enrich_project, write_fields, register_capabilities, retain, or any other write surface.
- Honor archived hiding. By default archived projects are not rendered. Show them only on explicit user request.
- Defer to the registry on enrichment gaps. If
portfolio_brief flags enrichment gaps (missing short_description, missing tech_stack, etc.), surface them in the render — don't invent values to fill the gaps.
- Read-only confirmation. When the user reacts to the render with "fix this" or "update this", switch to the
setlist-enroll-project skill or call the appropriate write tool directly. Do not silently widen this skill's scope.