Initial commit

commands/brainstorm.md

@@ -0,0 +1,101 @@
+---
+name: brainstorm
+description: Interactive design refinement using Socratic method
+argument-hint: "[topic]"
+---
+
+Transform rough ideas into fully-formed designs through structured questioning and alternative exploration. This command initiates an interactive design session using the Socratic method to refine your concept before implementation.
+
+## Usage
+
+```
+/ring-default:brainstorm [topic]
+```
+
+## Arguments
+
+| Argument | Required | Description |
+|----------|----------|-------------|
+| `topic` | Yes | The feature, product, or system you want to design (e.g., "user authentication", "payment processing", "notification system") |
+
+## Examples
+
+### Starting a Feature Design
+```
+/ring-default:brainstorm OAuth2 integration
+```
+Initiates a design session for adding OAuth2 authentication to your application.
+
+### Architectural Decision
+```
+/ring-default:brainstorm microservices migration strategy
+```
+Explores approaches for migrating from monolith to microservices architecture.
+
+### New Product Concept
+```
+/ring-default:brainstorm real-time collaboration feature
+```
+Refines requirements and design for a collaborative editing feature.
+
+## Process
+
+The brainstorming session follows these phases:
+
+### 1. Autonomous Recon (Prep)
+- Inspects repository structure, documentation, and recent commits
+- Forms initial understanding of the codebase context
+- Shares findings before asking questions
+
+### 2. Understanding (Phase 1)
+- Shares synthesized understanding for validation
+- Asks targeted questions (max 3) to fill knowledge gaps
+- Gathers: purpose, constraints, success criteria
+
+### 3. Exploration (Phase 2)
+- Proposes 2-3 different architectural approaches
+- Presents trade-offs for each option
+- Recommends preferred approach with rationale
+- Uses `AskUserQuestion` for approach selection
+
+### 4. Design Presentation (Phase 3)
+- Presents design in 200-300 word sections
+- Covers: architecture, components, data flow, error handling, testing
+- Validates each section incrementally
+- Requires explicit approval ("Approved", "Looks good", "Proceed")
+
+### 5. Design Documentation (Phase 4)
+- Writes validated design to `docs/plans/YYYY-MM-DD-<topic>-design.md`
+- Commits the design document to git
+
+### 6. Worktree Setup (Phase 5, if implementing)
+- Sets up isolated git worktree for development
+- Prepares clean workspace for implementation
+
+### 7. Planning Handoff (Phase 6, if implementing)
+- Creates detailed implementation plan using `writing-plans` skill
+- Breaks design into bite-sized executable tasks
+
+## Related Commands/Skills
+
+| Command/Skill | Relationship |
+|---------------|--------------|
+| `/ring-default:write-plan` | Use after brainstorming when design is complete |
+| `/ring-default:execute-plan` | Use after planning to implement the design |
+| `ring-default:writing-plans` | Underlying skill for creating implementation plans |
+
+## Troubleshooting
+
+### "Design not validated"
+The session requires explicit approval from you before proceeding. Responses like "interesting" or "I see" do not count as approval. Say "approved", "looks good", or "proceed" to advance.
+
+### "Too many questions"
+Each phase has a maximum of 3 questions. If you're being asked more, it indicates insufficient autonomous research. Request the agent to explore the codebase first.
+
+### "Skipping phases"
+The process is phase-locked. You cannot skip ahead until the current phase is complete. If you need to go faster, provide explicit approval at each checkpoint.
+
+### When NOT to use this command
+- Design is already complete and validated - use `/ring-default:write-plan`
+- Have a detailed plan ready to execute - use `/ring-default:execute-plan`
+- Just need task breakdown from existing design - use `/ring-default:write-plan`

commands/codereview.md

@@ -0,0 +1,200 @@
+---
+name: codereview
+description: Run comprehensive parallel code review with all 3 specialized reviewers
+argument-hint: "[files-or-paths]"
+---
+
+Dispatch all 3 specialized code reviewers in parallel, collect their reports, and provide a consolidated analysis.
+
+## Review Process
+
+### Step 1: Dispatch All Three Reviewers in Parallel
+
+**CRITICAL: Use a single message with 3 Task tool calls to launch all reviewers simultaneously.**
+
+Gather the required context first:
+- WHAT_WAS_IMPLEMENTED: Summary of changes made
+- PLAN_OR_REQUIREMENTS: Original plan or requirements (if available)
+- BASE_SHA: Base commit for comparison (if applicable)
+- HEAD_SHA: Head commit for comparison (if applicable)
+- DESCRIPTION: Additional context about the changes
+
+Then dispatch all 3 reviewers:
+
+```
+Task tool #1 (ring-default:code-reviewer):
+  model: "opus"
+  description: "Review code quality and architecture"
+  prompt: |
+    WHAT_WAS_IMPLEMENTED: [summary of changes]
+    PLAN_OR_REQUIREMENTS: [original plan/requirements]
+    BASE_SHA: [base commit if applicable]
+    HEAD_SHA: [head commit if applicable]
+    DESCRIPTION: [additional context]
+
+Task tool #2 (ring-default:business-logic-reviewer):
+  model: "opus"
+  description: "Review business logic correctness"
+  prompt: |
+    [Same parameters as above]
+
+Task tool #3 (ring-default:security-reviewer):
+  model: "opus"
+  description: "Review security vulnerabilities"
+  prompt: |
+    [Same parameters as above]
+```
+
+**Wait for all three reviewers to complete their work.**
+
+### Step 2: Collect and Aggregate Reports
+
+Each reviewer returns:
+- **Verdict:** PASS/FAIL/NEEDS_DISCUSSION
+- **Strengths:** What was done well
+- **Issues:** Categorized by severity (Critical/High/Medium/Low/Cosmetic)
+- **Recommendations:** Specific actionable feedback
+
+Consolidate all issues by severity across all three reviewers.
+
+### Step 3: Provide Consolidated Report
+
+Return a consolidated report in this format:
+
+```markdown
+# Full Review Report
+
+## VERDICT: [PASS | FAIL | NEEDS_DISCUSSION]
+
+## Executive Summary
+
+[2-3 sentences about overall review across all gates]
+
+**Total Issues:**
+- Critical: [N across all gates]
+- High: [N across all gates]
+- Medium: [N across all gates]
+- Low: [N across all gates]
+
+---
+
+## Code Quality Review (Foundation)
+
+**Verdict:** [PASS | FAIL]
+**Issues:** Critical [N], High [N], Medium [N], Low [N]
+
+### Critical Issues
+[List all critical code quality issues]
+
+### High Issues
+[List all high code quality issues]
+
+[Medium/Low issues summary]
+
+---
+
+## Business Logic Review (Correctness)
+
+**Verdict:** [PASS | FAIL]
+**Issues:** Critical [N], High [N], Medium [N], Low [N]
+
+### Critical Issues
+[List all critical business logic issues]
+
+### High Issues
+[List all high business logic issues]
+
+[Medium/Low issues summary]
+
+---
+
+## Security Review (Safety)
+
+**Verdict:** [PASS | FAIL]
+**Issues:** Critical [N], High [N], Medium [N], Low [N]
+
+### Critical Vulnerabilities
+[List all critical security vulnerabilities]
+
+### High Vulnerabilities
+[List all high security vulnerabilities]
+
+[Medium/Low vulnerabilities summary]
+
+---
+
+## Consolidated Action Items
+
+**MUST FIX (Critical):**
+1. [Issue from any gate] - `file:line`
+2. [Issue from any gate] - `file:line`
+
+**SHOULD FIX (High):**
+1. [Issue from any gate] - `file:line`
+2. [Issue from any gate] - `file:line`
+
+**CONSIDER (Medium/Low):**
+[Brief list]
+
+---
+
+## Next Steps
+
+**If PASS:**
+- ✅ All 3 reviewers passed
+- ✅ Ready for next step (merge/production)
+
+**If FAIL:**
+- ❌ Fix all Critical/High/Medium issues immediately
+- ❌ Add TODO(review) comments for Low issues in code
+- ❌ Add FIXME(nitpick) comments for Cosmetic/Nitpick issues in code
+- ❌ Re-run all 3 reviewers in parallel after fixes
+
+**If NEEDS_DISCUSSION:**
+- 💬 [Specific discussion points across gates]
+```
+
+## Severity-Based Action Guide
+
+After producing the consolidated report, provide clear guidance:
+
+**Critical/High/Medium Issues:**
+```
+These issues MUST be fixed immediately:
+1. [Issue description] - file.ext:line - [Reviewer]
+2. [Issue description] - file.ext:line - [Reviewer]
+
+Recommended approach:
+- Dispatch fix subagent to address all Critical/High/Medium issues
+- After fixes complete, re-run all 3 reviewers in parallel to verify
+```
+
+**Low Issues:**
+```
+Add TODO comments in the code for these issues:
+
+// TODO(review): [Issue description]
+// Reported by: [reviewer-name] on [date]
+// Severity: Low
+// Location: file.ext:line
+```
+
+**Cosmetic/Nitpick Issues:**
+```
+Add FIXME comments in the code for these issues:
+
+// FIXME(nitpick): [Issue description]
+// Reported by: [reviewer-name] on [date]
+// Severity: Cosmetic
+// Location: file.ext:line
+```
+
+## Remember
+
+1. **All reviewers are independent** - They run in parallel, not sequentially
+2. **Dispatch all 3 reviewers in parallel** - Single message, 3 Task calls
+3. **Specify model: "opus"** - All reviewers need opus for comprehensive analysis
+4. **Wait for all to complete** - Don't aggregate until all reports received
+5. **Consolidate findings by severity** - Group all issues across reviewers
+6. **Provide clear action guidance** - Tell user exactly what to fix vs. document
+7. **Overall FAIL if any reviewer fails** - One failure means work needs fixes

commands/codify.md

@@ -0,0 +1,160 @@
+---
+name: codify
+description: Document a solved problem to build searchable knowledge base
+argument-hint: "[optional-description]"
+---
+
+Capture the current problem solution as structured documentation in `docs/solutions/{category}/`. Use this after confirming a fix worked to build institutional knowledge that helps future debugging.
+
+## Usage
+
+```
+/ring-default:codify [optional description of the problem]
+```
+
+## Arguments
+
+| Argument | Required | Description |
+|----------|----------|-------------|
+| `description` | No | Brief description of the problem (helps pre-fill template) |
+
+## Examples
+
+### Document After Debugging
+```
+/ring-default:codify
+```
+Captures the solution from the current conversation context.
+
+### Document With Description
+```
+/ring-default:codify JWT parsing error in auth middleware
+```
+Pre-fills the title and helps with context gathering.
+
+### Document Specific Fix
+```
+/ring-default:codify race condition in user session cleanup
+```
+Documents a race condition fix with the given context.
+
+## What It Does
+
+1. **Gathers Context** - Extracts problem details from conversation history
+2. **Checks for Duplicates** - Searches `docs/solutions/` for similar issues
+3. **Validates Schema** - Ensures all required fields are present
+4. **Creates Documentation** - Writes structured markdown to `docs/solutions/{category}/`
+5. **Offers Next Steps** - Link issues, add patterns, continue workflow
+
+## When to Use
+
+- After debugging session where fix was non-trivial (> 5 min)
+- When solution would help future developers or AI agents
+- After investigating error that took multiple attempts to solve
+- When you want to prevent re-investigating the same issue
+
+## When NOT to Use
+
+- Simple typo or syntax error (took < 2 min)
+- Issue already documented in `docs/solutions/`
+- One-off issue that won't recur
+- Trivial fix obvious from error message
+
+## Output Location
+
+Solutions are stored in category-specific directories:
+
+```
+docs/solutions/
+├── build-errors/
+├── test-failures/
+├── runtime-errors/
+├── performance-issues/
+├── database-issues/
+├── security-issues/
+├── ui-bugs/
+├── integration-issues/
+├── logic-errors/
+├── dependency-issues/
+├── configuration-errors/
+└── workflow-issues/
+```
+
+## Required Fields
+
+The command will gather and validate:
+
+| Field | Description |
+|-------|-------------|
+| `date` | When the problem was solved |
+| `problem_type` | Category (determines directory) |
+| `component` | Affected module/service |
+| `symptoms` | Observable errors/behaviors (1-5) |
+| `root_cause` | Fundamental cause |
+| `resolution_type` | Type of fix applied |
+| `severity` | Impact level |
+
+## Process Flow
+
+```
+/codify invoked
+    ↓
+Gather context from conversation
+    ↓
+Check for existing similar docs
+    ↓
+Validate YAML schema
+    ↓
+Create documentation file
+    ↓
+Present next steps menu
+```
+
+## Related Commands/Skills
+
+| Command/Skill | Relationship |
+|---------------|--------------|
+| `ring-default:systematic-debugging` | Run /codify AFTER debugging completes |
+| `ring-default:codify-solution` | The underlying skill (invoked automatically) |
+| `/ring-default:write-plan` | Plans can search documented solutions (invokes write-plan agent) |
+| `/ring-pm-team:pre-dev-feature` | Pre-dev can reference prior solutions |
+
+## The Compounding Effect
+
+```
+Session 1: Debug issue (30 min) → Document (5 min)
+Session 2: Search docs (2 min) → Apply known fix (5 min)
+Session 3: Quick lookup (1 min) → Instant fix
+
+Time saved grows with each reuse.
+```
+
+## Troubleshooting
+
+### "Missing required context"
+The command needs more information. You'll be prompted for:
+- Component name
+- Error symptoms
+- Root cause
+- What was changed to fix it
+
+### "Similar issue already documented"
+A related solution exists. You'll be asked to:
+1. Create new doc with cross-reference (different root cause)
+2. Update existing doc (same root cause, new info)
+3. Skip documentation (exact duplicate)
+
+### "Schema validation failed"
+A required field has an invalid value. Check:
+- `problem_type` uses valid enum value
+- `root_cause` uses valid enum value
+- `symptoms` has 1-5 items
+- `severity` is critical/high/medium/low
+
+## Tips
+
+1. **Run immediately after fix** - Context is freshest right after solving
+2. **Include exact error messages** - Makes future searches work
+3. **Add prevention tips** - Most valuable part of documentation
+4. **Cross-reference related docs** - Build knowledge graph
+5. **Use tags** - Improves discoverability

commands/commit.md

@@ -0,0 +1,168 @@
+---
+name: commit
+description: Create a git commit with AI identification via Git trailers (no visible signature in message)
+argument-hint: "[message]"
+---
+
+Create a git commit following repository conventions with AI identification through Git trailers instead of visible signatures in the commit message body.
+
+## Commit Process
+
+### Step 1: Gather Context
+
+Run these commands in parallel to understand the current state:
+
+```bash
+# Check staged and unstaged changes
+git status
+
+# View staged changes
+git diff --cached
+
+# View recent commits for style reference
+git log --oneline -10
+```
+
+### Step 2: Analyze Changes
+
+Based on the diff output:
+1. **Identify the type of change**: feat, fix, chore, docs, refactor, test, style, perf, ci, build
+2. **Determine the scope** (optional): component or area affected
+3. **Summarize the "why"**: Focus on purpose, not just what changed
+
+### Step 3: Draft Commit Message
+
+Follow the repository's existing commit style. If Conventional Commits is used:
+
+```
+<type>(<scope>): <subject>
+
+<body - optional>
+```
+
+**Guidelines:**
+- Subject line: max 50 characters, imperative mood ("add" not "added")
+- Body: wrap at 72 characters, explain motivation/context
+- **DO NOT include** emoji signatures, "Generated by AI", or Co-Authored-By in the message body
+
+### Step 4: Create Commit with Trailers
+
+Use Git's `--trailer` parameter for AI identification. This keeps trailers separate from the message and follows Git's native trailer handling:
+
+```bash
+git commit \
+  -m "<type>(<scope>): <subject>" \
+  -m "<body if needed>" \
+  --trailer "Generated-by: Claude" \
+  --trailer "AI-Model: claude-opus-4-5-20251101"
+```
+
+**Available Trailers:**
+- `--trailer "Generated-by: Claude"` - Identifies AI assistance
+- `--trailer "AI-Model: <model-id>"` - Specific model used
+- `--trailer "AI-Session: <id>"` - Session identifier (optional)
+- `--trailer "Reviewed-by: <name>"` - If human reviewed before commit
+
+### Step 5: Verify Commit
+
+After committing, verify with:
+
+```bash
+git log -1 --format=full
+git status
+```
+
+## Examples
+
+### Simple Feature
+```bash
+git commit \
+  -m "feat(auth): add OAuth2 refresh token support" \
+  -m "Implements automatic token refresh when access token expires, preventing session interruptions for long-running operations." \
+  --trailer "Generated-by: Claude" \
+  --trailer "AI-Model: claude-opus-4-5-20251101"
+```
+
+### Bug Fix
+```bash
+git commit \
+  -m "fix(api): handle null response in user endpoint" \
+  --trailer "Generated-by: Claude" \
+  --trailer "AI-Model: claude-opus-4-5-20251101"
+```
+
+### Chore/Refactor
+```bash
+git commit \
+  -m "chore: update dependencies to latest versions" \
+  --trailer "Generated-by: Claude" \
+  --trailer "AI-Model: claude-opus-4-5-20251101"
+```
+
+## Trailer Query Commands
+
+Trailers can be queried programmatically:
+
+```bash
+# Find all AI-generated commits
+git log --all --grep="Generated-by: Claude"
+
+# Show trailers for a commit
+git log -1 --format="%(trailers)"
+
+# Filter by specific trailer
+git log --all --format="%H %s" | while read hash msg; do
+  git log -1 --format="%(trailers:key=Generated-by)" $hash | grep -q Claude && echo "$hash $msg"
+done
+```
+
+## Important Notes
+
+1. **No visible AI signature** - The message body stays clean and professional
+2. **Trailers are standard** - Git trailers are a recognized convention (like Signed-off-by)
+3. **Machine-readable** - Easy to filter/query AI-generated commits
+4. **Transparent** - AI assistance is documented, just not prominently displayed
+5. **Do not use --no-verify** - Always run pre-commit hooks unless user explicitly requests
+
+## When User Provides Message
+
+If the user provides a commit message as argument:
+1. Use their message as the subject/body
+2. Ensure proper formatting (50 char subject, etc.)
+3. Append the trailers via `--trailer` parameter
+
+```bash
+# User says: /ring-default:commit "fix login bug"
+git commit \
+  -m "fix: fix login bug" \
+  --trailer "Generated-by: Claude" \
+  --trailer "AI-Model: claude-opus-4-5-20251101"
+```
+
+## Step 6: Offer Push (Optional)
+
+After successful commit, ask the user if they want to push:
+
+```javascript
+AskUserQuestion({
+  questions: [{
+    question: "Push commit to remote?",
+    header: "Push",
+    multiSelect: false,
+    options: [
+      { label: "Yes", description: "Push to current branch" },
+      { label: "No", description: "Keep local only" }
+    ]
+  }]
+});
+```
+
+If user selects "Yes":
+```bash
+git push
+```
+
+If branch has no upstream, use:
+```bash
+git push -u origin <current-branch>
+```

commands/execute-plan.md

@@ -0,0 +1,122 @@
+---
+name: execute-plan
+description: Execute plan in batches with review checkpoints
+argument-hint: "[plan-file-path]"
+---
+
+Execute an existing implementation plan with controlled checkpoints and code review between batches. Supports autonomous one-go execution or batch mode with human review at each checkpoint.
+
+## Usage
+
+```
+/ring-default:execute-plan [plan-file-path]
+```
+
+## Arguments
+
+| Argument | Required | Description |
+|----------|----------|-------------|
+| `plan-file-path` | Yes | Path to the plan file (e.g., `docs/plans/2024-01-15-auth-feature.md`) |
+
+## Examples
+
+### Execute a Feature Plan
+```
+/ring-default:execute-plan docs/plans/2024-01-15-oauth-integration.md
+```
+Loads and executes the OAuth integration plan with review checkpoints.
+
+### Execute from Absolute Path
+```
+/ring-default:execute-plan /Users/dev/project/docs/plans/2024-01-15-api-refactor.md
+```
+Executes a plan using its full path.
+
+### Execute Latest Plan
+```
+/ring-default:execute-plan docs/plans/2024-01-20-notification-system.md
+```
+Executes the most recent plan for the notification system feature.
+
+## Process
+
+### Step 1: Load and Review Plan
+- Reads the plan file
+- Critically reviews for any questions or concerns
+- Raises issues with you before starting
+- Creates TodoWrite to track progress
+
+### Step 2: Choose Execution Mode (MANDATORY)
+You will be asked to choose between:
+
+| Mode | Behavior |
+|------|----------|
+| **One-go (autonomous)** | Executes all batches continuously with code review between each; no human review until completion |
+| **Batch (with review)** | Executes one batch, pauses for human feedback after code review, then continues |
+
+### Step 3: Execute Batch
+- Default batch size: first 3 tasks
+- Each task is marked in_progress, executed, then completed
+- Dispatches to specialized agents when available:
+  - Backend Go: `ring-dev-team:backend-engineer-golang`
+  - Backend Python: `ring-dev-team:backend-engineer-python`
+  - Frontend React/TypeScript: `ring-dev-team:frontend-engineer-typescript`
+  - Infrastructure: `ring-dev-team:devops-engineer`
+  - Testing: `ring-dev-team:qa-analyst`
+  - Reliability: `ring-dev-team:sre`
+
+### Step 4: Run Code Review
+After each batch, all 3 reviewers run in parallel:
+- `ring-default:code-reviewer` - Architecture and patterns
+- `ring-default:business-logic-reviewer` - Requirements and edge cases
+- `ring-default:security-reviewer` - OWASP and auth validation
+
+**Issue handling by severity:**
+| Severity | Action |
+|----------|--------|
+| Critical/High/Medium | Fix immediately, re-run all reviewers |
+| Low | Add `TODO(review):` comment in code |
+| Cosmetic/Nitpick | Add `FIXME(nitpick):` comment in code |
+
+### Step 5: Report and Continue
+**One-go mode:** Continues to next batch automatically, reports only at final completion.
+
+**Batch mode:** Shows implementation summary, verification output, and code review results. Waits for your feedback before proceeding.
+
+### Step 6: Complete Development
+After all tasks complete:
+- Uses `ring-default:finishing-a-development-branch` skill
+- Verifies tests pass
+- Presents options for branch completion
+
+## Related Commands/Skills
+
+| Command/Skill | Relationship |
+|---------------|--------------|
+| `/ring-default:write-plan` | Use first to create the plan file |
+| `/ring-default:brainstorm` | Use before writing-plans if design unclear |
+| `ring-default:writing-plans` | Creates the plan files this command executes |
+| `ring-default:requesting-code-review` | Called automatically after each batch |
+| `ring-default:finishing-a-development-branch` | Called at completion |
+
+## Troubleshooting
+
+### "No plan file found"
+Ensure the path is correct. Plans are typically stored in `docs/plans/`. Use `ls docs/plans/` to list available plans.
+
+### "Plan has critical gaps"
+The plan was reviewed and found to have issues preventing execution. You'll be asked to clarify or revise the plan before proceeding.
+
+### "Verification failed repeatedly"
+Execution stops when a verification step fails multiple times. Review the output to determine if the plan needs revision or if there's an environmental issue.
+
+### "Code review finds Critical issues"
+All Critical, High, and Medium issues must be fixed before proceeding. The reviewers will re-run after fixes until the batch passes.
+
+### Execution mode was not asked
+If you're not prompted for execution mode, this is a violation of the skill protocol. The mode selection is mandatory regardless of any "just execute" or "don't wait" instructions.
+
+### When NOT to use this command
+- No plan exists - use `/ring-default:write-plan` first
+- Plan needs revision - use `/ring-default:brainstorm` to refine the design
+- Working on independent tasks in current session - use `ring-default:subagent-driven-development` skill directly

commands/worktree.md

@@ -0,0 +1,73 @@
+---
+name: worktree
+description: Create isolated git worktree with interactive setup
+argument-hint: "[branch-name]"
+---
+
+I'm using the using-git-worktrees skill to set up an isolated workspace for your feature work.
+
+**This command will:**
+1. Ask you for the feature/branch name
+2. Auto-detect or ask about worktree directory location
+3. Create the isolated worktree
+4. Set up dependencies
+5. Verify baseline tests pass
+
+**The skill will systematically:**
+- Check for existing `.worktrees/` or `worktrees/` directories
+- Check CLAUDE.md for location preferences
+- Verify .gitignore (for project-local directories)
+- Auto-detect and run project setup (npm install, cargo build, etc.)
+- Run baseline tests to ensure clean starting point
+
+**First, let me ask you about your feature:**
+
+Please use the AskUserQuestion tool to gather:
+
+**Question 1:** "What is the name of your feature/branch?"
+- Header: "Feature Name"
+- This will be used for both the branch name and worktree directory name
+- Examples: "auth-system", "user-profiles", "payment-integration"
+
+After getting the feature name, follow the complete using-git-worktrees skill process:
+
+1. **Check for existing directories** (priority order):
+   - `.worktrees/` (preferred)
+   - `worktrees/` (alternative)
+   - If both exist, use `.worktrees/`
+
+2. **Check CLAUDE.md** for worktree directory preferences
+
+3. **If no directory exists and no CLAUDE.md preference**, ask user:
+   - Option 1: `.worktrees/` (project-local, hidden)
+   - Option 2: `~/.config/ring/worktrees/<project-name>/` (global location)
+
+4. **Verify .gitignore** (if project-local directory):
+   - MUST check if directory is in .gitignore
+   - If NOT: Add to .gitignore immediately and commit
+   - Per Jesse's rule: "Fix broken things immediately"
+
+5. **Create worktree**:
+   - Detect project name: `basename "$(git rev-parse --show-toplevel)"`
+   - Create: `git worktree add <path> -b <branch-name>`
+   - Navigate: `cd <path>`
+
+6. **Run project setup** (auto-detect):
+   - Node.js: `npm install` (if package.json exists)
+   - Rust: `cargo build` (if Cargo.toml exists)
+   - Python: `pip install -r requirements.txt` or `poetry install`
+   - Go: `go mod download` (if go.mod exists)
+
+7. **Verify clean baseline**:
+   - Run appropriate test command for the project
+   - If tests fail: Report failures and ask whether to proceed
+   - If tests pass: Report ready
+
+8. **Report completion**:
+   ```
+   Worktree ready at <full-path>
+   Tests passing (N tests, 0 failures)
+   Ready to implement <feature-name>
+   ```
+
+Follow the complete process defined in `skills/using-git-worktrees/SKILL.md`.

commands/write-plan.md

@@ -0,0 +1,124 @@
+---
+name: write-plan
+description: Create detailed implementation plan with bite-sized tasks
+argument-hint: "[feature-name]"
+---
+
+Create a comprehensive implementation plan for a feature, with exact file paths, complete code examples, and verification steps. Plans are designed to be executable by engineers with zero codebase context.
+
+## Usage
+
+```
+/ring-default:write-plan [feature-name]
+```
+
+## Arguments
+
+| Argument | Required | Description |
+|----------|----------|-------------|
+| `feature-name` | Yes | Descriptive name for the feature (e.g., "user-authentication", "payment-webhooks", "api-rate-limiting") |
+
+## Examples
+
+### Create a Feature Plan
+```
+/ring-default:write-plan oauth2-integration
+```
+Creates a detailed plan for implementing OAuth2 authentication.
+
+### Create an API Plan
+```
+/ring-default:write-plan rest-api-versioning
+```
+Plans the implementation of API versioning with migration path.
+
+### Create a Refactoring Plan
+```
+/ring-default:write-plan database-connection-pooling
+```
+Creates a step-by-step plan for implementing connection pooling.
+
+## Process
+
+### Step 1: Dispatch Planning Agent
+A specialized planning agent (running on Opus model) is dispatched to:
+- Explore the codebase to understand architecture
+- Identify all files that need modification
+- Break the feature into bite-sized tasks (2-5 minutes each)
+
+### Step 2: Agent Creates Plan
+The agent writes a comprehensive plan including:
+- Header with goal, architecture, tech stack, prerequisites
+- Bite-sized tasks with exact file paths
+- Complete, copy-paste ready code for each task
+- Exact verification commands with expected output
+- Code review checkpoints after task batches
+- Recommended agents for each task type
+- Failure recovery steps
+
+### Step 3: Save Plan
+Plan is saved to: `docs/plans/YYYY-MM-DD-<feature-name>.md`
+
+### Step 4: Choose Execution Mode
+After the plan is ready, you'll be asked:
+
+| Option | Description |
+|--------|-------------|
+| **Execute now** | Start implementation immediately using subagent-driven development |
+| **Execute in parallel session** | Open a new agent session in the worktree for batch execution |
+| **Save for later** | Keep the plan for manual review before execution |
+
+## Plan Requirements (Zero-Context Test)
+
+Every plan passes the "Zero-Context Test" - executable with only the document:
+
+- **Exact file paths** - Never "somewhere in src"
+- **Complete code** - Never "add validation here"
+- **Verification commands** - With expected output
+- **Failure recovery** - What to do when things go wrong
+- **Code review checkpoints** - Severity-based handling
+- **Agent recommendations** - Which specialized agent for each task
+
+## Agent Selection in Plans
+
+Plans specify recommended agents for execution:
+
+| Task Type | Recommended Agent |
+|-----------|-------------------|
+| Backend (Go) | `ring-dev-team:backend-engineer-golang` |
+| Backend (Python) | `ring-dev-team:backend-engineer-python` |
+| Backend (TypeScript) | `ring-dev-team:backend-engineer-typescript` |
+| Frontend (React/TypeScript) | `ring-dev-team:frontend-engineer-typescript` |
+| Infrastructure | `ring-dev-team:devops-engineer` |
+| Testing | `ring-dev-team:qa-analyst` |
+| Reliability | `ring-dev-team:sre` |
+| Fallback | `general-purpose` |
+
+## Related Commands/Skills
+
+| Command/Skill | Relationship |
+|---------------|--------------|
+| `/ring-default:brainstorm` | Use first if design is not yet validated |
+| `/ring-default:execute-plan` | Use after to execute the created plan |
+| `ring-default:brainstorming` | Design validation before planning |
+| `ring-default:executing-plans` | Batch execution with review checkpoints |
+| `ring-default:subagent-driven-development` | Alternative execution for current session |
+
+## Troubleshooting
+
+### "Design not validated"
+Planning requires a validated design. Use `/ring-default:brainstorm` first to refine your concept before creating the implementation plan.
+
+### "Plan is too vague"
+If the generated plan contains phrases like "implement the logic" or "add appropriate handling", the plan doesn't meet quality standards. Request revision with specific code examples.
+
+### "Worktree not set up"
+This command is best run in a dedicated worktree created by the brainstorming skill. You can still run it in main, but isolation is recommended.
+
+### "Agent selection unavailable"
+If `ring-dev-team` plugin is not installed, execution falls back to `general-purpose` agents automatically. Plans remain valid regardless.
+
+### When NOT to use this command
+- Design is not validated - use `/ring-default:brainstorm` first
+- Requirements still unclear - use pre-dev PRD/TRD workflow first
+- Already have a plan - use `/ring-default:execute-plan` instead