docs: document intentional git scope limitation in workflow commands

[sjnims]

Summary

• Document that the allowed-tools git scope (git init only) in workflow commands is intentional
• Add post-workflow git operation examples for users to run after completion

Problem

Fixes #136

The workflow commands (create-plugin.md and create-marketplace.md) only allow Bash(git init:*) in their allowed-tools. Issue #136 raised whether this should be expanded to include git add, git status, git commit, etc.

Solution

After analysis, the current limitation is intentionally minimal (Option C from the issue). This is the correct approach because:

1. Write tool handles file creation - Files are created via the Write tool, not bash commands, so git add isn't needed mid-workflow
2. Respects user preferences - Commit messages, timing, and git workflow vary by team/user
3. Focus on structure - The workflow's purpose is structure creation, not managing git history

Rather than expanding git permissions, this PR documents the intentional design and provides post-workflow git examples for users.

Alternatives Considered

• Option A (Bash(git:*)): Too permissive - allows destructive operations like push --force, reset --hard
• Option B (add specific subcommands): Unnecessary since Write tool handles file creation

Changes

• plugins/plugin-dev/commands/create-plugin.md: Updated Phase 4 step 7 with explanation, added post-workflow git examples
• plugins/plugin-dev/commands/create-marketplace.md: Updated Phase 4 step 5 with explanation, added post-workflow git examples

Testing

• markdownlint passes
• Changes limited to documentation only
• No functional changes to workflow behavior

---

🤖 Generated with Claude Code

[claude]

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

---

PR Review: Documentation of Git Scope Limitation

Summary

✅ Looks good - This PR correctly documents an intentional design decision with clear rationale and helpful user guidance.

---

What's Good

Clear Documentation of Intent

• The explanation that git init is the only allowed git operation is now explicit in both workflow commands
• The rationale is sound: workflow focuses on structure creation, not git history management
• Respects user preferences for commit messages and timing

Helpful User Guidance

• Post-workflow git examples provide clear next steps for users
• Examples show the natural git operations users would want to perform after structure creation
• Consistent formatting between both files

Quality Standards

• ✅ Markdownlint passes with no issues
• ✅ Changes are documentation-only (no functional changes)
• ✅ Consistent wording in both create-plugin.md and create-marketplace.md
• ✅ Addresses issue [Feature]: Evaluate git tool scope in workflow commands #136 with Option C (intentionally minimal)

---

Technical Review

Changed Files Analysis:

1. plugins/plugin-dev/commands/create-plugin.md (line 147)

   • Updated step 7 in Phase 4 to explain git scope limitation
   • Added post-workflow git examples section
   • Clear parenthetical explanation inline with the step

2. plugins/plugin-dev/commands/create-marketplace.md (line 160)

   • Updated step 5 in Phase 4 with identical explanation
   • Added matching post-workflow git examples section
   • Maintains consistency with create-plugin workflow

Design Decision Validation:
The PR's choice of Option C (intentionally minimal) is correct because:

• Write tool handles file creation (no need for git add during workflow)
• Prevents scope creep into git workflow management
• Avoids potential security issues with broader git permissions
• Aligns with principle that workflow should focus on structure, not version control

---

Checklist Verification

• ✅ Markdown linting: No issues found
• ✅ Consistency: Both files updated identically
• ✅ Documentation clarity: Explanation is clear and rationale is sound
• ✅ User experience: Post-workflow examples help users understand next steps
• ✅ No functional changes: Only documentation updates
• ✅ Follows plugin-dev conventions: Imperative voice, clear structure

---

Recommendation

Approve and merge. This PR successfully documents an intentional design decision, provides clear rationale, and improves user experience with helpful post-workflow examples.