Cold Start Interview

What's connected?

This plugin can work with: Slack (for new-skill / update notifications). Let me check which connectors you have configured — features that need them will work, and features that don't have them will fall back to manual gracefully instead of failing silently.

Check what's actually connected, not what's configured. A connector listed in .mcp.json is available. A connector that's actually responding is connected. These are different, and confusing them destroys trust. For each connector this plugin uses:

• If you can test the connection (call a simple MCP tool like a list or search), report ✓ only on a successful response.
• If you can't test (no way to probe from here), report ⚪ "configured but not verified — open your MCP settings to confirm" with a one-line how-to.
• Never report ✓ based on configuration alone.

For connectors that show as not connected, tell the user how to connect. Example phrasing: "Slack isn't connected. In Claude Cowork: Settings → Connectors → Add → Slack → sign in. In Claude Code: add the Slack MCP to your config or via /mcp. This plugin works without it — update notifications surface on next /legal-builder-hub:registry-browser or /legal-builder-hub:auto-updater instead of proactively — but connecting it makes notifications real-time."

Then report findings in this form:

• ✓ [Integration] — connected (tested)
• ⚪ [Integration] — configured but not verified. Open your MCP settings to confirm.
• ✗ [Integration] — not found. [Feature] will fall back to [manual alternative]. [How to connect.]

You don't need this. Core features — browse, install, QA, update — work with file access alone.

Write Part 0 answers to the plugin config under ## Who's using this and ## Available integrations. This plugin writes ## Who's using this so other plugins installed afterward can read the role from here instead of re-asking.

Before the five questions: "Do you already have a list of community-skill registries you watch, or an allowlist / blocklist of skill sources your team uses? Paste the contents, share a file path, or say 'no' and I'll add the default. If you share one, I'll read it and add those registries plus your allowlist to the profile rather than making you re-type them. (This feeds /legal-builder-hub:skill-installer — the installer reads allowlist.yaml before fetching anything, and blocks any source that isn't on the list in restrictive mode.)"

Deployment context. After the allowlist question and before writing the file, ask:

"How are you going to use the skills you install — just for yourself, shared across your firm, or embedded in a product or service you ship to others? (Personal / Firm-internal / Product-embedding.) (This feeds allowlist.yaml — the deployment context seeds the licenses: list, and /legal-builder-hub:skill-installer refuses to fetch any skill under a license not on that list.) This sets your license defaults. Most open source licenses are fine for personal use. Firm-internal adds file-level copyleft (LGPL, MPL — fine when you're not distributing). Product-embedding is the strict one: strong copyleft (GPL, AGPL) creates obligations that need legal review before you ship, so those get flagged rather than defaulted."

Record the answer in the profile under ## Sources I trust as Deployment context: [personal | firm-internal | product-embedding]. The allowlist's licenses: seeding below reads from it.

Write the allowlist to allowlist.yaml, not just the profile. The installer's gate reads from ~/.claude/plugins/config/claude-for-legal/legal-builder-hub/allowlist.yaml, not from CLAUDE.md. If you only record the answer in the profile, the installer sees an empty allowlist and falls back to permissive regardless of what the user said — silently defeating the headline structural defense. After this question:

1. Write allowlist.yaml at the config path, following the schema in skill-installer/references/allowlist.md:
   • mode: — the template default is restrictive (fail-closed). Offer permissive for Solo/small firm (they don't have IT-curated publisher lists, so restrictive mode would refuse everything). Keep restrictive for Midsize/large firm, In-house, or Government (those have security policies that want a firm gate). Always confirm: "I'm setting the allowlist to [mode]. Restrictive refuses unknown sources until you add them — safest, but you'll need to approve each new publisher. Permissive flags unknown sources and asks you before installing — more convenient, less strict. Which do you want?" Never write permissive without explicit user consent.
   • registries: — what the user provided plus the default.
   • publishers: — GitHub owners/orgs the user named or that own the trusted registries.
   • connectors: — empty unless the user provided a list; in restrictive mode, prompt: "Restrictive mode needs a connector allowlist — paste approved MCP server URLs, or I'll leave it empty and skills declaring any connector will be refused."
   • licenses: — seed based on the deployment-context answer above:
     • Personal → MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC, CC0-1.0.
     • Firm-internal → same as Personal plus LGPL-2.1-only, LGPL-3.0-only, MPL-2.0.
     • Product-embedding → same as Personal. Also write a top-of-file comment in allowlist.yaml: ## License review required before shipping — anything not on this list needs legal sign-off. Strong copyleft (GPL, AGPL) is deliberately excluded from the default here; adding those requires a deliberate edit.
2. Also summarize in the profile's ## Sources I trust section so a human can see the policy.
3. Tell the user where it lives: "Your allowlist is at ~/.claude/plugins/config/claude-for-legal/legal-builder-hub/allowlist.yaml. The installer reads it before fetching anything."

If the user uploads a registry/allowlist file: read it, extract the registry URLs and allowlist/blocklist entries, confirm what you found, write allowlist.yaml per the schema, and summarize in the profile.

Freshness reminders. After the allowlist question (deployment context is set) and before the five questions, ask:

"When a community skill bundles reference material — regulations, statutes, procedural templates — how long should it be trusted before I remind you to verify it's still current? (6 months is a common default for regulatory content. 12 months for procedural/stylistic content. Set it tighter if you work in a fast-moving area.)"

Accept either a single number (apply to regulatory; use the category defaults below for the others) or per-category answers. Validate each answer shapes to N days, N months, or N years with N a positive integer ≤ 120 — reject free-form prose and re-ask.

Write the answer to a ## Freshness reminders section in the profile (insert after ## Sources I trust and before ## Installed starter pack):

## Freshness reminders

| Content category | Max age before reminder | Rationale |
|---|---|---|
| regulatory | 6 months | Regulators update frequently; enforcement priorities shift |
| procedural | 12 months | Court rules and procedures change slower |
| stylistic | 24 months | House style, formatting templates |
| unknown | 3 months | A skill that doesn't declare freshness is treated cautiously |

When a skill's `last_verified` + `freshness_window` is past, or the user's threshold (above) is past — whichever is tighter — the skill-installer surfaces a warning before running.

If the user gave tighter numbers, write those in place of the defaults. If the user said "use defaults," write the table as shown.

If the user didn't upload a registry list: after the five questions, offer: "Want me to write your watched registries and update preferences up as a standalone policy note you can share with your team? Same content I'm saving to your profile, formatted so teammates or a new builder can see which sources you trust and how you want updates handled."

The five questions

1. Practice area — In-house or firm? Commercial, privacy, product, employment, litigation, M&A, something else? (This feeds /legal-builder-hub:related-skills-surfacer — the practice area is the primary key that maps to the starter pack.)

   Practices that don't fit the boxes. If the user's practice doesn't match the options (international arbitration, public international law, amicus-only, academic consulting, pro bono panel, tribal court, military justice, maritime, or anything else the standard categories assume away), offer: "It sounds like your practice doesn't fit my usual categories. Tell me about it in your own words — what you do, who for, what jurisdictions and forums, what the work looks like — and I'll build your profile from that instead of forcing you into boxes that don't fit. I'll skip or adapt the questions that don't apply." Then build the profile from the free-form description, flagging which template fields were filled, adapted, or left empty because they don't apply. A profile built from a forced fit is worse than a sparse profile built from what's actually true.

2. Industry — Tech, healthcare, finance, other, doesn't matter? (This feeds /legal-builder-hub:related-skills-surfacer and /legal-builder-hub:registry-browser — industry narrows the starter pack and filters registry results.)

3. Team size — Solo, small team (2-5), large legal department? (This feeds the allowlist.yaml mode default — Solo/small gets permissive, Midsize/large/In-house/Government gets restrictive.)

4. What's the thing you do most? — Contract review, compliance, launch reviews, deal support, brief writing, etc. (This feeds /legal-builder-hub:related-skills-surfacer — the surfacer nudges you when you're doing something the community has a skill for.)

5. Tooling comfort — Builder (you write your own skills), tinkerer (you edit what's installed), just-make-it-work (you want it to work out of the box)? (This feeds /legal-builder-hub:related-skills-surfacer — builders get the raw registries and /legal-builder-hub:skills-qa framework; just-make-it-work gets a curated, working pack.)

Recommend

Map the profile to registry skills:

For each recommended skill: show the SKILL.md description. Let them pick — don't install anything without a yes.

Writing the practice profile

Short. Profile + installed list + registry prefs. Per the template at ${CLAUDE_PLUGIN_ROOT}/CLAUDE.md.

After writing

Show what this plugin can do. Before closing, offer:

Want to see what I can help with?

If yes, show this tailored list (not a generic template — these are the concrete things this plugin does best):

Here's what I'm good at in legal skill management:

• Browse community legal skills — e.g., "See what other practitioners have built for your practice area." Try: /legal-builder-hub:registry-browser
• Install a skill from a registry — e.g., "Add a community skill to your environment — license-gated and allowlist-checked before it runs." Try: /legal-builder-hub:skill-installer
• Check for updates — e.g., "See which installed skills have newer versions in their source registry." Try: /legal-builder-hub:auto-updater
• Get skill recommendations — e.g., "Based on recent activity in your other plugins, surface skills worth trying." Try: /legal-builder-hub:related-skills-surfacer
• Evaluate a skill against the design framework — e.g., "Run the Legal Skill Design Framework on a skill — nine design parameters, three failure modes, a trust-surface check." Try: /legal-builder-hub:skills-qa

My suggestion for your first one: Browse the registry and pick one skill that matches a current project — install it and see how the allowlist gate feels. Or tell me what's on your plate and I'll pick.

This solves the cold-start problem (the supervisor doesn't know what to do first) and the value-prop problem (they don't know what the plugin can do) in one offer. Make the list specific. Skip this step if the supervisor already named a concrete first task during the interview.

• "Here's what I installed. Want to see what else is in the registries?"
• "The related-skills-surfacer will nudge you when you're doing something the community has a skill for. Want that on or off?"
• Before the first installed skill that cites authority, connect a research tool. Say: "Before the first installed skill that cites authority: connect a research tool if one of the installed plugins needs it. Without one, skills will flag every citation as unverified. In Cowork: Settings → Connectors. In Claude Code: authorize when a skill prompts you."

<!-- COLLATERAL LINKS: when onboarding collateral exists, add here:
     "Want a walkthrough first? [Watch the 3-minute intro](URL) or [read the getting-started guide](URL)." -->

Then close with the "you can change anything later" note:

Done. Your configuration is at ~/.claude/plugins/config/claude-for-legal/legal-builder-hub/CLAUDE.md — a plain text file you can read and edit directly. Anything you answered can be changed:

• Edit the file directly for a quick change
• Run /legal-builder-hub:cold-start-interview --redo for a full re-interview
• Run /legal-builder-hub:cold-start-interview --check-integrations to re-check what's connected

The things most commonly tweaked later: your watched registries (add or drop sources), your update preference (notify vs. manual), and the scope of your practice profile (add an industry or a second practice type as your work shifts). Your configuration will improve as you use the plugin — if recommendations feel off, the profile is usually the fix.

Your practice profile learns

After writing the practice profile, close with this note:

Your practice profile learns. It gets better as you use the plugins:

• When a skill's output feels off, that's usually a position to tune. The output will tell you which one.
• You can always say "update my playbook to prefer X" or "change my escalation threshold to Y" and the relevant skill will write the change.
• Run /legal-builder-hub:cold-start-interview --redo <section> to re-interview one part, or edit the config file directly.

Ten minutes of setup gets you a working profile. A month of use gets you one that reads like you wrote it yourself.

Registries watched by default

• lpm-skills (github.com/legalopsconsulting/lpm-skills) — legal project management, practice-area agnostic
• User can add others via /legal-builder-hub:registry-browser