mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-03-30 13:43:26 +08:00
feat(ecc): prune plugin 43→12 items, promote 7 rules to .claude/rules/ (#245)
ECC community plugin pruning: removed 530+ non-essential files (.cursor/, .opencode/, docs/ja-JP, docs/zh-CN, docs/zh-TW, language-specific skills/agents/rules). Retained 4 agents, 3 commands, 5 skills. Promoted 13 rule files (8 common + 5 typescript) to .claude/rules/ for CC native loading. Extracted reusable patterns to EXTRACTED-PATTERNS.md.
This commit is contained in:
park-kyungchan
@@ -1,56 +0,0 @@
|
||||
---
|
||||
description: Fix build and TypeScript errors with minimal changes
|
||||
agent: build-error-resolver
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Build Fix Command
|
||||
|
||||
Fix build and TypeScript errors with minimal changes: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
1. **Run type check**: `npx tsc --noEmit`
|
||||
2. **Collect all errors**
|
||||
3. **Fix errors one by one** with minimal changes
|
||||
4. **Verify each fix** doesn't introduce new errors
|
||||
5. **Run final check** to confirm all errors resolved
|
||||
|
||||
## Approach
|
||||
|
||||
### DO:
|
||||
- ✅ Fix type errors with correct types
|
||||
- ✅ Add missing imports
|
||||
- ✅ Fix syntax errors
|
||||
- ✅ Make minimal changes
|
||||
- ✅ Preserve existing behavior
|
||||
- ✅ Run `tsc --noEmit` after each change
|
||||
|
||||
### DON'T:
|
||||
- ❌ Refactor code
|
||||
- ❌ Add new features
|
||||
- ❌ Change architecture
|
||||
- ❌ Use `any` type (unless absolutely necessary)
|
||||
- ❌ Add `@ts-ignore` comments
|
||||
- ❌ Change business logic
|
||||
|
||||
## Common Error Fixes
|
||||
|
||||
| Error | Fix |
|
||||
|-------|-----|
|
||||
| Type 'X' is not assignable to type 'Y' | Add correct type annotation |
|
||||
| Property 'X' does not exist | Add property to interface or fix property name |
|
||||
| Cannot find module 'X' | Install package or fix import path |
|
||||
| Argument of type 'X' is not assignable | Cast or fix function signature |
|
||||
| Object is possibly 'undefined' | Add null check or optional chaining |
|
||||
|
||||
## Verification Steps
|
||||
|
||||
After fixes:
|
||||
1. `npx tsc --noEmit` - should show 0 errors
|
||||
2. `npm run build` - should succeed
|
||||
3. `npm test` - tests should still pass
|
||||
|
||||
---
|
||||
|
||||
**IMPORTANT**: Focus on fixing errors only. No refactoring, no improvements, no architectural changes. Get the build green with minimal diff.
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
description: Save verification state and progress checkpoint
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Checkpoint Command
|
||||
|
||||
Save current verification state and create progress checkpoint: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Create a snapshot of current progress including:
|
||||
|
||||
1. **Tests status** - Which tests pass/fail
|
||||
2. **Coverage** - Current coverage metrics
|
||||
3. **Build status** - Build succeeds or errors
|
||||
4. **Code changes** - Summary of modifications
|
||||
5. **Next steps** - What remains to be done
|
||||
|
||||
## Checkpoint Format
|
||||
|
||||
### Checkpoint: [Timestamp]
|
||||
|
||||
**Tests**
|
||||
- Total: X
|
||||
- Passing: Y
|
||||
- Failing: Z
|
||||
- Coverage: XX%
|
||||
|
||||
**Build**
|
||||
- Status: ✅ Passing / ❌ Failing
|
||||
- Errors: [if any]
|
||||
|
||||
**Changes Since Last Checkpoint**
|
||||
```
|
||||
git diff --stat [last-checkpoint-commit]
|
||||
```
|
||||
|
||||
**Completed Tasks**
|
||||
- [x] Task 1
|
||||
- [x] Task 2
|
||||
- [ ] Task 3 (in progress)
|
||||
|
||||
**Blocking Issues**
|
||||
- [Issue description]
|
||||
|
||||
**Next Steps**
|
||||
1. Step 1
|
||||
2. Step 2
|
||||
|
||||
## Usage with Verification Loop
|
||||
|
||||
Checkpoints integrate with the verification loop:
|
||||
|
||||
```
|
||||
/plan → implement → /checkpoint → /verify → /checkpoint → implement → ...
|
||||
```
|
||||
|
||||
Use checkpoints to:
|
||||
- Save state before risky changes
|
||||
- Track progress through phases
|
||||
- Enable rollback if needed
|
||||
- Document verification points
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Create checkpoints at natural breakpoints: after each phase, before major refactoring, after fixing critical bugs.
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
description: Review code for quality, security, and maintainability
|
||||
agent: code-reviewer
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Code Review Command
|
||||
|
||||
Review code changes for quality, security, and maintainability: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
1. **Get changed files**: Run `git diff --name-only HEAD`
|
||||
2. **Analyze each file** for issues
|
||||
3. **Generate structured report**
|
||||
4. **Provide actionable recommendations**
|
||||
|
||||
## Check Categories
|
||||
|
||||
### Security Issues (CRITICAL)
|
||||
- [ ] Hardcoded credentials, API keys, tokens
|
||||
- [ ] SQL injection vulnerabilities
|
||||
- [ ] XSS vulnerabilities
|
||||
- [ ] Missing input validation
|
||||
- [ ] Insecure dependencies
|
||||
- [ ] Path traversal risks
|
||||
- [ ] Authentication/authorization flaws
|
||||
|
||||
### Code Quality (HIGH)
|
||||
- [ ] Functions > 50 lines
|
||||
- [ ] Files > 800 lines
|
||||
- [ ] Nesting depth > 4 levels
|
||||
- [ ] Missing error handling
|
||||
- [ ] console.log statements
|
||||
- [ ] TODO/FIXME comments
|
||||
- [ ] Missing JSDoc for public APIs
|
||||
|
||||
### Best Practices (MEDIUM)
|
||||
- [ ] Mutation patterns (use immutable instead)
|
||||
- [ ] Unnecessary complexity
|
||||
- [ ] Missing tests for new code
|
||||
- [ ] Accessibility issues (a11y)
|
||||
- [ ] Performance concerns
|
||||
|
||||
### Style (LOW)
|
||||
- [ ] Inconsistent naming
|
||||
- [ ] Missing type annotations
|
||||
- [ ] Formatting issues
|
||||
|
||||
## Report Format
|
||||
|
||||
For each issue found:
|
||||
|
||||
```
|
||||
**[SEVERITY]** file.ts:123
|
||||
Issue: [Description]
|
||||
Fix: [How to fix]
|
||||
```
|
||||
|
||||
## Decision
|
||||
|
||||
- **CRITICAL or HIGH issues**: Block commit, require fixes
|
||||
- **MEDIUM issues**: Recommend fixes before merge
|
||||
- **LOW issues**: Optional improvements
|
||||
|
||||
---
|
||||
|
||||
**IMPORTANT**: Never approve code with security vulnerabilities!
|
||||
@@ -1,105 +0,0 @@
|
||||
---
|
||||
description: Generate and run E2E tests with Playwright
|
||||
agent: e2e-runner
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# E2E Command
|
||||
|
||||
Generate and run end-to-end tests using Playwright: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
1. **Analyze user flow** to test
|
||||
2. **Create test journey** with Playwright
|
||||
3. **Run tests** and capture artifacts
|
||||
4. **Report results** with screenshots/videos
|
||||
|
||||
## Test Structure
|
||||
|
||||
```typescript
|
||||
import { test, expect } from '@playwright/test'
|
||||
|
||||
test.describe('Feature: [Name]', () => {
|
||||
test.beforeEach(async ({ page }) => {
|
||||
// Setup: Navigate, authenticate, prepare state
|
||||
})
|
||||
|
||||
test('should [expected behavior]', async ({ page }) => {
|
||||
// Arrange: Set up test data
|
||||
|
||||
// Act: Perform user actions
|
||||
await page.click('[data-testid="button"]')
|
||||
await page.fill('[data-testid="input"]', 'value')
|
||||
|
||||
// Assert: Verify results
|
||||
await expect(page.locator('[data-testid="result"]')).toBeVisible()
|
||||
})
|
||||
|
||||
test.afterEach(async ({ page }, testInfo) => {
|
||||
// Capture screenshot on failure
|
||||
if (testInfo.status !== 'passed') {
|
||||
await page.screenshot({ path: `test-results/${testInfo.title}.png` })
|
||||
}
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Selectors
|
||||
- Prefer `data-testid` attributes
|
||||
- Avoid CSS classes (they change)
|
||||
- Use semantic selectors (roles, labels)
|
||||
|
||||
### Waits
|
||||
- Use Playwright's auto-waiting
|
||||
- Avoid `page.waitForTimeout()`
|
||||
- Use `expect().toBeVisible()` for assertions
|
||||
|
||||
### Test Isolation
|
||||
- Each test should be independent
|
||||
- Clean up test data after
|
||||
- Don't rely on test order
|
||||
|
||||
## Artifacts to Capture
|
||||
|
||||
- Screenshots on failure
|
||||
- Videos for debugging
|
||||
- Trace files for detailed analysis
|
||||
- Network logs if relevant
|
||||
|
||||
## Test Categories
|
||||
|
||||
1. **Critical User Flows**
|
||||
- Authentication (login, logout, signup)
|
||||
- Core feature happy paths
|
||||
- Payment/checkout flows
|
||||
|
||||
2. **Edge Cases**
|
||||
- Network failures
|
||||
- Invalid inputs
|
||||
- Session expiry
|
||||
|
||||
3. **Cross-Browser**
|
||||
- Chrome, Firefox, Safari
|
||||
- Mobile viewports
|
||||
|
||||
## Report Format
|
||||
|
||||
```
|
||||
E2E Test Results
|
||||
================
|
||||
✅ Passed: X
|
||||
❌ Failed: Y
|
||||
⏭️ Skipped: Z
|
||||
|
||||
Failed Tests:
|
||||
- test-name: Error message
|
||||
Screenshot: path/to/screenshot.png
|
||||
Video: path/to/video.webm
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Run with `--headed` flag for debugging: `npx playwright test --headed`
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
description: Run evaluation against acceptance criteria
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Eval Command
|
||||
|
||||
Evaluate implementation against acceptance criteria: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Run structured evaluation to verify the implementation meets requirements.
|
||||
|
||||
## Evaluation Framework
|
||||
|
||||
### Grader Types
|
||||
|
||||
1. **Binary Grader** - Pass/Fail
|
||||
- Does it work? Yes/No
|
||||
- Good for: feature completion, bug fixes
|
||||
|
||||
2. **Scalar Grader** - Score 0-100
|
||||
- How well does it work?
|
||||
- Good for: performance, quality metrics
|
||||
|
||||
3. **Rubric Grader** - Category scores
|
||||
- Multiple dimensions evaluated
|
||||
- Good for: comprehensive review
|
||||
|
||||
## Evaluation Process
|
||||
|
||||
### Step 1: Define Criteria
|
||||
|
||||
```
|
||||
Acceptance Criteria:
|
||||
1. [Criterion 1] - [weight]
|
||||
2. [Criterion 2] - [weight]
|
||||
3. [Criterion 3] - [weight]
|
||||
```
|
||||
|
||||
### Step 2: Run Tests
|
||||
|
||||
For each criterion:
|
||||
- Execute relevant test
|
||||
- Collect evidence
|
||||
- Score result
|
||||
|
||||
### Step 3: Calculate Score
|
||||
|
||||
```
|
||||
Final Score = Σ (criterion_score × weight) / total_weight
|
||||
```
|
||||
|
||||
### Step 4: Report
|
||||
|
||||
## Evaluation Report
|
||||
|
||||
### Overall: [PASS/FAIL] (Score: X/100)
|
||||
|
||||
### Criterion Breakdown
|
||||
|
||||
| Criterion | Score | Weight | Weighted |
|
||||
|-----------|-------|--------|----------|
|
||||
| [Criterion 1] | X/10 | 30% | X |
|
||||
| [Criterion 2] | X/10 | 40% | X |
|
||||
| [Criterion 3] | X/10 | 30% | X |
|
||||
|
||||
### Evidence
|
||||
|
||||
**Criterion 1: [Name]**
|
||||
- Test: [what was tested]
|
||||
- Result: [outcome]
|
||||
- Evidence: [screenshot, log, output]
|
||||
|
||||
### Recommendations
|
||||
|
||||
[If not passing, what needs to change]
|
||||
|
||||
## Pass@K Metrics
|
||||
|
||||
For non-deterministic evaluations:
|
||||
- Run K times
|
||||
- Calculate pass rate
|
||||
- Report: "Pass@K = X/K"
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Use eval for acceptance testing before marking features complete.
|
||||
@@ -1,112 +0,0 @@
|
||||
---
|
||||
description: Cluster instincts into skills
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Evolve Command
|
||||
|
||||
Cluster related instincts into structured skills: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Analyze instincts and promote clusters to skills.
|
||||
|
||||
## Evolution Process
|
||||
|
||||
### Step 1: Analyze Instincts
|
||||
|
||||
Group instincts by:
|
||||
- Trigger similarity
|
||||
- Action patterns
|
||||
- Category tags
|
||||
- Confidence levels
|
||||
|
||||
### Step 2: Identify Clusters
|
||||
|
||||
```
|
||||
Cluster: Error Handling
|
||||
├── Instinct: Catch specific errors (0.85)
|
||||
├── Instinct: Wrap errors with context (0.82)
|
||||
├── Instinct: Log errors with stack trace (0.78)
|
||||
└── Instinct: Return meaningful error messages (0.80)
|
||||
```
|
||||
|
||||
### Step 3: Generate Skill
|
||||
|
||||
When cluster has:
|
||||
- 3+ instincts
|
||||
- Average confidence > 0.75
|
||||
- Cohesive theme
|
||||
|
||||
Generate SKILL.md:
|
||||
|
||||
```markdown
|
||||
# Error Handling Skill
|
||||
|
||||
## Overview
|
||||
Patterns for robust error handling learned from session observations.
|
||||
|
||||
## Patterns
|
||||
|
||||
### 1. Catch Specific Errors
|
||||
**Trigger**: When catching errors with generic catch
|
||||
**Action**: Use specific error types
|
||||
|
||||
### 2. Wrap Errors with Context
|
||||
**Trigger**: When re-throwing errors
|
||||
**Action**: Add context with fmt.Errorf or Error.cause
|
||||
|
||||
### 3. Log with Stack Trace
|
||||
**Trigger**: When logging errors
|
||||
**Action**: Include stack trace for debugging
|
||||
|
||||
### 4. Meaningful Messages
|
||||
**Trigger**: When returning errors to users
|
||||
**Action**: Provide actionable error messages
|
||||
```
|
||||
|
||||
### Step 4: Archive Instincts
|
||||
|
||||
Move evolved instincts to `archived/` with reference to skill.
|
||||
|
||||
## Evolution Report
|
||||
|
||||
```
|
||||
Evolution Summary
|
||||
=================
|
||||
|
||||
Clusters Found: X
|
||||
|
||||
Cluster 1: Error Handling
|
||||
- Instincts: 5
|
||||
- Avg Confidence: 0.82
|
||||
- Status: ✅ Promoted to skill
|
||||
|
||||
Cluster 2: Testing Patterns
|
||||
- Instincts: 3
|
||||
- Avg Confidence: 0.71
|
||||
- Status: ⏳ Needs more confidence
|
||||
|
||||
Cluster 3: Git Workflow
|
||||
- Instincts: 2
|
||||
- Avg Confidence: 0.88
|
||||
- Status: ⏳ Needs more instincts
|
||||
|
||||
Skills Created:
|
||||
- skills/error-handling/SKILL.md
|
||||
|
||||
Instincts Archived: 5
|
||||
Remaining Instincts: 12
|
||||
```
|
||||
|
||||
## Thresholds
|
||||
|
||||
| Metric | Threshold |
|
||||
|--------|-----------|
|
||||
| Min instincts per cluster | 3 |
|
||||
| Min average confidence | 0.75 |
|
||||
| Min cluster cohesion | 0.6 |
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Run `/evolve` periodically to graduate instincts to skills as confidence grows.
|
||||
@@ -1,87 +0,0 @@
|
||||
---
|
||||
description: Fix Go build and vet errors
|
||||
agent: go-build-resolver
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Go Build Command
|
||||
|
||||
Fix Go build, vet, and compilation errors: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
1. **Run go build**: `go build ./...`
|
||||
2. **Run go vet**: `go vet ./...`
|
||||
3. **Fix errors** one by one
|
||||
4. **Verify fixes** don't introduce new errors
|
||||
|
||||
## Common Go Errors
|
||||
|
||||
### Import Errors
|
||||
```
|
||||
imported and not used: "package"
|
||||
```
|
||||
**Fix**: Remove unused import or use `_` prefix
|
||||
|
||||
### Type Errors
|
||||
```
|
||||
cannot use x (type T) as type U
|
||||
```
|
||||
**Fix**: Add type conversion or fix type definition
|
||||
|
||||
### Undefined Errors
|
||||
```
|
||||
undefined: identifier
|
||||
```
|
||||
**Fix**: Import package, define variable, or fix typo
|
||||
|
||||
### Vet Errors
|
||||
```
|
||||
printf: call has arguments but no formatting directives
|
||||
```
|
||||
**Fix**: Add format directive or remove arguments
|
||||
|
||||
## Fix Order
|
||||
|
||||
1. **Import errors** - Fix or remove imports
|
||||
2. **Type definitions** - Ensure types exist
|
||||
3. **Function signatures** - Match parameters
|
||||
4. **Vet warnings** - Address static analysis
|
||||
|
||||
## Build Commands
|
||||
|
||||
```bash
|
||||
# Build all packages
|
||||
go build ./...
|
||||
|
||||
# Build with race detector
|
||||
go build -race ./...
|
||||
|
||||
# Build for specific OS/arch
|
||||
GOOS=linux GOARCH=amd64 go build ./...
|
||||
|
||||
# Run go vet
|
||||
go vet ./...
|
||||
|
||||
# Run staticcheck
|
||||
staticcheck ./...
|
||||
|
||||
# Format code
|
||||
gofmt -w .
|
||||
|
||||
# Tidy dependencies
|
||||
go mod tidy
|
||||
```
|
||||
|
||||
## Verification
|
||||
|
||||
After fixes:
|
||||
```bash
|
||||
go build ./... # Should succeed
|
||||
go vet ./... # Should have no warnings
|
||||
go test ./... # Tests should pass
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**IMPORTANT**: Fix errors only. No refactoring, no improvements. Get the build green with minimal changes.
|
||||
@@ -1,71 +0,0 @@
|
||||
---
|
||||
description: Go code review for idiomatic patterns
|
||||
agent: go-reviewer
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Go Review Command
|
||||
|
||||
Review Go code for idiomatic patterns and best practices: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
1. **Analyze Go code** for idioms and patterns
|
||||
2. **Check concurrency** - goroutines, channels, mutexes
|
||||
3. **Review error handling** - proper error wrapping
|
||||
4. **Verify performance** - allocations, bottlenecks
|
||||
|
||||
## Review Checklist
|
||||
|
||||
### Idiomatic Go
|
||||
- [ ] Package naming (lowercase, no underscores)
|
||||
- [ ] Variable naming (camelCase, short)
|
||||
- [ ] Interface naming (ends with -er)
|
||||
- [ ] Error naming (starts with Err)
|
||||
|
||||
### Error Handling
|
||||
- [ ] Errors are checked, not ignored
|
||||
- [ ] Errors wrapped with context (`fmt.Errorf("...: %w", err)`)
|
||||
- [ ] Sentinel errors used appropriately
|
||||
- [ ] Custom error types when needed
|
||||
|
||||
### Concurrency
|
||||
- [ ] Goroutines properly managed
|
||||
- [ ] Channels buffered appropriately
|
||||
- [ ] No data races (use `-race` flag)
|
||||
- [ ] Context passed for cancellation
|
||||
- [ ] WaitGroups used correctly
|
||||
|
||||
### Performance
|
||||
- [ ] Avoid unnecessary allocations
|
||||
- [ ] Use `sync.Pool` for frequent allocations
|
||||
- [ ] Prefer value receivers for small structs
|
||||
- [ ] Buffer I/O operations
|
||||
|
||||
### Code Organization
|
||||
- [ ] Small, focused packages
|
||||
- [ ] Clear dependency direction
|
||||
- [ ] Internal packages for private code
|
||||
- [ ] Godoc comments on exports
|
||||
|
||||
## Report Format
|
||||
|
||||
### Idiomatic Issues
|
||||
- [file:line] Issue description
|
||||
Suggestion: How to fix
|
||||
|
||||
### Error Handling Issues
|
||||
- [file:line] Issue description
|
||||
Suggestion: How to fix
|
||||
|
||||
### Concurrency Issues
|
||||
- [file:line] Issue description
|
||||
Suggestion: How to fix
|
||||
|
||||
### Performance Issues
|
||||
- [file:line] Issue description
|
||||
Suggestion: How to fix
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Run `go vet` and `staticcheck` for additional automated checks.
|
||||
@@ -1,131 +0,0 @@
|
||||
---
|
||||
description: Go TDD workflow with table-driven tests
|
||||
agent: tdd-guide
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Go Test Command
|
||||
|
||||
Implement using Go TDD methodology: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Apply test-driven development with Go idioms:
|
||||
|
||||
1. **Define types** - Interfaces and structs
|
||||
2. **Write table-driven tests** - Comprehensive coverage
|
||||
3. **Implement minimal code** - Pass the tests
|
||||
4. **Benchmark** - Verify performance
|
||||
|
||||
## TDD Cycle for Go
|
||||
|
||||
### Step 1: Define Interface
|
||||
```go
|
||||
type Calculator interface {
|
||||
Calculate(input Input) (Output, error)
|
||||
}
|
||||
|
||||
type Input struct {
|
||||
// fields
|
||||
}
|
||||
|
||||
type Output struct {
|
||||
// fields
|
||||
}
|
||||
```
|
||||
|
||||
### Step 2: Table-Driven Tests
|
||||
```go
|
||||
func TestCalculate(t *testing.T) {
|
||||
tests := []struct {
|
||||
name string
|
||||
input Input
|
||||
want Output
|
||||
wantErr bool
|
||||
}{
|
||||
{
|
||||
name: "valid input",
|
||||
input: Input{...},
|
||||
want: Output{...},
|
||||
},
|
||||
{
|
||||
name: "invalid input",
|
||||
input: Input{...},
|
||||
wantErr: true,
|
||||
},
|
||||
}
|
||||
|
||||
for _, tt := range tests {
|
||||
t.Run(tt.name, func(t *testing.T) {
|
||||
got, err := Calculate(tt.input)
|
||||
if (err != nil) != tt.wantErr {
|
||||
t.Errorf("Calculate() error = %v, wantErr %v", err, tt.wantErr)
|
||||
return
|
||||
}
|
||||
if !reflect.DeepEqual(got, tt.want) {
|
||||
t.Errorf("Calculate() = %v, want %v", got, tt.want)
|
||||
}
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Step 3: Run Tests (RED)
|
||||
```bash
|
||||
go test -v ./...
|
||||
```
|
||||
|
||||
### Step 4: Implement (GREEN)
|
||||
```go
|
||||
func Calculate(input Input) (Output, error) {
|
||||
// Minimal implementation
|
||||
}
|
||||
```
|
||||
|
||||
### Step 5: Benchmark
|
||||
```go
|
||||
func BenchmarkCalculate(b *testing.B) {
|
||||
input := Input{...}
|
||||
for i := 0; i < b.N; i++ {
|
||||
Calculate(input)
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Go Testing Commands
|
||||
|
||||
```bash
|
||||
# Run all tests
|
||||
go test ./...
|
||||
|
||||
# Run with verbose output
|
||||
go test -v ./...
|
||||
|
||||
# Run with coverage
|
||||
go test -cover ./...
|
||||
|
||||
# Run with race detector
|
||||
go test -race ./...
|
||||
|
||||
# Run benchmarks
|
||||
go test -bench=. ./...
|
||||
|
||||
# Generate coverage report
|
||||
go test -coverprofile=coverage.out ./...
|
||||
go tool cover -html=coverage.out
|
||||
```
|
||||
|
||||
## Test File Organization
|
||||
|
||||
```
|
||||
package/
|
||||
├── calculator.go # Implementation
|
||||
├── calculator_test.go # Tests
|
||||
├── testdata/ # Test fixtures
|
||||
│ └── input.json
|
||||
└── mock_test.go # Mock implementations
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Use `testify/assert` for cleaner assertions, or stick with stdlib for simplicity.
|
||||
@@ -1,93 +0,0 @@
|
||||
---
|
||||
description: Export instincts for sharing
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Instinct Export Command
|
||||
|
||||
Export instincts for sharing with others: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Export instincts from the continuous-learning-v2 system.
|
||||
|
||||
## Export Options
|
||||
|
||||
### Export All
|
||||
```
|
||||
/instinct-export
|
||||
```
|
||||
|
||||
### Export High Confidence Only
|
||||
```
|
||||
/instinct-export --min-confidence 0.8
|
||||
```
|
||||
|
||||
### Export by Category
|
||||
```
|
||||
/instinct-export --category coding
|
||||
```
|
||||
|
||||
### Export to Specific Path
|
||||
```
|
||||
/instinct-export --output ./my-instincts.json
|
||||
```
|
||||
|
||||
## Export Format
|
||||
|
||||
```json
|
||||
{
|
||||
"instincts": [
|
||||
{
|
||||
"id": "instinct-123",
|
||||
"trigger": "[situation description]",
|
||||
"action": "[recommended action]",
|
||||
"confidence": 0.85,
|
||||
"category": "coding",
|
||||
"applications": 10,
|
||||
"successes": 9,
|
||||
"source": "session-observation"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"version": "1.0",
|
||||
"exported": "2025-01-15T10:00:00Z",
|
||||
"author": "username",
|
||||
"total": 25,
|
||||
"filter": "confidence >= 0.8"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Export Report
|
||||
|
||||
```
|
||||
Export Summary
|
||||
==============
|
||||
Output: ./instincts-export.json
|
||||
Total instincts: X
|
||||
Filtered: Y
|
||||
Exported: Z
|
||||
|
||||
Categories:
|
||||
- coding: N
|
||||
- testing: N
|
||||
- security: N
|
||||
- git: N
|
||||
|
||||
Top Instincts (by confidence):
|
||||
1. [trigger] (0.XX)
|
||||
2. [trigger] (0.XX)
|
||||
3. [trigger] (0.XX)
|
||||
```
|
||||
|
||||
## Sharing
|
||||
|
||||
After export:
|
||||
- Share JSON file directly
|
||||
- Upload to team repository
|
||||
- Publish to instinct registry
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Export high-confidence instincts (>0.8) for better quality shares.
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
description: Import instincts from external sources
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Instinct Import Command
|
||||
|
||||
Import instincts from a file or URL: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Import instincts into the continuous-learning-v2 system.
|
||||
|
||||
## Import Sources
|
||||
|
||||
### File Import
|
||||
```
|
||||
/instinct-import path/to/instincts.json
|
||||
```
|
||||
|
||||
### URL Import
|
||||
```
|
||||
/instinct-import https://example.com/instincts.json
|
||||
```
|
||||
|
||||
### Team Share Import
|
||||
```
|
||||
/instinct-import @teammate/instincts
|
||||
```
|
||||
|
||||
## Import Format
|
||||
|
||||
Expected JSON structure:
|
||||
|
||||
```json
|
||||
{
|
||||
"instincts": [
|
||||
{
|
||||
"trigger": "[situation description]",
|
||||
"action": "[recommended action]",
|
||||
"confidence": 0.7,
|
||||
"category": "coding",
|
||||
"source": "imported"
|
||||
}
|
||||
],
|
||||
"metadata": {
|
||||
"version": "1.0",
|
||||
"exported": "2025-01-15T10:00:00Z",
|
||||
"author": "username"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Import Process
|
||||
|
||||
1. **Validate format** - Check JSON structure
|
||||
2. **Deduplicate** - Skip existing instincts
|
||||
3. **Adjust confidence** - Reduce confidence for imports (×0.8)
|
||||
4. **Merge** - Add to local instinct store
|
||||
5. **Report** - Show import summary
|
||||
|
||||
## Import Report
|
||||
|
||||
```
|
||||
Import Summary
|
||||
==============
|
||||
Source: [path or URL]
|
||||
Total in file: X
|
||||
Imported: Y
|
||||
Skipped (duplicates): Z
|
||||
Errors: W
|
||||
|
||||
Imported Instincts:
|
||||
- [trigger] (confidence: 0.XX)
|
||||
- [trigger] (confidence: 0.XX)
|
||||
...
|
||||
```
|
||||
|
||||
## Conflict Resolution
|
||||
|
||||
When importing duplicates:
|
||||
- Keep higher confidence version
|
||||
- Merge application counts
|
||||
- Update timestamp
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Review imported instincts with `/instinct-status` after import.
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
description: View learned instincts with confidence scores
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Instinct Status Command
|
||||
|
||||
Display learned instincts and their confidence scores: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Read and display instincts from the continuous-learning-v2 system.
|
||||
|
||||
## Instinct Location
|
||||
|
||||
Global: `~/.claude/instincts/`
|
||||
Project: `.claude/instincts/`
|
||||
|
||||
## Status Display
|
||||
|
||||
### Instinct Summary
|
||||
|
||||
| Category | Count | Avg Confidence |
|
||||
|----------|-------|----------------|
|
||||
| Coding | X | 0.XX |
|
||||
| Testing | X | 0.XX |
|
||||
| Security | X | 0.XX |
|
||||
| Git | X | 0.XX |
|
||||
|
||||
### High Confidence Instincts (>0.8)
|
||||
|
||||
```
|
||||
[trigger] → [action] (confidence: 0.XX)
|
||||
```
|
||||
|
||||
### Learning Progress
|
||||
|
||||
- Total instincts: X
|
||||
- This session: X
|
||||
- Promoted to skills: X
|
||||
|
||||
### Recent Instincts
|
||||
|
||||
Last 5 instincts learned:
|
||||
|
||||
1. **[timestamp]** - [trigger] → [action]
|
||||
2. **[timestamp]** - [trigger] → [action]
|
||||
...
|
||||
|
||||
## Instinct Structure
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "instinct-123",
|
||||
"trigger": "When I see a try-catch without specific error type",
|
||||
"action": "Suggest using specific error types for better handling",
|
||||
"confidence": 0.75,
|
||||
"applications": 5,
|
||||
"successes": 4,
|
||||
"source": "session-observation",
|
||||
"timestamp": "2025-01-15T10:30:00Z"
|
||||
}
|
||||
```
|
||||
|
||||
## Confidence Calculation
|
||||
|
||||
```
|
||||
confidence = (successes + 1) / (applications + 2)
|
||||
```
|
||||
|
||||
Bayesian smoothing ensures new instincts don't have extreme confidence.
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Use `/evolve` to cluster related instincts into skills when confidence is high.
|
||||
@@ -1,61 +0,0 @@
|
||||
---
|
||||
description: Extract patterns and learnings from current session
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Learn Command
|
||||
|
||||
Extract patterns, learnings, and reusable insights from the current session: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Analyze the conversation and code changes to extract:
|
||||
|
||||
1. **Patterns discovered** - Recurring solutions or approaches
|
||||
2. **Best practices applied** - Techniques that worked well
|
||||
3. **Mistakes to avoid** - Issues encountered and solutions
|
||||
4. **Reusable snippets** - Code patterns worth saving
|
||||
|
||||
## Output Format
|
||||
|
||||
### Patterns Discovered
|
||||
|
||||
**Pattern: [Name]**
|
||||
- Context: When to use this pattern
|
||||
- Implementation: How to apply it
|
||||
- Example: Code snippet
|
||||
|
||||
### Best Practices Applied
|
||||
|
||||
1. [Practice name]
|
||||
- Why it works
|
||||
- When to apply
|
||||
|
||||
### Mistakes to Avoid
|
||||
|
||||
1. [Mistake description]
|
||||
- What went wrong
|
||||
- How to prevent it
|
||||
|
||||
### Suggested Skill Updates
|
||||
|
||||
If patterns are significant, suggest updates to:
|
||||
- `skills/coding-standards/SKILL.md`
|
||||
- `skills/[domain]/SKILL.md`
|
||||
- `rules/[category].md`
|
||||
|
||||
## Instinct Format (for continuous-learning-v2)
|
||||
|
||||
```json
|
||||
{
|
||||
"trigger": "[situation that triggers this learning]",
|
||||
"action": "[what to do]",
|
||||
"confidence": 0.7,
|
||||
"source": "session-extraction",
|
||||
"timestamp": "[ISO timestamp]"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Run `/learn` periodically during long sessions to capture insights before context compaction.
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
description: Orchestrate multiple agents for complex tasks
|
||||
agent: planner
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Orchestrate Command
|
||||
|
||||
Orchestrate multiple specialized agents for this complex task: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
1. **Analyze task complexity** and break into subtasks
|
||||
2. **Identify optimal agents** for each subtask
|
||||
3. **Create execution plan** with dependencies
|
||||
4. **Coordinate execution** - parallel where possible
|
||||
5. **Synthesize results** into unified output
|
||||
|
||||
## Available Agents
|
||||
|
||||
| Agent | Specialty | Use For |
|
||||
|-------|-----------|---------|
|
||||
| planner | Implementation planning | Complex feature design |
|
||||
| architect | System design | Architectural decisions |
|
||||
| code-reviewer | Code quality | Review changes |
|
||||
| security-reviewer | Security analysis | Vulnerability detection |
|
||||
| tdd-guide | Test-driven dev | Feature implementation |
|
||||
| build-error-resolver | Build fixes | TypeScript/build errors |
|
||||
| e2e-runner | E2E testing | User flow testing |
|
||||
| doc-updater | Documentation | Updating docs |
|
||||
| refactor-cleaner | Code cleanup | Dead code removal |
|
||||
| go-reviewer | Go code | Go-specific review |
|
||||
| go-build-resolver | Go builds | Go build errors |
|
||||
| database-reviewer | Database | Query optimization |
|
||||
|
||||
## Orchestration Patterns
|
||||
|
||||
### Sequential Execution
|
||||
```
|
||||
planner → tdd-guide → code-reviewer → security-reviewer
|
||||
```
|
||||
Use when: Later tasks depend on earlier results
|
||||
|
||||
### Parallel Execution
|
||||
```
|
||||
┌→ security-reviewer
|
||||
planner →├→ code-reviewer
|
||||
└→ architect
|
||||
```
|
||||
Use when: Tasks are independent
|
||||
|
||||
### Fan-Out/Fan-In
|
||||
```
|
||||
┌→ agent-1 ─┐
|
||||
planner →├→ agent-2 ─┼→ synthesizer
|
||||
└→ agent-3 ─┘
|
||||
```
|
||||
Use when: Multiple perspectives needed
|
||||
|
||||
## Execution Plan Format
|
||||
|
||||
### Phase 1: [Name]
|
||||
- Agent: [agent-name]
|
||||
- Task: [specific task]
|
||||
- Depends on: [none or previous phase]
|
||||
|
||||
### Phase 2: [Name] (parallel)
|
||||
- Agent A: [agent-name]
|
||||
- Task: [specific task]
|
||||
- Agent B: [agent-name]
|
||||
- Task: [specific task]
|
||||
- Depends on: Phase 1
|
||||
|
||||
### Phase 3: Synthesis
|
||||
- Combine results from Phase 2
|
||||
- Generate unified output
|
||||
|
||||
## Coordination Rules
|
||||
|
||||
1. **Plan before execute** - Create full execution plan first
|
||||
2. **Minimize handoffs** - Reduce context switching
|
||||
3. **Parallelize when possible** - Independent tasks in parallel
|
||||
4. **Clear boundaries** - Each agent has specific scope
|
||||
5. **Single source of truth** - One agent owns each artifact
|
||||
|
||||
---
|
||||
|
||||
**NOTE**: Complex tasks benefit from multi-agent orchestration. Simple tasks should use single agents directly.
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
description: Create implementation plan with risk assessment
|
||||
agent: planner
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Plan Command
|
||||
|
||||
Create a detailed implementation plan for: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
1. **Restate Requirements** - Clarify what needs to be built
|
||||
2. **Identify Risks** - Surface potential issues, blockers, and dependencies
|
||||
3. **Create Step Plan** - Break down implementation into phases
|
||||
4. **Wait for Confirmation** - MUST receive user approval before proceeding
|
||||
|
||||
## Output Format
|
||||
|
||||
### Requirements Restatement
|
||||
[Clear, concise restatement of what will be built]
|
||||
|
||||
### Implementation Phases
|
||||
[Phase 1: Description]
|
||||
- Step 1.1
|
||||
- Step 1.2
|
||||
...
|
||||
|
||||
[Phase 2: Description]
|
||||
- Step 2.1
|
||||
- Step 2.2
|
||||
...
|
||||
|
||||
### Dependencies
|
||||
[List external dependencies, APIs, services needed]
|
||||
|
||||
### Risks
|
||||
- HIGH: [Critical risks that could block implementation]
|
||||
- MEDIUM: [Moderate risks to address]
|
||||
- LOW: [Minor concerns]
|
||||
|
||||
### Estimated Complexity
|
||||
[HIGH/MEDIUM/LOW with time estimates]
|
||||
|
||||
**WAITING FOR CONFIRMATION**: Proceed with this plan? (yes/no/modify)
|
||||
|
||||
---
|
||||
|
||||
**CRITICAL**: Do NOT write any code until the user explicitly confirms with "yes", "proceed", or similar affirmative response.
|
||||
@@ -1,102 +0,0 @@
|
||||
---
|
||||
description: Remove dead code and consolidate duplicates
|
||||
agent: refactor-cleaner
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Refactor Clean Command
|
||||
|
||||
Analyze and clean up the codebase: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
1. **Detect dead code** using analysis tools
|
||||
2. **Identify duplicates** and consolidation opportunities
|
||||
3. **Safely remove** unused code with documentation
|
||||
4. **Verify** no functionality broken
|
||||
|
||||
## Detection Phase
|
||||
|
||||
### Run Analysis Tools
|
||||
|
||||
```bash
|
||||
# Find unused exports
|
||||
npx knip
|
||||
|
||||
# Find unused dependencies
|
||||
npx depcheck
|
||||
|
||||
# Find unused TypeScript exports
|
||||
npx ts-prune
|
||||
```
|
||||
|
||||
### Manual Checks
|
||||
|
||||
- Unused functions (no callers)
|
||||
- Unused variables
|
||||
- Unused imports
|
||||
- Commented-out code
|
||||
- Unreachable code
|
||||
- Unused CSS classes
|
||||
|
||||
## Removal Phase
|
||||
|
||||
### Before Removing
|
||||
|
||||
1. **Search for usage** - grep, find references
|
||||
2. **Check exports** - might be used externally
|
||||
3. **Verify tests** - no test depends on it
|
||||
4. **Document removal** - git commit message
|
||||
|
||||
### Safe Removal Order
|
||||
|
||||
1. Remove unused imports first
|
||||
2. Remove unused private functions
|
||||
3. Remove unused exported functions
|
||||
4. Remove unused types/interfaces
|
||||
5. Remove unused files
|
||||
|
||||
## Consolidation Phase
|
||||
|
||||
### Identify Duplicates
|
||||
|
||||
- Similar functions with minor differences
|
||||
- Copy-pasted code blocks
|
||||
- Repeated patterns
|
||||
|
||||
### Consolidation Strategies
|
||||
|
||||
1. **Extract utility function** - for repeated logic
|
||||
2. **Create base class** - for similar classes
|
||||
3. **Use higher-order functions** - for repeated patterns
|
||||
4. **Create shared constants** - for magic values
|
||||
|
||||
## Verification
|
||||
|
||||
After cleanup:
|
||||
|
||||
1. `npm run build` - builds successfully
|
||||
2. `npm test` - all tests pass
|
||||
3. `npm run lint` - no new lint errors
|
||||
4. Manual smoke test - features work
|
||||
|
||||
## Report Format
|
||||
|
||||
```
|
||||
Dead Code Analysis
|
||||
==================
|
||||
|
||||
Removed:
|
||||
- file.ts: functionName (unused export)
|
||||
- utils.ts: helperFunction (no callers)
|
||||
|
||||
Consolidated:
|
||||
- formatDate() and formatDateTime() → dateUtils.format()
|
||||
|
||||
Remaining (manual review needed):
|
||||
- oldComponent.tsx: potentially unused, verify with team
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**CAUTION**: Always verify before removing. When in doubt, ask or add `// TODO: verify usage` comment.
|
||||
@@ -1,89 +0,0 @@
|
||||
---
|
||||
description: Run comprehensive security review
|
||||
agent: security-reviewer
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Security Review Command
|
||||
|
||||
Conduct a comprehensive security review: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Analyze the specified code for security vulnerabilities following OWASP guidelines and security best practices.
|
||||
|
||||
## Security Checklist
|
||||
|
||||
### OWASP Top 10
|
||||
|
||||
1. **Injection** (SQL, NoSQL, OS command, LDAP)
|
||||
- Check for parameterized queries
|
||||
- Verify input sanitization
|
||||
- Review dynamic query construction
|
||||
|
||||
2. **Broken Authentication**
|
||||
- Password storage (bcrypt, argon2)
|
||||
- Session management
|
||||
- Multi-factor authentication
|
||||
- Password reset flows
|
||||
|
||||
3. **Sensitive Data Exposure**
|
||||
- Encryption at rest and in transit
|
||||
- Proper key management
|
||||
- PII handling
|
||||
|
||||
4. **XML External Entities (XXE)**
|
||||
- Disable DTD processing
|
||||
- Input validation for XML
|
||||
|
||||
5. **Broken Access Control**
|
||||
- Authorization checks on every endpoint
|
||||
- Role-based access control
|
||||
- Resource ownership validation
|
||||
|
||||
6. **Security Misconfiguration**
|
||||
- Default credentials removed
|
||||
- Error handling doesn't leak info
|
||||
- Security headers configured
|
||||
|
||||
7. **Cross-Site Scripting (XSS)**
|
||||
- Output encoding
|
||||
- Content Security Policy
|
||||
- Input sanitization
|
||||
|
||||
8. **Insecure Deserialization**
|
||||
- Validate serialized data
|
||||
- Implement integrity checks
|
||||
|
||||
9. **Using Components with Known Vulnerabilities**
|
||||
- Run `npm audit`
|
||||
- Check for outdated dependencies
|
||||
|
||||
10. **Insufficient Logging & Monitoring**
|
||||
- Security events logged
|
||||
- No sensitive data in logs
|
||||
- Alerting configured
|
||||
|
||||
### Additional Checks
|
||||
|
||||
- [ ] Secrets in code (API keys, passwords)
|
||||
- [ ] Environment variable handling
|
||||
- [ ] CORS configuration
|
||||
- [ ] Rate limiting
|
||||
- [ ] CSRF protection
|
||||
- [ ] Secure cookie flags
|
||||
|
||||
## Report Format
|
||||
|
||||
### Critical Issues
|
||||
[Issues that must be fixed immediately]
|
||||
|
||||
### High Priority
|
||||
[Issues that should be fixed before release]
|
||||
|
||||
### Recommendations
|
||||
[Security improvements to consider]
|
||||
|
||||
---
|
||||
|
||||
**IMPORTANT**: Security issues are blockers. Do not proceed until critical issues are resolved.
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
description: Configure package manager preference
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Setup Package Manager Command
|
||||
|
||||
Configure your preferred package manager: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Set up package manager preference for the project or globally.
|
||||
|
||||
## Detection Order
|
||||
|
||||
1. **Environment variable**: `CLAUDE_PACKAGE_MANAGER`
|
||||
2. **Project config**: `.claude/package-manager.json`
|
||||
3. **package.json**: `packageManager` field
|
||||
4. **Lock file**: Auto-detect from lock files
|
||||
5. **Global config**: `~/.claude/package-manager.json`
|
||||
6. **Fallback**: First available
|
||||
|
||||
## Configuration Options
|
||||
|
||||
### Option 1: Environment Variable
|
||||
```bash
|
||||
export CLAUDE_PACKAGE_MANAGER=pnpm
|
||||
```
|
||||
|
||||
### Option 2: Project Config
|
||||
```bash
|
||||
# Create .claude/package-manager.json
|
||||
echo '{"packageManager": "pnpm"}' > .claude/package-manager.json
|
||||
```
|
||||
|
||||
### Option 3: package.json
|
||||
```json
|
||||
{
|
||||
"packageManager": "pnpm@8.0.0"
|
||||
}
|
||||
```
|
||||
|
||||
### Option 4: Global Config
|
||||
```bash
|
||||
# Create ~/.claude/package-manager.json
|
||||
echo '{"packageManager": "yarn"}' > ~/.claude/package-manager.json
|
||||
```
|
||||
|
||||
## Supported Package Managers
|
||||
|
||||
| Manager | Lock File | Commands |
|
||||
|---------|-----------|----------|
|
||||
| npm | package-lock.json | `npm install`, `npm run` |
|
||||
| pnpm | pnpm-lock.yaml | `pnpm install`, `pnpm run` |
|
||||
| yarn | yarn.lock | `yarn install`, `yarn run` |
|
||||
| bun | bun.lockb | `bun install`, `bun run` |
|
||||
|
||||
## Verification
|
||||
|
||||
Check current setting:
|
||||
```bash
|
||||
node scripts/setup-package-manager.js --detect
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**TIP**: For consistency across team, add `packageManager` field to package.json.
|
||||
@@ -1,117 +0,0 @@
|
||||
---
|
||||
description: Generate skills from git history analysis
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Skill Create Command
|
||||
|
||||
Analyze git history to generate Claude Code skills: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
1. **Analyze commits** - Pattern recognition from history
|
||||
2. **Extract patterns** - Common practices and conventions
|
||||
3. **Generate SKILL.md** - Structured skill documentation
|
||||
4. **Create instincts** - For continuous-learning-v2
|
||||
|
||||
## Analysis Process
|
||||
|
||||
### Step 1: Gather Commit Data
|
||||
```bash
|
||||
# Recent commits
|
||||
git log --oneline -100
|
||||
|
||||
# Commits by file type
|
||||
git log --name-only --pretty=format: | sort | uniq -c | sort -rn
|
||||
|
||||
# Most changed files
|
||||
git log --pretty=format: --name-only | sort | uniq -c | sort -rn | head -20
|
||||
```
|
||||
|
||||
### Step 2: Identify Patterns
|
||||
|
||||
**Commit Message Patterns**:
|
||||
- Common prefixes (feat, fix, refactor)
|
||||
- Naming conventions
|
||||
- Co-author patterns
|
||||
|
||||
**Code Patterns**:
|
||||
- File structure conventions
|
||||
- Import organization
|
||||
- Error handling approaches
|
||||
|
||||
**Review Patterns**:
|
||||
- Common review feedback
|
||||
- Recurring fix types
|
||||
- Quality gates
|
||||
|
||||
### Step 3: Generate SKILL.md
|
||||
|
||||
```markdown
|
||||
# [Skill Name]
|
||||
|
||||
## Overview
|
||||
[What this skill teaches]
|
||||
|
||||
## Patterns
|
||||
|
||||
### Pattern 1: [Name]
|
||||
- When to use
|
||||
- Implementation
|
||||
- Example
|
||||
|
||||
### Pattern 2: [Name]
|
||||
- When to use
|
||||
- Implementation
|
||||
- Example
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. [Practice 1]
|
||||
2. [Practice 2]
|
||||
3. [Practice 3]
|
||||
|
||||
## Common Mistakes
|
||||
|
||||
1. [Mistake 1] - How to avoid
|
||||
2. [Mistake 2] - How to avoid
|
||||
|
||||
## Examples
|
||||
|
||||
### Good Example
|
||||
```[language]
|
||||
// Code example
|
||||
```
|
||||
|
||||
### Anti-pattern
|
||||
```[language]
|
||||
// What not to do
|
||||
```
|
||||
```
|
||||
|
||||
### Step 4: Generate Instincts
|
||||
|
||||
For continuous-learning-v2:
|
||||
|
||||
```json
|
||||
{
|
||||
"instincts": [
|
||||
{
|
||||
"trigger": "[situation]",
|
||||
"action": "[response]",
|
||||
"confidence": 0.8,
|
||||
"source": "git-history-analysis"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
Creates:
|
||||
- `skills/[name]/SKILL.md` - Skill documentation
|
||||
- `skills/[name]/instincts.json` - Instinct collection
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Run `/skill-create --instincts` to also generate instincts for continuous learning.
|
||||
@@ -1,66 +0,0 @@
|
||||
---
|
||||
description: Enforce TDD workflow with 80%+ coverage
|
||||
agent: tdd-guide
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# TDD Command
|
||||
|
||||
Implement the following using strict test-driven development: $ARGUMENTS
|
||||
|
||||
## TDD Cycle (MANDATORY)
|
||||
|
||||
```
|
||||
RED → GREEN → REFACTOR → REPEAT
|
||||
```
|
||||
|
||||
1. **RED**: Write a failing test FIRST
|
||||
2. **GREEN**: Write minimal code to pass the test
|
||||
3. **REFACTOR**: Improve code while keeping tests green
|
||||
4. **REPEAT**: Continue until feature complete
|
||||
|
||||
## Your Task
|
||||
|
||||
### Step 1: Define Interfaces (SCAFFOLD)
|
||||
- Define TypeScript interfaces for inputs/outputs
|
||||
- Create function signature with `throw new Error('Not implemented')`
|
||||
|
||||
### Step 2: Write Failing Tests (RED)
|
||||
- Write tests that exercise the interface
|
||||
- Include happy path, edge cases, and error conditions
|
||||
- Run tests - verify they FAIL
|
||||
|
||||
### Step 3: Implement Minimal Code (GREEN)
|
||||
- Write just enough code to make tests pass
|
||||
- No premature optimization
|
||||
- Run tests - verify they PASS
|
||||
|
||||
### Step 4: Refactor (IMPROVE)
|
||||
- Extract constants, improve naming
|
||||
- Remove duplication
|
||||
- Run tests - verify they still PASS
|
||||
|
||||
### Step 5: Check Coverage
|
||||
- Target: 80% minimum
|
||||
- 100% for critical business logic
|
||||
- Add more tests if needed
|
||||
|
||||
## Coverage Requirements
|
||||
|
||||
| Code Type | Minimum |
|
||||
|-----------|---------|
|
||||
| Standard code | 80% |
|
||||
| Financial calculations | 100% |
|
||||
| Authentication logic | 100% |
|
||||
| Security-critical code | 100% |
|
||||
|
||||
## Test Types to Include
|
||||
|
||||
- **Unit Tests**: Individual functions
|
||||
- **Edge Cases**: Empty, null, max values, boundaries
|
||||
- **Error Conditions**: Invalid inputs, network failures
|
||||
- **Integration Tests**: API endpoints, database operations
|
||||
|
||||
---
|
||||
|
||||
**MANDATORY**: Tests must be written BEFORE implementation. Never skip the RED phase.
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
description: Analyze and improve test coverage
|
||||
agent: tdd-guide
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Test Coverage Command
|
||||
|
||||
Analyze test coverage and identify gaps: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
1. **Run coverage report**: `npm test -- --coverage`
|
||||
2. **Analyze results** - Identify low coverage areas
|
||||
3. **Prioritize gaps** - Critical code first
|
||||
4. **Generate missing tests** - For uncovered code
|
||||
|
||||
## Coverage Targets
|
||||
|
||||
| Code Type | Target |
|
||||
|-----------|--------|
|
||||
| Standard code | 80% |
|
||||
| Financial logic | 100% |
|
||||
| Auth/security | 100% |
|
||||
| Utilities | 90% |
|
||||
| UI components | 70% |
|
||||
|
||||
## Coverage Report Analysis
|
||||
|
||||
### Summary
|
||||
```
|
||||
File | % Stmts | % Branch | % Funcs | % Lines
|
||||
---------------|---------|----------|---------|--------
|
||||
All files | XX | XX | XX | XX
|
||||
```
|
||||
|
||||
### Low Coverage Files
|
||||
[Files below target, prioritized by criticality]
|
||||
|
||||
### Uncovered Lines
|
||||
[Specific lines that need tests]
|
||||
|
||||
## Test Generation
|
||||
|
||||
For each uncovered area:
|
||||
|
||||
### [Function/Component Name]
|
||||
|
||||
**Location**: `src/path/file.ts:123`
|
||||
|
||||
**Coverage Gap**: [description]
|
||||
|
||||
**Suggested Tests**:
|
||||
```typescript
|
||||
describe('functionName', () => {
|
||||
it('should [expected behavior]', () => {
|
||||
// Test code
|
||||
})
|
||||
|
||||
it('should handle [edge case]', () => {
|
||||
// Edge case test
|
||||
})
|
||||
})
|
||||
```
|
||||
|
||||
## Coverage Improvement Plan
|
||||
|
||||
1. **Critical** (add immediately)
|
||||
- [ ] file1.ts - Auth logic
|
||||
- [ ] file2.ts - Payment handling
|
||||
|
||||
2. **High** (add this sprint)
|
||||
- [ ] file3.ts - Core business logic
|
||||
|
||||
3. **Medium** (add when touching file)
|
||||
- [ ] file4.ts - Utilities
|
||||
|
||||
---
|
||||
|
||||
**IMPORTANT**: Coverage is a metric, not a goal. Focus on meaningful tests, not just hitting numbers.
|
||||
@@ -1,81 +0,0 @@
|
||||
---
|
||||
description: Update codemaps for codebase navigation
|
||||
agent: doc-updater
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Update Codemaps Command
|
||||
|
||||
Update codemaps to reflect current codebase structure: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Generate or update codemaps in `docs/CODEMAPS/` directory:
|
||||
|
||||
1. **Analyze codebase structure**
|
||||
2. **Generate component maps**
|
||||
3. **Document relationships**
|
||||
4. **Update navigation guides**
|
||||
|
||||
## Codemap Types
|
||||
|
||||
### Architecture Map
|
||||
```
|
||||
docs/CODEMAPS/ARCHITECTURE.md
|
||||
```
|
||||
- High-level system overview
|
||||
- Component relationships
|
||||
- Data flow diagrams
|
||||
|
||||
### Module Map
|
||||
```
|
||||
docs/CODEMAPS/MODULES.md
|
||||
```
|
||||
- Module descriptions
|
||||
- Public APIs
|
||||
- Dependencies
|
||||
|
||||
### File Map
|
||||
```
|
||||
docs/CODEMAPS/FILES.md
|
||||
```
|
||||
- Directory structure
|
||||
- File purposes
|
||||
- Key files
|
||||
|
||||
## Codemap Format
|
||||
|
||||
### [Module Name]
|
||||
|
||||
**Purpose**: [Brief description]
|
||||
|
||||
**Location**: `src/[path]/`
|
||||
|
||||
**Key Files**:
|
||||
- `file1.ts` - [purpose]
|
||||
- `file2.ts` - [purpose]
|
||||
|
||||
**Dependencies**:
|
||||
- [Module A]
|
||||
- [Module B]
|
||||
|
||||
**Exports**:
|
||||
- `functionName()` - [description]
|
||||
- `ClassName` - [description]
|
||||
|
||||
**Usage Example**:
|
||||
```typescript
|
||||
import { functionName } from '@/module'
|
||||
```
|
||||
|
||||
## Generation Process
|
||||
|
||||
1. Scan directory structure
|
||||
2. Parse imports/exports
|
||||
3. Build dependency graph
|
||||
4. Generate markdown maps
|
||||
5. Validate links
|
||||
|
||||
---
|
||||
|
||||
**TIP**: Keep codemaps updated when adding new modules or significant refactoring.
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
description: Update documentation for recent changes
|
||||
agent: doc-updater
|
||||
subtask: true
|
||||
---
|
||||
|
||||
# Update Docs Command
|
||||
|
||||
Update documentation to reflect recent changes: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
1. **Identify changed code** - `git diff --name-only`
|
||||
2. **Find related docs** - README, API docs, guides
|
||||
3. **Update documentation** - Keep in sync with code
|
||||
4. **Verify accuracy** - Docs match implementation
|
||||
|
||||
## Documentation Types
|
||||
|
||||
### README.md
|
||||
- Installation instructions
|
||||
- Quick start guide
|
||||
- Feature overview
|
||||
- Configuration options
|
||||
|
||||
### API Documentation
|
||||
- Endpoint descriptions
|
||||
- Request/response formats
|
||||
- Authentication details
|
||||
- Error codes
|
||||
|
||||
### Code Comments
|
||||
- JSDoc for public APIs
|
||||
- Complex logic explanations
|
||||
- TODO/FIXME cleanup
|
||||
|
||||
### Guides
|
||||
- How-to tutorials
|
||||
- Architecture decisions (ADRs)
|
||||
- Troubleshooting guides
|
||||
|
||||
## Update Checklist
|
||||
|
||||
- [ ] README reflects current features
|
||||
- [ ] API docs match endpoints
|
||||
- [ ] JSDoc updated for changed functions
|
||||
- [ ] Examples are working
|
||||
- [ ] Links are valid
|
||||
- [ ] Version numbers updated
|
||||
|
||||
## Documentation Quality
|
||||
|
||||
### Good Documentation
|
||||
- Accurate and up-to-date
|
||||
- Clear and concise
|
||||
- Has working examples
|
||||
- Covers edge cases
|
||||
|
||||
### Avoid
|
||||
- Outdated information
|
||||
- Missing parameters
|
||||
- Broken examples
|
||||
- Ambiguous language
|
||||
|
||||
---
|
||||
|
||||
**IMPORTANT**: Documentation should be updated alongside code changes, not as an afterthought.
|
||||
@@ -1,67 +0,0 @@
|
||||
---
|
||||
description: Run verification loop to validate implementation
|
||||
agent: build
|
||||
---
|
||||
|
||||
# Verify Command
|
||||
|
||||
Run verification loop to validate the implementation: $ARGUMENTS
|
||||
|
||||
## Your Task
|
||||
|
||||
Execute comprehensive verification:
|
||||
|
||||
1. **Type Check**: `npx tsc --noEmit`
|
||||
2. **Lint**: `npm run lint`
|
||||
3. **Unit Tests**: `npm test`
|
||||
4. **Integration Tests**: `npm run test:integration` (if available)
|
||||
5. **Build**: `npm run build`
|
||||
6. **Coverage Check**: Verify 80%+ coverage
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
### Code Quality
|
||||
- [ ] No TypeScript errors
|
||||
- [ ] No lint warnings
|
||||
- [ ] No console.log statements
|
||||
- [ ] Functions < 50 lines
|
||||
- [ ] Files < 800 lines
|
||||
|
||||
### Tests
|
||||
- [ ] All tests passing
|
||||
- [ ] Coverage >= 80%
|
||||
- [ ] Edge cases covered
|
||||
- [ ] Error conditions tested
|
||||
|
||||
### Security
|
||||
- [ ] No hardcoded secrets
|
||||
- [ ] Input validation present
|
||||
- [ ] No SQL injection risks
|
||||
- [ ] No XSS vulnerabilities
|
||||
|
||||
### Build
|
||||
- [ ] Build succeeds
|
||||
- [ ] No warnings
|
||||
- [ ] Bundle size acceptable
|
||||
|
||||
## Verification Report
|
||||
|
||||
### Summary
|
||||
- Status: ✅ PASS / ❌ FAIL
|
||||
- Score: X/Y checks passed
|
||||
|
||||
### Details
|
||||
| Check | Status | Notes |
|
||||
|-------|--------|-------|
|
||||
| TypeScript | ✅/❌ | [details] |
|
||||
| Lint | ✅/❌ | [details] |
|
||||
| Tests | ✅/❌ | [details] |
|
||||
| Coverage | ✅/❌ | XX% (target: 80%) |
|
||||
| Build | ✅/❌ | [details] |
|
||||
|
||||
### Action Items
|
||||
[If FAIL, list what needs to be fixed]
|
||||
|
||||
---
|
||||
|
||||
**NOTE**: Verification loop should be run before every commit and PR.
|
||||
Reference in New Issue
Block a user