omgkit 2.1.1 → 2.3.0

package/plugin/skills/methodology/problem-solving/SKILL.md

@@ -1,355 +1,109 @@
 ---
-name: problem-solving
-description: Systematic 5-phase approaches when stuck on complex problems
+name: solving-problems
+description: AI agent applies a 5-phase systematic framework for tackling complex problems when conventional approaches fail. Use when stuck, blocked, or troubleshooting issues.
 category: methodology
 triggers:
   - stuck
   - blocked
-  - can't figure out
   - problem solving
-  - not working
+  - troubleshooting
+  - can't figure out
 ---
 
-# Problem Solving
-
-A **systematic 5-phase framework** for tackling complex problems when conventional approaches fail. This skill provides structured methods to break through blockers and find solutions efficiently.
+# Solving Problems
 
 ## Purpose
 
-When you're stuck, random attempts waste time and energy. This skill provides:
+Apply a systematic 5-phase framework for complex problems:
 
-- Structured approach to unknown problems
-- Multiple hypothesis generation
-- Systematic elimination process
-- Time-boxed investigation phases
-- Clear escalation criteria
+- Define problem boundaries clearly before investigating
+- Generate multiple hypotheses before testing any
+- Test hypotheses efficiently with time-boxing
+- Fix root causes, not just symptoms
+- Prevent recurrence with process improvements
 
-## The 5-Phase Framework
+## Quick Start
+
+1. **Define** (5-10 min) - Clarify what IS and IS NOT the problem, set success criteria
+2. **Hypothesize** (10-15 min) - Generate 3+ hypotheses BEFORE testing any
+3. **Test** (time-boxed) - Test cheapest hypothesis first, mark confirmed/eliminated
+4. **Solve** - Fix root cause, verify fix, add regression test
+5. **Prevent** - Analyze why it happened, implement preventive measures
+
+## Features
+
+| Feature | Description | Guide |
+|---------|-------------|-------|
+| Problem Boundary | Define what IS vs IS NOT the problem | List symptoms, affected scope, working parts |
+| Hypothesis Generation | Create 3+ theories before testing | Include evidence for/against, test cost |
+| Prioritized Testing | Test highest-value hypotheses first | Score = evidence x (1/cost) |
+| Root Cause Fix | Address underlying cause, not symptoms | Verify fix prevents recurrence |
+| Prevention Plan | Stop future occurrences | Code, process, monitoring changes |
+| Escalation Criteria | Know when to ask for help | Time-boxed out, all hypotheses eliminated |
+
+## Common Patterns
 
-### Phase 1: Define (5-10 minutes)
 ```
+# Define Phase
 BOUNDARY DEFINITION
-==================
 What IS the problem:
-- [ ] Specific error/behavior observed
-- [ ] Exact steps to reproduce
-- [ ] When it started occurring
-- [ ] Affected scope (users, features, environments)
+- Specific error: [error message]
+- Steps to reproduce: [steps]
+- When started: [date/commit]
 
 What is NOT the problem:
-- [ ] What still works correctly
-- [ ] Unrelated symptoms
-- [ ] Red herrings already eliminated
+- What still works: [list]
+- Red herrings eliminated: [list]
 
 Success criteria:
-- [ ] What does "solved" look like?
-- [ ] How will we verify the fix?
-```
+- What does "solved" look like?
 
-### Phase 2: Hypothesize (10-15 minutes)
-```
-HYPOTHESIS GENERATION (minimum 3)
-================================
-H1: [Most likely] ________________________
-    Evidence for: ________________________
-    Evidence against: ____________________
-    Test cost: Low / Medium / High
-
-H2: [Second likely] ______________________
-    Evidence for: ________________________
-    Evidence against: ____________________
-    Test cost: Low / Medium / High
+# Hypothesize Phase
+H1: [Most likely] - Evidence: ___ - Test cost: Low
+H2: [Second likely] - Evidence: ___ - Test cost: Medium
+H3: [Less likely] - Evidence: ___ - Test cost: High
 
-H3: [Unlikely but possible] ______________
-    Evidence for: ________________________
-    Evidence against: ____________________
-    Test cost: Low / Medium / High
-
-RULE: Generate hypotheses BEFORE testing any of them.
-```
-
-### Phase 3: Test (Time-boxed per hypothesis)
-```
-HYPOTHESIS TESTING ORDER
-========================
-Sort by: (Evidence strength) × (1 / Test cost)
+RULE: Generate hypotheses BEFORE testing any.
 
+# Test Phase
 Test H1: [15 min box]
-  Action: ________________________________
-  Result: CONFIRMED / ELIMINATED / INCONCLUSIVE
-  If inconclusive: Need more data on __________
-
-Test H2: [15 min box]
-  Action: ________________________________
+  Action: ___
   Result: CONFIRMED / ELIMINATED / INCONCLUSIVE
-
-STOP when: Hypothesis confirmed OR all eliminated
 ```
 
-### Phase 4: Solve (Implementation)
-```
-SOLUTION IMPLEMENTATION
-=======================
-Root cause: ______________________________
-Solution approach: _______________________
-
-Implementation checklist:
-- [ ] Write the fix
-- [ ] Verify fix addresses root cause (not symptom)
-- [ ] Check for side effects
-- [ ] Add test to prevent regression
-- [ ] Document the issue and solution
-```
-
-### Phase 5: Prevent (Post-mortem)
-```
-PREVENTION ANALYSIS
-===================
-Why did this happen?
-- Immediate cause: _______________________
-- Contributing factors: __________________
-- Systemic issues: _______________________
-
-How do we prevent recurrence?
-- [ ] Code changes
-- [ ] Process changes
-- [ ] Monitoring/alerting
-- [ ] Documentation updates
-```
-
-## Features
-
-### 1. Root Cause Hypothesis Generator
-```javascript
-// Common hypothesis categories for software issues:
-
-const hypothesisCategories = {
-  data: [
-    "Invalid input data",
-    "Data corruption",
-    "Missing required data",
-    "Encoding/format mismatch",
-    "Stale/cached data"
-  ],
-  configuration: [
-    "Environment variable missing",
-    "Config file incorrect",
-    "Feature flag state",
-    "Permission misconfiguration",
-    "Version mismatch"
-  ],
-  timing: [
-    "Race condition",
-    "Timeout too short",
-    "Order of operations",
-    "Async/await issue",
-    "Deadlock"
-  ],
-  resources: [
-    "Memory exhaustion",
-    "Disk space",
-    "Connection pool depleted",
-    "Rate limiting",
-    "CPU throttling"
-  ],
-  external: [
-    "Third-party service down",
-    "Network connectivity",
-    "DNS resolution",
-    "Certificate expiry",
-    "API contract change"
-  ]
-};
-```
-
-### 2. Decision Tree Construction
-```
-START: Error occurs
-  |
-  +-- Is it reproducible?
-  |     |
-  |     +-- YES: Proceed to isolation
-  |     |
-  |     +-- NO: Focus on logging/monitoring
-  |           |
-  |           +-- Add debug logging
-  |           +-- Wait for recurrence
-  |           +-- Analyze patterns
-  |
-  +-- Can you isolate the component?
-        |
-        +-- YES: Deep dive that component
-        |
-        +-- NO: Binary search approach
-              |
-              +-- Disable half the system
-              +-- Does error persist?
-              +-- Narrow down iteratively
-```
-
-### 3. Risk Assessment Matrix
 ```
+# Risk Assessment Matrix
 | Hypothesis | Probability | Impact | Test Effort | Priority |
 |------------|-------------|--------|-------------|----------|
 | H1         | High        | High   | Low         | 1st      |
 | H2         | Medium      | High   | Medium      | 2nd      |
-| H3         | Low         | High   | Low         | 3rd      |
-| H4         | High        | Low    | High        | 4th      |
-```
-
-### 4. Time-Boxing Templates
-```
-INVESTIGATION TIME BOX: 2 hours total
-
-Phase 1 (Define):      15 min  [■■■□□□□□□□□□]
-Phase 2 (Hypothesize): 15 min  [■■■□□□□□□□□□]
-Phase 3 (Test):        60 min  [■■■■■■■■■■■■]
-Phase 4 (Solve):       20 min  [■■■■□□□□□□□□]
-Phase 5 (Prevent):     10 min  [■■□□□□□□□□□□]
-
-ESCALATION TRIGGER: If no progress after Phase 3, escalate.
 ```
 
 ## Use Cases
 
-### Stuck on Implementation
-```
-PROBLEM: Feature works locally but fails in staging
-
-Phase 1 - Define:
-  - Works: Local dev environment
-  - Fails: Staging environment
-  - Error: "Connection refused to service X"
-  - Started: After last deployment
-
-Phase 2 - Hypothesize:
-  H1: Environment variable not set in staging
-  H2: Network policy blocking connection
-  H3: Service X not deployed to staging
-  H4: Different service discovery mechanism
-
-Phase 3 - Test:
-  H1 Test: Check env vars → MISSING API_URL! ✓ CONFIRMED
-
-Phase 4 - Solve:
-  - Add API_URL to staging config
-  - Verify connection works
-  - Add config validation on startup
-
-Phase 5 - Prevent:
-  - Add env var validation script to CI
-  - Document all required env vars
-```
-
-### Performance Bottleneck
-```
-PROBLEM: API response time degraded from 100ms to 2s
-
-Phase 1 - Define:
-  - Specific: GET /api/users endpoint
-  - Started: Monday after deployment
-  - Scope: All users, all requests
-
-Phase 2 - Hypothesize:
-  H1: N+1 query introduced
-  H2: Missing database index
-  H3: External API slowdown
-  H4: Resource contention
-
-Phase 3 - Test:
-  H1: Query count check → 1 query, not N+1
-  H2: EXPLAIN ANALYZE → Full table scan! ✓ CONFIRMED
-
-Phase 4 - Solve:
-  - Add index on users.organization_id
-  - Response time: 2s → 50ms
-
-Phase 5 - Prevent:
-  - Add query performance tests
-  - Require EXPLAIN for new queries in PR review
-```
-
-### Integration Failures
-```
-PROBLEM: Webhook deliveries failing intermittently
-
-Phase 1 - Define:
-  - Failure rate: ~5% of webhooks
-  - No pattern in time/endpoint
-  - Error: Timeout after 30s
-  - Started: Gradual increase over 2 weeks
-
-Phase 2 - Hypothesize:
-  H1: Receiving servers slow
-  H2: Our server resource exhaustion
-  H3: Network issues
-  H4: Payload size growth
-
-Phase 3 - Test:
-  H1: Check receiving server logs → Mixed results
-  H2: Monitor our CPU/memory → Normal
-  H3: Network packet loss test → Normal
-  H4: Analyze payload sizes → 10x increase! ✓ CONFIRMED
-
-Phase 4 - Solve:
-  - Compress payloads
-  - Increase timeout for large payloads
-  - Add pagination for large datasets
-
-Phase 5 - Prevent:
-  - Add payload size monitoring
-  - Set alerts for size thresholds
-```
+- Debugging complex bugs when conventional approaches fail
+- Troubleshooting production incidents with unknown root causes
+- Analyzing intermittent failures or race conditions
+- Investigating performance regressions
+- Resolving integration issues between systems
 
 ## Best Practices
 
-### Do's
-- **Generate multiple hypotheses** before testing any
-- **Test cheapest hypothesis first** when evidence is equal
-- **Time-box each phase** to prevent rabbit holes
-- **Document failed approaches** - they're valuable data
-- **Escalate when time-boxed out** - don't hero-code
-
-### Don'ts
-- Don't test the first idea that comes to mind
-- Don't spend 4 hours on 1 hypothesis
-- Don't discard hypotheses without testing
-- Don't fix symptoms without understanding root cause
-- Don't skip the prevention phase
-
-### Escalation Criteria
-```
-ESCALATE WHEN:
-- [ ] Time box exceeded with no progress
-- [ ] All hypotheses eliminated but problem persists
-- [ ] Problem scope larger than initially understood
-- [ ] Required access/knowledge not available
-- [ ] Business impact exceeds threshold
-
-ESCALATION FORMAT:
-"I've investigated [problem] for [time].
- Tested hypotheses: [H1, H2, H3]
- Current status: [findings]
- Blocker: [what's needed]
- Ask: [specific help needed]"
-```
+| Do | Avoid |
+|----|-------|
+| Generate multiple hypotheses before testing | Testing first idea that comes to mind |
+| Test cheapest hypothesis first when evidence equal | Spending 4 hours on 1 hypothesis |
+| Time-box each phase | Rabbit holes without progress |
+| Document failed approaches (valuable data) | Discarding hypotheses without testing |
+| Verify root cause, not just symptoms | Fixing symptoms without understanding cause |
+| Escalate when time-boxed out | Hero-coding beyond time limits |
+| Add regression tests for every fix | Skipping prevention phase |
 
 ## Related Skills
 
-- **systematic-debugging** - Four-phase debugging with 95% fix rate
-- **root-cause-tracing** - Deep investigation techniques
-- **sequential-thinking** - Structure reasoning as numbered thoughts
-- **brainstorming** - Generate more hypotheses
-- **verification-before-completion** - Ensure fix is complete
-
-## Integration
+See also these related skill documents for complementary techniques:
 
-Works seamlessly with debugging workflows:
-```
-1. Bug reported → problem-solving Phase 1 (Define)
-2. Reproduce → systematic-debugging Phase 1 (Reproduce)
-3. Investigate → problem-solving Phases 2-3 (Hypothesize, Test)
-4. Fix → systematic-debugging Phase 3 (Fix)
-5. Verify → verification-before-completion
-6. Prevent → problem-solving Phase 5 (Prevent)
-```
+- `debugging-systematically` - Four-phase debugging framework
+- `tracing-root-causes` - Deep investigation techniques
+- `thinking-sequentially` - Structure reasoning as numbered thoughts
+- `verifying-before-completion` - Ensure fix is complete

package/plugin/skills/methodology/receiving-code-review/SKILL.md

@@ -1,41 +1,90 @@
 ---
-name: receiving-code-review
-description: Receiving code review feedback. Use when handling review comments.
+name: receiving-code-reviews
+description: AI agent handles code review feedback professionally by categorizing, responding appropriately, and extracting learnings. Use when PR feedback arrives, addressing reviewer comments, or improving from feedback.
 ---
 
-# Receiving Code Review Skill
+# Receiving Code Reviews
 
-## Mindset
-- Feedback is about code, not you
-- Reviewers want to help
-- Every comment is an opportunity
+## Quick Start
 
-## Response Types
+1. **Pause** - Read all comments before responding; don't react immediately
+2. **Categorize** - Sort by type: blocking, suggestion, question, nitpick, praise
+3. **Prioritize** - Address blocking issues first, then questions, then suggestions
+4. **Respond** - Acknowledge every comment with specific action or reasoning
+5. **Learn** - Track recurring feedback patterns for improvement
 
-### Agree
-```
-Good catch! Fixed in abc123.
-```
+## Features
+
+| Feature | Description | Guide |
+|---------|-------------|-------|
+| Feedback Categories | Classify comment types | Blocking > Question > Suggestion > Nitpick |
+| Response Templates | Professional reply patterns | Agree, disagree-with-reason, clarify, defer |
+| Systematic Processing | Address all comments | Group related, post summary update |
+| Learning Extraction | Identify improvement patterns | Track recurring categories |
+| Anti-Patterns | Avoid defensive responses | No arguing, ignoring, or dismissiveness |
+| Progress Tracking | Communicate resolution status | Addressed X, Discussing Y, Deferred Z |
+
+## Common Patterns
 
-### Discuss
 ```
-I considered that, but chose X because [reason].
-What do you think about [alternative]?
+# Feedback Category Priority
+1. blocking - Must fix before merge
+2. question - Answer to unblock discussion
+3. suggestion - Consider and respond
+4. nitpick - Fix if easy, discuss if not
+5. praise - Thank the reviewer
+6. fyi - Acknowledge
+
+# Response Templates
+AGREE:
+"Good catch! Fixed in abc123."
+
+DISAGREE (with reason):
+"I considered this approach but chose current because:
+- [reason 1]
+- [reason 2]
+What do you think given these trade-offs?"
+
+CLARIFY:
+"Could you elaborate on [point]? Want to understand fully."
+
+DEFER:
+"Good idea! Outside PR scope - created follow-up: [link]"
 ```
 
-### Clarify
 ```
-Could you elaborate on [specific point]?
-I want to make sure I understand.
+# Processing Workflow
+1. Read ALL comments first (don't start responding)
+2. Categorize and sort by priority
+3. Group related comments together
+4. Address blocking issues first
+5. Answer questions to unblock
+6. Consider suggestions thoughtfully
+7. Post summary update:
+
+## Review Response Summary
+- Addressed: 8 comments
+- Pending discussion: 2 comments
+- Deferred (follow-up issues): 1 comment
+Ready for another look!
 ```
 
-## Process
-1. Read all comments first
-2. Address each comment
-3. Mark resolved when fixed
-4. Re-request review
+## Best Practices
+
+| Do | Avoid |
+|----|-------|
+| Read all comments before responding | Reacting immediately/defensively |
+| Categorize by priority (blocking first) | Ignoring comments without explanation |
+| Respond to every comment | Marking resolved without addressing |
+| Be specific - reference commit hashes | Over-explaining simple changes |
+| Thank reviewers for insights | Taking feedback personally |
+| Ask for clarification when needed | Arguing about preferences endlessly |
+| Learn from recurring feedback | Dismissing nitpicks dismissively |
+| Re-request review when done | Delaying response to feedback |
+
+## Related Skills
 
-## Anti-Patterns
-- Defensive reactions
-- Ignoring comments
-- Changing without acknowledgment
+- `requesting-code-reviews` - How to request effective reviews
+- `finishing-development-branches` - Complete PR preparation
+- `verifying-before-completion` - Pre-review verification
+- `solving-problems` - Handle tough feedback constructively

package/plugin/skills/methodology/requesting-code-review/SKILL.md

@@ -1,38 +1,109 @@
 ---
-name: requesting-code-review
-description: Requesting code reviews. Use when submitting code for review.
+name: requesting-code-reviews
+description: AI agent requests effective code reviews through proper preparation, clear descriptions, and appropriate reviewer selection. Use when creating PRs, requesting feedback, or submitting for review.
 ---
 
-# Requesting Code Review Skill
+# Requesting Code Reviews
 
-## Before Requesting
-- [ ] Tests pass
-- [ ] Self-reviewed
-- [ ] No debug code
-- [ ] Docs updated
+## Quick Start
 
-## PR Description
-```markdown
+1. **Self-Review** - Review your own diff first, catch obvious issues
+2. **Prepare Code** - Tests pass, no debug code, documentation updated
+3. **Write Description** - Clear summary, changes list, testing info, screenshots
+4. **Select Reviewers** - Match expertise to changes, respect workload
+5. **Time Appropriately** - Early week, morning hours, avoid Fridays
+
+## Features
+
+| Feature | Description | Guide |
+|---------|-------------|-------|
+| Self-Review | Catch issues before requesting | Check debug code, TODOs, test coverage |
+| PR Description | Guide reviewers effectively | Summary, changes, testing, attention areas |
+| Reviewer Selection | Match expertise to needs | Code owner, domain expert, security reviewer |
+| PR Sizing | Optimal size for review quality | <400 lines ideal, split larger PRs |
+| Timing | When to request reviews | Morning, early week, check availability |
+| Reviewer Guidance | Help reviewers focus | Key areas, skip suggestions, questions |
+
+## Common Patterns
+
+```
+# PR Description Template
 ## Summary
-[What changed and why]
+[What changed and why - 2-3 sentences]
+Resolves #123
 
 ## Changes
-- [Specific change 1]
-- [Specific change 2]
+- [Bullet point each significant change]
 
 ## Testing
-- [ ] Unit tests added
-- [ ] Manual testing done
+### Automated Tests
+- [x] Unit tests added/updated
+- [x] Integration tests pass
+
+### Manual Testing
+1. [Step to verify]
+2. [Expected result]
 
 ## Screenshots
-[If UI changes]
+[For UI changes]
+
+## Areas Needing Review
+- Security: [specific file/concern]
+- Performance: [specific concern]
+
+## Checklist
+- [x] Self-review completed
+- [x] Tests pass locally
+- [x] Documentation updated
+```
 
-## Questions
-[Specific areas needing review]
+```
+# PR Size Guide
+| Size | Lines | Review Time | Recommendation |
+|------|-------|-------------|----------------|
+| Small | <100 | 15-30 min | Ideal for quality review |
+| Medium | <400 | 30-60 min | Acceptable |
+| Large | <800 | 1-2 hours | Consider splitting |
+| Too Large | 800+ | 2+ hours | Split required |
+
+# Reviewer Selection
+1. Code owner - maintains affected area
+2. Domain expert - knows the technology
+3. Security - for auth/crypto changes
+4. Architecture - for design changes
+
+Max reviewers: 4 (too many = diffused responsibility)
+```
+
+```
+# Self-Review Checklist
+[ ] No console.log/debug statements
+[ ] No commented-out code
+[ ] No hardcoded values (should be config)
+[ ] Error handling appropriate
+[ ] All tests pass
+[ ] New code has tests
+[ ] Complex logic has comments
+[ ] Commit messages clear
+[ ] Rebased on latest main
 ```
 
 ## Best Practices
-- Keep PRs small (<400 lines)
-- One concern per PR
-- Descriptive commit messages
-- Respond to feedback promptly
+
+| Do | Avoid |
+|----|-------|
+| Self-review first | Submitting PRs without testing |
+| Keep PRs small (<400 lines) | Creating massive PRs |
+| Write clear descriptions | Leaving descriptions empty |
+| Highlight key review areas | Expecting reviewers to find everything |
+| Choose reviewers wisely | Overloading single reviewers |
+| Be responsive to feedback | Ignoring reviewer availability |
+| Include screenshots for UI | Rushing reviewers |
+| Test thoroughly first | Wasting reviewer time on broken code |
+
+## Related Skills
+
+- `receiving-code-reviews` - Handle feedback professionally
+- `finishing-development-branches` - Complete PR preparation
+- `verifying-before-completion` - Pre-submission verification
+- `writing-plans` - Plan review-ready deliverables