docs: update create-plugin command frontmatter to follow best practices

[sjnims]

Summary

Updates the create-plugin.md command frontmatter to align with Claude Code slash command best practices documented in official docs and the command-development skill.

Problem

Fixes #99

The command's YAML frontmatter had three style issues:

1. Description too long (96 chars, recommended < 60)
2. argument-hint missing bracket convention (should use [])
3. Unrestricted Bash tool (command only uses mkdir)

Solution

Updated frontmatter with these changes:

• Shortened description from 96 to 43 characters: Create plugins with guided 8-phase workflow
• Added bracket convention to argument-hint: [plugin-description]
• Restricted Bash to Bash(mkdir:*) since the command only uses mkdir commands

Alternatives Considered

• Keeping unrestricted Bash for flexibility - rejected because best practices say "be as restrictive as possible" and the command content only uses mkdir

Changes

• plugins/plugin-dev/commands/create-plugin.md: Updated YAML frontmatter (lines 2-4)

Testing

• Command validators pass (validate-command.sh, check-frontmatter.sh)
• Markdownlint passes
• Description now 43 chars (under 60 limit)

---

🤖 Generated with Claude Code

[claude]

Claude finished @sjnims's task in 1m 11s —— View job

---

PR Review Complete ✅

I've reviewed the frontmatter changes to create-plugin.md against the command development best practices.

---

Summary

Looks good! This PR successfully aligns the command frontmatter with documented best practices. All three changes are improvements and follow the guidelines from the command-development skill.

---

What's Good

1. Description optimization (line 2):

   • Before: Guided end-to-end plugin creation workflow with component design, implementation, and validation (96 chars)
   • After: Create plugins with guided 8-phase workflow (43 chars)
   • ✅ Now under the recommended 60-character limit
   • ✅ Starts with imperative verb ("Create")
   • ✅ Concise while still conveying purpose
   • ✅ Follows best practice: "Keep under 60 characters for clean display" (frontmatter-reference.md:45)

2. argument-hint bracket convention (line 3):

   • Before: Optional plugin description
   • After: [plugin-description]
   • ✅ Now uses square bracket convention consistently
   • ✅ Follows best practice: "Use square brackets [] for each argument" (frontmatter-reference.md:239)
   • ✅ More descriptive name than generic "description"

3. Bash tool restriction (line 4):

   • Before: "Bash" (unrestricted)
   • After: "Bash(mkdir:*)"
   • ✅ Follows best practice: "Be as restrictive as possible" (frontmatter-reference.md:125)
   • ✅ Follows best practice: "Use command filters for Bash (e.g., git:* not *)" (frontmatter-reference.md:126)
   • ✅ Matches actual usage in the command (only mkdir commands appear in the content)

---

Markdown Linting

markdownlint --config .markdownlint.json plugins/plugin-dev/commands/create-plugin.md

✅ No issues found - All markdown style rules pass

---

Checklist Verification

• ✅ YAML frontmatter valid and well-formed
• ✅ Description concise and actionable
• ✅ argument-hint uses proper bracket notation
• ✅ allowed-tools properly restricted with command filter
• ✅ Changes align with command-development skill guidelines
• ✅ Command validators would pass
• ✅ Markdown linting passes

---

Conclusion

This is a solid documentation improvement PR. All three changes are justified improvements that bring the command into alignment with the best practices documented in the command-development skill. The restrictions are appropriate given the command's actual usage, and the description is now more scannable in /help output.

Recommendation: ✅ Ready to merge