feat(workflow): Add workflow plugin v1.0.0

Git workflow, code quality, context management and testing commands:
- commit, push, pr, issue - git operations
- simplify, refactor, verify, check - code quality
- catchup, onboard, save, cleanup - context management
- test, format, sync - development utilities

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
Claude Agent
2026-01-22 15:23:48 +00:00
parent db47652b5c
commit 45e28e7e94
23 changed files with 2622 additions and 0 deletions

View File

@@ -20,6 +20,13 @@
"description": "Autonomous loop for PRD implementation - context detection, adaptive questions, browser verification", "description": "Autonomous loop for PRD implementation - context detection, adaptive questions, browser verification",
"version": "1.2.1", "version": "1.2.1",
"keywords": ["ralph", "prd", "autonomous", "agent", "loop", "browser", "verification"] "keywords": ["ralph", "prd", "autonomous", "agent", "loop", "browser", "verification"]
},
{
"name": "workflow",
"source": "./plugins/workflow",
"description": "Git workflow, code quality, context management and testing commands",
"version": "1.0.0",
"keywords": ["git", "commit", "pr", "issue", "simplify", "verify", "test", "catchup", "context"]
} }
] ]
} }

View File

@@ -0,0 +1,8 @@
{
"name": "workflow",
"description": "Git workflow, code quality, context management and testing commands",
"version": "1.0.0",
"author": {
"name": "Romfast Team"
}
}

158
plugins/workflow/README.md Normal file
View File

@@ -0,0 +1,158 @@
# Workflow Plugin for Claude Code
A comprehensive plugin providing Git workflow, code quality, testing, and context management commands for Claude Code.
## Installation
```bash
# Add to your project
claude plugins add workflow --source https://gitea.romfast.ro/romfast/claude-plugins
# Or test locally
claude --plugin-dir ./plugins/workflow
```
## Commands Overview
### Git Workflow (5 commands)
| Command | Description |
|---------|-------------|
| `/workflow:commit` | Smart commit with conventional message |
| `/workflow:push` | Push with safety checks |
| `/workflow:pr` | Create PR with auto-generated summary |
| `/workflow:sync` | Pull + rebase + push in one command |
| `/workflow:issue <n>` | Analyze and fix GitHub issue #n |
### Code Quality (4 commands)
| Command | Description |
|---------|-------------|
| `/workflow:simplify` | Reduce code complexity without changing behavior |
| `/workflow:format` | Run code formatters (prettier, eslint, black) |
| `/workflow:cleanup` | Remove unused imports and dead code |
| `/workflow:refactor` | Detect patterns and suggest improvements |
### Testing & Verification (3 commands)
| Command | Description |
|---------|-------------|
| `/workflow:test` | Smart test runner (changed files only) |
| `/workflow:check` | Run typecheck + lint + test combined |
| `/workflow:verify` | End-to-end verification of implementation |
### Context Management (3 commands)
| Command | Description |
|---------|-------------|
| `/workflow:catchup` | Rebuild context after /clear |
| `/workflow:save` | Save progress to HANDOFF.md |
| `/workflow:onboard` | Quick onboarding to a new project |
## Usage Examples
### Daily Workflow
```bash
# Start of day - sync your branch
/workflow:sync
# After implementing a feature
/workflow:check # Verify everything works
/workflow:commit # Create commit
# Create PR when ready
/workflow:pr
# End of day - save context
/workflow:save
/clear
# Next session - restore context
/workflow:catchup
```
### Fix a GitHub Issue
```bash
/workflow:issue 42
```
This will:
1. Fetch issue details from GitHub
2. Search codebase for relevant files
3. Implement the fix
4. Run tests
5. Create a commit referencing the issue
### Code Review Workflow
```bash
# After making changes
/workflow:verify # Full verification
/workflow:simplify # Simplify if needed
/workflow:commit # Commit changes
/workflow:pr # Create PR
```
### New Project Onboarding
```bash
cd /path/to/new/project
claude
# In Claude:
/workflow:onboard
```
## Subagents
The plugin includes specialized subagents for complex tasks:
### code-simplifier
Used by `/workflow:simplify` for multi-file simplification.
### app-verifier
Used by `/workflow:verify` for comprehensive verification.
## Templates
Located in `templates/`:
- `commit-message.md` - Conventional commit format
- `pr-template.md` - Pull request body template
- `handoff-template.md` - Context handoff format
## Configuration
The plugin auto-detects your project's tech stack and tools. No configuration needed.
### Supported Stacks
- **JavaScript/TypeScript**: Jest, Vitest, ESLint, Prettier
- **Python**: pytest, mypy, ruff, black
- **Go**: go test, go fmt
- **Rust**: cargo test, cargo fmt
## Best Practices
1. **Use `/workflow:check` before committing** - Catch issues early
2. **Use `/workflow:save` before `/clear`** - Preserve context
3. **Use `/workflow:catchup` to restore context** - Continue seamlessly
4. **Use `/workflow:issue` for GitHub issues** - Automate the fix process
## Inspiration
This plugin is inspired by:
- [wshobson/commands](https://github.com/wshobson/commands)
- [awesome-claude-code](https://github.com/hesreallyhim/awesome-claude-code)
- [claude-code-tips](https://github.com/ykdojo/claude-code-tips)
- [Anthropic Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices)
## License
MIT
## Contributing
Contributions welcome! Please follow the conventional commit format.

View File

@@ -0,0 +1,183 @@
---
name: app-verifier
description: End-to-end verification agent for implementations
tools:
- Read
- Glob
- Grep
- Bash
---
# Application Verifier Agent
You are a verification specialist. Your goal is to thoroughly verify that an implementation is correct and complete.
## Mission
Perform comprehensive verification of recent changes:
- Static analysis (types, lint)
- Dynamic analysis (tests)
- Code review (patterns, security)
- Integration check (data flow)
## Process
### 1. Identify Scope
Determine what was changed:
```bash
git diff --name-only HEAD~5
git log --oneline -5
```
### 2. Static Analysis
#### TypeScript
```bash
npx tsc --noEmit
```
Check for:
- Type errors
- Implicit any
- Unused variables
- Missing return types
#### ESLint
```bash
npx eslint . --ext .ts,.tsx,.js,.jsx
```
Check for:
- Code style violations
- Potential bugs
- Best practice violations
#### Python
```bash
python -m mypy .
ruff check .
```
### 3. Test Execution
Run all available tests:
```bash
# JavaScript
npm test 2>/dev/null || npx jest 2>/dev/null || npx vitest run 2>/dev/null
# Python
pytest -v 2>/dev/null || python -m unittest discover 2>/dev/null
```
Focus on:
- All tests pass
- Coverage doesn't decrease
- New code is tested
### 4. Security Review
Check each changed file for:
#### Critical Issues
- [ ] Hardcoded secrets (API keys, passwords)
- [ ] SQL injection vulnerabilities
- [ ] XSS vulnerabilities (unsanitized user input in HTML)
- [ ] Command injection (user input in shell commands)
- [ ] Path traversal (user-controlled file paths)
#### Medium Issues
- [ ] Missing input validation
- [ ] Sensitive data in logs
- [ ] Insecure dependencies
- [ ] Missing authentication checks
#### Regex for Common Issues
```bash
# Hardcoded secrets
grep -rn "password\s*=\s*['\"]" --include="*.ts" --include="*.js" .
grep -rn "api[_-]?key\s*=\s*['\"]" --include="*.ts" --include="*.js" .
# SQL injection
grep -rn "query.*\$\{" --include="*.ts" --include="*.js" .
# Dangerous eval
grep -rn "eval(" --include="*.ts" --include="*.js" .
```
### 5. Pattern Verification
Ensure code follows existing patterns:
- Consistent error handling
- Consistent logging
- Consistent API responses
- Consistent state management
### 6. Integration Check
Trace data flow through the changes:
1. Entry point (API route, event handler)
2. Validation layer
3. Business logic
4. Data persistence
5. Response/output
Verify each step handles:
- Happy path
- Error cases
- Edge cases
### 7. Build Verification
Ensure the project builds:
```bash
npm run build 2>/dev/null || yarn build 2>/dev/null
```
## Report Format
```markdown
## Verification Report
### Summary
- **Status**: PASS / FAIL / WARNINGS
- **Files Checked**: N
- **Tests**: X passed, Y failed
- **Lint**: N errors, M warnings
### Static Analysis
- [x] TypeScript: No errors
- [x] ESLint: 2 warnings (non-blocking)
- [x] Build: Successful
### Tests
- [x] Unit tests: 45/45 passed
- [x] Integration tests: 12/12 passed
- [ ] E2E tests: Not configured
### Security
- [x] No hardcoded secrets
- [x] Input validation present
- [!] Consider rate limiting on /api/login
### Code Review
- [x] Follows existing patterns
- [x] Error handling consistent
- [!] Missing JSDoc on public function
### Recommendations
1. Add rate limiting to authentication endpoints
2. Add JSDoc to exported functions
3. Consider adding E2E tests for critical flows
```
## Exit Criteria
Verification passes when:
1. No type errors
2. No critical lint errors
3. All tests pass
4. No security vulnerabilities found
5. Build succeeds
Verification fails if any critical issue is found.

View File

@@ -0,0 +1,127 @@
---
name: code-simplifier
description: Analyzes and simplifies code without changing behavior
tools:
- Read
- Write
- Edit
- Glob
- Grep
- Bash
---
# Code Simplifier Agent
You are a code simplification specialist. Your goal is to reduce code complexity while maintaining identical behavior.
## Mission
Analyze recently modified files and apply simplification patterns to reduce:
- Line count
- Cyclomatic complexity
- Cognitive load
## Process
### 1. Identify Targets
Find recently modified source files:
```bash
git diff --name-only HEAD~5 | grep -E '\.(ts|tsx|js|jsx|py|go|rs)$'
```
### 2. Analyze Each File
For each target file:
1. Read the entire file
2. Count current lines
3. Identify simplification opportunities
4. Estimate potential reduction
### 3. Apply Simplifications
#### Priority Order
1. **Guard clauses** - Convert nested ifs to early returns
2. **Ternary expressions** - Simple if/else to ternary
3. **Optional chaining** - Replace && chains with ?.
4. **Nullish coalescing** - Replace || with ?? where appropriate
5. **Array methods** - Replace loops with map/filter/reduce
6. **Destructuring** - Extract repeated property access
#### Example Transformations
```typescript
// Guard clause
// Before
function process(user) {
if (user) {
if (user.isActive) {
return doWork(user);
}
}
return null;
}
// After
function process(user) {
if (!user?.isActive) return null;
return doWork(user);
}
```
```typescript
// Array methods
// Before
const results = [];
for (let i = 0; i < items.length; i++) {
if (items[i].valid) {
results.push(items[i].value);
}
}
// After
const results = items.filter(i => i.valid).map(i => i.value);
```
### 4. Verify
After each simplification:
- Ensure no syntax errors
- Behavior must be identical
- Run tests if available
### 5. Report
Generate a summary:
```markdown
## Simplification Report
| File | Before | After | Reduction |
|------|--------|-------|-----------|
| src/utils.ts | 120 | 95 | 21% |
| src/api/client.ts | 85 | 72 | 15% |
### Changes Applied
- 5 guard clauses added
- 3 loops converted to array methods
- 8 optional chaining replacements
### Total: -38 lines (18% reduction)
```
## Rules
1. **Never change public APIs** - Function signatures, exports, interfaces stay identical
2. **Never change behavior** - Same inputs must produce same outputs
3. **Preserve readability** - Sometimes verbose is clearer
4. **One change at a time** - Easier to review and rollback
5. **Skip if uncertain** - Don't simplify if the intent isn't clear
## Limitations
- Don't refactor code you don't understand
- Don't optimize prematurely
- Don't add dependencies to simplify
- Don't change formatting style

View File

@@ -0,0 +1,64 @@
---
description: Read all changed files in current branch to rebuild context after /clear
---
# Catchup - Context Recovery
## Pre-computed Context
**Current Branch:**
!`git branch --show-current`
**Base Branch:**
!`git remote show origin 2>/dev/null | grep "HEAD branch" | cut -d: -f2 | tr -d ' ' || echo "main"`
**Commits Since Branch:**
!`BASE=$(git remote show origin 2>/dev/null | grep "HEAD branch" | cut -d: -f2 | tr -d ' ' || echo "main"); git log --oneline origin/$BASE...HEAD 2>/dev/null || git log --oneline $BASE...HEAD 2>/dev/null | head -15`
**Changed Files:**
!`BASE=$(git remote show origin 2>/dev/null | grep "HEAD branch" | cut -d: -f2 | tr -d ' ' || echo "main"); git diff --name-only origin/$BASE...HEAD 2>/dev/null || git diff --name-only $BASE...HEAD 2>/dev/null`
**Recent Activity (staged + unstaged):**
!`git status --porcelain | head -10`
**HANDOFF.md (if exists):**
!`cat .claude/HANDOFF.md 2>/dev/null || cat HANDOFF.md 2>/dev/null || echo "No HANDOFF.md found"`
---
## Instructions
You are rebuilding context after a `/clear` command. Your goal is to understand what work has been done on this branch.
### 1. Review Commits
Summarize the commits shown above - what feature/fix is being worked on?
### 2. Read Changed Files
Read each changed file to understand the current state of the implementation:
- Use the Read tool for each file in the "Changed Files" list
- Pay attention to new functions, modified logic, and TODOs
### 3. Check HANDOFF.md
If a HANDOFF.md exists, it contains notes from the previous session about:
- Current goal and progress
- Key decisions made
- Next steps to continue
### 4. Summarize Context
Provide a brief summary:
- **Goal**: What is being implemented/fixed
- **Progress**: What's done so far
- **Current State**: Any uncommitted changes
- **Next Steps**: What should be done next
---
## Usage
After running `/clear` to free up context:
```
/workflow:catchup
```
This reads all modified files and reconstructs the context so you can continue working seamlessly.

View File

@@ -0,0 +1,149 @@
---
description: Run typecheck + lint + test combined
argument-hint: [--fix] - Optional flag to auto-fix lint issues
---
# Full Check
## Pre-computed Context
**Package Scripts:**
!`cat package.json 2>/dev/null | grep -E '"(check|typecheck|lint|test|validate)"' | head -8 || echo "No package.json"`
**TypeScript Config:**
!`test -f tsconfig.json && echo "tsconfig.json found" || echo "No tsconfig.json"`
**ESLint Config:**
!`ls .eslintrc* eslint.config.* 2>/dev/null | head -1 || echo "No ESLint config"`
**Python Tools:**
!`cat pyproject.toml 2>/dev/null | grep -E '\[(tool\.)?(mypy|ruff|flake8|pylint)\]' | head -3 || echo "No Python lint config"`
---
## Instructions
You are running a comprehensive check: typecheck, lint, and test in sequence.
### Execution Order
Run checks in this order (stop on first failure unless `--continue` specified):
#### 1. Type Checking
**TypeScript:**
```bash
npx tsc --noEmit
```
**Python (mypy):**
```bash
python -m mypy . 2>/dev/null || echo "mypy not configured"
```
**Python (pyright):**
```bash
npx pyright 2>/dev/null || echo "pyright not configured"
```
#### 2. Linting
**ESLint:**
```bash
npx eslint . --ext .ts,.tsx,.js,.jsx
```
With `--fix` argument:
```bash
npx eslint . --ext .ts,.tsx,.js,.jsx --fix
```
**Python (ruff):**
```bash
ruff check .
```
With fix:
```bash
ruff check --fix .
```
**Python (flake8):**
```bash
flake8 .
```
#### 3. Tests
```bash
npm test
# or
pytest
```
### Using npm Scripts
If the project has a `check` or `validate` script, prefer that:
```bash
npm run check 2>/dev/null || npm run validate 2>/dev/null
```
Common patterns:
```bash
npm run typecheck && npm run lint && npm test
```
### Report Format
```
## Check Results
### TypeScript
[PASS] No type errors
### ESLint
[PASS] No lint errors
# or
[FAIL] 3 errors, 5 warnings
- src/api.ts:15 - @typescript-eslint/no-explicit-any
- src/utils.ts:42 - no-unused-vars
### Tests
[PASS] 45 tests passed
# or
[FAIL] 2 tests failed
- UserService.test.ts > should handle null input
- ApiClient.test.ts > should retry on failure
### Summary
2/3 checks passed
```
### On Failure
If any check fails:
1. Show the specific errors
2. If `--fix` was provided, attempt auto-fixes
3. Re-run the failing check after fixes
4. Report remaining issues
---
## Quick Commands
**Check everything:**
```bash
/workflow:check
```
**Check and auto-fix:**
```bash
/workflow:check --fix
```
**Check specific phase:**
```bash
npx tsc --noEmit # just typecheck
npx eslint . # just lint
npm test # just test
```

View File

@@ -0,0 +1,134 @@
---
description: Remove unused code, imports, and dead code
argument-hint: [path] - Optional path to cleanup (defaults to recent changes)
---
# Code Cleanup
## Pre-computed Context
**Recently Modified Files:**
!`git diff --name-only HEAD~5 2>/dev/null | grep -E '\.(ts|tsx|js|jsx|py)$' | head -15`
**TypeScript Config:**
!`cat tsconfig.json 2>/dev/null | grep -E '"(noUnused|strict)"' | head -5 || echo "No tsconfig.json"`
**ESLint Unused Rules:**
!`cat .eslintrc* eslint.config.* 2>/dev/null | grep -i unused | head -3 || echo "No ESLint config"`
---
## Instructions
You are cleaning up unused code from the codebase.
### What to Remove
#### 1. Unused Imports
```typescript
// Remove these
import { unusedFunction } from './utils'; // never used
import * as _ from 'lodash'; // never used
```
**Detection:**
```bash
# TypeScript/ESLint
npx eslint --rule 'no-unused-vars: error' --rule '@typescript-eslint/no-unused-vars: error' .
# Or use ts-prune for exports
npx ts-prune 2>/dev/null
```
#### 2. Unused Variables
```typescript
// Remove
const unusedConfig = { ... }; // declared but never read
function helper(used, unused) { return used; } // unused parameter
```
#### 3. Dead Code
```typescript
// Remove unreachable code
function process() {
return result;
console.log('never runs'); // dead code
}
// Remove commented-out code
// function oldImplementation() { ... } // delete, use git history
```
#### 4. Unused Exports
```typescript
// If not imported anywhere, consider removing
export function neverImported() { ... }
```
Use `ts-prune` to find unused exports:
```bash
npx ts-prune 2>/dev/null | head -20
```
### Automated Tools
#### ESLint Auto-fix
```bash
npx eslint --fix --rule 'no-unused-vars: error' .
```
#### TypeScript Strict Mode
Enable in tsconfig.json:
```json
{
"compilerOptions": {
"noUnusedLocals": true,
"noUnusedParameters": true
}
}
```
#### Python
```bash
# Find unused imports
autoflake --remove-all-unused-imports --in-place -r . 2>/dev/null
# Or with ruff
ruff check --select F401 --fix . 2>/dev/null
```
### Manual Review
For each file in the target path:
1. Read the file
2. Identify unused:
- Imports at the top
- Variables declared but not used
- Functions defined but not called
- Commented-out code blocks
3. Remove with Edit tool
4. Verify no errors introduced
### Safety Rules
1. **Don't remove exports** that might be used externally (public APIs)
2. **Check for side effects** - some imports run code on load
3. **Preserve intentional unused** - parameters with `_` prefix
4. **Run tests after cleanup** to verify nothing broke
### Report
```
## Cleanup Report
### Removed
- 15 unused imports
- 3 unused variables
- 2 dead code blocks
- 45 lines of commented code
### Files Cleaned
- src/utils.ts: -12 lines
- src/api/client.ts: -8 lines
```

View File

@@ -0,0 +1,124 @@
---
description: Smart git commit with conventional message and emoji
argument-hint: [message] - Optional custom commit message
---
# Smart Commit
## Pre-computed Context
**Branch:**
!`git branch --show-current`
**Staged Files:**
!`git diff --cached --name-only`
**Staged Changes (stat):**
!`git diff --cached --stat`
**Unstaged Changes:**
!`git diff --name-only`
**Recent Commits (style reference):**
!`git log --oneline -5`
---
## Instructions
You are creating a commit with a conventional commit message and appropriate emoji.
### 1. Verify Staged Changes
If no files are staged, suggest staging:
```bash
git add <specific-files>
```
Never use `git add -A` or `git add .` without explicit user approval - these can accidentally stage sensitive files.
### 2. Analyze Changes
Review the staged diff to determine:
- **Type**: What kind of change is this?
- **Scope**: What area of the codebase is affected?
- **Description**: What does this change do?
### 3. Determine Commit Type & Emoji
| Type | Emoji | When to use |
|------|-------|-------------|
| feat | `feat:` | New feature or functionality |
| fix | `fix:` | Bug fix |
| refactor | `refactor:` | Code restructuring without behavior change |
| docs | `docs:` | Documentation only |
| test | `test:` | Adding or updating tests |
| chore | `chore:` | Maintenance, dependencies, config |
| style | `style:` | Formatting, whitespace, semicolons |
| perf | `perf:` | Performance improvement |
### 4. Generate Commit Message
Format:
```
<type>(<scope>): <description>
[optional body - explain WHY, not WHAT]
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
```
Rules:
- Description: imperative mood, lowercase, no period
- Max 72 characters for first line
- Body explains motivation if not obvious
### 5. Execute Commit
If user provided a message argument, use it. Otherwise, use the generated message.
```bash
git commit -m "$(cat <<'EOF'
<type>(<scope>): <description>
<optional body>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
EOF
)"
```
### 6. Verify
Show the commit result:
```bash
git log -1 --stat
```
---
## Examples
**Single file fix:**
```
fix(auth): resolve token refresh race condition
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
```
**New feature:**
```
feat(api): add user preferences endpoint
Allows users to save and retrieve their app preferences.
Includes validation for preference keys.
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
```
**Refactoring:**
```
refactor(utils): simplify date formatting helpers
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
```

View File

@@ -0,0 +1,111 @@
---
description: Run code formatters (prettier, eslint --fix, black, etc.)
argument-hint: [path] - Optional path to format (defaults to .)
---
# Format Code
## Pre-computed Context
**Package.json Scripts:**
!`cat package.json 2>/dev/null | grep -E '"(format|lint|prettier)"' | head -5 || echo "No package.json"`
**Prettier Config:**
!`ls -la .prettierrc* prettier.config.* 2>/dev/null | head -3 || echo "No Prettier config"`
**ESLint Config:**
!`ls -la .eslintrc* eslint.config.* 2>/dev/null | head -3 || echo "No ESLint config"`
**Python Formatters:**
!`ls -la pyproject.toml setup.cfg .flake8 2>/dev/null | head -3 || echo "No Python config"`
**Modified Files:**
!`git diff --name-only | head -10`
---
## Instructions
You are running code formatters on the codebase.
### Detect Stack & Run Formatters
#### JavaScript/TypeScript
Check for and run in order:
1. **npm scripts** (preferred):
```bash
npm run format 2>/dev/null || npm run lint:fix 2>/dev/null
```
2. **Prettier directly**:
```bash
npx prettier --write "**/*.{js,jsx,ts,tsx,json,css,md}" 2>/dev/null
```
3. **ESLint fix**:
```bash
npx eslint --fix . 2>/dev/null
```
#### Python
1. **Black**:
```bash
black . 2>/dev/null || python -m black . 2>/dev/null
```
2. **isort** (import sorting):
```bash
isort . 2>/dev/null || python -m isort . 2>/dev/null
```
3. **Ruff** (fast linter + formatter):
```bash
ruff format . 2>/dev/null
ruff check --fix . 2>/dev/null
```
#### Go
```bash
go fmt ./... 2>/dev/null
goimports -w . 2>/dev/null
```
#### Rust
```bash
cargo fmt 2>/dev/null
```
### Path Argument
If a path argument is provided, format only that path:
```bash
npx prettier --write "$ARGUMENTS"
```
### Report Changes
After formatting, show what changed:
```bash
git diff --stat
```
---
## Common Issues
**Prettier vs ESLint conflicts:**
- Use `eslint-config-prettier` to disable conflicting rules
- Run Prettier first, then ESLint
**Format on save not working:**
- Check VS Code settings: `editor.formatOnSave`
- Verify default formatter is set
**Some files not formatted:**
- Check `.prettierignore` / `.eslintignore`
- Verify file extensions in config

View File

@@ -0,0 +1,68 @@
---
description: Analyze and fix a GitHub issue automatically
argument-hint: <issue-number> - Required issue number to fix
---
# Fix GitHub Issue
## Pre-computed Context
**Issue Details:**
!`gh issue view $ARGUMENTS --json number,title,body,labels,assignees 2>/dev/null || echo "Error: Could not fetch issue $ARGUMENTS. Make sure gh is authenticated and issue exists."`
**Repository Info:**
!`gh repo view --json nameWithOwner,defaultBranchRef -q '"\(.nameWithOwner) (default: \(.defaultBranchRef.name))"' 2>/dev/null || echo "Not a GitHub repository"`
**Current Branch:**
!`git branch --show-current`
**Working Tree Status:**
!`git status --porcelain | head -5`
---
## Instructions
You are fixing GitHub issue #$ARGUMENTS. Follow this workflow:
### 1. Parse Issue
- Extract the problem description from the issue body
- Note any specific files, error messages, or reproduction steps mentioned
- Check labels for context (bug, feature, enhancement, etc.)
### 2. Search Codebase
- Use Grep/Glob to find relevant files mentioned in the issue
- Look for error messages, function names, or keywords from the issue
- Read the most relevant files to understand the context
### 3. Implement Fix
- Make minimal, focused changes to fix the issue
- Follow existing code patterns and style
- Add comments only if the logic isn't self-evident
### 4. Verify
- Run relevant tests if they exist
- Check for type errors: `npx tsc --noEmit` or equivalent
- Ensure the fix addresses all points in the issue
### 5. Create Commit
Create a commit with a message that references the issue:
```
<type>: <description> (closes #$ARGUMENTS)
<optional body explaining the fix>
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
```
Where `<type>` is one of: fix, feat, refactor, docs, test, chore
---
## Important Notes
- If the issue is unclear or needs more information, explain what's missing
- If the issue requires changes outside your scope (infrastructure, external services), explain the limitation
- Always verify your fix works before committing
- Create a focused branch if working on main: `git checkout -b fix/issue-$ARGUMENTS`

View File

@@ -0,0 +1,136 @@
---
description: Quick onboarding for a new project - detect stack and read key files
---
# Project Onboarding
## Pre-computed Context
**Project Root Files:**
!`ls -la | head -20`
**Package.json (if exists):**
!`cat package.json 2>/dev/null | head -30 || echo "No package.json"`
**README (if exists):**
!`head -50 README.md 2>/dev/null || head -50 README 2>/dev/null || echo "No README"`
**Git Info:**
!`git remote -v 2>/dev/null | head -2 && echo "---" && git log --oneline -3 2>/dev/null || echo "Not a git repo"`
---
## Instructions
You are onboarding to a new project. Your goal is to understand the codebase quickly.
### 1. Detect Tech Stack
Look for these indicators:
| File | Stack |
|------|-------|
| `package.json` | Node.js/JavaScript |
| `tsconfig.json` | TypeScript |
| `pyproject.toml`, `requirements.txt` | Python |
| `go.mod` | Go |
| `Cargo.toml` | Rust |
| `pom.xml`, `build.gradle` | Java |
| `Gemfile` | Ruby |
| `composer.json` | PHP |
### 2. Identify Framework
| Indicator | Framework |
|-----------|-----------|
| `next.config.*` | Next.js |
| `vite.config.*` | Vite |
| `angular.json` | Angular |
| `vue.config.*` | Vue |
| `remix.config.*` | Remix |
| `astro.config.*` | Astro |
| `django`, `settings.py` | Django |
| `flask` | Flask |
| `fastapi` | FastAPI |
### 3. Read Key Files
#### Always Read
- `README.md` - Project overview
- `CONTRIBUTING.md` - Development guidelines
- `CLAUDE.md` or `.claude/rules/` - AI assistant instructions
#### JavaScript/TypeScript
- `package.json` - Dependencies and scripts
- `tsconfig.json` - TypeScript configuration
- `src/index.ts` or `src/main.ts` - Entry point
#### Python
- `pyproject.toml` or `setup.py` - Project config
- `requirements.txt` - Dependencies
- `main.py` or `app.py` - Entry point
### 4. Understand Project Structure
```bash
# Show directory structure
find . -type d -not -path '*/node_modules/*' -not -path '*/.git/*' -not -path '*/__pycache__/*' | head -30
```
Common patterns:
- `src/` - Source code
- `tests/` or `__tests__/` - Test files
- `lib/` - Library code
- `docs/` - Documentation
- `scripts/` - Build/utility scripts
### 5. Generate Summary
After analysis, provide:
```markdown
## Project: <name>
### Tech Stack
- **Language**: TypeScript
- **Framework**: Next.js 14
- **Database**: PostgreSQL with Prisma
- **Testing**: Jest + React Testing Library
### Key Directories
- `src/app/` - Next.js app router pages
- `src/components/` - React components
- `src/lib/` - Utility functions
- `prisma/` - Database schema
### Available Scripts
- `npm run dev` - Start development server
- `npm run build` - Build for production
- `npm test` - Run tests
### Quick Start
1. `npm install`
2. `cp .env.example .env`
3. `npm run dev`
### Notes
- Uses App Router (not Pages Router)
- Auth handled by NextAuth.js
- State management with Zustand
```
---
## Usage
When starting work on a new project:
```bash
cd /path/to/new/project
claude
# In Claude:
/workflow:onboard
```
This gives you context to start working effectively.

View File

@@ -0,0 +1,101 @@
---
description: Create a pull request with auto-generated summary from commits
argument-hint: [base-branch] - Optional base branch (defaults to main/master)
---
# Create Pull Request
## Pre-computed Context
**Current Branch:**
!`git branch --show-current`
**Base Branch:**
!`if [ -n "$ARGUMENTS" ]; then echo "$ARGUMENTS"; else git remote show origin 2>/dev/null | grep "HEAD branch" | cut -d: -f2 | tr -d ' ' || echo "main"; fi`
**Remote Tracking:**
!`git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null || echo "No upstream branch"`
**Commits for PR:**
!`BASE=$(if [ -n "$ARGUMENTS" ]; then echo "$ARGUMENTS"; else git remote show origin 2>/dev/null | grep "HEAD branch" | cut -d: -f2 | tr -d ' ' || echo "main"; fi); git log --oneline origin/$BASE...HEAD 2>/dev/null || git log --oneline $BASE...HEAD 2>/dev/null | head -20`
**Files Changed:**
!`BASE=$(if [ -n "$ARGUMENTS" ]; then echo "$ARGUMENTS"; else git remote show origin 2>/dev/null | grep "HEAD branch" | cut -d: -f2 | tr -d ' ' || echo "main"; fi); git diff --stat origin/$BASE...HEAD 2>/dev/null || git diff --stat $BASE...HEAD 2>/dev/null`
**Diff Summary:**
!`BASE=$(if [ -n "$ARGUMENTS" ]; then echo "$ARGUMENTS"; else git remote show origin 2>/dev/null | grep "HEAD branch" | cut -d: -f2 | tr -d ' ' || echo "main"; fi); git diff origin/$BASE...HEAD --shortstat 2>/dev/null || git diff $BASE...HEAD --shortstat 2>/dev/null`
**Working Tree Clean:**
!`git status --porcelain | wc -l | xargs -I{} sh -c 'if [ {} -eq 0 ]; then echo "Yes"; else echo "No - {} uncommitted changes"; fi'`
---
## Instructions
You are creating a pull request for the current branch.
### 1. Pre-flight Checks
Verify before creating PR:
- [ ] Working tree is clean (no uncommitted changes)
- [ ] Branch is pushed to remote
- [ ] There are commits to include in the PR
If branch is not pushed:
```bash
git push -u origin $(git branch --show-current)
```
### 2. Analyze All Commits
Review ALL commits that will be in the PR (not just the latest). Understanding the full scope:
- What feature/fix does this PR implement?
- What are the key changes?
- Are there any breaking changes?
### 3. Generate PR Title
Create a concise title following the pattern:
- `feat: Add user authentication flow`
- `fix: Resolve race condition in data sync`
- `refactor: Simplify error handling logic`
### 4. Generate PR Body
Use this format:
```markdown
## Summary
- [1-3 bullet points describing what this PR does]
## Changes
- [List key changes made]
## Test Plan
- [ ] [How to test this PR]
- [ ] [Additional verification steps]
---
Generated with [Claude Code](https://claude.ai/claude-code)
```
### 5. Create PR
```bash
gh pr create --title "<title>" --body "$(cat <<'EOF'
<body content>
EOF
)"
```
### 6. Report Result
Show the PR URL and summary after creation.
---
## Options
- To create a draft PR, add `--draft` to the gh command
- To assign reviewers: `gh pr create ... --reviewer user1,user2`
- To add labels: `gh pr create ... --label bug,urgent`

View File

@@ -0,0 +1,107 @@
---
description: Push to remote with safety checks
argument-hint: [remote] [branch] - Optional remote and branch (defaults to origin and current branch)
---
# Safe Push
## Pre-computed Context
**Current Branch:**
!`git branch --show-current`
**Upstream Branch:**
!`git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null || echo "No upstream configured"`
**Commits to Push:**
!`git log --oneline @{u}..HEAD 2>/dev/null || echo "No upstream or no commits to push"`
**Local vs Remote:**
!`git status -sb | head -1`
**Uncommitted Changes:**
!`git status --porcelain | wc -l | xargs -I{} sh -c 'if [ {} -eq 0 ]; then echo "Working tree clean"; else echo "{} uncommitted changes"; fi'`
---
## Instructions
You are pushing commits to the remote repository with safety checks.
### 1. Pre-flight Checks
Before pushing, verify:
- [ ] **No uncommitted changes**: Ensure everything is committed
- [ ] **Not pushing to protected branch**: Warn if pushing directly to main/master
- [ ] **Upstream configured**: Set upstream if needed
### 2. Protected Branch Warning
If current branch is `main` or `master`:
```
WARNING: You are pushing directly to the main branch.
Consider creating a feature branch and PR instead.
Continue? [y/N]
```
### 3. Set Upstream (if needed)
If no upstream is configured:
```bash
git push -u origin $(git branch --show-current)
```
### 4. Execute Push
Standard push:
```bash
git push
```
With explicit remote/branch:
```bash
git push origin <branch>
```
### 5. Verify
After push, show status:
```bash
git status -sb
```
---
## Safety Rules
**NEVER run these without explicit user request:**
- `git push --force`
- `git push --force-with-lease`
- `git push -f`
**If push is rejected:**
1. Run `git fetch` to see remote state
2. Explain the divergence
3. Suggest: `git pull --rebase` then push again
4. Only suggest force push if user explicitly asks
---
## Common Scenarios
**First push of new branch:**
```bash
git push -u origin feature/my-branch
```
**Push after rebase (requires user confirmation):**
```bash
# Only with explicit user approval:
git push --force-with-lease
```
**Push to different remote:**
```bash
git push upstream main
```

View File

@@ -0,0 +1,156 @@
---
description: Detect code patterns and suggest improvements
argument-hint: [file-or-pattern] - Optional file or area to focus refactoring on
---
# Refactor
## Pre-computed Context
**Project Structure:**
!`find . -type f -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.py" 2>/dev/null | head -20 | xargs -I{} dirname {} | sort -u | head -10`
**Recent Changes:**
!`git diff --name-only HEAD~10 2>/dev/null | head -15`
**Large Files (potential refactor targets):**
!`find . -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.py" 2>/dev/null | xargs wc -l 2>/dev/null | sort -rn | head -10`
---
## Instructions
You are analyzing code for refactoring opportunities. Focus on improving maintainability without changing behavior.
### Analysis Targets
If argument provided, focus on that file/area. Otherwise, analyze recent changes and large files.
### Patterns to Detect
#### 1. Code Duplication
Look for similar code blocks that could be extracted:
```typescript
// Before: duplicated in multiple places
const userA = await db.query('SELECT * FROM users WHERE id = ?', [idA]);
const userB = await db.query('SELECT * FROM users WHERE id = ?', [idB]);
// After: extracted function
const getUser = (id) => db.query('SELECT * FROM users WHERE id = ?', [id]);
const userA = await getUser(idA);
const userB = await getUser(idB);
```
#### 2. Long Functions
Functions over 50 lines are candidates for splitting:
```typescript
// Before: 100-line function doing multiple things
function processOrder(order) {
// validate (20 lines)
// calculate totals (30 lines)
// apply discounts (25 lines)
// save to database (25 lines)
}
// After: composed smaller functions
function processOrder(order) {
validateOrder(order);
const totals = calculateTotals(order);
const finalPrice = applyDiscounts(totals);
return saveOrder(order, finalPrice);
}
```
#### 3. Deep Nesting
More than 3 levels of nesting hurts readability:
```typescript
// Before: deeply nested
if (user) {
if (user.isActive) {
if (user.hasPermission) {
// do something
}
}
}
// After: early returns
if (!user || !user.isActive || !user.hasPermission) return;
// do something
```
#### 4. Magic Numbers/Strings
Replace with named constants:
```typescript
// Before
if (status === 3) { ... }
setTimeout(fn, 86400000);
// After
const STATUS_COMPLETED = 3;
const ONE_DAY_MS = 24 * 60 * 60 * 1000;
if (status === STATUS_COMPLETED) { ... }
setTimeout(fn, ONE_DAY_MS);
```
#### 5. God Objects/Files
Files doing too much should be split:
- Over 500 lines
- Multiple unrelated responsibilities
- Too many imports from different domains
#### 6. Inconsistent Patterns
Different patterns for the same thing:
```typescript
// Inconsistent: some use async/await, some use .then()
const dataA = await fetchA();
fetchB().then(dataB => { ... });
// Consistent: all async/await
const dataA = await fetchA();
const dataB = await fetchB();
```
### Process
1. **Analyze** - Read target files, identify patterns
2. **Prioritize** - Rank by impact and risk
3. **Propose** - Explain each refactoring opportunity
4. **Implement** - Apply changes if user approves
5. **Verify** - Run tests to ensure no regressions
### Report Format
```
## Refactoring Opportunities
### High Priority
1. **Extract duplicated user fetching** (5 occurrences)
- Files: src/api/*.ts
- Benefit: Remove 45 duplicated lines
2. **Split UserService class** (380 lines)
- Current: handles auth, profile, preferences
- Proposed: UserAuthService, UserProfileService, UserPreferencesService
### Medium Priority
3. **Replace magic numbers in config.ts**
- 12 magic numbers found
### Low Priority
4. **Standardize error handling pattern**
- Mix of try/catch and .catch()
```
---
## Important Notes
- Refactoring should NOT change behavior
- Always run tests after refactoring
- Do one refactoring at a time for easy rollback
- Document why the refactoring improves the code

View File

@@ -0,0 +1,117 @@
---
description: Save current progress to HANDOFF.md before /clear
---
# Save Progress
## Pre-computed Context
**Current Branch:**
!`git branch --show-current`
**Recent Commits:**
!`git log --oneline -5`
**Changed Files (uncommitted):**
!`git status --porcelain | head -10`
**Changed Files (in branch):**
!`BASE=$(git remote show origin 2>/dev/null | grep "HEAD branch" | cut -d: -f2 | tr -d ' ' || echo "main"); git diff --name-only origin/$BASE...HEAD 2>/dev/null | head -10`
**Existing HANDOFF.md:**
!`cat .claude/HANDOFF.md 2>/dev/null || cat HANDOFF.md 2>/dev/null || echo "No existing HANDOFF.md"`
---
## Instructions
You are saving the current work context to a HANDOFF.md file so the next session can continue seamlessly.
### Purpose
Before running `/clear` to free up context, save important information:
- What you were working on
- Progress made
- Decisions and context
- Next steps
### HANDOFF.md Location
Save to `.claude/HANDOFF.md` (create `.claude/` directory if needed):
```bash
mkdir -p .claude
```
### Template
Create/update `.claude/HANDOFF.md` with this structure:
```markdown
# Handoff Document
**Branch:** <current-branch>
**Last Updated:** <timestamp>
**Session Goal:** <what we were trying to accomplish>
## Progress
- [x] Completed task 1
- [x] Completed task 2
- [ ] In progress: task 3
- [ ] Not started: task 4
## Key Decisions
- Decision 1: Why we chose approach A over B
- Decision 2: Important context about the implementation
## Files Modified
- `path/to/file1.ts` - Added feature X
- `path/to/file2.ts` - Fixed bug Y
## Current State
<Brief description of where things stand>
<Any uncommitted work that needs attention>
## Next Steps
1. First thing to do
2. Second thing to do
3. Third thing to do
## Notes
<Any other important context for the next session>
```
### Content Guidelines
1. **Be Specific**: Include file paths, function names, error messages
2. **Explain Why**: Document decisions, not just what was done
3. **List Blockers**: Note anything that prevented progress
4. **Include Context**: Add relevant links, issue numbers, PR URLs
### Workflow
```
# End of session
/workflow:save # Creates HANDOFF.md
/clear # Clears context
# Next session
/workflow:catchup # Reads HANDOFF.md + changed files
```
---
## Do NOT Commit HANDOFF.md
Add to `.gitignore`:
```
.claude/HANDOFF.md
```
HANDOFF.md is for session continuity, not for version control.

View File

@@ -0,0 +1,147 @@
---
description: Simplify code after implementation - reduce complexity without changing behavior
argument-hint: [file-or-pattern] - Optional file path or glob pattern to focus on
---
# Code Simplifier
## Pre-computed Context
**Recently Modified Files:**
!`git diff --name-only HEAD~3 2>/dev/null | grep -E '\.(ts|tsx|js|jsx|py|go|rs)$' | head -10`
**Staged Files:**
!`git diff --cached --name-only | grep -E '\.(ts|tsx|js|jsx|py|go|rs)$' | head -10`
**Changed Lines (recent):**
!`git diff --stat HEAD~3 2>/dev/null | tail -5`
---
## Instructions
You are simplifying recently changed code. The goal is to reduce complexity while maintaining identical behavior.
### Target Files
If argument provided, focus on that file/pattern. Otherwise, use the recently modified files shown above.
### Simplification Patterns
Look for these opportunities:
#### 1. Conditional Simplification
```typescript
// Before
if (condition) {
return true;
} else {
return false;
}
// After
return condition;
```
#### 2. Guard Clauses
```typescript
// Before
function process(data) {
if (data) {
if (data.valid) {
// long logic
}
}
}
// After
function process(data) {
if (!data || !data.valid) return;
// long logic
}
```
#### 3. Optional Chaining
```typescript
// Before
const name = user && user.profile && user.profile.name;
// After
const name = user?.profile?.name;
```
#### 4. Nullish Coalescing
```typescript
// Before
const value = data !== null && data !== undefined ? data : defaultValue;
// After
const value = data ?? defaultValue;
```
#### 5. Array Methods
```typescript
// Before
let result = [];
for (let i = 0; i < items.length; i++) {
if (items[i].active) {
result.push(items[i].name);
}
}
// After
const result = items.filter(i => i.active).map(i => i.name);
```
#### 6. Destructuring
```typescript
// Before
const name = props.name;
const age = props.age;
const email = props.email;
// After
const { name, age, email } = props;
```
### Rules
1. **Do NOT change APIs** - function signatures, exports, and interfaces stay the same
2. **Do NOT change behavior** - output must be identical for all inputs
3. **Keep it readable** - sometimes verbose is clearer; don't over-optimize
4. **Test after changes** - verify nothing broke
### Process
1. Read target files
2. Identify simplification opportunities
3. Apply changes using Edit tool
4. Report summary: lines before vs after
### Report Format
```
## Simplification Report
### File: <path>
- Lines: 150 → 120 (20% reduction)
- Changes:
- Converted 3 if/else to ternary
- Applied guard clauses in 2 functions
- Replaced loop with array methods
### Total
- Files simplified: N
- Lines removed: N
```
---
## Subagent Mode
For larger codebases, spawn a subagent:
```
Use Task tool with subagent_type="general-purpose" to analyze and simplify
multiple files in parallel.
```

View File

@@ -0,0 +1,121 @@
---
description: Pull, rebase, and push in one command
argument-hint: [base-branch] - Optional base branch to sync with (defaults to main)
---
# Sync Branch
## Pre-computed Context
**Current Branch:**
!`git branch --show-current`
**Base Branch:**
!`git remote show origin 2>/dev/null | grep "HEAD branch" | cut -d: -f2 | tr -d ' ' || echo "main"`
**Uncommitted Changes:**
!`git status --porcelain | head -5`
**Behind/Ahead:**
!`git rev-list --left-right --count origin/main...HEAD 2>/dev/null || echo "Unable to compare"`
**Last Sync:**
!`git log -1 --format="%ar" origin/main 2>/dev/null || echo "Unknown"`
---
## Instructions
You are syncing the current branch with the base branch (fetch + rebase + push).
### 1. Pre-flight Check
If there are uncommitted changes:
```
WARNING: You have uncommitted changes.
Options:
1. Commit them first: /workflow:commit
2. Stash them: git stash
3. Discard them: git checkout . (destructive!)
```
### 2. Fetch Latest
```bash
git fetch origin
```
### 3. Rebase on Base Branch
Determine base branch (argument or default to main):
```bash
git rebase origin/main
```
Or if argument provided:
```bash
git rebase origin/$ARGUMENTS
```
### 4. Handle Conflicts
If conflicts occur:
```
Rebase conflict detected in: <files>
Options:
1. Resolve conflicts manually, then: git rebase --continue
2. Abort rebase: git rebase --abort
3. Skip this commit: git rebase --skip
```
Show the conflicting files and help resolve.
### 5. Push Updated Branch
After successful rebase:
```bash
git push --force-with-lease
```
Note: `--force-with-lease` is safe because it only overwrites if remote hasn't changed unexpectedly.
### 6. Report Status
```
Sync complete:
- Rebased X commits on origin/main
- Pushed to origin/<branch>
- Branch is now up to date
```
---
## Common Workflow
```bash
# Start of day: sync your branch
/workflow:sync
# Work on feature...
# ...
# End of day: commit and sync
/workflow:commit
/workflow:sync
```
---
## If Things Go Wrong
**Rebase conflicts too complex:**
```bash
git rebase --abort # Return to pre-rebase state
```
**Pushed wrong thing:**
```bash
git reflog # Find the commit before the mistake
git reset --hard <commit> # Only with user approval!
```

View File

@@ -0,0 +1,145 @@
---
description: Smart test runner - runs tests for changed files only
argument-hint: [pattern] - Optional test pattern or file to run
---
# Smart Test Runner
## Pre-computed Context
**Test Framework Detection:**
!`cat package.json 2>/dev/null | grep -E '"(jest|vitest|mocha|ava|tape)"' | head -3 || echo "No JS test framework"`
**Python Test Framework:**
!`cat pyproject.toml setup.cfg 2>/dev/null | grep -E '(pytest|unittest|nose)' | head -3 || echo "No Python test framework"`
**Test Scripts:**
!`cat package.json 2>/dev/null | grep -E '"test' | head -5 || echo "No test scripts"`
**Changed Files:**
!`git diff --name-only HEAD~3 2>/dev/null | head -10`
**Related Test Files:**
!`git diff --name-only HEAD~3 2>/dev/null | sed 's/\.\(ts\|tsx\|js\|jsx\)$/.test.\1/' | xargs -I{} sh -c 'test -f {} && echo {}' 2>/dev/null | head -5`
---
## Instructions
You are running tests intelligently - focusing on changed files when possible.
### Detect Test Framework
#### JavaScript/TypeScript
1. **Jest**
```bash
npx jest --passWithNoTests
```
2. **Vitest**
```bash
npx vitest run
```
3. **npm test script**
```bash
npm test
```
#### Python
1. **pytest**
```bash
pytest -v
```
2. **unittest**
```bash
python -m unittest discover
```
### Smart Test Selection
If no argument provided, run tests related to changed files:
#### Jest - Run related tests
```bash
npx jest --findRelatedTests $(git diff --name-only HEAD~3 | tr '\n' ' ')
```
#### Jest - Run changed test files only
```bash
npx jest --testPathPattern="$(git diff --name-only HEAD~3 | grep -E '\.test\.(ts|tsx|js|jsx)$' | tr '\n' '|' | sed 's/|$//')"
```
#### Vitest - Run changed
```bash
npx vitest run --changed HEAD~3
```
#### pytest - Run specific files
```bash
pytest $(git diff --name-only HEAD~3 | grep -E '_test\.py$|test_.*\.py$' | tr '\n' ' ')
```
### With Pattern Argument
If argument provided, run tests matching that pattern:
```bash
# Jest
npx jest --testPathPattern="$ARGUMENTS"
# Vitest
npx vitest run "$ARGUMENTS"
# pytest
pytest -k "$ARGUMENTS"
```
### Test Output
Show test results with appropriate verbosity:
```bash
# Jest with coverage
npx jest --coverage --passWithNoTests
# pytest verbose
pytest -v --tb=short
```
### On Failure
If tests fail:
1. Show the failing test names
2. Show the error messages
3. Identify the source file that likely caused the failure
4. Suggest fix or ask if you should investigate
---
## Common Options
**Run all tests:**
```bash
/workflow:test --all
```
**Run with coverage:**
```bash
/workflow:test --coverage
```
**Run in watch mode:**
```bash
npx jest --watch
# or
npx vitest
```
**Run specific test file:**
```bash
/workflow:test src/utils.test.ts
```

View File

@@ -0,0 +1,114 @@
---
description: End-to-end verification of implementation using subagent
argument-hint: [scope] - Optional scope (e.g., "auth flow", "api endpoints")
---
# Verify Implementation
## Pre-computed Context
**Changed Files:**
!`git diff --name-only HEAD~5 2>/dev/null | head -20 || git diff --name-only --cached`
**Recent Commits:**
!`git log --oneline -5`
**Package Scripts:**
!`cat package.json 2>/dev/null | grep -A 20 '"scripts"' | head -25 || echo "No package.json"`
**Test Files:**
!`find . -name "*.test.*" -o -name "*.spec.*" 2>/dev/null | head -10 || echo "No test files found"`
---
## Instructions
You are performing end-to-end verification of recent changes. This is a thorough check before committing or creating a PR.
### Verification Checklist
#### 1. Static Analysis
Run available linters and type checkers:
```bash
# TypeScript
npx tsc --noEmit 2>/dev/null || echo "No TypeScript"
# ESLint
npx eslint . --ext .ts,.tsx,.js,.jsx 2>/dev/null || echo "No ESLint"
# For Python
python -m mypy . 2>/dev/null || echo "No mypy"
ruff check . 2>/dev/null || echo "No ruff"
```
#### 2. Unit Tests
Run tests for changed files:
```bash
# Jest
npx jest --passWithNoTests 2>/dev/null || echo "No Jest"
# Vitest
npx vitest run 2>/dev/null || echo "No Vitest"
# pytest
pytest 2>/dev/null || echo "No pytest"
```
#### 3. Build Verification
Ensure the project builds:
```bash
npm run build 2>/dev/null || yarn build 2>/dev/null || echo "No build script"
```
#### 4. Manual Code Review
For each changed file, verify:
- [ ] No hardcoded secrets or credentials
- [ ] Error handling is present where needed
- [ ] No obvious security vulnerabilities (SQL injection, XSS, etc.)
- [ ] Code follows existing patterns in the codebase
#### 5. Integration Check
If the scope argument is provided, focus verification on that area:
- Read related files
- Trace the data flow
- Verify edge cases are handled
### Report
After verification, provide a summary:
```
## Verification Report
### Passed
- [x] TypeScript compilation
- [x] Unit tests (X passed)
- [x] Build successful
### Issues Found
- [ ] Issue 1: description
- [ ] Issue 2: description
### Recommendations
- Suggestion 1
- Suggestion 2
```
---
## Subagent Mode
For comprehensive verification, this command can spawn a verification subagent:
```
Use the Task tool with subagent_type="general-purpose" to:
1. Read all changed files
2. Run all available test suites
3. Check for common issues
4. Report findings
```
The subagent has access to Bash, Read, Grep, and Glob tools to perform thorough verification.

View File

@@ -0,0 +1,93 @@
# Commit Message Template
## Format
```
<type>(<scope>): <description>
[optional body]
[optional footer]
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
```
## Types
| Type | Description | Emoji |
|------|-------------|-------|
| `feat` | New feature | n/a |
| `fix` | Bug fix | n/a |
| `docs` | Documentation only | n/a |
| `style` | Formatting, missing semicolons | n/a |
| `refactor` | Code change that neither fixes a bug nor adds a feature | n/a |
| `perf` | Performance improvement | n/a |
| `test` | Adding missing tests | n/a |
| `chore` | Maintenance tasks | n/a |
| `ci` | CI configuration | n/a |
| `build` | Build system or dependencies | n/a |
| `revert` | Reverts a previous commit | n/a |
## Scope
The scope is optional and should be the affected area:
- `auth` - Authentication
- `api` - API routes
- `ui` - User interface
- `db` - Database
- `config` - Configuration
- etc.
## Description Rules
1. Use imperative mood: "add" not "added" or "adds"
2. Lowercase first letter
3. No period at the end
4. Max 50 characters
## Body Rules
1. Separated from subject by a blank line
2. Explain "why" not "what"
3. Wrap at 72 characters
## Footer Rules
Used for:
- `BREAKING CHANGE: description` - Breaking changes
- `Closes #123` - Issue references
- `Refs #456` - Related issues
## Examples
### Simple fix
```
fix(auth): resolve token refresh race condition
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
```
### Feature with body
```
feat(api): add user preferences endpoint
Allows users to save and retrieve their app preferences.
Includes validation for preference keys and values.
Closes #42
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
```
### Breaking change
```
refactor(api)!: change response format for /users endpoint
BREAKING CHANGE: The /users endpoint now returns an object with
a `data` array instead of a direct array.
Before: [{ id: 1 }, { id: 2 }]
After: { data: [{ id: 1 }, { id: 2 }], meta: { total: 2 } }
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
```

View File

@@ -0,0 +1,130 @@
# Handoff Template
Use this template when saving progress with `/workflow:save`.
---
```markdown
# Handoff Document
**Branch:** [branch-name]
**Last Updated:** [YYYY-MM-DD HH:MM]
**Goal:** [What we're trying to accomplish]
---
## Progress
### Completed
- [x] Task 1: Brief description
- [x] Task 2: Brief description
### In Progress
- [ ] Task 3: Brief description
- Started: [what's done]
- Remaining: [what's left]
### Not Started
- [ ] Task 4: Brief description
- [ ] Task 5: Brief description
---
## Key Decisions
### Decision 1: [Title]
**Context:** Why this decision was needed
**Choice:** What was decided
**Rationale:** Why this option was chosen
### Decision 2: [Title]
**Context:** ...
**Choice:** ...
**Rationale:** ...
---
## Files Modified
| File | Changes |
|------|---------|
| `path/to/file1.ts` | Added feature X |
| `path/to/file2.ts` | Fixed bug Y |
| `path/to/file3.ts` | Refactored Z |
---
## Current State
### Working
- Feature A is functional
- Tests pass
### Not Working
- Feature B has a bug in edge case
- Test for C is flaky
### Uncommitted Changes
```
M src/utils.ts
M src/api/client.ts
?? src/new-file.ts
```
---
## Blockers
- [ ] Blocker 1: Description and what's needed to unblock
- [ ] Blocker 2: Description
---
## Next Steps
1. **Immediate**: First thing to do when resuming
2. **Then**: Second priority
3. **Later**: Can be done after main task
---
## Notes
### Important Context
- Note 1: Something important to remember
- Note 2: A gotcha or edge case
### Links
- Issue: #123
- PR: #456
- Docs: https://...
### Questions for User
- Question 1?
- Question 2?
```
---
## Minimal Handoff
For quick saves:
```markdown
# Handoff
**Branch:** feature/xyz
**Goal:** Implement user preferences
## Done
- [x] Database schema
- [x] API endpoint
## Next
1. Add frontend form
2. Write tests
## Notes
- Using Zustand for state (user preference)
- Validation schema in src/lib/validators.ts
```

View File

@@ -0,0 +1,122 @@
# Pull Request Template
## Title Format
```
<type>: <description>
```
Examples:
- `feat: Add user authentication flow`
- `fix: Resolve data sync race condition`
- `refactor: Simplify error handling in API client`
---
## Body Template
```markdown
## Summary
Brief description of what this PR does and why.
- Key change 1
- Key change 2
- Key change 3
## Changes
### Added
- New feature or file
### Changed
- Modified behavior or file
### Removed
- Deleted feature or file
### Fixed
- Bug that was fixed
## Screenshots
If applicable, add screenshots or recordings.
## Test Plan
- [ ] Unit tests added/updated
- [ ] Manual testing completed
- [ ] Edge cases verified
### How to Test
1. Step 1
2. Step 2
3. Step 3
## Checklist
- [ ] Code follows project style guidelines
- [ ] Self-review completed
- [ ] Comments added for complex logic
- [ ] Documentation updated (if needed)
- [ ] No new warnings introduced
- [ ] Tests pass locally
## Related Issues
- Closes #123
- Refs #456
---
Generated with [Claude Code](https://claude.ai/claude-code)
```
---
## Minimal Template
For small changes:
```markdown
## Summary
- [One line description]
## Test Plan
- [ ] [How you verified this works]
---
Generated with [Claude Code](https://claude.ai/claude-code)
```
---
## Draft PR Template
For work in progress:
```markdown
## WIP: [Feature Name]
### Done
- [x] Task 1
- [x] Task 2
### In Progress
- [ ] Task 3
### Blocked
- [ ] Task 4 (waiting on X)
### Questions
- Question 1?
- Question 2?
---
Generated with [Claude Code](https://claude.ai/claude-code)
```