smith

# Smith: Plugin Scaffolder

You are the Smith orchestrator. When the user runs `/smith <plugin-name>`, scaffold a new Quickstop plugin with correct structure, frontmatter, and marketplace registration. Follow each phase in order.

> **Human-driven by design.** Smith carries `disable-model-invocation: true` in its frontmatter, which means agents and sub-Claudes cannot dispatch it through the Skill tool — `Skill(smith, ...)` returns `Skill smith cannot be used with Skill tool due to disable-model-invocation`. This is intentional, not an oversight. Smith is an interactive scaffolding skill: it asks questions via AskUserQuestion and produces a plugin from human answers. Letting an agent answer those questions on the user's behalf would defeat the purpose. The supported way for an agent to "dogfood" smith is the **recipe-by-hand** path — read this SKILL.md and execute each phase manually against the user's stated inputs, calling Read/Write/Edit/Bash directly rather than dispatching the skill.

> **Hook note.** Smith does not scaffold a `hooks/` directory. If you see the user mention "hooks" anywhere during the questionnaire — in the Description, in Components, or in any free-text answer — prepend the following note to the very next prompt you display (once, not repeatedly): *"Note: smith doesn't scaffold hooks. Author a hook by hand: a small script under `bin/` wired from a `hooks/hooks.json` entry in the consumer's surface, observing only (no payload or flow mutation)."* Then continue normally.

## Phase 0: Validation

### Step 1: Parse Plugin Name

Extract the plugin name from `$ARGUMENTS`. If empty or missing, use AskUserQuestion to ask:
- "What should the plugin be named? (kebab-case, e.g. `my-plugin`)"

### Step 2: Validate Name

1. **Kebab-case**: Name must match `^[a-z][a-z0-9]*(-[a-z0-9]+)*$`. If not, reject and ask for a valid name.
2. **No conflicts**: Glob for `plugins/$ARGUMENTS/` — if it exists, tell the user and abort.
3. **PROJECT_ROOT**: Run `git rev-parse --show-toplevel` via Bash to get the repo root.

Tell the user:
```
Scaffolding plugin: <name>
Gathering requirements...
```

---

## Phase 1: Build Expert Context (lazy)

> **Default: skip this phase.** Phase 1's output rarely influences the scaffolded files for a standard plugin — Phase 3's templates contain no Expert-Context substitution slots. Substitutions come from user answers (Phase 2); none flow from Expert Context. The expert-context fanout is a defensive measure, sunk cost on the standard path.
>
> Run Phase 1 only when one of the trigger conditions below fires during Phase 2, and then run it **between Phase 2 and Phase 3** (not before Phase 2 — you need the questionnaire answers to know whether a trigger applies). For the common case, jump straight from Phase 0 to Phase 2.

### Trigger conditions

Run Phase 1 if any of these surface during Phase 2:

- **A free-text answer (description, component follow-up, skill/agent descriptions) names a capability the templates don't cover** — e.g. hook-only plugins (smith doesn't scaffold hooks; redirect to the by-hand hook pattern), LSP/monitor servers, or anything outside the Skills / Agents / MCP / References component classes the questionnaire lists. Load Expert Context if you're unsure how to scaffold the request.
- **You explicitly need to verify frontmatter details that aren't already in `.claude/skills/smith/references/plugin-spec.md`** — e.g. a recently-added `claude-plugin/plugin.json` field. Lean conservative: when in doubt, load.

If none of these fire, skip directly to Phase 3.

### Step 1: Load Expert Context (only if a trigger fired)

Invoke `/claudit:knowledge ecosystem` to retrieve ecosystem knowledge.

**If the skill runs successfully** (outputs `=== CLAUDIT KNOWLEDGE: ecosystem ===` block):
- Use its output as the ecosystem portion of Expert Context
- Also read `.claude/skills/smith/references/plugin-spec.md` for plugin-authoring-specific detail (plugin.json schema, directory conventions) that the ecosystem cache may not cover at full depth
- Combine both as **Expert Context**
- Continue to Phase 3

**If the skill is not available** (claudit not installed — the invocation produces an error, is not recognized as a command, or produces no knowledge output):
- Proceed to Step 2

### Step 2: Dispatch Research Agents (Fallback)

Dispatch **2 research subagents in parallel** using the Task tool. Both must be foreground.

In a single message, dispatch both Task tool calls:

**Research Plugin Spec:**
- `description`: "Research plugin spec docs"
- `subagent_type`: "research-plugin-spec"
- `prompt`: "Build expert knowledge on Claude Code plugin, skill, and sub-agent authoring. Read the baseline from .claude/skills/smith/references/plugin-spec.md first, then fetch official Anthropic documentation. Return structured expert knowledge including any Quickstop Conventions section from your research."

**Research Hooks & MCP:**
- `description`: "Research hooks/MCP docs"
- `subagent_type`: "research-hooks-mcp"
- `prompt`: "Build expert knowledge on Claude Code hooks and MCP server configuration. Fetch official Anthropic documentation. Return structured expert knowledge."

### Assemble Expert Context

Once both return, combine their results:

```
=== EXPERT CONTEXT ===

## Plugin System Knowledge
[Results from research-plugin-spec]

## Hooks & MCP Knowledge
[Results from research-hooks-mcp]

=== END EXPERT CONTEXT ===
```

Tell the user:
```
Expert context assembled. Continuing to scaffold...
```

---

## Phase 2: Gather Requirements

Use AskUserQuestion for each question. Skip questions that don't apply based on previous answers.

> **Hook-mention detection.** Track whether the user has typed the word "hook" (case-insensitive) in any free-text answer. If detected for the first time, prepend the migration note to the next prompt (see top of this file). Only once — don't repeat.

### Question 1: Description
"What does this plugin do? (1-2 sentence description)"

### Question