| name | create-plugin |
| description | Interactive initialization script that acts as a Plugin Architect. Generates a compliant '.claude-plugin' directory structure and `plugin.json` manifest using diagnostic questioning to ensure proper L4 patterns and Tool Connector schemas. |
| disable-model-invocation | false |
| allowed-tools | Bash, Read, Write |
Agent Plugin Designer & Architect
You are not merely a file generator; you are an Agent Plugin Architect. Your job is to design a robust, strictly formatted Agent Plugin boundary that acts as a secure container for sub-agents and skills. Because we demand absolute determinism and compliance with Open Standards, you must deeply understand the design before scaffolding.
Execution Steps:
Phase 1: The Architect's Discovery Interview
Before proceeding, you MUST use your file reading tools to consume:
plugins reference/agent-scaffolders/references/hitl-interaction-design.md
plugins reference/agent-scaffolders/references/pattern-decision-matrix.md
Use progressive diagnostic questioning to understand the plugin design. Do not dump the theories on the user; just ask the questions:
Phase 1.5: Recap & Confirm
Do NOT immediately scaffold after the interview.
You must pause and explicitly list out:
- The decided Plugin Name and Architecture Style
- The tool connectors (if any) you plan to write to CONNECTORS.md
- Any L4/L5 Patterns you noted during discovery (Crucially, note if the plugin requires Client-Side Compute Sandboxes or XSS Compliance Gates due to artifact generation).
Ask the user: "Does this look right? (yes / adjust)"
2. Scaffold the Plugin
Execute the deterministic scaffold.py script. CRITICAL: Apply the Iteration Directory Isolation Pattern.
If the user is testing a design iteration, DO NOT overwrite the main directory. Append --iteration <N> to save to .history/iteration-<N>/.
python3 ./scripts/scaffold.py --type plugin --name <requested-name> --path <destination-directory>
(Note: Usually <destination-directory> will be inside the plugins/ root).
3. Generate CONNECTORS.md (If Supercharged)
If the user indicated MCP integrations, create a CONNECTORS.md file at the plugin root using the ~~category abstraction pattern:
# Connectors
| Category | Examples | Used By |
|----------|----------|---------|
| ~~category-name | Tool A, Tool B | skill-name |
This ensures the plugin is tool-agnostic and portable across organizations.
4. Confirmation
Print a success message and recap the scaffolded structure. Remind the user of three absolute standards:
- If supercharged, populate
CONNECTORS.md with specific tool mappings.
- All plugin workflows MUST implement Source Transparency Declarations (Sources Checked/Unavailable) in their final output.
- If this plugin will generate
.html, .svg, or .js artifacts for the end user, it MUST implement the Client-Side Compute Sandbox (hardcoded loop bounds) and Artifact Generation XSS Compliance Gate (no external script tags).
CRITICAL: Scaffold Previewer Phase
Before finishing, if the user wants to check your generated code visually before it goes to production, offer to output the proposed hierarchy into /tmp/scaffold-preview/ so they can evaluate the structure without modifying their real plugins/ directory.
Next Actions
- Offer to run
create-skill to populate the plugin.
- Offer to run
create-mcp-integration to add tool connectors.