Agent skill
plugin-creator
This skill should be used when the user asks to 'create a plugin', 'scaffold a plugin', 'set up plugin structure', 'new plugin', 'add plugin components', or needs to substantially edit an existing plugin.
Install this agent skill to your Project
npx add-skill https://github.com/edwinhu/workflows/tree/main/skills/plugin-creator
SKILL.md
Plugin Creator (with Superpowers Enforcement)
This skill wraps the built-in plugin-dev:create-plugin with enforcement pattern awareness from the superpowers framework. It adds an enforcement audit layer and PostToolUse validation hooks that the built-in version lacks.
Process
Step 1: Classify the Plugin
Before drafting, classify what's being created or edited:
| Type | Description | Enforcement Needs |
|---|---|---|
| Full plugin | New plugin with skills, hooks, commands, agents | High — needs enforcement across all components |
| Skill addition | Adding a skill to an existing plugin | Medium — needs skill-level enforcement audit |
| Hook addition | Adding hooks to an existing plugin | Medium — needs path validation, matcher coverage |
| Component edit | Substantial edit to existing plugin component | Medium — needs re-audit of affected enforcement |
Anti-Patterns: Read Before Drafting
!cat ${CLAUDE_SKILL_DIR}/../../references/creator-anti-patterns.md
Step 1b: Check for Mechanical Enforcement Opportunities
Before drafting, identify constraints that should be mechanically enforced rather than prompt-enforced. Four mechanisms are available:
| Mechanism | Resolves at | Use for |
|---|---|---|
${CLAUDE_SKILL_DIR} |
Skill load | Script paths in Bash templates (use directly, never wrap in $()) |
!command`` (bang) |
Skill load | Injecting reference file content, environment state |
| Scoped hooks (Pre/PostToolUse) | Each tool call | Mechanically checkable constraints (lint, path guards) |
SessionStart hook (once: true) |
Session start | Expensive computations (API calls, index builds) — not paths or content |
The principle: if a constraint is mechanically checkable, enforce it with a hook. If it requires judgment, keep it as prompt text.
Step 2: Invoke the Built-in Plugin Creator
Use the Skill tool to invoke the built-in plugin creator:
Skill(skill="plugin-dev:create-plugin")
Follow its full process. The built-in creator handles the workflow — do not reimplement it.
Step 3: Enforcement Audit (After Each Draft)
After writing or revising plugin components (and before final validation), audit against the superpowers enforcement patterns. Read the enforcement checklist:
!cat ${CLAUDE_SKILL_DIR}/../../references/enforcement-checklist.md
Then score the draft using the appropriate template:
For Plugin Skills
Score against all 12 patterns from the checklist. Focus especially on:
- Iron Laws — Does each skill have absolute constraints for high-drift actions?
- Rationalization Tables — Does each skill preempt the agent's excuses?
- Red Flags + STOP — Are there pattern interrupts for observable wrong actions?
- Trigger-Only Descriptions — Does each skill description contain ONLY trigger phrases, no process summary?
- Gate Functions — Does every phase transition have a verifiable exit condition?
For Plugin Hooks
Verify:
- Matcher coverage — Do hooks fire on the right tool events?
- Path validity — Do hook commands use
${CLAUDE_SKILL_DIR}/../..(not${CLAUDE_SKILL_DIR})? - Error handling — Do hooks fail gracefully (non-zero exit blocks the action)?
- Scope — Are hooks scoped to skills (frontmatter) or global (plugin.json)?
For Plugin Structure
Verify:
- plugin.json — Valid manifest with correct version, name, description
- marketplace.json — Version matches plugin.json in all locations
- Directory layout — skills/, hooks/, commands/, agents/ as needed
- Path portability — No hardcoded absolute paths in any component
Step 4: Reconcile Tensions
Tension resolution: Enforcement patterns go in skill body (not description), implementation code goes in scripts/, names are descriptive but descriptions are trigger-only.
Step 5: Continue Iteration
Return to the built-in plugin creator's process for validation and testing. After each iteration's revision, re-run the enforcement audit (Step 3).
During iteration, watch for enforcement iteration signals (see "Enforcement Iteration Signals" in the anti-patterns reference loaded above).
References
- Enforcement checklist:
references/enforcement-checklist.md(loaded above via bang injection) - Anti-patterns:
references/creator-anti-patterns.md(loaded above via bang injection) - Philosophy:
references/PHILOSOPHY.md - Built-in plugin creator:
plugin-dev:create-plugin
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
audit-fix-loop
This skill should be used when the user asks to 'iteratively improve', 'audit and fix', 'hill-climb quality', 'grade and improve', 'score and fix', 'audit loop', 'quality loop', or needs structured iterative improvement of an artifact using scored independent audits. Also use when the user invokes a ralph loop for quality improvement rather than task completion.
ds-spec-reviewer
Internal skill used by ds-brainstorm at Phase 1 exit gate. Dispatches a reviewer subagent to verify SPEC.md completeness before planning. NOT user-facing.
pptx-render
Use when the user asks to "render pptx", "show pptx slide", "compare with pptx", "pptx to image", "export pptx slide", "original slide", "show me the original", "what does the pptx look like", or needs to extract a specific PPTX slide's content for visual comparison.
obsidian-organize
Organize Obsidian notes according to clawd's preferences. Use when user asks to "organize notes", "move notes to right folder", "clean up vault", "tidy vault", "file this note", or when creating new notes in the Obsidian vault. Also use when moving, renaming, or categorizing notes, or when the vault root has stray files.
dev-verify
This skill should be used when the user asks to 'verify completion', 'check that tests pass', 'confirm feature works', or REQUIRED Phase 7 of /dev workflow (final). Enforces fresh runtime evidence before claiming completion.
dev
This skill should be used when the user asks to 'start a feature', 'build a feature', 'implement a feature', 'develop', 'new feature', or needs the full 7-phase development workflow with TDD enforcement.
Didn't find tool you were looking for?