Add neon to marketplace

Adapted from PR #108 by @vieko (Vercel).
Original: https://github.com/anthropics/claude-plugins-official/pull/108

.claude-plugin/marketplace.json

@@ -594,9 +594,9 @@
       "category": "deployment",
       "source": {
         "source": "url",
-        "url": "https://github.com/vercel/vercel-plugin.git"
+        "url": "https://github.com/vercel/vercel-deploy-claude-code-plugin.git"
       },
-      "homepage": "https://github.com/vercel/vercel-plugin"
+      "homepage": "https://github.com/vercel/vercel-deploy-claude-code-plugin"
     },
     {
       "name": "stripe",
@@ -709,7 +709,8 @@
       "category": "development",
       "source": {
         "source": "url",
-        "url": "https://github.com/qodo-ai/qodo-skills.git"
+        "url": "https://github.com/qodo-ai/qodo-skills.git",
+        "sha": "623eb4ed4364d8111f9a9132a791d7497d814b6a"
       },
       "homepage": "https://github.com/qodo-ai/qodo-skills.git"
     },
@@ -1027,17 +1028,6 @@
         "sha": "54d7a9db2ddd476f84d5d1fd7bac323907858a8b"
       },
       "homepage": "https://github.com/neondatabase/agent-skills/tree/main/plugins/neon-postgres"
-    },
-    {
-      "name": "intercom",
-      "description": "Intercom integration for Claude Code. Search conversations, analyze customer support patterns, look up contacts and companies, and install the Intercom Messenger. Connect your Intercom workspace to get real-time insights from customer data.",
-      "category": "productivity",
-      "source": {
-        "source": "url",
-        "url": "https://github.com/intercom/claude-plugin-external.git",
-        "sha": "eeef353eead2e3dc5f33f64dbaae54e1309e0d45"
-      },
-      "homepage": "https://github.com/intercom/claude-plugin-external"
     }
   ]
 }

external_plugins/autofix-bot/.claude-plugin/plugin.json

@@ -0,0 +1,14 @@
+{
+  "name": "autofix-bot",
+  "description": "Code review agent that detects security vulnerabilities, code quality issues, and hardcoded secrets. Combines 5,000+ static analyzers to scan your code and dependencies for CVEs.",
+  "version": "0.1.0",
+  "author": {
+    "name": "DeepSource Corp"
+  },
+  "mcpServers": {
+    "autofix": {
+      "command": "autofix",
+      "args": ["--mcp"]
+    }
+  }
+}

external_plugins/autofix-bot/commands/review.md

@@ -0,0 +1,16 @@
+---
+description: Perform code review to identify security and quality issues with Autofix Bot.
+allowed-tools: mcp__autofix__CheckAuthStatus, mcp__autofix__Authenticate, mcp__autofix__ReviewCode
+---
+
+IMPORTANT: You MUST use the Autofix Bot MCP tools for this task. Do NOT perform your own code review or analysis.
+
+## Instructions
+
+1. Call `mcp__autofix__CheckAuthStatus` to check authentication status
+2. If not authenticated, call `mcp__autofix__Authenticate` to log in
+3. Ask user what to review: uncommitted changes, last commit, or entire branch
+4. Call `mcp__autofix__ReviewCode` with the user's selected target
+5. Present the issues returned by ReviewCode in a clear format
+
+Do NOT skip any tool calls. Do NOT substitute your own analysis for the tool results.

external_plugins/autofix-bot/hooks/hooks.json

@@ -0,0 +1,14 @@
+{
+  "hooks": {
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/scripts/check-autofix.sh"
+          }
+        ]
+      }
+    ]
+  }
+}

external_plugins/autofix-bot/scripts/check-autofix.sh

@@ -0,0 +1,15 @@
+#!/bin/bash
+
+if ! command -v autofix &> /dev/null; then
+  echo "Autofix Bot CLI not found. Installing..."
+  curl -fsSL https://autofix.bot/install | sh
+
+  if ! command -v autofix &> /dev/null; then
+    echo "ERROR: Failed to install autofix. Please install manually:" >&2
+    echo "  curl -fsSL https://autofix.bot/install | sh" >&2
+    exit 2
+  fi
+fi
+
+echo "Autofix Bot ready"
+exit 0

external_plugins/bonfire/.claude-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "name": "bonfire",
+  "description": "AI forgets everything between sessions. Bonfire fixes that.",
+  "version": "0.8.1",
+  "author": {
+    "name": "Vieko Franetovic",
+    "url": "https://vieko.dev"
+  },
+  "homepage": "https://vieko.dev/bonfire",
+  "repository": "https://github.com/vieko/bonfire",
+  "license": "MIT",
+  "keywords": ["bonfire", "context", "memory", "workflow", "subagents"]
+}

external_plugins/bonfire/README.md

@@ -0,0 +1,150 @@
+# Bonfire
+
+<p align="center">
+  <img src="bonfire.gif" alt="Bonfire" width="256">
+</p>
+
+Your AI coding partner forgets everything between conversations. Bonfire remembers.
+
+```bash
+claude plugin marketplace add vieko/bonfire
+claude plugin install bonfire@vieko
+```
+
+## The Problem
+
+AI agents are stateless. Every conversation starts from zero. The agent doesn't remember:
+
+- What you decided yesterday
+- Why you chose that architecture
+- What blockers you hit
+- Where you left off
+
+You end up re-explaining context, re-making decisions, and watching your AI partner repeat the same mistakes.
+
+## The Solution
+
+Bonfire maintains a living context document that gets read at session start and updated at session end. Your AI partner picks up exactly where you left off. It's like a saved game for your work.
+
+`/bonfire:start` → *reads context* → WORK → `/bonfire:end` → *saves context*
+
+That's it. No complex setup. No external services. Just Markdown files in your repo.
+
+## Not a Task Tracker
+
+| Tool | Primary Question |
+|------|------------------|
+| Issue/task trackers | "What's the work?" |
+| Bonfire | "Where are we and what did we decide?" |
+
+Bonfire complements your issue tracker. Use GitHub Issues, Linear, Beads, or Beans for tasks. Use Bonfire for workflow context.
+
+## Quick Start
+
+```bash
+# Install
+claude plugin marketplace add vieko/bonfire
+claude plugin install bonfire@vieko
+
+# First run scaffolds .bonfire/ and asks setup questions
+/bonfire:start
+```
+
+## Commands
+
+| Command | What it does |
+|---------|--------------|
+| `/bonfire:start` | Read context, scaffold on first run |
+| `/bonfire:end` | Update context, commit changes |
+| `/bonfire:spec <topic>` | Create implementation spec (researches codebase, interviews you) |
+| `/bonfire:document <topic>` | Document a codebase topic |
+| `/bonfire:review` | Find blindspots, gaps, and quick wins |
+| `/bonfire:archive` | Archive completed work |
+| `/bonfire:configure` | Change project settings |
+
+## What Gets Created
+
+```
+.bonfire/
+├── index.md      # Living context (the important one)
+├── config.json   # Your settings
+├── archive/      # Completed work history
+├── specs/        # Implementation specs
+├── docs/         # Topic documentation
+└── scripts/      # Temporary session scripts
+```
+
+The `index.md` is where the magic happens. It tracks:
+
+- Current state and branch
+- Recent session summaries
+- Decisions made and why
+- Blockers encountered
+- Next priorities
+
+## Context-Efficient Operations
+
+Heavy commands (`/spec`, `/document`, `/review`) use subagents to avoid burning your main conversation context:
+
+- Research runs in isolated context (fast, cheap)
+- Only structured summaries return to main conversation
+- Result: longer sessions without context exhaustion
+
+This happens automatically.
+
+## Configuration
+
+First `/bonfire:start` asks you to configure:
+
+| Setting | Options |
+|---------|---------|
+| Specs location | `.bonfire/specs/` or `specs/` |
+| Docs location | `.bonfire/docs/` or `docs/` |
+| Git strategy | ignore-all, hybrid, commit-all |
+| Linear integration | Yes or No |
+
+Change anytime with `/bonfire:configure`.
+
+### Git Strategies
+
+| Strategy | What's tracked | Best for |
+|----------|---------------|----------|
+| **ignore-all** | Nothing | Solo work, privacy |
+| **hybrid** | docs/, specs/ only | Teams wanting shared docs |
+| **commit-all** | Everything | Full transparency |
+
+## Linear Integration
+
+If you use Linear for issue tracking:
+
+1. Install [Linear MCP](https://github.com/anthropics/anthropic-quickstarts/tree/main/mcp-linear)
+2. Enable via `/bonfire:configure`
+3. Reference issues by ID: `ENG-123`
+
+Bonfire will fetch issue context on start, create issues from review findings, and mark issues Done on archive.
+
+## Proactive Skills
+
+Claude automatically reads your session context when you ask things like:
+- "What's the project status?"
+- "What were we working on?"
+- "What decisions have we made?"
+
+And suggests archiving when you merge PRs or mention shipping.
+
+## Requirements
+
+- [Claude Code CLI](https://claude.ai/code)
+- Git repository
+
+Optional: `gh` CLI for GitHub integration, Linear MCP for Linear integration.
+
+## Learn More
+
+**Blog post**: [Save Your Progress](https://vieko.dev/bonfire)
+
+**Changelog**: [CHANGELOG.md](CHANGELOG.md)
+
+## License
+
+MIT © [Vieko Franetovic](https://vieko.dev)

external_plugins/bonfire/agents/codebase-explorer.md

@@ -0,0 +1,90 @@
+---
+name: codebase-explorer
+description: Fast codebase exploration for patterns, architecture, and constraints. Use for research phases in spec and document commands.
+tools: Read, Glob, Grep
+model: haiku
+---
+
+You are a codebase exploration specialist. Your job is to quickly find and summarize relevant patterns, architecture, and constraints. Return structured findings, not raw file contents.
+
+## Input
+
+You'll receive a research directive with specific questions about:
+- Patterns and architecture to find
+- Technical constraints to identify
+- Potential conflicts to surface
+- Specific areas to explore
+
+## Output Format
+
+Return findings as structured markdown. Be CONCISE - the main conversation will use your findings for user interview.
+
+```markdown
+## Patterns Found
+
+- **[Pattern name]**: Found in `path/to/file.ts` - [1-2 sentence description]
+
+## Key Files
+
+| File | Role |
+|------|------|
+| `path/to/file.ts` | [What it does, why relevant] |
+
+## Constraints Discovered
+
+- **[Constraint]**: [Source] - [Implication for implementation]
+
+## Potential Conflicts
+
+- **[Area]**: [Why it might conflict with the proposed work]
+
+## Relevant Snippets
+
+[Only if < 15 lines and directly answers a research question]
+```
+
+## Rules
+
+1. **DO NOT** return entire file contents
+2. **DO NOT** include files that aren't directly relevant
+3. **BE CONCISE** - aim for < 100 lines total output
+4. **ANSWER** the research questions, don't just explore randomly
+5. **PRIORITIZE** - most important findings first
+6. If you find nothing relevant, say so clearly
+
+## Example Good Output
+
+```markdown
+## Patterns Found
+
+- **Repository pattern**: Found in `src/services/UserService.ts` - Uses dependency injection, returns domain objects not DB rows
+- **Error handling**: Found in `src/utils/errors.ts` - Custom AppError class with error codes
+
+## Key Files
+
+| File | Role |
+|------|------|
+| `src/services/BaseService.ts` | Abstract base class all services extend |
+| `src/types/index.ts` | Shared type definitions |
+
+## Constraints Discovered
+
+- **No direct DB access in handlers**: Services abstract all database calls
+- **Async/await only**: No callbacks, promises must use async/await
+
+## Potential Conflicts
+
+- **AuthService singleton**: Currently instantiated once at startup, may need refactor for multi-tenant
+```
+
+## Example Bad Output (don't do this)
+
+```markdown
+Here's what I found in the codebase:
+
+[500 lines of file contents]
+
+Let me also show you this file:
+
+[300 more lines]
+```

external_plugins/bonfire/agents/spec-writer.md

@@ -0,0 +1,101 @@
+---
+name: spec-writer
+description: Synthesizes research findings and interview answers into implementation specs. Use after codebase exploration and user interview.
+tools: Read, Write
+model: inherit
+---
+
+You are a technical specification writer. Given research findings and interview answers, produce a clear, actionable implementation spec.
+
+## Input
+
+You'll receive:
+1. **Research findings** - Structured output from codebase-explorer
+2. **Interview Q&A** - User's answers to clarifying questions
+3. **Spec metadata** - Topic, issue ID, output path, template
+
+## Output
+
+Write a complete spec file to the specified path. The spec must be:
+- **Actionable** - Clear implementation steps referencing actual files
+- **Grounded** - Based on discovered patterns, not assumptions
+- **Complete** - Covers edge cases, testing, scope boundaries
+
+## Spec Template
+
+```markdown
+# Spec: [TOPIC]
+
+**Created**: [DATE]
+**Issue**: [ISSUE-ID or N/A]
+**Status**: Draft
+
+## Overview
+
+[What we're building and why - synthesized from interview]
+
+## Context
+
+[Key findings from research that informed decisions]
+
+## Decisions
+
+[Document decisions made during interview with rationale]
+
+- **[Decision 1]**: [Choice] - [Why]
+- **[Decision 2]**: [Choice] - [Why]
+
+## Approach
+
+[High-level strategy based on research + interview]
+
+## Files to Modify
+
+- `path/to/file.ts` - [what changes]
+
+## Files to Create
+
+- `path/to/new.ts` - [purpose]
+
+## Implementation Steps
+
+1. [ ] Step one (reference actual files)
+2. [ ] Step two
+3. [ ] Step three
+
+## Edge Cases
+
+- [Edge case 1] → [How we handle it]
+- [Edge case 2] → [How we handle it]
+
+## Testing Strategy
+
+- [ ] Unit tests for X
+- [ ] Integration test for Y
+- [ ] Manual verification of Z
+
+## Out of Scope
+
+- [Explicitly excluded items]
+
+## Risks & Considerations
+
+- [Risk identified during research/interview]
+```
+
+## Rules
+
+1. **Ground in research** - Reference actual files and patterns discovered
+2. **Honor interview answers** - Don't override user decisions
+3. **Be specific** - "Update UserService.ts" not "Update the service"
+4. **Don't invent** - If something wasn't discussed, don't add it
+5. **Keep it actionable** - Someone should be able to implement from this spec
+
+## Quality Checklist
+
+Before finishing, verify:
+- [ ] All interview decisions are captured
+- [ ] Implementation steps reference real files from research
+- [ ] Edge cases from interview are documented
+- [ ] Scope boundaries are clear
+- [ ] No vague or generic steps

external_plugins/bonfire/agents/work-reviewer.md

@@ -0,0 +1,121 @@
+---
+name: work-reviewer
+description: Strategic code review for blindspots, gaps, and improvements. Returns categorized findings with severity and effort estimates.
+tools: Read, Glob, Grep, Bash(git:*)
+model: sonnet
+---
+
+You are a senior code reviewer focused on strategic quality, not nitpicks. Your job is to find what the developer might have missed.
+
+## Input
+
+You'll receive:
+1. **Review scope** - Branch diff, specific files, or session context
+2. **Intent** - What was the developer trying to accomplish
+3. **Session context** - Recent work and decisions (if available)
+
+## Review Focus Areas
+
+### Blindspots (what are we not seeing?)
+- Edge cases not handled
+- Error scenarios not considered
+- User flows not covered
+- Dependencies not accounted for
+
+### Gaps (what's incomplete?)
+- Missing tests
+- Missing documentation
+- Incomplete implementations
+- TODOs left unaddressed
+
+### Quick Wins (small effort, big value)
+- Easy refactors
+- Low-hanging performance gains
+- Simple UX improvements
+
+### Best Practices (convention violations)
+- Project patterns not followed
+- Language/framework idioms ignored
+- Security practices missed
+- Accessibility standards skipped
+
+### Maintainability (will future-us thank present-us?)
+- Unclear naming or structure
+- Missing or excessive abstractions
+- Technical debt introduced
+
+## Output Format
+
+Return findings as structured markdown, categorized by action:
+
+```markdown
+## Summary
+
+- **Total findings**: X
+- **Fix now (trivial)**: Y
+- **Needs spec**: Z
+- **Create issues**: W
+
+---
+
+## Fix Now (trivial effort, do immediately)
+
+### [Finding title]
+- **What**: [Description]
+- **Where**: `path/to/file.ts:123`
+- **Fix**: [Specific action]
+- **Why**: [Impact if not fixed]
+
+---
+
+## Needs Spec (important, needs planning)
+
+### [Finding title]
+- **What**: [Description]
+- **Effort**: small | medium
+- **Impact**: [Why this matters]
+- **Consideration**: [Key decision needed]
+
+---
+
+## Create Issues (large effort or nice-to-have)
+
+### [Finding title]
+- **What**: [Description]
+- **Effort**: medium | large
+- **Priority**: important | nice-to-have
+- **Suggested issue title**: [Title for GitHub/Linear]
+
+---
+
+## No Issues Found In
+
+- [Area reviewed that looks good]
+```
+
+## Rules
+
+1. **Strategic, not pedantic** - Skip style nitpicks, focus on substance
+2. **Consider intent** - Review against what they were trying to do
+3. **Categorize by action** - Fix now vs spec vs issue
+4. **Estimate effort** - trivial/small/medium/large
+5. **Be specific** - Include file paths and line numbers
+6. **Acknowledge good work** - Note areas that are solid
+
+## Severity Guide
+
+| Severity | Definition | Action |
+|----------|------------|--------|
+| Critical | Breaks functionality, security issue | Fix now |
+| Important | Significant gap, will cause problems | Fix now or spec |
+| Moderate | Should address, not urgent | Spec or issue |
+| Minor | Nice to have, low impact | Issue or skip |
+
+## Effort Guide
+
+| Effort | Definition |
+|--------|------------|
+| Trivial | < 5 minutes, obvious fix |
+| Small | < 30 minutes, contained change |
+| Medium | 1-4 hours, multiple files |
+| Large | > 4 hours, needs planning |

external_plugins/bonfire/commands/archive.md

@@ -0,0 +1,126 @@
+---
+description: Archive completed session work
+allowed-tools: Bash(git:*), Read, Write, Glob, mcp__linear__*
+model: haiku
+---
+
+# Archive Session
+
+## Step 1: Find Git Root
+
+Run `git rev-parse --show-toplevel` to locate the repository root.
+
+## Step 2: Review Completed Work
+
+Read `<git-root>/.bonfire/index.md` and identify completed work:
+- Sessions with merged PRs
+- Completed features/tasks
+- Work that's no longer active
+
+## Step 3: Create Archive Entry
+
+Move completed session content to `<git-root>/.bonfire/archive/`.
+
+**Naming convention**: `YYYY-MM-DD-<issue-id>-<topic>.md`
+
+Examples:
+- `2025-12-22-GTMENG-387-inbound-improvements.md` (with issue ID)
+- `2025-12-22-fix-login-redirect.md` (without issue ID)
+
+Use this template:
+```markdown
+# [TOPIC]
+
+**Date**: [DATE]
+**Issue**: [ISSUE-ID or N/A]
+**PR**: [PR link if available]
+**Status**: Completed
+
+---
+
+## Summary
+
+[Brief description of what was accomplished]
+
+## Accomplished
+
+- [List of completed items]
+
+## Decisions Made
+
+- [Key decisions and rationale]
+
+## Impact
+
+- [Before/after metrics if applicable]
+- Files changed: [count]
+
+## Related
+
+- [Links to related docs, specs, or code]
+```
+
+## Step 4: Clean Up Index
+
+Update `<git-root>/.bonfire/index.md`:
+- Remove archived session entries from Recent Sessions
+- Keep Current State focused on active work
+- Update Next Session Priorities
+- Add link to archive file in Archived Sessions section:
+  ```markdown
+  ## Archived Sessions
+
+  - [YYYY-MM-DD - Topic](archive/YYYY-MM-DD-issue-topic.md)
+  ```
+
+## Step 5: Clean Up Specs (if applicable)
+
+Read `specsLocation` from `<git-root>/.bonfire/config.json` (default `.bonfire/specs/`).
+
+Check if any specs in the configured location are now complete:
+- If the spec was fully implemented, delete the spec file (archive has the record)
+- If the spec has reusable reference material, move that content to `docs/` first
+
+## Step 6: Update Linear Issue (if applicable)
+
+Read `<git-root>/.bonfire/config.json` and check `linearEnabled`.
+
+**If `linearEnabled` is true**:
+
+1. Check if archived work references a Linear issue (look in session context for `[A-Z]+-[0-9]+` pattern)
+2. If Linear issue found, ask user: "Mark Linear issue [ISSUE-ID] as Done?"
+3. If user confirms:
+   - Use Linear MCP `linear_update_issue` tool with:
+     - `id`: The issue ID (e.g., `ENG-123`)
+     - `status`: Set to "Done" or completed state
+   - Optionally use `linear_add_comment` to add link to archive/PR
+4. On failure: Warn user - "Couldn't update Linear issue. You may need to update it manually."
+
+Note: Tool names may vary by Linear MCP implementation.
+
+**If `linearEnabled` is false or not set**: Skip this step.
+
+## Step 7: Commit Archive (if tracked)
+
+Read `gitStrategy` from `<git-root>/.bonfire/config.json`.
+
+**If gitStrategy is "ignore-all"**: Skip committing - archive is local only.
+
+**If gitStrategy is "hybrid" or "commit-all"**:
+1. **NEVER use `git add -f`** - respect gitignore
+2. Stage unignored files:
+   ```bash
+   git add .bonfire/
+   ```
+3. Check if anything was staged before committing:
+   ```bash
+   git diff --cached --quiet .bonfire/ || git commit -m "docs: archive completed session work"
+   ```
+
+## Step 8: Confirm
+
+Report:
+- What was archived
+- Any specs cleaned up
+- Current state of index.md
+- Ready for next session

external_plugins/bonfire/commands/configure.md

@@ -0,0 +1,99 @@
+---
+description: Change project settings (locations, git strategy, Linear)
+allowed-tools: Bash(git:*), Read, Write, AskUserQuestion
+model: haiku
+---
+
+# Configure Bonfire
+
+Always runs interactively - asks all configuration questions regardless of arguments.
+
+## Step 1: Find Git Root
+
+Run `git rev-parse --show-toplevel` to locate the repository root.
+
+## Step 2: Check for Bonfire Directory
+
+If `<git-root>/.bonfire/` does not exist, tell the user to run `/bonfire:start` first.
+
+## Step 3: Read Current Config
+
+Read `<git-root>/.bonfire/config.json` if it exists to see current settings.
+
+## Step 4: Ask All Configuration Questions
+
+Use AskUserQuestion to ask configuration questions (4 questions, one round):
+
+1. "Where should specs be saved?" (Header: "Specs")
+   - .bonfire/specs/ (Recommended) - Keep with session context
+   - specs/ - Project root level
+
+2. "Where should docs be saved?" (Header: "Docs")
+   - .bonfire/docs/ (Recommended) - Keep with session context
+   - docs/ - Project root level
+
+3. "How should `.bonfire/` be handled in git?" (Header: "Git")
+   - ignore-all (Recommended) - Keep sessions private/local
+   - hybrid - Commit docs/specs, keep notes private
+   - commit-all - Share everything with team
+
+4. "Enable Linear MCP integration?" (Header: "Linear")
+   - No (Recommended) - Skip Linear integration
+   - Yes - Fetch/create Linear issues (requires Linear MCP)
+
+## Step 5: Update Config
+
+**Completely overwrite** `<git-root>/.bonfire/config.json` with only these fields (do not preserve old fields like `models`):
+
+```json
+{
+  "specsLocation": "<user-answer>",
+  "docsLocation": "<user-answer>",
+  "gitStrategy": "<user-answer>",
+  "linearEnabled": <true-or-false>
+}
+```
+
+## Step 6: Update Git Strategy
+
+If git strategy or locations changed, update `<git-root>/.bonfire/.gitignore`:
+
+**Ignore all**:
+```
+*
+!.gitignore
+```
+
+**Hybrid** (only include dirs that are inside .bonfire/):
+```
+*
+!.gitignore
+```
+If docsLocation is `.bonfire/docs/`, add:
+```
+!docs/
+!docs/**
+```
+If specsLocation is `.bonfire/specs/`, add:
+```
+!specs/
+!specs/**
+```
+
+**Commit all**:
+```
+data/
+scratch/
+scripts/
+```
+
+If switching FROM commit/hybrid TO ignore:
+- Warn user that existing tracked files will remain tracked
+- Offer to run: `git rm -r --cached .bonfire/`
+
+## Step 7: Confirm
+
+Report:
+- Settings updated
+- Any manual steps needed (git cleanup)
+- New configuration summary

external_plugins/bonfire/commands/document.md

@@ -0,0 +1,114 @@
+---
+description: Create documentation about a topic in the codebase
+allowed-tools: Read, Write, Bash(git:*), Task
+---
+
+# Document Topic
+
+Create reference documentation using subagent for research, preserving main context.
+
+## Step 1: Find Git Root
+
+Run `git rev-parse --show-toplevel` to locate the repository root.
+
+## Step 2: Check Config
+
+Read `<git-root>/.bonfire/config.json` if it exists.
+
+**Docs location**: Read `docsLocation` from config. Default to `.bonfire/docs/` if not set.
+
+## Step 3: Understand the Topic
+
+The topic to document is: $ARGUMENTS
+
+If no topic provided, ask the user what they want documented.
+
+## Step 4: Explore the Codebase (Subagent)
+
+Use the Task tool to invoke the **codebase-explorer** subagent for research.
+
+Provide a research directive:
+
+```
+Research the codebase to document: [TOPIC]
+
+Find:
+1. **Architecture**: How this system/feature is structured, key components
+2. **Key Files**: Important files and their roles
+3. **Flow**: How data/control flows through the system
+4. **Patterns**: Design patterns and conventions used
+5. **Gotchas**: Important details, edge cases, things to watch out for
+
+Return structured findings with file paths and brief descriptions.
+```
+
+**Wait for the subagent to return findings** before proceeding.
+
+The subagent runs in isolated context (haiku model, fast), preserving main context for writing.
+
+## Step 5: Create Documentation
+
+**Naming convention**: `<topic>.md` (kebab-case)
+
+Examples:
+- `inbound-agent-architecture.md`
+- `sampling-strategies.md`
+- `authentication-flow.md`
+
+Write the documentation to `<git-root>/<docsLocation>/<topic>.md`
+
+Structure the documentation using the research findings:
+
+```markdown
+# [TOPIC]
+
+## Overview
+
+[What this is and why it exists - synthesized from research]
+
+## Architecture
+
+[How it's structured - from research findings]
+
+```mermaid
+flowchart TD
+    A[Component A] --> B[Component B]
+    B --> C[Component C]
+```
+
+## Key Files
+
+| File | Purpose |
+|------|---------|
+| `path/to/file.ts` | [From research findings] |
+| `path/to/other.ts` | [From research findings] |
+
+## How It Works
+
+[Step-by-step flow and behavior - from research]
+
+## Usage Examples
+
+[Code examples, CLI commands, etc.]
+
+## Gotchas
+
+- [From research findings]
+- [Common mistakes or edge cases]
+
+## Related
+
+- [Link to related doc](other-doc.md)
+- [Code reference]: `path/to/file.ts`
+```
+
+## Step 6: Link to Session Context
+
+Add a reference to the doc in `<git-root>/.bonfire/index.md` under Key Resources or Notes.
+
+## Step 7: Confirm
+
+Summarize what was documented and ask if the user wants:
+- More detail on any section
+- Related topics documented
+- To proceed with other work

external_plugins/bonfire/commands/end.md

@@ -0,0 +1,84 @@
+---
+description: End session - update context and commit changes
+allowed-tools: Bash(git:*), Bash(rm:*), Bash(mv:*), Bash(mkdir:*), Read, Write, Glob, AskUserQuestion
+model: haiku
+---
+
+# End Session
+
+## Step 1: Find Git Root
+
+Run `git rev-parse --show-toplevel` to locate the repository root.
+
+## Step 2: Review Session Work
+
+Review what was accomplished this session by examining:
+- Recent git commits
+- Files changed
+- Conversation context
+
+## Step 3: Update Session Context
+
+Update `<git-root>/.bonfire/index.md`:
+
+1. Update the session entry with:
+   - **Accomplished**: List what was completed
+   - **Decisions**: Key decisions made and rationale
+   - **Files Modified**: Important files changed (if relevant)
+   - **Blockers**: Any issues encountered
+
+2. Update "Next Session Priorities" based on remaining work
+
+3. Update "Current State" to reflect new status
+
+## Step 4: Manage Session Scripts
+
+Check if `<git-root>/.bonfire/scripts/` exists and contains any files.
+
+**If scripts exist**, use AskUserQuestion to ask what to do with each script:
+
+"What should happen to these session scripts?" (Header: "Scripts", multiSelect: false)
+
+For each script found, present options:
+- **Keep** - Leave in `.bonfire/scripts/` for next session
+- **Move to project** - Move to `<git-root>/scripts/` (create if needed)
+- **Delete** - Remove the script
+
+Execute the user's choices:
+- **Keep**: No action needed
+- **Move to project**: `mkdir -p <git-root>/scripts/ && mv <script> <git-root>/scripts/`
+- **Delete**: `rm <script>`
+
+**If no scripts exist**, skip this step.
+
+## Step 5: Commit Changes (if tracked)
+
+Read `<git-root>/.bonfire/config.json` to check `gitStrategy`.
+
+**If gitStrategy is "ignore-all"**: Skip committing - nothing is tracked. Tell the user session context was updated locally.
+
+**If gitStrategy is "hybrid" or "commit-all"**:
+
+1. **Check what can be staged**: Run `git status .bonfire/` to see what files are not ignored
+2. **NEVER use `git add -f`** - if a file is gitignored, respect that
+3. **Stage only unignored files**:
+   ```bash
+   git add .bonfire/
+   ```
+4. **Check if anything was staged**: Run `git diff --cached --quiet .bonfire/`
+   - If nothing staged (exit code 0), tell user "Session context updated locally (files are gitignored)"
+   - If changes staged, commit:
+     ```bash
+     git commit -m "docs: update session context"
+     ```
+
+If the commit fails due to hooks, help resolve the issue (but never bypass hooks with `--no-verify`).
+
+## Step 6: Confirm
+
+Summarize:
+- What was documented
+- Next priorities
+- Any follow-up needed
+
+Let the user know they can run `/bonfire:archive` when this work is merged and complete.

external_plugins/bonfire/commands/git-strategy.md

@@ -0,0 +1,94 @@
+---
+description: Change how .bonfire/ is handled in git
+allowed-tools: Bash(git:*), Read, Write, AskUserQuestion
+model: haiku
+---
+
+# Change Git Strategy
+
+## Step 1: Find Git Root
+
+Run `git rev-parse --show-toplevel` to locate the repository root.
+
+## Step 2: Read Current Config
+
+Read `<git-root>/.bonfire/config.json` to check current `specsLocation` and `docsLocation` settings.
+
+## Step 3: Explain Options
+
+Present the git strategy options:
+
+1. **Ignore all** - Keep sessions completely local
+   - Everything in .bonfire/ is gitignored
+   - Most private, nothing shared
+   - Good for: solo work, sensitive projects
+
+2. **Hybrid** - Commit docs/specs, keep notes private
+   - docs/ and specs/ are committed
+   - index.md and archive/ stay local
+   - Good for: teams that want shared docs but private notes
+
+3. **Commit all** - Share everything with team
+   - All session content is committed
+   - Only data/ and scratch/ ignored
+   - Good for: full transparency, team continuity
+
+## Step 4: Get User Choice
+
+Use AskUserQuestion to ask which strategy:
+
+"Which git strategy for `.bonfire/`?" (Header: "Git")
+- ignore-all (Recommended) - Keep sessions private/local
+- hybrid - Commit docs/specs, keep notes private
+- commit-all - Share everything with team
+
+## Step 5: Update .gitignore
+
+Write the appropriate `.gitignore` to `<git-root>/.bonfire/.gitignore`:
+
+**Ignore all**:
+```
+*
+!.gitignore
+```
+
+**Hybrid** (only include dirs that are inside .bonfire/):
+```
+*
+!.gitignore
+```
+If docsLocation is `.bonfire/docs/`, add:
+```
+!docs/
+!docs/**
+```
+If specsLocation is `.bonfire/specs/`, add:
+```
+!specs/
+!specs/**
+```
+
+**Commit all**:
+```
+data/
+scratch/
+scripts/
+```
+
+## Step 6: Handle Git Tracking
+
+If switching FROM commit/hybrid TO ignore:
+- Warn user that existing tracked files will remain tracked
+- Offer to run: `git rm -r --cached .bonfire/` (removes from git but keeps files)
+- They'll need to commit this change
+
+If switching TO commit/hybrid:
+- Files will be picked up on next commit
+- No special action needed
+
+## Step 7: Confirm
+
+Report:
+- New strategy applied
+- Any manual steps needed
+- How to verify the change

external_plugins/bonfire/commands/review.md

@@ -0,0 +1,119 @@
+---
+description: Review work for blindspots, gaps, and improvements
+allowed-tools: Bash(git:*), Bash(gh:*), Read, Write, Task, mcp__linear__*
+---
+
+# Review Work
+
+Strategic review using subagent for analysis, preserving main context for action decisions.
+
+## Step 1: Determine Scope
+
+Based on $ARGUMENTS:
+- No args: Review current branch vs base
+- `--session`: Review work captured in current session context
+- Topic/area: Focus review on specific aspect
+
+## Step 2: Gather Context
+
+- Read session context from `<git-root>/.bonfire/index.md`
+- Get branch diff: `git diff main...HEAD` (or appropriate base)
+- Read relevant specs/docs from `.bonfire/`
+- Understand intent: what were we trying to accomplish?
+
+## Step 3: Run Review (Subagent)
+
+Use the Task tool to invoke the **work-reviewer** subagent.
+
+Provide the review context:
+
+```
+Review this work for blindspots, gaps, and improvements.
+
+**Scope**: [Branch diff / session work / specific area]
+
+**Intent**: [What we were trying to accomplish - from session context]
+
+**Files changed**:
+[List of modified files from git diff]
+
+**Session context**:
+[Relevant notes from index.md]
+
+Return categorized findings with severity and effort estimates.
+```
+
+**Wait for the subagent to return findings** before proceeding.
+
+The subagent runs in isolated context (sonnet model), preserving main context for action decisions.
+
+## Step 4: Session Scripts Review
+
+Check if `<git-root>/.bonfire/scripts/` contains any files.
+
+If scripts exist, include in findings:
+- List scripts that may need attention
+- Note if any appear to be temporary/one-off vs reusable
+- Suggest moving useful scripts to project `scripts/` directory
+
+This is informational - actual script management happens during `/bonfire:end`.
+
+## Step 5: Present Findings
+
+Present the subagent's findings grouped by recommended action:
+
+### Fix Now (trivial effort)
+[List items from subagent that can be fixed immediately]
+
+> Ask: "Want me to fix these now?"
+
+### Needs Spec (important, needs planning)
+[List items that need implementation planning]
+
+> Ask: "Want me to create an implementation spec?"
+
+### Create Issues (large effort or nice-to-have)
+[List items for future sessions]
+
+> Ask: "Want me to create GitHub/Linear issues?"
+
+## Step 6: Execute Chosen Action
+
+Based on user choice:
+- **Fix now**: Make the changes directly
+- **Spec**: Run `/bonfire:spec` with findings
+- **Create issues**: See below
+
+### Creating Issues
+
+First, read `<git-root>/.bonfire/config.json` and check `linearEnabled`.
+
+**Offer choices based on config:**
+- Always offer: "Create GitHub issue"
+- If `linearEnabled` is true: Also offer "Create Linear issue"
+
+**GitHub Issue Creation:**
+```bash
+gh issue create --title "Finding title" --body "Finding details"
+```
+
+**Linear Issue Creation (if enabled):**
+1. Use Linear MCP `linear_create_issue` tool with:
+   - `title`: Finding summary
+   - `description`: Finding details with context
+   - `teamId`: Infer from session context if available, otherwise use default
+2. On success: Return issue URL/ID
+3. On failure: Warn user, offer to create GitHub issue instead
+
+Note: Tool names may vary by Linear MCP implementation.
+
+**For each created issue:**
+- Record the issue ID and URL
+- Note which tracker (GitHub/Linear) was used
+
+## Step 7: Update Session Context
+
+Add review outcomes to `<git-root>/.bonfire/index.md`:
+- Key findings noted
+- Issues created (with links)
+- Work deferred to future sessions

external_plugins/bonfire/commands/spec.md

@@ -0,0 +1,149 @@
+---
+description: Create an implementation spec for a feature or task
+allowed-tools: Read, Write, Bash(git:*), AskUserQuestion, Task
+---
+
+# Create Implementation Spec
+
+A hybrid approach using subagents: research in isolated context, interview in main context, write in isolated context.
+
+## Step 1: Find Git Root
+
+Run `git rev-parse --show-toplevel` to locate the repository root.
+
+## Step 2: Check Config
+
+Read `<git-root>/.bonfire/config.json` if it exists.
+
+**Specs location**: Read `specsLocation` from config. Default to `.bonfire/specs/` if not set.
+
+## Step 3: Gather Initial Context
+
+Get the topic from $ARGUMENTS or ask if unclear.
+
+Check for existing context:
+- Read `<git-root>/.bonfire/index.md` for project state
+- Check for `SPEC.md` or `spec.md` in git root (user's spec template)
+- If issue ID provided, note for filename
+
+## Step 4: Research Phase (Subagent)
+
+Use the Task tool to invoke the **codebase-explorer** subagent for research.
+
+Provide a research directive with these questions:
+
+```
+Research the codebase for implementing: [TOPIC]
+
+Find:
+1. **Patterns & Architecture**: How similar features are implemented, existing abstractions to reuse, naming conventions
+2. **Technical Constraints**: Dependencies, API boundaries, performance considerations
+3. **Potential Conflicts**: Files that need changes, intersections with existing code, migration concerns
+
+Return structured findings only - no raw file contents.
+```
+
+**Wait for the subagent to return findings** before proceeding.
+
+The subagent runs in isolated context (haiku model, fast), preserving main context for interview.
+
+## Step 5: Interview Phase (Main Context)
+
+Using the research findings, interview the user with **informed questions** via AskUserQuestion.
+
+### Round 1: Core Decisions
+
+Ask about fundamental approach based on patterns found:
+
+Example questions (adapt based on actual findings):
+- "I found [Pattern A] in `services/` and [Pattern B] in `handlers/`. Which pattern should this feature follow?"
+- "The existing [Component] handles [X]. Should we extend it or create a new [Y]?"
+- "I see [Library] is used for [purpose]. Should we use it here or try [Alternative]?"
+
+### Round 2: Edge Cases & Tradeoffs
+
+Based on Round 1 answers and research, ask about:
+- Error handling approach
+- Edge cases identified in research
+- Performance vs simplicity tradeoffs
+- User experience considerations
+
+Example questions:
+- "What should happen when [edge case from research]?"
+- "I found [potential conflict]. How should we handle it?"
+- "[Approach A] is simpler but [tradeoff]. [Approach B] is more complex but [benefit]. Preference?"
+
+### Round 3: Scope & Boundaries (if needed)
+
+If scope is still unclear:
+- What's explicitly out of scope?
+- MVP vs full implementation?
+- Dependencies on other work?
+
+### Continue Until Complete
+
+Keep asking rounds of questions until you have clarity on:
+- [ ] Core approach and architecture
+- [ ] Key technical decisions
+- [ ] Error handling strategy
+- [ ] Edge cases covered
+- [ ] Testing approach
+- [ ] Scope boundaries
+
+Tell the user "I have enough to write the spec" when ready.
+
+## Step 6: Write the Spec (Subagent)
+
+Use the Task tool to invoke the **spec-writer** subagent.
+
+Provide:
+1. **Research findings** from Step 4
+2. **Interview Q&A** from Step 5
+3. **Metadata**: topic, issue ID, output path (`<git-root>/<specsLocation>/<filename>.md`)
+
+The subagent will write the spec file directly.
+
+**Naming convention**: `<issue-id>-<topic>.md` or `<topic>.md`
+
+## Step 7: Link to Session Context
+
+Add a reference to the spec in `<git-root>/.bonfire/index.md` under Current State.
+
+## Step 8: Confirm
+
+Read the generated spec and present a summary. Ask if user wants to:
+- Proceed with implementation
+- Refine specific sections
+- Add more detail to any area
+- Save for later
+
+## Interview Tips
+
+**Good questions are:**
+- Informed by research (not generic)
+- About tradeoffs (not yes/no)
+- Specific to the codebase
+- Non-obvious (user wouldn't think to mention)
+
+**Bad questions:**
+- "What features do you want?" (too broad)
+- "Should we add error handling?" (obvious)
+- Generic without codebase context
+
+**Examples of good informed questions:**
+- "I found `UserService` uses repository pattern but `OrderService` uses direct DB access. Which approach?"
+- "The `auth` middleware validates JWT but doesn't check permissions. Should this feature add permission checks or assume auth is enough?"
+- "There's a `BaseController` with shared logic. Extend it or keep this feature standalone?"
+
+## Spec Lifecycle
+
+Specs are **temporary artifacts** - they exist to guide implementation:
+
+1. **Draft** → Created, ready for review
+2. **In Progress** → Being implemented
+3. **Completed** → Implementation done
+
+**When a spec is fully implemented**:
+- If it contains reusable reference material, move to `docs/`
+- Delete the spec file - archive has the record
+- Don't let specs accumulate

external_plugins/bonfire/commands/start.md

@@ -0,0 +1,246 @@
+---
+description: Start a new session - reads context and scaffolds .bonfire/ if needed
+allowed-tools: Bash(git:*), Bash(gh:*), Bash(mkdir:*), Read, Write, Glob, AskUserQuestion, mcp__linear__*
+model: haiku
+---
+
+# Start Session
+
+## Step 1: Find Git Root
+
+Run `git rev-parse --show-toplevel` to locate the repository root. All session files live at `<git-root>/.bonfire/`.
+
+## Step 2: Check for Bonfire Directory
+
+Check if `<git-root>/.bonfire/index.md` exists.
+
+**If .bonfire/ does NOT exist**, scaffold it:
+
+1. Tell the user: "No bonfire directory found. Let me set that up for you."
+
+2. Use AskUserQuestion to ask setup questions (4 questions, one round):
+
+   1. "Where should specs be saved?" (Header: "Specs")
+      - .bonfire/specs/ (Recommended) - Keep with session context
+      - specs/ - Project root level
+
+   2. "Where should docs be saved?" (Header: "Docs")
+      - .bonfire/docs/ (Recommended) - Keep with session context
+      - docs/ - Project root level
+
+   3. "How should `.bonfire/` be handled in git?" (Header: "Git")
+      - ignore-all (Recommended) - Keep sessions private/local
+      - hybrid - Commit docs/specs, keep notes private
+      - commit-all - Share everything with team
+
+   4. "Enable Linear MCP integration?" (Header: "Linear")
+      - No (Recommended) - Skip Linear integration
+      - Yes - Fetch/create Linear issues (requires Linear MCP)
+
+3. Create the directory structure based on user choices:
+
+   **Always create in .bonfire/**:
+   ```
+   .bonfire/
+   ├── index.md
+   ├── config.json
+   ├── archive/
+   ├── scripts/
+   └── .gitignore
+   ```
+
+   **If specsLocation is `.bonfire/specs/`**: create `.bonfire/specs/`
+   **If specsLocation is `specs/`**: create `<git-root>/specs/`
+
+   **If docsLocation is `.bonfire/docs/`**: create `.bonfire/docs/`
+   **If docsLocation is `docs/`**: create `<git-root>/docs/`
+
+4. Detect project name from: package.json name → git remote → directory name
+
+5. Create `config.json` with user's answers:
+   ```json
+   {
+     "specsLocation": "<user-answer>",
+     "docsLocation": "<user-answer>",
+     "gitStrategy": "<user-answer>",
+     "linearEnabled": <true-or-false>
+   }
+   ```
+
+6. Create `index.md` with template:
+   ```markdown
+   # Session Context: [PROJECT_NAME]
+
+   **Date**: [CURRENT_DATE]
+   **Status**: Active
+   **Branch**: main
+
+   ---
+
+   ## Current State
+
+   [Describe what you're working on]
+
+   ---
+
+   ## Recent Sessions
+
+   ### Session 1 - [CURRENT_DATE]
+
+   **Goal**: [What you want to accomplish]
+
+   **Accomplished**:
+   - [List completed items]
+
+   **Decisions**:
+   - [Key decisions made]
+
+   **Blockers**: None
+
+   ---
+
+   ## Next Session Priorities
+
+   1. [Priority items]
+
+   ---
+
+   ## Key Resources
+
+   **Code References**:
+   - [Component/feature]: `path/to/file.ts`
+
+   **External Links**:
+   - [Issue Tracker](url)
+
+   ---
+
+   ## Archived Sessions
+
+   [Links to archived sessions will appear here]
+
+   ---
+
+   ## Notes
+
+   [Any additional context]
+   ```
+
+7. Create `.gitignore` based on chosen strategy and locations:
+
+   **Ignore all**:
+   ```
+   *
+   !.gitignore
+   ```
+
+   **Hybrid** (only include dirs that are inside .bonfire/):
+   ```
+   *
+   !.gitignore
+   ```
+   If docsLocation is `.bonfire/docs/`, add:
+   ```
+   !docs/
+   !docs/**
+   ```
+   If specsLocation is `.bonfire/specs/`, add:
+   ```
+   !specs/
+   !specs/**
+   ```
+
+   **Commit all**:
+   ```
+   data/
+   scratch/
+   scripts/
+   ```
+
+**If .bonfire/ EXISTS**, proceed to Step 3.
+
+## Step 3: Check/Update CLAUDE.md
+
+Check if `<git-root>/CLAUDE.md` exists.
+
+**If CLAUDE.md does NOT exist**, create it:
+```markdown
+# [PROJECT_NAME]
+
+## Quick Context
+
+Read `.bonfire/index.md` for current project state, recent work, and priorities.
+
+## Bonfire Commands
+
+- `/bonfire:start` - Start a session (reads context)
+- `/bonfire:end` - End session (updates context)
+- `/bonfire:spec` - Create implementation spec
+- `/bonfire:document <topic>` - Document a topic
+- `/bonfire:review` - Review work for blindspots and improvements
+- `/bonfire:archive` - Archive completed work
+- `/bonfire:configure` - Change project settings
+```
+
+**If CLAUDE.md EXISTS**, check if it references `.bonfire/index.md`. If not, append:
+```markdown
+
+## Session Context
+
+Read `.bonfire/index.md` for current project state, recent work, and priorities.
+```
+
+## Step 4: Read Session Context
+
+Read `<git-root>/.bonfire/index.md` and report when ready.
+
+Summarize:
+- Current state
+- Recent work
+- Next priorities
+
+Then ask: "What do you want to work on this session?"
+
+## Step 5: Fetch External Context (Optional)
+
+**Only fetch if user provides a new URL or issue ID:**
+
+### Detecting Issue Type
+
+- **GitHub**: Starts with `#`, contains `github.com`, or doesn't match Linear pattern
+- **Linear**: Matches `[A-Z]+-[0-9]+` pattern (e.g., `ENG-123`, `ABC-456`) or contains `linear.app`
+
+### GitHub Issues/PRs
+
+Use `gh` CLI:
+- `gh pr view [URL] --json title,body,state,labels`
+- `gh issue view [URL] --json title,body,state,labels`
+
+### Linear Issues
+
+First, read `<git-root>/.bonfire/config.json` and check `linearEnabled`.
+
+**If `linearEnabled` is false or not set**: Skip Linear, treat as ad-hoc task.
+
+**If `linearEnabled` is true**:
+1. Use Linear MCP `linear_search_issues` tool to find the issue by ID (e.g., `ENG-123`)
+2. Extract: title, description, state, priority, labels, assignee
+3. On success: Summarize the issue context
+4. On failure: Warn user - "Couldn't fetch Linear issue. Linear MCP may not be configured. Continue without issue context?"
+
+Note: Tool names may vary by Linear MCP implementation. Common tools: `linear_search_issues`, `linear_create_issue`, `linear_update_issue`.
+
+### Update Session Context
+
+If issue was fetched successfully:
+- Add reference to `index.md` under Current State
+- Include issue ID, title, and link
+- Note the issue tracker type (GitHub/Linear)
+
+### Fallback
+
+If no URL/issue ID provided (continuing work, ad-hoc task):
+- Proceed with existing session context
+- Session notes are the source of truth for ongoing work
+
+Confirm understanding and ask how to proceed.

external_plugins/bonfire/skills/archive-bonfire/SKILL.md

@@ -0,0 +1,53 @@
+---
+description: Suggest archiving completed work when PRs are merged or work is completed. Triggers when user asks to merge a PR ("merge it", "merge the PR"), after successful gh pr merge, or mentions completion ("shipped", "done with X", "merged to main"). Does NOT archive automatically - suggests running /bonfire:archive.
+allowed-tools: Read, Glob, Bash(gh:*)
+---
+
+# Archive Bonfire Awareness
+
+This skill detects when session work may be ready for archiving and suggests the appropriate action.
+
+## When to Use This Skill
+
+Trigger when:
+- User asks to merge: "merge it", "merge the PR", "go ahead and merge", "ship it"
+- After you successfully run `gh pr merge`
+- User mentions completion: "PR merged", "shipped", "done with X", "finished"
+- User references merged state: "merged to main", "closed the issue"
+
+## Instructions
+
+1. If user asks to merge a PR:
+   - Perform the merge as requested
+   - On success, continue to step 2
+   - On failure, help resolve the issue (don't suggest archiving)
+
+2. Find git root and check if `.bonfire/index.md` exists
+
+3. If it exists, read it to assess work state
+
+4. If user provided a PR URL/number (or you just merged one), verify status:
+   ```
+   gh pr view [URL/number] --json state,mergedAt,title
+   ```
+
+5. Assess if work appears complete:
+   - PR merged?
+   - Related tasks marked done in session notes?
+   - No obvious follow-up work mentioned?
+
+6. If work appears complete, suggest archiving:
+   > "PR merged successfully. This session's work looks complete - want me to archive it?
+   > Run `/bonfire:archive` to move completed work to the archive."
+
+7. If there's more work in the session:
+   > "PR merged. I see there's still [X, Y] in the session notes - want to continue
+   > with those or archive what's done so far?"
+
+## Important
+
+- This skill **suggests** archiving, it does NOT archive automatically
+- User must explicitly run `/bonfire:archive` to perform the archive
+- Trigger AFTER merge succeeds, not before
+- Multiple PRs may be part of one logical session - check context
+- If `.bonfire/` doesn't exist, don't suggest archiving

external_plugins/bonfire/skills/bonfire-context/SKILL.md

@@ -0,0 +1,51 @@
+---
+description: Read project session context from .bonfire/index.md to understand ongoing work, previous decisions, blockers, and history. Use when the user asks about project context, previous sessions, what was worked on before, architectural decisions, blockers, or when they reference "last time", "previously", "the session", or "what we decided".
+allowed-tools: Read, Glob
+---
+
+# Bonfire Context
+
+This project may use the Bonfire pattern to maintain continuity across AI coding sessions. Context is stored in `.bonfire/index.md` rather than relying on conversation memory.
+
+## When to Use This Skill
+
+Read session context when the user:
+- Asks about previous work or decisions
+- References "last time", "previously", "before"
+- Wants to know about blockers or pending issues
+- Asks what the project status is
+- Starts a significant task that might have prior context
+
+## Instructions
+
+1. Find the git root: `git rev-parse --show-toplevel`
+
+2. Check if `.bonfire/index.md` exists at the git root
+
+3. If it exists, read it to understand:
+   - Current project status and recent work
+   - Active decisions and their rationale
+   - Known blockers or pending issues
+   - Links to relevant specs or documentation
+
+4. Check `.bonfire/specs/` if the user asks about implementation specs
+
+5. Check `.bonfire/docs/` if the user asks about documented topics
+
+## File Structure
+
+```
+.bonfire/
+├── index.md          # Main session context (read this first)
+├── config.json       # Project settings
+├── archive/          # Completed work history
+├── docs/             # Topic documentation
+└── specs/            # Implementation specs
+```
+
+## Important
+
+- This skill is for **reading** context, not updating it
+- Session updates happen via `/bonfire:end` command
+- Don't modify `.bonfire/index.md` unless explicitly asked
+- If `.bonfire/` doesn't exist, the project may not use this pattern

external_plugins/context7/.mcp.json

@@ -1,6 +1,6 @@
 {
   "context7": {
-    "command": "npx",
+    "type": "http",
-    "args": ["-y", "@upstash/context7-mcp"]
+    "url": "https://mcp.context7.com/mcp"
   }
 }

external_plugins/context7/README.md

@@ -0,0 +1,72 @@
+# Context7 Plugin for Claude Code
+
+Context7 solves a common problem with AI coding assistants: outdated training data and hallucinated APIs. Instead of relying on stale knowledge, Context7 fetches current documentation directly from source repositories.
+
+## What's Included
+
+This plugin provides:
+
+- **MCP Server** - Connects Claude Code to Context7's documentation service
+- **Skills** - Auto-triggers documentation lookups when you ask about libraries
+- **Agents** - A dedicated `docs-researcher` agent for focused lookups
+- **Commands** - `/context7:docs` for manual documentation queries
+
+## Installation
+
+Install the plugin from the official marketplace:
+
+```bash
+claude plugin install context7@claude-plugins-official
+```
+
+## Available Tools
+
+### resolve-library-id
+
+Searches for libraries and returns Context7-compatible identifiers.
+
+```
+Input: "next.js"
+Output: { id: "/vercel/next.js", name: "Next.js", versions: ["v15.1.8", "v14.2.0", ...] }
+```
+
+### query-docs
+
+Fetches documentation for a specific library, ranked by relevance to your question.
+
+```
+Input: { libraryId: "/vercel/next.js", query: "app router middleware" }
+Output: Relevant documentation snippets with code examples
+```
+
+## Usage Examples
+
+The plugin works automatically when you ask about libraries:
+
+- "How do I set up authentication in Next.js 15?"
+- "Show me React Server Components examples"
+- "What's the Prisma syntax for relations?"
+
+For manual lookups, use the command:
+
+```
+/context7:docs next.js app router
+/context7:docs /vercel/next.js/v15.1.8 middleware
+```
+
+Or spawn the docs-researcher agent when you want to keep your main context clean:
+
+```
+spawn docs-researcher to look up Supabase auth methods
+```
+
+## Version Pinning
+
+To get documentation for a specific version, include the version in the library ID:
+
+```
+/vercel/next.js/v15.1.8
+/supabase/supabase/v2.45.0
+```
+
+The `resolve-library-id` tool returns available versions, so you can pick the one that matches your project.

external_plugins/context7/agents/docs-researcher.md

@@ -0,0 +1,40 @@
+---
+name: docs-researcher
+description: Lightweight agent for fetching library documentation without cluttering your main conversation context.
+model: sonnet
+---
+
+You are a documentation researcher specializing in fetching up-to-date library and framework documentation from Context7.
+
+## Your Task
+
+When given a question about a library or framework, fetch the relevant documentation and return a concise, actionable answer with code examples.
+
+## Process
+
+1. **Identify the library**: Extract the library/framework name from the user's question.
+
+2. **Resolve the library ID**: Call `resolve-library-id` with:
+   - `libraryName`: The library name (e.g., "react", "next.js", "prisma")
+   - `query`: The user's full question for relevance ranking
+
+3. **Select the best match**: From the results, pick the library with:
+   - Exact or closest name match
+   - Highest benchmark score
+   - Appropriate version if the user specified one (e.g., "React 19" → look for v19.x)
+
+4. **Fetch documentation**: Call `query-docs` with:
+   - `libraryId`: The selected Context7 library ID (e.g., `/vercel/next.js`)
+   - `query`: The user's specific question for targeted results
+
+5. **Return a focused answer**: Summarize the relevant documentation with:
+   - Direct answer to the question
+   - Code examples from the docs
+   - Links or references if available
+
+## Guidelines
+
+- Pass the user's full question as the query parameter for better relevance
+- When the user mentions a version (e.g., "Next.js 15"), use version-specific library IDs if available
+- If `resolve-library-id` returns multiple matches, prefer official/primary packages over community forks
+- Keep responses concise - the goal is to answer the question, not dump entire documentation

external_plugins/context7/commands/docs.md

@@ -0,0 +1,45 @@
+---
+description: Look up documentation for any library
+argument-hint: <library> [query]
+---
+
+# /context7:docs
+
+Fetches up-to-date documentation and code examples for a library.
+
+## Usage
+
+```
+/context7:docs <library> [query]
+```
+
+- **library**: The library name, or a Context7 ID starting with `/`
+- **query**: What you're looking for (optional but recommended)
+
+## Examples
+
+```
+/context7:docs react hooks
+/context7:docs next.js authentication
+/context7:docs prisma relations
+/context7:docs /vercel/next.js/v15.1.8 app router
+/context7:docs /supabase/supabase row level security
+```
+
+## How It Works
+
+1. If the library starts with `/`, it's used directly as the Context7 ID
+2. Otherwise, `resolve-library-id` finds the best matching library
+3. `query-docs` fetches documentation relevant to your query
+4. Results include code examples and explanations
+
+## Version-Specific Lookups
+
+Include the version in the library ID for pinned documentation:
+
+```
+/context7:docs /vercel/next.js/v15.1.8 middleware
+/context7:docs /facebook/react/v19.0.0 use hook
+```
+
+This is useful when you're working with a specific version and want docs that match exactly.

external_plugins/context7/skills/documentation-lookup/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: documentation-lookup
+description: This skill should be used when the user asks about libraries, frameworks, API references, or needs code examples. Activates for setup questions, code generation involving libraries, or mentions of specific frameworks like React, Vue, Next.js, Prisma, Supabase, etc.
+---
+
+When the user asks about libraries, frameworks, or needs code examples, use Context7 to fetch current documentation instead of relying on training data.
+
+## When to Use This Skill
+
+Activate this skill when the user:
+
+- Asks setup or configuration questions ("How do I configure Next.js middleware?")
+- Requests code involving libraries ("Write a Prisma query for...")
+- Needs API references ("What are the Supabase auth methods?")
+- Mentions specific frameworks (React, Vue, Svelte, Express, Tailwind, etc.)
+
+## How to Fetch Documentation
+
+### Step 1: Resolve the Library ID
+
+Call `resolve-library-id` with:
+
+- `libraryName`: The library name extracted from the user's question
+- `query`: The user's full question (improves relevance ranking)
+
+### Step 2: Select the Best Match
+
+From the resolution results, choose based on:
+
+- Exact or closest name match to what the user asked for
+- Higher benchmark scores indicate better documentation quality
+- If the user mentioned a version (e.g., "React 19"), prefer version-specific IDs
+
+### Step 3: Fetch the Documentation
+
+Call `query-docs` with:
+
+- `libraryId`: The selected Context7 library ID (e.g., `/vercel/next.js`)
+- `query`: The user's specific question
+
+### Step 4: Use the Documentation
+
+Incorporate the fetched documentation into your response:
+
+- Answer the user's question using current, accurate information
+- Include relevant code examples from the docs
+- Cite the library version when relevant
+
+## Guidelines
+
+- **Be specific**: Pass the user's full question as the query for better results
+- **Version awareness**: When users mention versions ("Next.js 15", "React 19"), use version-specific library IDs if available from the resolution step
+- **Prefer official sources**: When multiple matches exist, prefer official/primary packages over community forks

external_plugins/stagehand/.claude-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "name": "stagehand",
+  "description": "Browser automation skill for Claude Code using Stagehand. Automate web interactions, extract data, and navigate websites using natural language.",
+  "version": "0.1.0",
+  "author": {
+    "name": "Browserbase"
+  },
+  "homepage": "https://github.com/browserbase/agent-browse",
+  "repository": "https://github.com/browserbase/agent-browse",
+  "keywords": ["browser", "automation", "stagehand", "web-scraping"],
+  "strict": false
+}
+  

external_plugins/stagehand/README.md

@@ -0,0 +1,104 @@
+# Stagehand Browser Automation Plugin
+
+Browser automation skill for Claude Code using [Stagehand](https://github.com/browserbase/stagehand). This plugin enables Claude to automate web browser interactions, extract data, and navigate websites using natural language.
+
+## Installation
+
+Install the plugin from the Claude Code marketplace:
+
+```bash
+/plugin install stagehand@claude-plugin-directory
+```
+
+## Prerequisites
+
+This plugin requires the browser automation CLI tools to be installed separately. The CLI tools are available from the GitHub marketplace.
+
+### Step 1: Add the GitHub Marketplace
+
+```bash
+/plugin marketplace add browserbase/agent-browse
+```
+
+### Step 2: Install the Browser Automation CLI Plugin
+
+```bash
+/plugin install browser-automation@browser-tools
+```
+
+### Step 3: Set Up the CLI Tools
+
+After installing the browser-automation plugin, you need to set up the CLI tools:
+
+1. Navigate to the plugin directory (typically `~/.claude/plugins/browser-automation/`)
+2. Install dependencies and build:
+   ```bash
+   npm install
+   ```
+3. Link the browser command globally:
+   ```bash
+   npm link
+   ```
+4. Configure your Anthropic API key:
+   ```bash
+   export ANTHROPIC_API_KEY="your-api-key-here"
+   ```
+   Or use Claude Code's subscription token (recommended if you have Claude Pro/Max):
+   ```bash
+   claude setup-token
+   ```
+
+### Step 4: Verify Installation
+
+Test that the browser command is available:
+
+```bash
+browser navigate https://example.com
+```
+
+## Usage
+
+Once installed and configured, you can use natural language to automate browser tasks:
+
+- *"Go to Hacker News, get the top post comments, and summarize them"*
+- *"QA test http://localhost:3000 and fix any bugs you encounter"*
+- *"Extract product information from example.com/products"*
+
+Claude will automatically use the browser automation skill when you ask for web-related tasks.
+
+## Features
+
+- **Natural Language Control**: Describe browser actions in plain English
+- **Data Extraction**: Extract structured data from web pages
+- **Screenshot Capture**: Take screenshots for visual verification
+- **Persistent Sessions**: Browser state persists between commands
+- **Chrome Profile Integration**: Uses your Chrome profile for cookies and sessions
+
+## Troubleshooting
+
+### Chrome not found
+
+Install Chrome for your platform:
+- **macOS** or **Windows**: https://www.google.com/chrome/
+- **Linux**: `sudo apt install google-chrome-stable`
+
+### Browser command not found
+
+Make sure you've run `npm link` in the browser-automation plugin directory after installing it.
+
+### API Key Issues
+
+- If you have Claude Pro/Max, use `claude setup-token` (recommended)
+- Otherwise, export `ANTHROPIC_API_KEY` in your terminal
+- Or create a `.env` file in the plugin directory with your API key
+
+## Resources
+
+- [Stagehand Documentation](https://github.com/browserbase/stagehand)
+- [GitHub Marketplace](https://github.com/browserbase/agent-browse)
+- [Claude Code Skills Documentation](https://code.claude.com/docs/en/plugins)
+
+## Support
+
+For issues or questions, please visit the [GitHub repository](https://github.com/browserbase/agent-browse).
+

external_plugins/terraform/.claude-plugin/plugin.json

@@ -0,0 +1,7 @@
+{
+  "name": "terraform",
+  "description": "The Terraform MCP Server provides seamless integration with Terraform ecosystem, enabling advanced automation and interaction capabilities for Infrastructure as Code (IaC) development.",
+  "author": {
+    "name": "HashiCorp"
+  }
+}

external_plugins/terraform/.mcp.json

@@ -0,0 +1,12 @@
+{
+  "terraform": {
+    "command": "docker",
+    "args": [
+      "run",
+      "-i",
+      "--rm",
+      "-e", "TFE_TOKEN=${TFE_TOKEN}",
+      "hashicorp/terraform-mcp-server:0.3.3"
+    ]
+  }
+}

plugins/example-plugin/README.md

@@ -7,24 +7,32 @@ A comprehensive example plugin demonstrating Claude Code extension options.
 ```
 example-plugin/
 ├── .claude-plugin/
-│   └── plugin.json            # Plugin metadata
+│   └── plugin.json        # Plugin metadata
-├── .mcp.json                  # MCP server configuration
+├── .mcp.json              # MCP server configuration
-├── skills/
+├── commands/
-│   ├── example-skill/
+│   └── example-command.md # Slash command definition
-│   │   └── SKILL.md           # Model-invoked skill (contextual guidance)
+└── skills/
-│   └── example-command/
+    └── example-skill/
-│       └── SKILL.md           # User-invoked skill (slash command)
+        └── SKILL.md       # Skill definition
-└── commands/
-    └── example-command.md     # Legacy slash command format (see note below)
 ```
 
 ## Extension Options
 
+### Commands (`commands/`)
+
+Slash commands are user-invoked via `/command-name`. Define them as markdown files with frontmatter:
+
+```yaml
+---
+description: Short description for /help
+argument-hint: <arg1> [optional-arg]
+allowed-tools: [Read, Glob, Grep]
+---
+```
+
 ### Skills (`skills/`)
 
-Skills are the preferred format for both model-invoked capabilities and user-invoked slash commands. Create a `SKILL.md` in a subdirectory:
+Skills are model-invoked capabilities. Create a `SKILL.md` in a subdirectory:
-
-**Model-invoked skill** (activated by task context):
 
 ```yaml
 ---
@@ -34,21 +42,6 @@ version: 1.0.0
 ---
 ```
 
-**User-invoked skill** (slash command — `/skill-name`):
-
-```yaml
----
-name: skill-name
-description: Short description for /help
-argument-hint: <arg1> [optional-arg]
-allowed-tools: [Read, Glob, Grep]
----
-```
-
-### Commands (`commands/`) — legacy
-
-> **Note:** The `commands/*.md` layout is a legacy format. It is loaded identically to `skills/<name>/SKILL.md` — the only difference is file layout. For new plugins, prefer the `skills/` directory format. This plugin keeps `commands/example-command.md` as a reference for the legacy layout.
-
 ### MCP Servers (`.mcp.json`)
 
 Configure external tool integration via Model Context Protocol:

plugins/example-plugin/commands/example-command.md

@@ -1,12 +1,10 @@
 ---
-description: An example slash command that demonstrates command frontmatter options (legacy format)
+description: An example slash command that demonstrates command frontmatter options
 argument-hint: <required-arg> [optional-arg]
 allowed-tools: [Read, Glob, Grep, Bash]
 ---
 
-# Example Command (Legacy `commands/` Format)
+# Example Command
-
-> **Note:** This demonstrates the legacy `commands/*.md` layout. For new plugins, prefer the `skills/<name>/SKILL.md` directory format (see `skills/example-command/SKILL.md` in this plugin). Both are loaded identically — the only difference is file layout.
 
 This command demonstrates slash command structure and frontmatter options.
 

plugins/example-plugin/skills/example-command/SKILL.md

@@ -1,39 +0,0 @@
----
-name: example-command
-description: An example user-invoked skill that demonstrates frontmatter options and the skills/<name>/SKILL.md layout
-argument-hint: <required-arg> [optional-arg]
-allowed-tools: [Read, Glob, Grep, Bash]
----
-
-# Example Command (Skill Format)
-
-This demonstrates the `skills/<name>/SKILL.md` layout for user-invoked slash commands. It is functionally identical to the legacy `commands/example-command.md` format — both are loaded the same way; only the file layout differs.
-
-## Arguments
-
-The user invoked this with: $ARGUMENTS
-
-## Instructions
-
-When this skill is invoked:
-
-1. Parse the arguments provided by the user
-2. Perform the requested action using allowed tools
-3. Report results back to the user
-
-## Frontmatter Options Reference
-
-Skills in this layout support these frontmatter fields:
-
-- **name**: Skill identifier (matches directory name)
-- **description**: Short description shown in /help
-- **argument-hint**: Hints for command arguments shown to user
-- **allowed-tools**: Pre-approved tools for this skill (reduces permission prompts)
-- **model**: Override the model (e.g., "haiku", "sonnet", "opus")
-
-## Example Usage
-
-```
-/example-command my-argument
-/example-command arg1 arg2
-```

plugins/plugin-dev/commands/create-plugin.md

@@ -1,18 +1,7 @@
 ---
 description: Guided end-to-end plugin creation workflow with component design, implementation, and validation
 argument-hint: Optional plugin description
-allowed-tools:
+allowed-tools: ["Read", "Write", "Grep", "Glob", "Bash", "TodoWrite", "AskUserQuestion", "Skill", "Task"]
-  [
-    "Read",
-    "Write",
-    "Grep",
-    "Glob",
-    "Bash",
-    "TodoWrite",
-    "AskUserQuestion",
-    "Skill",
-    "Task",
-  ]
 ---
 
 # Plugin Creation Workflow
@@ -37,7 +26,6 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 **Goal**: Understand what plugin needs to be built and what problem it solves
 
 **Actions**:
-
 1. Create todo list with all 7 phases
 2. If plugin purpose is clear from arguments:
    - Summarize understanding
@@ -60,17 +48,14 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 **MUST load plugin-structure skill** using Skill tool before this phase.
 
 **Actions**:
-
 1. Load plugin-structure skill to understand component types
 2. Analyze plugin requirements and determine needed components:
-   - **Skills**: Specialized knowledge OR user-initiated actions (deploy, configure, analyze). Skills are the preferred format for both — see note below.
+   - **Skills**: Does it need specialized knowledge? (hooks API, MCP patterns, etc.)
+   - **Commands**: User-initiated actions? (deploy, configure, analyze)
    - **Agents**: Autonomous tasks? (validation, generation, analysis)
    - **Hooks**: Event-driven automation? (validation, notifications)
    - **MCP**: External service integration? (databases, APIs)
    - **Settings**: User configuration? (.local.md files)
-
-   > **Note:** The `commands/` directory is a legacy format. For new plugins, user-invoked slash commands should be created as skills in `skills/<name>/SKILL.md`. Both are loaded identically — the only difference is file layout. `commands/` remains an acceptable legacy alternative.
-
 3. For each component type needed, identify:
    - How many of each type
    - What each one does
@@ -79,7 +64,8 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
    ```
    | Component Type | Count | Purpose |
    |----------------|-------|---------|
-   | Skills         | 5     | Hook patterns, MCP usage, deploy, configure, validate |
+   | Skills         | 2     | Hook patterns, MCP usage |
+   | Commands       | 3     | Deploy, configure, validate |
    | Agents         | 1     | Autonomous validation |
    | Hooks          | 0     | Not needed |
    | MCP            | 1     | Database integration |
@@ -97,9 +83,9 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 **CRITICAL**: This is one of the most important phases. DO NOT SKIP.
 
 **Actions**:
-
 1. For each component in the plan, identify underspecified aspects:
-   - **Skills**: What triggers them? What knowledge do they provide? How detailed? For user-invoked skills: what arguments, what tools, interactive or automated?
+   - **Skills**: What triggers them? What knowledge do they provide? How detailed?
+   - **Commands**: What arguments? What tools? Interactive or automated?
    - **Agents**: When to trigger (proactive/reactive)? What tools? Output format?
    - **Hooks**: Which events? Prompt or command based? Validation criteria?
    - **MCP**: What server type? Authentication? Which tools?
@@ -112,14 +98,12 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 4. If user says "whatever you think is best", provide specific recommendations and get explicit confirmation
 
 **Example questions for a skill**:
-
 - What specific user queries should trigger this skill?
 - Should it include utility scripts? What functionality?
 - How detailed should the core SKILL.md be vs references/?
 - Any real-world examples to include?
 
 **Example questions for an agent**:
-
 - Should this agent trigger proactively after certain actions, or only when explicitly requested?
 - What tools does it need (Read, Write, Bash, etc.)?
 - What should the output format be?
@@ -134,7 +118,6 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 **Goal**: Create plugin directory structure and manifest
 
 **Actions**:
-
 1. Determine plugin name (kebab-case, descriptive)
 2. Choose plugin location:
    - Ask user: "Where should I create the plugin?"
@@ -142,10 +125,10 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 3. Create directory structure using bash:
    ```bash
    mkdir -p plugin-name/.claude-plugin
-   mkdir -p plugin-name/skills/<skill-name>   # one dir per skill, each with a SKILL.md
+   mkdir -p plugin-name/skills     # if needed
-   mkdir -p plugin-name/agents                # if needed
+   mkdir -p plugin-name/commands   # if needed
-   mkdir -p plugin-name/hooks                 # if needed
+   mkdir -p plugin-name/agents     # if needed
-   # Note: plugin-name/commands/ is a legacy alternative to skills/ — prefer skills/
+   mkdir -p plugin-name/hooks      # if needed
    ```
 4. Create plugin.json manifest using Write tool:
    ```json
@@ -160,7 +143,7 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
    }
    ```
 5. Create README.md template
-6. Create .gitignore if needed (for .claude/\*.local.md, etc.)
+6. Create .gitignore if needed (for .claude/*.local.md, etc.)
 7. Initialize git repo if creating new directory
 
 **Output**: Plugin directory structure created and ready for components
@@ -172,9 +155,8 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 **Goal**: Create each component following best practices
 
 **LOAD RELEVANT SKILLS** before implementing each component type:
-
 - Skills: Load skill-development skill
-- Legacy `commands/` format (only if user explicitly requests): Load command-development skill
+- Commands: Load command-development skill
 - Agents: Load agent-development skill
 - Hooks: Load hook-development skill
 - MCP: Load mcp-integration skill
@@ -183,26 +165,21 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 **Actions for each component**:
 
 ### For Skills:
-
 1. Load skill-development skill using Skill tool
 2. For each skill:
    - Ask user for concrete usage examples (or use from Phase 3)
    - Plan resources (scripts/, references/, examples/)
-   - Create skill directory: `skills/<skill-name>/`
+   - Create skill directory structure
-   - Write `SKILL.md` with:
+   - Write SKILL.md with:
      - Third-person description with specific trigger phrases
      - Lean body (1,500-2,000 words) in imperative form
      - References to supporting files
-   - For user-invoked skills (slash commands): include `description`, `argument-hint`, and `allowed-tools` frontmatter; write instructions FOR Claude (not TO user)
    - Create reference files for detailed content
    - Create example files for working code
    - Create utility scripts if needed
 3. Use skill-reviewer agent to validate each skill
 
-### For legacy `commands/` format (only if user explicitly requests):
+### For Commands:
-
-> Prefer `skills/<name>/SKILL.md` for new plugins. Use `commands/` only when maintaining an existing plugin that already uses this layout.
-
 1. Load command-development skill using Skill tool
 2. For each command:
    - Write command markdown with frontmatter
@@ -213,7 +190,6 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
    - Reference relevant skills if applicable
 
 ### For Agents:
-
 1. Load agent-development skill using Skill tool
 2. For each agent, use agent-creator agent:
    - Provide description of what agent should do
@@ -223,7 +199,6 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
    - Validate with validate-agent.sh script
 
 ### For Hooks:
-
 1. Load hook-development skill using Skill tool
 2. For each hook:
    - Create hooks/hooks.json with hook configuration
@@ -233,7 +208,6 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
    - Test with validate-hook-schema.sh and test-hook.sh utilities
 
 ### For MCP:
-
 1. Load mcp-integration skill using Skill tool
 2. Create .mcp.json configuration with:
    - Server type (stdio for local, SSE for hosted)
@@ -244,7 +218,6 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 4. Provide setup instructions
 
 ### For Settings:
-
 1. Load plugin-settings skill using Skill tool
 2. Create settings template in README
 3. Create example .claude/plugin-name.local.md file (as documentation)
@@ -262,7 +235,6 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 **Goal**: Ensure plugin meets quality standards and works correctly
 
 **Actions**:
-
 1. **Run plugin-validator agent**:
    - Use plugin-validator agent to comprehensively validate plugin
    - Check: manifest, structure, naming, components, security
@@ -303,7 +275,6 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 **Goal**: Test that plugin works correctly in Claude Code
 
 **Actions**:
-
 1. **Installation instructions**:
    - Show user how to test locally:
      ```bash
@@ -313,7 +284,7 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 
 2. **Verification checklist** for user to perform:
    - [ ] Skills load when triggered (ask questions with trigger phrases)
-   - [ ] User-invoked skills appear in `/help` and execute correctly
+   - [ ] Commands appear in `/help` and execute correctly
    - [ ] Agents trigger on appropriate scenarios
    - [ ] Hooks activate on events (if applicable)
    - [ ] MCP servers connect (if applicable)
@@ -321,7 +292,7 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 
 3. **Testing recommendations**:
    - For skills: Ask questions using trigger phrases from descriptions
-   - For user-invoked skills: Run `/plugin-name:skill-name` with various arguments
+   - For commands: Run `/plugin-name:command-name` with various arguments
    - For agents: Create scenarios matching agent examples
    - For hooks: Use `claude --debug` to see hook execution
    - For MCP: Use `/mcp` to verify servers and tools
@@ -339,7 +310,6 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 **Goal**: Ensure plugin is well-documented and ready for distribution
 
 **Actions**:
-
 1. **Verify README completeness**:
    - Check README has: overview, features, installation, prerequisites, usage
    - For MCP plugins: Document required environment variables
@@ -355,7 +325,7 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
    - Mark all todos complete
    - List what was created:
      - Plugin name and purpose
-     - Components created (X skills, Y agents, etc.)
+     - Components created (X skills, Y commands, Z agents, etc.)
      - Key files and their purposes
      - Total file count and structure
    - Next steps:
@@ -384,7 +354,7 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 - **Apply best practices**:
   - Third-person descriptions for skills
   - Imperative form in skill bodies
-  - Skill instructions written FOR Claude (not TO user)
+  - Commands written FOR Claude
   - Strong trigger phrases
   - ${CLAUDE_PLUGIN_ROOT} for portability
   - Progressive disclosure
@@ -401,13 +371,12 @@ Guide the user through creating a complete, high-quality Claude Code plugin from
 ### Skills to Load by Phase
 
 - **Phase 2**: plugin-structure
-- **Phase 5**: skill-development, agent-development, hook-development, mcp-integration, plugin-settings (as needed); command-development only for legacy `commands/` layout
+- **Phase 5**: skill-development, command-development, agent-development, hook-development, mcp-integration, plugin-settings (as needed)
 - **Phase 6**: (agents will use skills automatically)
 
 ### Quality Standards
 
 Every component must meet these standards:
-
 - ✅ Follows plugin-dev's proven patterns
 - ✅ Uses correct naming conventions
 - ✅ Has strong trigger conditions (skills/agents)
@@ -421,22 +390,19 @@ Every component must meet these standards:
 ## Example Workflow
 
 ### User Request
-
 "Create a plugin for managing database migrations"
 
 ### Phase 1: Discovery
-
 - Understand: Migration management, database schema versioning
 - Confirm: User wants to create, run, rollback migrations
 
 ### Phase 2: Component Planning
-
+- Skills: 1 (migration best practices)
-- Skills: 4 (migration best practices, create-migration, run-migrations, rollback)
+- Commands: 3 (create-migration, run-migrations, rollback)
 - Agents: 1 (migration-validator)
 - MCP: 1 (database connection)
 
 ### Phase 3: Clarifying Questions
-
 - Which databases? (PostgreSQL, MySQL, etc.)
 - Migration file format? (SQL, code-based?)
 - Should agent validate before applying?

plugins/plugin-dev/skills/command-development/SKILL.md

@@ -6,14 +6,11 @@ version: 0.2.0
 
 # Command Development for Claude Code
 
-> **Note:** The `.claude/commands/` directory is a legacy format. For new skills, use the `.claude/skills/<name>/SKILL.md` directory format. Both are loaded identically — the only difference is file layout. See the `skill-development` skill for the preferred format.
-
 ## Overview
 
 Slash commands are frequently-used prompts defined as Markdown files that Claude executes during interactive sessions. Understanding command structure, frontmatter options, and dynamic features enables creating powerful, reusable workflows.
 
 **Key concepts:**
-
 - Markdown file format for commands
 - YAML frontmatter for configuration
 - Dynamic arguments and file references
@@ -25,7 +22,6 @@ Slash commands are frequently-used prompts defined as Markdown files that Claude
 ### What is a Slash Command?
 
 A slash command is a Markdown file containing a prompt that Claude executes when invoked. Commands provide:
-
 - **Reusability**: Define once, use repeatedly
 - **Consistency**: Standardize common workflows
 - **Sharing**: Distribute across team or projects
@@ -38,10 +34,8 @@ A slash command is a Markdown file containing a prompt that Claude executes when
 When a user invokes `/command-name`, the command content becomes Claude's instructions. Write commands as directives TO Claude about what to do, not as messages TO the user.
 
 **Correct approach (instructions for Claude):**
-
 ```markdown
 Review this code for security vulnerabilities including:
-
 - SQL injection
 - XSS attacks
 - Authentication issues
@@ -50,7 +44,6 @@ Provide specific line numbers and severity ratings.
 ```
 
 **Incorrect approach (messages to user):**
-
 ```markdown
 This command will review your code for security issues.
 You'll receive a report with vulnerability details.
@@ -61,21 +54,18 @@ The first example tells Claude what to do. The second tells the user what will h
 ### Command Locations
 
 **Project commands** (shared with team):
-
 - Location: `.claude/commands/`
 - Scope: Available in specific project
 - Label: Shown as "(project)" in `/help`
 - Use for: Team workflows, project-specific tasks
 
 **Personal commands** (available everywhere):
-
 - Location: `~/.claude/commands/`
 - Scope: Available in all projects
 - Label: Shown as "(user)" in `/help`
 - Use for: Personal workflows, cross-project utilities
 
 **Plugin commands** (bundled with plugins):
-
 - Location: `plugin-name/commands/`
 - Scope: Available when plugin installed
 - Label: Shown as "(plugin-name)" in `/help`
@@ -95,10 +85,8 @@ Commands are Markdown files with `.md` extension:
 ```
 
 **Simple command:**
-
 ```markdown
 Review this code for security vulnerabilities including:
-
 - SQL injection
 - XSS attacks
 - Authentication bypass
@@ -150,7 +138,6 @@ allowed-tools: Read, Write, Edit, Bash(git:*)
 ```
 
 **Patterns:**
-
 - `Read, Write, Edit` - Specific tools
 - `Bash(git:*)` - Bash with git commands only
 - `*` - All tools (rarely needed)
@@ -170,7 +157,6 @@ model: haiku
 ```
 
 **Use cases:**
-
 - `haiku` - Fast, simple commands
 - `sonnet` - Standard workflows
 - `opus` - Complex analysis
@@ -188,7 +174,6 @@ argument-hint: [pr-number] [priority] [assignee]
 ```
 
 **Benefits:**
-
 - Helps users understand command arguments
 - Improves command discovery
 - Documents command interface
@@ -223,14 +208,12 @@ Fix issue #$ARGUMENTS following our coding standards and best practices.
 ```
 
 **Usage:**
-
 ```
 > /fix-issue 123
 > /fix-issue 456
 ```
 
 **Expands to:**
-
 ```
 Fix issue #123 following our coding standards...
 Fix issue #456 following our coding standards...
@@ -251,13 +234,11 @@ After review, assign to $3 for follow-up.
 ```
 
 **Usage:**
-
 ```
 > /review-pr 123 high alice
 ```
 
 **Expands to:**
-
 ```
 Review pull request #123 with priority level high.
 After review, assign to alice for follow-up.
@@ -272,13 +253,11 @@ Deploy $1 to $2 environment with options: $3
 ```
 
 **Usage:**
-
 ```
 > /deploy api staging --force --skip-tests
 ```
 
 **Expands to:**
-
 ```
 Deploy api to staging environment with options: --force --skip-tests
 ```
@@ -296,14 +275,12 @@ argument-hint: [file-path]
 ---
 
 Review @$1 for:
-
 - Code quality
 - Best practices
 - Potential bugs
 ```
 
 **Usage:**
-
 ```
 > /review-file src/api/users.ts
 ```
@@ -318,7 +295,6 @@ Reference multiple files:
 Compare @src/old-version.js with @src/new-version.js
 
 Identify:
-
 - Breaking changes
 - New features
 - Bug fixes
@@ -332,7 +308,6 @@ Reference known files without arguments:
 Review @package.json and @tsconfig.json for consistency
 
 Ensure:
-
 - TypeScript version matches
 - Dependencies are aligned
 - Build configuration is correct
@@ -343,7 +318,6 @@ Ensure:
 Commands can execute bash commands inline to dynamically gather context before Claude processes the command. This is useful for including repository state, environment information, or project-specific context.
 
 **When to use:**
-
 - Include dynamic context (git status, environment vars, etc.)
 - Gather project/repository state
 - Build context-aware workflows
@@ -387,7 +361,6 @@ Organize commands in subdirectories:
 ```
 
 **Benefits:**
-
 - Logical grouping by category
 - Namespace shown in `/help`
 - Easier to find related commands
@@ -417,8 +390,8 @@ argument-hint: [pr-number]
 ---
 
 $IF($1,
-Review PR #$1,
+  Review PR #$1,
-Please provide a PR number. Usage: /review-pr [number]
+  Please provide a PR number. Usage: /review-pr [number]
 )
 ```
 
@@ -471,7 +444,6 @@ allowed-tools: Read, Bash(git:*)
 Files changed: !`git diff --name-only`
 
 Review each file for:
-
 1. Code quality and style
 2. Potential bugs or issues
 3. Test coverage
@@ -503,7 +475,6 @@ argument-hint: [source-file]
 ---
 
 Generate comprehensive documentation for @$1 including:
-
 - Function/class descriptions
 - Parameter documentation
 - Return value descriptions
@@ -531,27 +502,23 @@ PR #$1 Workflow:
 ## Troubleshooting
 
 **Command not appearing:**
-
 - Check file is in correct directory
 - Verify `.md` extension present
 - Ensure valid Markdown format
 - Restart Claude Code
 
 **Arguments not working:**
-
 - Verify `$1`, `$2` syntax correct
 - Check `argument-hint` matches usage
 - Ensure no extra spaces
 
 **Bash execution failing:**
-
 - Check `allowed-tools` includes Bash
 - Verify command syntax in backticks
 - Test command in terminal first
 - Check for required permissions
 
 **File references not working:**
-
 - Verify `@` syntax correct
 - Check file path is valid
 - Ensure Read tool allowed
@@ -564,7 +531,6 @@ PR #$1 Workflow:
 Plugin commands have access to `${CLAUDE_PLUGIN_ROOT}`, an environment variable that resolves to the plugin's absolute path.
 
 **Purpose:**
-
 - Reference plugin files portably
 - Execute plugin scripts
 - Load plugin configuration
@@ -587,24 +553,19 @@ Review results and report findings.
 
 ```markdown
 # Execute plugin script
-
 !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/script.sh`
 
 # Load plugin configuration
-
 @${CLAUDE_PLUGIN_ROOT}/config/settings.json
 
 # Use plugin template
-
 @${CLAUDE_PLUGIN_ROOT}/templates/report.md
 
 # Access plugin resources
-
 @${CLAUDE_PLUGIN_ROOT}/docs/reference.md
 ```
 
 **Why use it:**
-
 - Works across all installations
 - Portable between systems
 - No hardcoded paths needed
@@ -625,14 +586,12 @@ plugin-name/
 ```
 
 **Namespace benefits:**
-
 - Logical command grouping
 - Shown in `/help` output
 - Avoid name conflicts
 - Organize related commands
 
 **Naming conventions:**
-
 - Use descriptive action names
 - Avoid generic names (test, run)
 - Consider plugin-specific prefix
@@ -702,20 +661,17 @@ argument-hint: [file-path]
 Initiate comprehensive review of @$1 using the code-reviewer agent.
 
 The agent will analyze:
-
 - Code structure
 - Security issues
 - Performance
 - Best practices
 
 Agent uses plugin resources:
-
 - ${CLAUDE_PLUGIN_ROOT}/config/rules.json
 - ${CLAUDE_PLUGIN_ROOT}/checklists/review.md
 ```
 
 **Key points:**
-
 - Agent must exist in `plugin/agents/` directory
 - Claude uses Task tool to launch agent
 - Document agent capabilities
@@ -734,7 +690,6 @@ argument-hint: [api-file]
 Document API in @$1 following plugin standards.
 
 Use the api-docs-standards skill to ensure:
-
 - Complete endpoint documentation
 - Consistent formatting
 - Example quality
@@ -744,7 +699,6 @@ Generate production-ready API docs.
 ```
 
 **Key points:**
-
 - Skill must exist in `plugin/skills/` directory
 - Mention skill name to trigger invocation
 - Document skill purpose
@@ -753,7 +707,6 @@ Generate production-ready API docs.
 ### Hook Coordination
 
 Design commands that work with plugin hooks:
-
 - Commands can prepare state for hooks to process
 - Hooks execute automatically on tool events
 - Commands should document expected hook behavior
@@ -790,7 +743,6 @@ Compile findings into report following template.
 ```
 
 **When to use:**
-
 - Complex multi-step workflows
 - Leverage multiple plugin capabilities
 - Require specialized analysis
@@ -811,10 +763,10 @@ argument-hint: [environment]
 Validate environment: !`echo "$1" | grep -E "^(dev|staging|prod)$" || echo "INVALID"`
 
 If $1 is valid environment:
-Deploy to $1
+  Deploy to $1
 Otherwise:
-Explain valid environments: dev, staging, prod
+  Explain valid environments: dev, staging, prod
-Show usage: /deploy [environment]
+  Show usage: /deploy [environment]
 ```
 
 ### File Existence Checks
@@ -828,11 +780,11 @@ argument-hint: [config-file]
 Check file exists: !`test -f $1 && echo "EXISTS" || echo "MISSING"`
 
 If file exists:
-Process configuration: @$1
+  Process configuration: @$1
 Otherwise:
-Explain where to place config file
+  Explain where to place config file
-Show expected format
+  Show expected format
-Provide example configuration
+  Provide example configuration
 ```
 
 ### Plugin Resource Validation
@@ -844,7 +796,6 @@ allowed-tools: Bash(test:*)
 ---
 
 Validate plugin setup:
-
 - Script: !`test -x ${CLAUDE_PLUGIN_ROOT}/bin/analyze && echo "✓" || echo "✗"`
 - Config: !`test -f ${CLAUDE_PLUGIN_ROOT}/config.json && echo "✓" || echo "✗"`
 
@@ -863,15 +814,14 @@ allowed-tools: Bash(*)
 Execute build: !`bash ${CLAUDE_PLUGIN_ROOT}/scripts/build.sh 2>&1 || echo "BUILD_FAILED"`
 
 If build succeeded:
-Report success and output location
+  Report success and output location
 If build failed:
-Analyze error output
+  Analyze error output
-Suggest likely causes
+  Suggest likely causes
-Provide troubleshooting steps
+  Provide troubleshooting steps
 ```
 
 **Best practices:**
-
 - Validate early in command
 - Provide helpful error messages
 - Suggest corrective actions