zhongwei/gh-kylesnowschwartz-simpleclaude-plugins-sc-extras
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:36:25 +08:00
commit c7501d0ed5
10 changed files with 949 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,11 @@
{
"name": "sc-extras",
"description": "Optional SimpleClaude utilities for debugging, git workflows, and task validation",
"version": "2.0.0",
"author": {
"name": "Kyle Snow Schwartz"
},
"commands": [
"./commands"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# sc-extras
Optional SimpleClaude utilities for debugging, git workflows, and task validation

84
commands/sc-create-command.md Normal file
View File

@@ -0,0 +1,84 @@
# sc-create-command: Guide for creating new custom Claude commands with proper structure.
## Process:
### 1. Understanding Purpose
- What problem does this command solve?
- Who will use this command?
- What is the expected output?
- How will users interact with it?
### 2. Category Classification
Determine command type:
- **Planning**: Project setup, architecture decisions
- **Implementation**: Code generation, feature development
- **Analysis**: Code review, performance analysis
- **Testing**: Test creation, validation
- **Documentation**: Docs generation, updates
- **Workflow**: Multi-step processes
- **Utility**: Helper commands, tools
### 3. Pattern Selection
Study similar existing commands:
- Analyze structure and flow
- Note common patterns
- Identify reusable components
- Follow established conventions
### 4. Command Location
Choose appropriate location:
- **Project-specific**: `.claude/commands/`
- **User-level**: `~/.claude/commands/`
- Consider reusability and context
### 5. Command Structure
Create with these sections:
- **Title**: Clear, action-oriented name
- **Description**: One-line summary
- **Usage**: How to invoke with parameters
- **Process**: Step-by-step instructions
- **Output**: Expected results
- **Notes**: Special considerations
## Template:
For SimpleClaude commands look at @templates/sc-command-template.md, or use this basic markdown template:
```markdown
# Command Name
Brief description of what this command does.
## Usage:
`/command-name [arguments]`
## Process:
1. First step
2. Second step
3. Third step
## Notes:
- Important considerations
- Limitations
```
## Best Practices:
- Keep commands focused and single-purpose
- Include parameter validation
- Provide helpful error messages
- Document expected inputs/outputs
- Consider edge cases
- Test thoroughly before finalizing

33
commands/sc-eastereggs.md Normal file
View File

@@ -0,0 +1,33 @@
# sc-eastereggs: Discover undocumented features, hidden flags, and clever implementations throughout the codebase
---
## Agent Orchestration
Based on request complexity and intent, delegate to specialized agents using Task() calls:
**Execution Strategy**: For complex discovery tasks, spawn agents simultaneously for parallel investigation streams focusing on discovery, investigation, and documentation rather than implementation.
## Command Execution
**If "{{ARGUMENTS}}" is empty**: Display usage suggestions and stop.
**If "{{ARGUMENTS}}" has content**: Think step-by-step, then execute.
Transforms: "{{ARGUMENTS}}" into structured intent:
- What: [extracted-target]
- How: [detected-approach]
- Mode: [execution-mode]
- Agents: [specialized Task() agents]
**Auto-Spawning:** Spawns 2-3 code-expert agents via in parallel execution.
Intelligent discovery router that transforms natural language queries into systematic searches for hidden features, undocumented capabilities, and clever implementations that aren't explicitly documented.
**Context Detection:** Documentation scan → Code analysis → Pattern recognition → Feature extraction → Category organization
## Core Workflows
**Planner:** Agents → Ingest README/docs → Map documented features → Identify search patterns → Plan discovery strategy
**Implementer:** Agents → Search codebase → Extract hidden features → Analyze implementations → Categorize findings
**Tester:** Agents → Validate discoveries → Test feature combinations → Document edge cases → Verify functionality

154
commands/sc-five-whys.md Normal file
View File

@@ -0,0 +1,154 @@
# sc-five-whys: Autonomous Root Cause Analysis Protocol
_A systematic approach to finding root causes in software problems._
## Process:
### 1. Capture the Problem
**Define specifically what's broken:**
- Problem statement exists in ${ARGUMENTS} or conversation context
- You have access to relevant data/logs/documentation
- What's the observed issue? (error, wrong behavior, visual bug)
- When does it occur? (specific triggers, conditions, frequency)
- Where does it manifest? (backend/frontend/specific component)
- Who/what is affected? (users, systems, features)
**Gather evidence:**
- Error messages, stack traces, console logs
- Screenshots for visual issues
- Steps to reproduce
- Recent changes that might relate
### 2. Ask "Why?" (Usually 5 Times, Sometimes Less)
**Build your causal chain:**
```
Problem: [Specific issue]
├── Why? → [Technical cause A]
│ └── Why? → [Deeper cause A2]
│ └── Why? → [Continue until root]
└── Why? → [Technical cause B] (if multiple factors)
└── Why? → [Continue separately]
```
**Focus your whys based on problem type:**
- **Backend issues**: logic errors, data state, resources, timing
- **Frontend issues**: events, state management, CSS, browser differences
- **Visual bugs**: often only need 2-3 whys (styling → specificity → root)
- **Performance**: may need 6-7 whys to reach architectural roots
**Watch for false roots (keep digging if you hit these):**
- "Human error" / "Someone made a mistake"
- "Lack of time/resources"
- "That's how it's always been"
- "Random occurrence"
- "Just make the test pass"
- "I'll commit this with --no-verify"
### 3. Validate Your Root Cause
**Can you answer YES to:**
- Can I point to specific code/config that embodies this cause?
- If I fix this exact thing, will the problem definitely stop?
- Does this cause explain all observed symptoms?
**For UI/UX issues also check:**
- Can I demonstrate the fix in DevTools?
- Does this explain why it works in some contexts but not others?
### 4. Develop the Fix
**Address multiple levels:**
- **Immediate**: Stop the bleeding (workaround, feature flag, revert)
- **Root fix**: Address the actual cause you found
- **Prevention**: Ensure this class of issue can't recur (tests, types, linting)
## Example - Backend:
**Problem**: API returns 500 error for specific users
1. **Why?** → Database query times out
2. **Why?** → Query joins 5 tables for these users
3. **Why?** → These users have 1000x normal data volume
4. **Why?** → No pagination on user data retrieval
5. **Why?** → Original design assumed <100 items per user
**Root**: Missing pagination in data access layer
**Fix**: Add pagination, set query limits, add volume tests
## Example - Frontend:
**Problem**: Button doesn't respond on mobile
1. **Why?** → Click handler not firing
2. **Why?** → Parent div has touch handler that prevents bubbling
3. **Why?** → Swipe gesture detection consumes all touch events
**Root**: Overly aggressive event.preventDefault() in swipe handler
**Fix**: Add conditional logic to allow tap-through on buttons
## Smart Patterns:
**When to stop before 5:**
- Found the exact line of broken code
- Identified the specific config value
- Located the CSS rule causing misalignment
- Going deeper would just explain "why coding exists"
**When to go beyond 5:**
- Intermittent failures (race conditions need deep tracing)
- Performance degradation (often architectural)
- Complex state corruption (may have long cause chains)
**When to branch your investigation:**
- "Works on dev but not prod" → investigate environment differences
- "Sometimes fails" → investigate timing/concurrency separately
- "Only certain users" → investigate data patterns separately
## Output Template:
```markdown
### Problem
[One sentence description]
### Five Whys Analysis
1. Why? [Answer] - _Evidence: [what proves this]_
2. Why? [Answer] - _Evidence: [what proves this]_
[...continue to root]
### Root Cause
**Location**: [file:line or component]
**Issue**: [Specific technical problem]
**Confidence**: [High/Medium/Low based on evidence]
### Solution
**Immediate mitigation**: [If urgent]
**Root fix**: [Code/config change needed]
**Prevention**: [Test/process to prevent recurrence]
### Notes
[Any branches explored, assumptions made, or additional context]
```
---
_Remember: Five Whys is a thinking tool, not a rigid formula. Sometimes three whys finds the root. Sometimes you need seven. The goal is understanding, not completing a checklist._
${ARGUMENTS}

58
commands/sc-pr-comments.md Normal file
View File

@@ -0,0 +1,58 @@
# sc-pr-comments: Fetch and display comments from a GitHub pull request.
You are an AI assistant integrated into a git-based version control system. Follow these steps:
1. Use \gh pr view --json number,headRepository\ to get the PR number and repository info
2. Use \gh api /repos/{owner}/{repo}/issues/{number}/comments\ to get PR-level comments
3. Use \gh api /repos/{owner}/{repo}/pulls/{number}/comments\ to get review comments. Pay particular attention to the following fields: \body\, \diff_hunk\, \path\, \line\, etc. If the comment references some code, consider fetching it using eg \gh api /repos/{owner}/{repo}/contents/{path}?ref={branch} | jq .content -r | base64 -d\
4. Parse and organize all comments by file path
5. Create a well-organized summary with comment summaries
Format the output as:
## Detailed Comments
[Include the full formatted comments for reference:]
### {file path}
[For each comment thread:]
• @author file.ts#line: \\\`diff [diff_hunk from the API response] \\\`
> quoted comment text
[any replies indented]
---
# PR Comments Summary
## File-Specific Comments
[Organize by file path, with summaries for each comment:]
### {file path}
[For each comment on this file:]
- @{commenter name} suggests {summary of feedback}
## General Comments
[For PR-level comments that don't target specific files, create summary entries like:]
- @{commenter name} suggests {summary of feedback}
If there are no comments, return "No comments found."
Remember:
1. Create meaningful summaries of comments using "@{commenter name} suggests {summary of feedback}" format
2. Organize comments by file path for easy navigation
3. Include both PR-level and code review comments
4. Preserve the threading/nesting of comment replies in the detailed section
5. Show the file and line number context for code review comments
6. Use \jq\ to parse the JSON responses from the GitHub API
7. Provide both summarized and detailed views for comprehensive understanding
${ADDITIONAL USER INPUT}

325
commands/sc-pre-commit-setup.md Normal file
View File

@@ -0,0 +1,325 @@
# sc-pre-commit-setup-2: Streamlined Pre-commit Framework Setup
**Purpose**: Set up pre-commit framework with repository-specific hooks and intelligent auto-restaging behavior for seamless development workflow.
## Step 1: Verify Pre-commit Installation
Before configuring hooks, ensure pre-commit is properly installed:
```bash
# Check if pre-commit is available
if ! command -v pre-commit >/dev/null; then
echo "Installing pre-commit via Homebrew..."
brew install pre-commit
fi
# Verify installation
pre-commit --version
# Install git hooks (creates .git/hooks/pre-commit)
pre-commit install
```
**Expected Output**: `pre-commit installed at .git/hooks/pre-commit`
## Step 2: Repository Analysis
Use GitHub CLI to detect repository technologies and appropriate hooks:
```bash
# Verify required tools are installed
if ! command -v gh &> /dev/null || ! command -v jq &> /dev/null; then
echo "Error: Missing dependencies. Please install 'gh' and 'jq'" >&2
exit 1
fi
# Get repository languages and suggest appropriate hooks
REPO_LANGS=$(gh repo view --json languages | jq -r '.languages | map(.node.name) | join(" ")')
echo "Detected languages: $REPO_LANGS"
echo ""
echo "Recommended hooks based on detected languages:"
# Universal (always include)
echo " - pre-commit/pre-commit-hooks (file hygiene, always include)"
# Python
if echo "$REPO_LANGS" | grep -q "Python"; then
echo " - astral-sh/ruff-pre-commit (Python linting & formatting)"
fi
# JavaScript/TypeScript
if echo "$REPO_LANGS" | grep -qE "JavaScript|TypeScript"; then
echo " - pre-commit/mirrors-prettier (JS/TS formatting)"
echo " - pre-commit/mirrors-eslint (JS/TS linting)"
fi
# Ruby
if echo "$REPO_LANGS" | grep -q "Ruby"; then
echo " - pre-commit/mirrors-rubocop (Ruby linting & formatting)"
fi
# Shell
if echo "$REPO_LANGS" | grep -q "Shell"; then
echo " - koalaman/shellcheck-precommit (Shell linting)"
echo " - scop/pre-commit-shfmt (Shell formatting)"
fi
echo ""
echo "Configuration files present:"
find . -maxdepth 2 \( -name ".git" -o -name "node_modules" \) -prune -o -type f \( -name "package.json" -o -name "requirements.txt" -o -name "Gemfile" -o -name "pyproject.toml" -o -name "tsconfig.json" -o -name ".pre-commit-config.yaml" \) -print
```
Select appropriate hook repositories from the recommendations above.
## Step 3: Create Configuration
**⚠️ Important**: The version numbers in the examples below are illustrative only and may be outdated. Always fetch the latest versions using the commands shown at the end of this section before creating your configuration.
Generate `.pre-commit-config.yaml` based on detected languages:
```yaml
# Pre-commit configuration for [REPOSITORY_NAME]
repos:
# Core file hygiene (always include)
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v5.0.0 # Use latest from: gh api repos/pre-commit/pre-commit-hooks/releases/latest
hooks:
- id: trailing-whitespace
exclude: '\.md$'
- id: end-of-file-fixer
- id: check-merge-conflict
- id: check-added-large-files
args: [--maxkb=1024]
- id: check-yaml
- id: check-json
- id: detect-private-key
# Language-specific hooks (add based on repository analysis)
# Example for Python (modern approach using Ruff):
- repo: https://github.com/astral-sh/ruff-pre-commit
rev: v0.8.4
hooks:
- id: ruff
args: [--fix]
- id: ruff-format
# Example for Ruby:
- repo: https://github.com/pre-commit/mirrors-rubocop
rev: v1.70.0
hooks:
- id: rubocop
args: [--auto-correct]
# Example for Shell scripts:
- repo: https://github.com/koalaman/shellcheck-precommit
rev: v0.10.0
hooks:
- id: shellcheck
args: [--severity=warning]
- repo: https://github.com/scop/pre-commit-shfmt
rev: v3.12.0-2
hooks:
- id: shfmt
args: [-w, -i, "2"] # 2-space indentation
```
**Get latest versions**:
```bash
# Core hooks
gh api repos/pre-commit/pre-commit-hooks/releases/latest | jq -r '.tag_name'
# Python
gh api repos/astral-sh/ruff-pre-commit/releases/latest | jq -r '.tag_name'
# Ruby
gh api repos/pre-commit/mirrors-rubocop/tags | jq -r '.[0].name'
# Shell
gh api repos/koalaman/shellcheck-precommit/tags | jq -r '.[0].name'
gh api repos/scop/pre-commit-shfmt/tags | jq -r '.[0].name'
```
## Step 4: Test Configuration
Validate and test the configuration incrementally:
```bash
# Validate YAML syntax
pre-commit validate-config
# Test core hooks first
pre-commit run trailing-whitespace --all-files
pre-commit run end-of-file-fixer --all-files
# Run all hooks
pre-commit run --all-files
```
**If hooks modify files**: They will exit with code 1 and require manual re-staging.
## Step 5: Add Auto-restaging Wrapper (Optional)
Pre-commit **does not** have built-in auto-restaging. If your hooks modify files (formatters, fixers), add a custom wrapper to preserve staging intent.
**Detection**: Your config contains file-modifying hooks like:
- `shfmt`, `black`, `prettier` (formatters)
- `trailing-whitespace`, `end-of-file-fixer` (fixers)
- Hooks with `--fix` arguments
**Implementation**:
1. Ensure `pre-commit install` has been run (from Step 1). This generates `.git/hooks/pre-commit` which we'll now enhance with auto-restaging capability.
2. Extract system-specific values from the generated hook:
```bash
# Backup the generated hook
cp .git/hooks/pre-commit .git/hooks/pre-commit.original
# Extract the templated values (these are system-specific)
grep "INSTALL_PYTHON=" .git/hooks/pre-commit.original
grep "ARGS=(" .git/hooks/pre-commit.original
```
3. Create the staging-aware wrapper using YOUR extracted values:
```bash
#!/usr/bin/env bash
# Staging-aware pre-commit wrapper
# Preserves original staging intent while using pre-commit framework
# start templated (REPLACE these lines with YOUR extracted values from step 2)
INSTALL_PYTHON=/usr/local/opt/pre-commit/libexec/bin/python3.13
ARGS=(hook-impl --config=.pre-commit-config.yaml --hook-type=pre-commit)
# end templated
HERE="$(cd "$(dirname "$0")" && pwd)"
ARGS+=(--hook-dir "$HERE" -- "$@")
# Check if this is an initial commit
if git rev-parse --verify HEAD >/dev/null 2>&1; then
against=HEAD
else
against=$(git hash-object -t tree /dev/null)
fi
# Store originally staged files BEFORE pre-commit runs
original_staged_files=$(git diff --cached --name-only --diff-filter=ACDMRT "$against")
# Run original pre-commit framework logic
if [ -x "$INSTALL_PYTHON" ]; then
"$INSTALL_PYTHON" -mpre_commit "${ARGS[@]}"
result=$?
elif command -v pre-commit >/dev/null; then
pre-commit "${ARGS[@]}"
result=$?
else
echo '`pre-commit` not found. Did you forget to activate your virtualenv?' 1>&2
exit 1
fi
# If pre-commit failed due to file modifications (exit code 1),
# restore proper staging to only include originally staged files.
# Exit codes: 0=success, 1=failures/fixes applied, >1=actual errors
if [ $result -eq 1 ] && [ -n "$original_staged_files" ]; then
# Reset staging area completely
git reset HEAD --quiet
# Re-stage only originally staged files (which now include hook modifications)
echo "$original_staged_files" | while IFS= read -r file; do
git add "$file"
done
echo "Pre-commit: Auto-formatted files and preserved original staging intent"
exit 0
fi
# Pass through original exit code for other scenarios
exit $result
```
4. Write the complete wrapper to `.git/hooks/pre-commit` and make it executable:
```bash
# Copy your complete wrapper script to .git/hooks/pre-commit
# (After editing the templated section with your extracted values)
chmod +x .git/hooks/pre-commit
```
## Step 6: Final Verification
Test the complete setup:
```bash
# Create test scenario
echo "test content " > test-format.txt # Trailing space
git add test-format.txt
# Test commit (should auto-format and succeed with wrapper, or fail without)
git commit -m "Test pre-commit setup"
# Cleanup
git restore --staged test-format.txt
rm test-format.txt
```
## Common Hook Repositories
Research latest versions using GitHub CLI:
```bash
# Core hooks
gh api repos/pre-commit/pre-commit-hooks/releases/latest # Basic file checks
# Python (2025 recommended: Ruff replaces Black, isort, Flake8, pyupgrade)
gh api repos/astral-sh/ruff-pre-commit/releases/latest # Python linting & formatting
gh api repos/RobertCraigie/pyright-python/releases/latest # Python type checking
# Ruby
gh api repos/pre-commit/mirrors-rubocop/tags | jq -r '.[0].name' # Ruby linting & formatting
# JavaScript/TypeScript
gh api repos/pre-commit/mirrors-prettier/tags | jq -r '.[0].name' # JS/TS formatting
gh api repos/pre-commit/mirrors-eslint/tags | jq -r '.[0].name' # JS/TS linting
# Shell
gh api repos/koalaman/shellcheck-precommit/tags | jq -r '.[0].name' # Shell linting
gh api repos/scop/pre-commit-shfmt/tags | jq -r '.[0].name' # Shell formatting
# Security & General
gh api repos/zricethezav/gitleaks/releases/latest # Secret detection
gh api repos/codespell-project/codespell/releases/latest # Typo detection
```
## Success Criteria
- ✅ `pre-commit --version` works
- ✅ `pre-commit install` completes without errors
- ✅ `pre-commit validate-config` passes
- ✅ `pre-commit run --all-files` executes (may modify files)
- ✅ Repository-specific hooks included for detected languages
- ✅ Auto-restaging wrapper installed if needed
- ✅ Test commit workflow succeeds
## Troubleshooting
**Config validation fails**: Check YAML syntax and hook repository accessibility
**Hooks fail to run**: Verify repository URLs and versions with `pre-commit try-repo <url>`
**Performance issues**: Add file exclusions or remove problematic hooks
**Staging issues**: Verify auto-restaging wrapper is correctly installed and executable
## Maintenance
```bash
# Update hook versions
pre-commit autoupdate
# Run hooks manually
pre-commit run --all-files
# Update specific hook
pre-commit autoupdate --repo https://github.com/astral-sh/ruff-pre-commit
```

128
commands/sc-validate-task.md Normal file
View File

@@ -0,0 +1,128 @@
# sc-validate-task: Single Task Validation Protocol
_Focused validation of specific completed tasks or todo items._
## Usage:
`/sc-validate-task [task-description]`
## Process:
### 1. Task Definition Capture
**Identify exactly what was supposed to be accomplished:**
- Task description from ${ARGUMENTS} or conversation context
- Original requirement or todo item
- Expected deliverable or outcome
- Success criteria (implicit or explicit)
**Gather implementation evidence:**
- Code changes made for this specific task
- Files modified or created
- Tests added or updated
- Documentation changes
### 2. Implementation Verification
**Confirm code changes address the specific task:**
```
Task: [Original requirement]
├── Changes Made → [List actual modifications]
│ ├── Files: [Which files were touched]
│ ├── Logic: [What core functionality was added/changed]
│ └── Tests: [What validation was added]
└── Matches Requirement? → [Yes/No with evidence]
```
**Focus validation based on task type:**
- **Bug fixes**: Does it resolve the reported issue without side effects?
- **Features**: Does it implement the requested functionality completely?
- **Refactoring**: Does it improve code without changing behavior?
- **Tests**: Do they cover the intended scenarios adequately?
### 3. Functional Validation
**Verify the implementation works as intended:**
- Can you demonstrate the functionality works?
- Does it handle expected inputs correctly?
- Are edge cases covered appropriately?
- Does it integrate properly with existing code?
### 4. Quality Gate Check
**Ensure basic quality standards:**
- Code follows project conventions
- No obvious security vulnerabilities introduced
- Performance impact is acceptable
- Breaking changes are intentional and documented
## Validation Decision Matrix:
**✅ VALIDATED** - Task is complete and working correctly
**❌ NEEDS FIXES** - Task has issues that must be resolved
**⚠️ PARTIAL** - Task is mostly complete but has minor issues
## Output Template:
```markdown
# Task Validation: [Specific Task Description]
## Task Definition
**Original Request**: [What was asked for]
**Expected Outcome**: [What should have been delivered]
**Success Criteria**: [How we know it's working]
## Implementation Evidence
**Files Changed**: [List of modified files]
**Core Changes**: [Brief summary of what was implemented]
**Tests Added**: [New validation coverage]
## Functional Verification
**Manual Testing**: [Steps taken to verify functionality]
**Results**: [What happened when testing]
**Edge Cases**: [Boundary conditions checked]
## Validation Results
**Status**: ✅ VALIDATED | ❌ NEEDS FIXES | ⚠️ PARTIAL
**Evidence**: [Specific proof the task works/doesn't work]
**Confidence**: [High/Medium/Low based on testing]
## Issues Found (if any)
- **[Priority]**: [Specific problem with location and fix needed]
## Decision
- **If ✅**: Task complete, ready for next todo
- **If ❌**: [Specific fixes needed before marking complete]
- **If ⚠️**: [What works, what needs attention, acceptable to proceed?]
```
## Smart Patterns:
**When to validate quickly (2-3 checks):**
- Simple bug fixes with clear before/after behavior
- Minor UI adjustments with visual confirmation
- Configuration changes with immediate effects
**When to validate thoroughly (full protocol):**
- New features with multiple integration points
- Security-related changes
- Performance optimizations
- API modifications
**Red flags that require deeper investigation:**
- "It works on my machine" without broader testing
- Changes that touch multiple unrelated areas
- Missing or inadequate test coverage
- Functionality that partially works
---
_Remember: This is task-specific validation, not comprehensive code review. Stay focused on whether this one thing was completed correctly._
${ARGUMENTS}

84
commands/sc-worktrees.md Normal file
View File

@@ -0,0 +1,84 @@
# sc-worktrees: Git Worktrees for Parallel Claude Code Sessions
Git worktrees let you work on multiple branches simultaneously in separate directories. Perfect for parallel Claude Code sessions without losing context.
## Quick Start
**Create a new worktree:**
```bash
git worktree add tree/feature-name -b feature-name
cd tree/feature-name
claude
```
**Create worktree for existing branch:**
```bash
git worktree add tree/existing-branch existing-branch
cd tree/existing-branch
claude
```
## Essential Commands
**List all worktrees:**
```bash
git worktree list
```
**Remove finished worktree:**
```bash
git worktree remove tree/feature-name
git branch -d feature-name # optional: delete branch
```
**Clean up stale references:**
```bash
git worktree prune
```
## Directory Structure
```
YourProject/
├── .git/
├── src/
├── .gitignore # add: /tree/
└── tree/
├── feature-auth/
└── hotfix-123/
```
## Usage Examples
**Parallel development:**
- Terminal 1: `cd ~/project && claude` (main)
- Terminal 2: `cd ~/project/tree/feature && claude` (feature)
- Terminal 3: `cd ~/project/tree/hotfix && claude` (urgent fix)
**Code review:**
```bash
git worktree add tree/review -b review/pr-123
cd tree/review
git pull origin pull/123/head
claude
```
## Setup Notes
1. Add `/tree/` to `.gitignore`
2. Run `npm install` (or equivalent) in each new worktree
3. Each worktree maintains separate Claude Code context
4. All worktrees share the same `.git` database
**If no $ARGUMENTS are provided** Instruct the user on how to manually create and verify their own worktrees and worktree status
**If $ARGUMENTS are provided** Help the user fulfill their request asking any necessary clarifying questions
${ARGUMENTS}

69
plugin.lock.json Normal file
View File

@@ -0,0 +1,69 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:kylesnowschwartz/SimpleClaude:plugins/sc-extras",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "e734017030ad4051f7d907fe046fae7d56524f7b",
"treeHash": "e4bd7ff8d920a298cf23d319a53027f57213d6cac4b9d59f781c2368263f0d8d",
"generatedAt": "2025-11-28T10:20:01.614094Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "sc-extras",
"description": "Optional SimpleClaude utilities for debugging, git workflows, and task validation",
"version": "2.0.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "ddb22e2587f4074a9e9460f22395c523408d7698091d3d50de5fc04b14bc3ecf"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "b30f1f1923df753e68bcf8cc292c270ec4361de0c6b68d24d40b059451981d9d"
},
{
"path": "commands/sc-pr-comments.md",
"sha256": "4e463aed3df3457276f6daaec391e322585183b8339e23a797451f498d66fb67"
},
{
"path": "commands/sc-pre-commit-setup.md",
"sha256": "eccbfef9945bed2a85657cb758ad298f68f82ca64cf3a716377bf3fa579dfcbc"
},
{
"path": "commands/sc-validate-task.md",
"sha256": "f8ee5854b17b34b097358eea20d3e4f31fcd6dd6d2614a7e99155041f81c2a84"
},
{
"path": "commands/sc-worktrees.md",
"sha256": "73619fb9388d417a30c0da4aed56d53b999ab8a49d63ce2f093a2a04d37b9ddd"
},
{
"path": "commands/sc-eastereggs.md",
"sha256": "05c22743121c7136d2906f189c409e5ce7a595127e92833cf6f4be954ad20d03"
},
{
"path": "commands/sc-create-command.md",
"sha256": "59e297d3c93afeb6bc80fc9a25b725b15db3fe9e2f90c8616f07ec9766f6f4df"
},
{
"path": "commands/sc-five-whys.md",
"sha256": "8cfcda95b217b5c3098f17b0736324d8d602a782a36a41c94c19b544dfd796d1"
}
],
"dirSha256": "e4bd7ff8d920a298cf23d319a53027f57213d6cac4b9d59f781c2368263f0d8d"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}