omgkit 2.1.1 → 2.3.0

package/plugin/skills/methodology/test-driven-development/SKILL.md

@@ -1,39 +1,133 @@
 ---
-name: test-driven-development
-description: TDD workflow. Use when implementing features with test-first approach.
+name: developing-test-driven
+description: AI agent practices test-first development with the Red-Green-Refactor cycle for confident, well-designed code. Use when implementing features, fixing bugs, or establishing testing practices.
 ---
 
-# Test-Driven Development Skill
+# Developing Test-Driven
 
-## TDD Cycle
-1. 🔴 **RED** - Write failing test
-2. 🟢 **GREEN** - Make it pass (minimal code)
-3. ♻️ **REFACTOR** - Improve code
+## Quick Start
 
-## Rules
-- No production code without failing test
-- Only enough code to pass test
-- Refactor only when green
-- One assertion per test
+1. **Red** - Write a failing test that defines desired behavior
+2. **Green** - Write minimal code to make the test pass
+3. **Refactor** - Improve code while keeping tests green
+4. **Repeat** - Continue with next behavior (1-5 minute cycles)
+
+## Features
+
+| Feature | Description | Guide |
+|---------|-------------|-------|
+| Red-Green-Refactor | Core TDD cycle | Fail -> Pass -> Improve -> Repeat |
+| Test Patterns | Effective test structures | Arrange-Act-Assert, Given-When-Then |
+| Test Fixtures | Reusable test setup | beforeEach, factories, builders |
+| Mocking Strategies | Isolate dependencies | Inject deps, mock boundaries only |
+| Parameterized Tests | Test multiple inputs | `it.each` for input variations |
+| Coverage Analysis | Verify thoroughness | Statements, branches, functions |
+
+## Common Patterns
 
-## Example
 ```typescript
-// 1. RED - Write test first
-describe('calculateTax', () => {
-  it('calculates 10% tax', () => {
-    expect(calculateTax(100, 0.1)).toBe(10);
-  });
+// RED-GREEN-REFACTOR CYCLE
+
+// RED: Write failing test
+it('rejects passwords shorter than 8 characters', () => {
+  const result = validatePassword('short');
+  expect(result.valid).toBe(false);
+  expect(result.errors).toContain('Password must be at least 8 characters');
 });
 
-// 2. GREEN - Minimal implementation
-function calculateTax(amount: number, rate: number) {
-  return amount * rate;
+// GREEN: Minimal implementation
+function validatePassword(password: string) {
+  const errors = [];
+  if (password.length < 8) {
+    errors.push('Password must be at least 8 characters');
+  }
+  return { valid: errors.length === 0, errors };
 }
 
-// 3. REFACTOR if needed
+// REFACTOR: Extract rules (tests stay green)
+const rules = [
+  { test: (p) => p.length >= 8, message: 'Must be 8+ chars' },
+  { test: (p) => /[A-Z]/.test(p), message: 'Must have uppercase' },
+];
+function validatePassword(password: string) {
+  const errors = rules.filter(r => !r.test(password)).map(r => r.message);
+  return { valid: errors.length === 0, errors };
+}
 ```
 
-## Benefits
-- Design emerges from tests
-- 100% coverage by default
-- Confidence in refactoring
+```typescript
+// ARRANGE-ACT-ASSERT Pattern
+it('increases total when item added', () => {
+  // ARRANGE
+  const cart = new ShoppingCart();
+  const item = { id: '1', price: 10.00 };
+
+  // ACT
+  cart.addItem(item);
+
+  // ASSERT
+  expect(cart.total).toBe(10.00);
+});
+
+// PARAMETERIZED TESTS
+it.each([
+  ['simple@example.com', true],
+  ['user.name@domain.org', true],
+  ['invalid', false],
+  ['@nodomain.com', false],
+])('validates %s as %s', (email, expected) => {
+  expect(isValidEmail(email)).toBe(expected);
+});
+
+// BUILDER PATTERN for test data
+const user = new UserBuilder().admin().inactive().build();
+```
+
+```
+# Mocking Guidelines
+MOCK (external boundaries):
+- External APIs (payment, email)
+- Third-party services
+- System clock, random
+- Network requests
+
+DON'T MOCK (your code):
+- Pure functions
+- Data transformations
+- Business logic
+- Internal services
+```
+
+```
+# Coverage Analysis
+| Type | Target | Notes |
+|------|--------|-------|
+| Statements | 80%+ | Code executed |
+| Branches | 70%+ | If/else paths |
+| Functions | 90%+ | All functions called |
+
+REMEMBER: 100% coverage != well-tested
+- Test edge cases
+- Test error paths
+- Test boundary conditions
+```
+
+## Best Practices
+
+| Do | Avoid |
+|----|-------|
+| Write test BEFORE implementation | Writing implementation first |
+| Keep tests focused on ONE behavior | Testing multiple things in one test |
+| Use descriptive test names | Generic names like "test1" |
+| Run tests frequently (every few minutes) | Long gaps between test runs |
+| Refactor only when tests green | Refactoring with failing tests |
+| Test behavior, not implementation | Testing private methods directly |
+| Keep cycles short (1-5 minutes) | 30+ minute cycles |
+| Mock only external dependencies | Over-mocking your own code |
+
+## Related Skills
+
+- `avoiding-testing-anti-patterns` - Avoid common test mistakes
+- `testing-with-vitest` - Vitest testing framework
+- `testing-with-playwright` - E2E testing with Playwright
+- `verifying-before-completion` - Ensure test quality

package/plugin/skills/methodology/testing-anti-patterns/SKILL.md

@@ -1,50 +1,103 @@
 ---
-name: testing-anti-patterns
-description: Testing anti-patterns to avoid. Use when writing or reviewing tests.
+name: avoiding-testing-anti-patterns
+description: AI agent identifies and fixes common testing anti-patterns that lead to flaky, slow, or unmaintainable test suites. Use when reviewing tests, debugging test failures, or improving test quality.
 ---
 
-# Testing Anti-Patterns Skill
+# Avoiding Testing Anti-Patterns
 
-## Anti-Patterns
+## Quick Start
 
-### 1. Testing Implementation
-```typescript
-// Bad - tests internal implementation
-expect(component.state.count).toBe(1);
+1. **Identify** - Recognize anti-pattern category (flaky, implementation, over-mocking)
+2. **Assess Severity** - Critical (fix now), High (fix soon), Medium (plan to fix)
+3. **Apply Fix** - Use proper async handling, test behavior not implementation
+4. **Verify** - Run tests in random order, ensure independence
+5. **Prevent** - Add test smell detection to CI
 
-// Good - tests behavior
-expect(screen.getByText('1')).toBeInTheDocument();
-```
+## Features
 
-### 2. Flaky Tests
-```typescript
-// Bad - timing dependent
-await sleep(1000);
-expect(result).toBe(true);
+| Feature | Description | Guide |
+|---------|-------------|-------|
+| Flaky Tests | Random failures destroying trust | Use waitFor, not sleep; deterministic data |
+| Implementation Testing | Breaks on every refactor | Test behavior through public interface |
+| Over-Mocking | Tests pass but bugs slip through | Mock boundaries only, not your own code |
+| Slow Tests | Hurt development velocity | Right test layer, shared setup, mock network |
+| Test Interdependence | Can't run tests in isolation | Fresh state in beforeEach, no shared mutation |
+| Poor Design | Hard to understand/maintain | Descriptive names, focused tests, clear values |
 
-// Good - wait for condition
-await waitFor(() => expect(result).toBe(true));
-```
+## Common Patterns
 
-### 3. Test Interdependence
 ```typescript
-// Bad - tests share state
-let user;
-it('creates user', () => { user = create(); });
-it('uses user', () => { expect(user).toBe(...); });
+// FLAKY: Timing-dependent
+await sleep(100);  // May not be enough
+expect(result).toBe('processed');
+
+// FIXED: Wait for condition
+await waitFor(() => {
+  expect(result).toBe('processed');
+}, { timeout: 5000 });
+
+// FLAKY: Shared state between tests
+let sharedState = [];
+it('test1', () => { sharedState.push('a'); });
+it('test2', () => { expect(sharedState).toHaveLength(1); }); // Order-dependent!
+
+// FIXED: Fresh state each test
+beforeEach(() => { sharedState = []; });
+
+// IMPLEMENTATION: Testing private state
+expect(counter._count).toBe(1);
+
+// BEHAVIOR: Testing public interface
+expect(counter.getValue()).toBe(1);
 
-// Good - independent tests
-beforeEach(() => { user = create(); });
+// OVER-MOCKING: Everything mocked
+const mockDb = { save: jest.fn() };
+const mockPayment = { charge: jest.fn() };
+// Only testing that mocks were called
+
+// FIXED: Mock boundaries only
+const testDb = await createTestDatabase();  // Real
+const mockPayment = createMockPaymentProvider();  // External only
 ```
 
-### 4. Overmocking
-```typescript
-// Bad - mock everything
-// Good - use real implementations when practical
 ```
+# Anti-Pattern Severity Guide
+CRITICAL (fix immediately):
+- Flaky tests - Random failures destroy trust
+- Testing implementation - Breaks on every refactor
+- Hidden dependencies - Tests fail mysteriously
+
+HIGH (fix soon):
+- Slow tests - Hurt development velocity
+- Test interdependence - Can't run in isolation
+- Over-mocking - Tests pass but bugs slip through
+
+MEDIUM (plan to fix):
+- Poor naming - Tests don't document behavior
+- Magic values - Unclear expected values
+- Giant tests - Hard to understand
+
+LOW (fix when touching):
+- Commented tests - Remove or fix
+- Duplicate tests - Consolidate
+```
+
+## Best Practices
+
+| Do | Avoid |
+|----|-------|
+| Test behavior, not implementation | Accessing private properties |
+| Use factories for test data | Random/inconsistent test data |
+| Write descriptive test names | Generic names like "test1", "should work" |
+| Keep tests independent | Shared mutable state between tests |
+| Mock only external boundaries | Mocking your own code extensively |
+| Use waitFor, not sleep | setTimeout/sleep in tests |
+| Make assertions specific | toBeDefined() for everything |
+| Run tests in random order | Assuming test execution order |
+
+## Related Skills
 
-## Guidelines
-- Test behavior, not implementation
-- Keep tests independent
-- Mock only external dependencies
-- Use realistic test data
+- `developing-test-driven` - TDD with proper patterns
+- `testing-with-vitest` - Vitest testing framework
+- `testing-with-playwright` - E2E testing patterns
+- `debugging-systematically` - Debug flaky test failures

package/plugin/skills/methodology/token-optimization/SKILL.md

@@ -1,51 +1,90 @@
 ---
-name: token-optimization
-description: Token/cost optimization. Use for efficient AI interactions.
+name: optimizing-tokens
+description: AI agent maximizes efficiency and minimizes costs through strategic token usage while maintaining output quality. Use when managing AI interactions, designing prompts, or reducing costs.
 ---
 
-# Token Optimization Skill
+# Optimizing Tokens
 
-## Strategies
+## Quick Start
 
-### 1. Concise Prompts
-```
-# Bad
-Can you please help me understand what this function does
-and explain it in detail with examples?
+1. **Analyze** - Identify input vs output token distribution
+2. **Minimize Context** - Read only relevant file sections, not entire files
+3. **Optimize Prompts** - Use direct commands, remove filler words
+4. **Structure Outputs** - Request concise formats (JSON over prose)
+5. **Batch Operations** - Combine related requests, avoid duplicate context
+6. **Select Model** - Match model tier to task complexity
 
-# Good
-Explain this function briefly.
-```
+## Features
 
-### 2. Targeted Reading
-```
-# Bad
-Read("entire-large-file.ts")
+| Feature | Description | Guide |
+|---------|-------------|-------|
+| Context Targeting | Read only needed code sections | Line ranges, pattern search, summaries |
+| Prompt Efficiency | Direct commands vs verbose requests | 79% reduction possible |
+| Output Formatting | Structured concise responses | JSON/YAML over verbose explanations |
+| Model Selection | Right model for task complexity | Haiku: simple, Sonnet: standard, Opus: complex |
+| Batching | Combine related operations | Single request with multiple outputs |
+| Caching | Avoid redundant computation | Cache by content hash + timestamp |
 
-# Good
-Read("file.ts", { offset: 50, limit: 30 })
-```
+## Common Patterns
 
-### 3. Efficient Searches
 ```
-# Bad
-Grep(".*") in all files
+# Prompt Optimization (79% reduction)
+INEFFICIENT (120 tokens):
+"I would really appreciate it if you could help me
+with this task. What I need you to do is to please
+analyze this code and look for any bugs..."
+
+EFFICIENT (25 tokens):
+"Analyze for bugs, error handling issues, security.
+For each: location, problem, fix."
+
+# Context Optimization
+INEFFICIENT: Read entire 1000-line file
+EFFICIENT: Read lines 45-60 around target function
 
-# Good
-Grep("specificPattern", { path: "src/", glob: "*.ts" })
+# Output Format
+INEFFICIENT: "Please explain in detail..."
+EFFICIENT: "Output: JSON {name, severity, fix}"
+
+# Batching
+INEFFICIENT:
+  Request 1: "Given code [100 lines], find bugs"
+  Request 2: "Given code [same 100 lines], add types"
+
+EFFICIENT:
+  Single request: "Given code [100 lines]:
+  1. Find bugs
+  2. Add types"
 ```
 
-### 4. Batch Operations
 ```
-# Bad
-Multiple separate tool calls
+# Model Selection Guide
+| Task Type | Model | Examples |
+|-----------|-------|----------|
+| Simple | Haiku | Formatting, syntax check, lookups |
+| Standard | Sonnet | Features, bugs, reviews, tests |
+| Complex | Opus | Architecture, security, critical code |
 
-# Good
-Combined operations in one call
+# Search Efficiency
+INEFFICIENT: grep ".*" / (matches everything)
+EFFICIENT: grep "handleAuth" src/ --type ts
 ```
 
-## Savings
-- 30-70% reduction possible
-- Focus on high-value output
-- Minimize unnecessary context
-- Use token-efficient mode
+## Best Practices
+
+| Do | Avoid |
+|----|-------|
+| Read only what's needed - use line ranges | Reading entire files for one function |
+| Use direct language - commands over requests | Verbose, polite phrasing in prompts |
+| Structure outputs - JSON/YAML over prose | Requesting detailed explanations for simple tasks |
+| Batch operations - combine related requests | Repeating context across multiple requests |
+| Choose right model - Haiku for simple tasks | Using most powerful model for everything |
+| Limit search results - use head_limit | Unbounded searches returning thousands of results |
+| Cache results - avoid redundant computation | Re-analyzing unchanged files |
+| Progressive loading - start minimal, expand | Loading full context when partial suffices |
+
+## Related Skills
+
+- `dispatching-parallel-agents` - Efficient multi-agent patterns
+- `writing-plans` - Structured planning reduces iteration
+- `thinking-sequentially` - Organized reasoning saves tokens

package/plugin/skills/methodology/verification-before-completion/SKILL.md

@@ -1,32 +1,132 @@
 ---
-name: verification-before-completion
-description: Evidence-based verification. Use before marking tasks complete.
+name: verifying-before-completion
+description: AI agent validates work through evidence-based verification with comprehensive checklists, automated validation, and proof-of-work documentation. Use when completing tasks, preparing for review, or ensuring quality.
 ---
 
-# Verification Before Completion Skill
-
-## Checklist
-Before marking complete:
-
-- [ ] **Tests pass** - All tests green
-- [ ] **Manual test** - Verified manually
-- [ ] **Edge cases** - Considered and handled
-- [ ] **Errors** - Error handling works
-- [ ] **Types** - No type errors
-- [ ] **Lint** - No lint errors
-
-## Verification Steps
-1. Run full test suite
-2. Test happy path manually
-3. Test error cases
-4. Check type safety
-5. Verify in production-like env
-
-## Evidence
-Document verification:
-```markdown
-## Verification
-- Tests: ✅ 45 passed
-- Manual: ✅ Tested [scenario]
-- Edge cases: ✅ Handled [case]
+# Verifying Before Completion
+
+## Quick Start
+
+1. **Functional** - All acceptance criteria met, happy path works, edge cases handled
+2. **Technical** - Tests pass, coverage met, lint clean, build succeeds
+3. **Security** - No secrets exposed, input sanitized, auth verified
+4. **Performance** - Response time acceptable, no N+1, no memory leaks
+5. **Documentation** - Code comments, API docs, README updated
+6. **Evidence** - Collect screenshots, test output, metrics for proof
+
+## Features
+
+| Feature | Description | Guide |
+|---------|-------------|-------|
+| Universal Checklist | Comprehensive validation | Functional, technical, security, perf, docs |
+| Evidence Collection | Proof of verification | Test output, screenshots, metrics |
+| Automated Pipeline | CI/CD validation | Type check, lint, test, build, audit |
+| Type-Specific Checks | Context-aware validation | UI, API, migration, bug fix, optimization |
+| Pre-Commit Hooks | Catch issues early | lint-staged, related tests |
+| Sign-Off Template | Formal completion record | Verified by, date, evidence links |
+
+## Common Patterns
+
+```
+# Universal Verification Checklist
+FUNCTIONAL:
+[ ] All acceptance criteria met
+[ ] Happy path works correctly
+[ ] Edge cases handled
+[ ] Error handling works
+[ ] Input validation works
+
+TECHNICAL:
+[ ] Tests pass (unit, integration, E2E)
+[ ] Coverage meets threshold (80%+)
+[ ] No TypeScript/lint errors
+[ ] Build succeeds
+[ ] No security vulnerabilities
+
+DOCUMENTATION:
+[ ] Complex logic commented
+[ ] API documentation updated
+[ ] README updated if needed
+```
+
+```bash
+# Automated Verification Script
+npm run lint         # Lint check
+npm run typecheck    # Type check
+npm test             # Unit tests
+npm run build        # Build verification
+npm audit            # Security audit
+
+# Full verification
+npm run verify       # Runs all checks
+```
+
 ```
+# Evidence Documentation Template
+## Test Evidence
+$ npm test
+Test Suites: 15 passed
+Tests: 87 passed
+Coverage: 85.2%
+
+## Manual Verification
+| Step | Expected | Actual | Status |
+|------|----------|--------|--------|
+| Login | Form appears | Works | Pass |
+| Submit | Success msg | Shows | Pass |
+
+## Performance Metrics
+| Metric | Baseline | Current | Status |
+|--------|----------|---------|--------|
+| Bundle | 245 KB | 248 KB | Pass |
+| API | 150ms | 145ms | Pass |
+
+## Sign-Off
+[x] All tests pass
+[x] Manual testing complete
+[x] Ready for review
+Verified by: [Name] on [Date]
+```
+
+```
+# Type-Specific Checklists
+UI COMPONENT:
+[ ] Renders in all browsers
+[ ] Responsive mobile/tablet/desktop
+[ ] Loading/error/empty states
+[ ] Keyboard accessible
+[ ] Matches design specs
+
+API ENDPOINT:
+[ ] Correct status codes
+[ ] Response matches schema
+[ ] Auth/authz enforced
+[ ] Input validated
+[ ] Documented in OpenAPI
+
+BUG FIX:
+[ ] Root cause identified
+[ ] Fix addresses root cause
+[ ] Regression test added
+[ ] No new bugs introduced
+```
+
+## Best Practices
+
+| Do | Avoid |
+|----|-------|
+| Run all tests before marking complete | Skipping verification steps |
+| Document evidence of verification | Marking complete without evidence |
+| Test both happy and unhappy paths | Assuming tests are enough |
+| Verify on multiple browsers/devices | Ignoring edge cases |
+| Check performance impact | Skipping security checks |
+| Use automated verification | Merging without green CI |
+| Include screenshots for UI | Forgetting mobile testing |
+| Self-review before requesting | Rushing verification |
+
+## Related Skills
+
+- `finishing-development-branches` - Complete branch preparation
+- `executing-plans` - Quality gates during execution
+- `debugging-systematically` - Verify fixes work
+- `developing-test-driven` - Build verification into process