oh-my-customcode 0.12.1 → 0.12.2

package/templates/.codex/skills/python-best-practices/SKILL.md

@@ -1,222 +0,0 @@
----
-name: python-best-practices
-description: Pythonic patterns from PEP 8 and PEP 20
-user-invocable: false
----
-
-## Purpose
-
-Apply idiomatic Python patterns and best practices from official Python documentation.
-
-## The Zen of Python (PEP 20)
-
-```
-Beautiful is better than ugly.
-Explicit is better than implicit.
-Simple is better than complex.
-Complex is better than complicated.
-Flat is better than nested.
-Sparse is better than dense.
-Readability counts.
-Special cases aren't special enough to break the rules.
-Although practicality beats purity.
-Errors should never pass silently.
-Unless explicitly silenced.
-In the face of ambiguity, refuse the temptation to guess.
-There should be one-- and preferably only one --obvious way to do it.
-Although that way may not be obvious at first unless you're Dutch.
-Now is better than never.
-Although never is often better than *right* now.
-If the implementation is hard to explain, it's a bad idea.
-If the implementation is easy to explain, it may be a good idea.
-Namespaces are one honking great idea -- let's do more of those!
-```
-
-## Rules
-
-### 1. Code Layout
-
-```yaml
-indentation:
-  - Use 4 spaces per indentation level
-  - Never mix tabs and spaces
-  - Continuation lines align vertically or use hanging indent
-
-line_length:
-  - Maximum 79 characters for code
-  - Maximum 72 characters for docstrings/comments
-  - Teams may agree on 99 characters for code
-
-blank_lines:
-  - Two blank lines around top-level definitions
-  - One blank line between method definitions
-  - Use sparingly inside functions
-```
-
-### 2. Imports
-
-```yaml
-rules:
-  - One import per line
-  - Position at file top, after docstrings
-  - Group order: standard library → third-party → local
-  - Separate groups with blank lines
-  - Prefer absolute imports
-  - Avoid wildcard imports (from X import *)
-
-example: |
-  import os
-  import sys
-
-  from third_party import lib
-
-  from myproject import module
-```
-
-### 3. Whitespace
-
-```yaml
-avoid:
-  - Extra spaces inside parentheses/brackets
-  - Spaces before commas or colons
-  - Spaces between function name and parenthesis
-  - Multiple spaces for alignment
-
-required:
-  - Single space around binary operators
-  - Spaces around -> in annotations
-  - No spaces around = for default parameters
-```
-
-### 4. Naming Conventions
-
-```yaml
-modules_packages:
-  style: lowercase_with_underscores
-  example: my_module
-
-classes:
-  style: CapWords
-  example: MyClass
-
-functions_variables:
-  style: lowercase_with_underscores
-  example: my_function, my_variable
-
-constants:
-  style: ALL_CAPS_WITH_UNDERSCORES
-  example: MAX_SIZE, DEFAULT_VALUE
-
-exceptions:
-  style: CapWords + Error suffix
-  example: ValueError, CustomError
-
-private:
-  single_underscore: _internal (weak internal)
-  double_underscore: __private (name mangling)
-  trailing_underscore: class_ (avoid keyword conflict)
-
-avoid:
-  - Single characters l, O, I (ambiguous)
-```
-
-### 5. Comments and Docstrings
-
-```yaml
-principles:
-  - Comments contradicting code are worse than none
-  - Use complete sentences
-  - Keep comments up to date
-
-block_comments:
-  - Indent at same level as code
-  - Start each line with # and space
-
-inline_comments:
-  - Minimum two spaces from code
-  - Avoid obvious statements
-
-docstrings:
-  - Write for all public modules, functions, classes, methods
-  - Use triple quotes
-  - First line: concise summary
-  - Blank line before detailed description
-```
-
-### 6. Programming Recommendations
-
-```yaml
-comparisons:
-  - Use 'is' and 'is not' for None, True, False
-  - Prefer isinstance() over type()
-  - Use 'is not' rather than 'not ... is'
-
-sequences:
-  - Test empty: if not seq: (not if len(seq) == 0)
-  - Use .startswith() and .endswith()
-
-exceptions:
-  - Derive from Exception, not BaseException
-  - Catch specific exceptions
-  - Avoid bare except clauses
-  - Use 'raise X from Y' for chaining
-
-functions:
-  - Use def, not lambda assignment
-  - Consistent return statements
-  - Use with for resource management
-
-type_hints:
-  - Follow PEP 484 syntax
-  - Space after colon in annotations
-  - No space before colon
-```
-
-### 7. Pythonic Idioms
-
-```yaml
-list_comprehension:
-  prefer: "[x*2 for x in items if x > 0]"
-  over: |
-    result = []
-    for x in items:
-        if x > 0:
-            result.append(x*2)
-
-context_managers:
-  prefer: "with open('file') as f:"
-  over: |
-    f = open('file')
-    try:
-        ...
-    finally:
-        f.close()
-
-unpacking:
-  prefer: "a, b = b, a"
-  over: |
-    temp = a
-    a = b
-    b = temp
-
-enumerate:
-  prefer: "for i, item in enumerate(items):"
-  over: "for i in range(len(items)):"
-
-dictionary:
-  prefer: "d.get(key, default)"
-  over: "d[key] if key in d else default"
-```
-
-## Application
-
-When writing or reviewing Python code:
-
-1. **Always** follow PEP 8 formatting
-2. **Always** write docstrings for public APIs
-3. **Prefer** explicit over implicit
-4. **Prefer** simple over complex
-5. **Prefer** flat over nested
-6. **Avoid** premature optimization
-7. **Use** list comprehensions when readable
-8. **Use** context managers for resources

package/templates/.codex/skills/qa-lead-routing/SKILL.md

@@ -1,290 +0,0 @@
----
-name: qa-lead-routing
-description: Coordinates QA workflow across planning, writing, and execution agents. Use when user requests testing, quality assurance, or test documentation.
-user-invocable: false
----
-
-# QA Lead Routing Skill
-
-## Purpose
-
-Coordinates QA team activities by routing tasks to qa-planner, qa-writer, and qa-engineer agents. This skill contains the coordination logic for orchestrating the complete quality assurance workflow.
-
-## QA Team Agents
-
-| Agent | Role | Output |
-|-------|------|--------|
-| qa-planner | Test planning | QA plans, test scenarios, acceptance criteria |
-| qa-writer | Documentation | Test cases, test reports, templates |
-| qa-engineer | Execution | Test results, defect reports, coverage reports |
-
-## Command Routing
-
-```
-QA Request → Routing → QA Agent(s)
-
-test_planning      → qa-planner
-test_documentation → qa-writer
-test_execution     → qa-engineer
-quality_analysis   → qa-planner + qa-engineer (parallel)
-full_qa_cycle      → all agents (sequential)
-```
-
-## Routing Rules
-
-### 1. Test Planning
-
-```
-User: "Create test plan for feature X"
-
-Route:
-  Task(qa-planner role → create test plan, model: "balanced")
-
-Output:
-  - Test scenarios
-  - Coverage targets
-  - Acceptance criteria
-  - Risk assessment
-```
-
-### 2. Test Documentation
-
-```
-User: "Document test cases for API"
-
-Route:
-  Task(qa-writer role → document test cases, model: "balanced")
-
-Output:
-  - Test case specifications
-  - Test data requirements
-  - Expected results
-  - Test templates
-```
-
-### 3. Test Execution
-
-```
-User: "Execute tests for module Y"
-
-Route:
-  Task(qa-engineer role → execute tests, model: "balanced")
-
-Output:
-  - Test execution results
-  - Pass/fail metrics
-  - Defect reports
-  - Coverage reports
-```
-
-### 4. Quality Analysis
-
-When analysis is needed (parallel execution):
-
-```
-User: "Analyze quality metrics"
-
-Route (parallel):
-  Task(qa-planner role → analyze strategy, model: "balanced")
-  Task(qa-engineer role → analyze results, model: "balanced")
-
-Aggregate:
-  Strategy insights + execution data
-```
-
-### 5. Full QA Cycle (Sequential)
-
-For complete quality assurance workflow:
-
-```
-User: "Run full QA cycle for feature Z"
-
-Route (sequential):
-  1. Task(qa-planner role → create test plan, model: "balanced")
-  2. Task(qa-writer role → document test cases, model: "balanced")
-  3. Task(qa-engineer role → execute tests, model: "balanced")
-  4. Task(qa-writer role → generate report, model: "balanced")
-
-Aggregate and present final report
-```
-
-## Full QA Cycle Workflow
-
-```
-1. Planning Phase (qa-planner)
-   - Analyze requirements
-   - Define test scenarios
-   - Set acceptance criteria
-   - Identify risks
-
-2. Documentation Phase (qa-writer)
-   - Write test cases
-   - Define test data
-   - Document expected results
-   - Create templates
-
-3. Execution Phase (qa-engineer)
-   - Execute test cases
-   - Record results
-   - Report defects
-   - Calculate coverage
-
-4. Reporting Phase (qa-writer)
-   - Aggregate results
-   - Generate reports
-   - Document findings
-   - Provide recommendations
-
-5. Aggregation (qa-lead routing)
-   - Combine all phases
-   - Present unified status
-   - Highlight critical issues
-```
-
-## Sequential vs Parallel Execution
-
-### Sequential (typical for QA workflow)
-
-QA workflow is typically sequential because each phase depends on the previous:
-- Planning must complete before documentation
-- Documentation must complete before execution
-- Execution must complete before reporting
-
-```
-qa-planner → qa-writer → qa-engineer → qa-writer
-   (plan)    (document)    (execute)     (report)
-```
-
-### Parallel (rare, for independent analyses)
-
-Only when tasks are truly independent:
-- Quality analysis (strategy + results)
-- Multi-module testing (independent modules)
-
-```
-Example:
-  Task(qa-engineer role → test module A, model: "balanced")
-  Task(qa-engineer role → test module B, model: "balanced")
-  Task(qa-engineer role → test module C, model: "balanced")
-```
-
-## Sub-agent Model Selection
-
-### Model Mapping
-
-| Agent | Recommended Model | Reason |
-|-------|-------------------|--------|
-| qa-planner | `balanced` | Strategy requires balanced reasoning |
-| qa-writer | `balanced` | Documentation quality matters |
-| qa-engineer | `balanced` | Test execution needs accuracy |
-
-All QA agents typically use `balanced` for balanced quality output.
-
-### Task Call Examples
-
-```
-# Test planning
-Task(
-  subagent_type: "general-purpose",
-  prompt: "Create comprehensive test plan for authentication feature following qa-planner guidelines",
-  model: "balanced"
-)
-
-# Test documentation
-Task(
-  subagent_type: "general-purpose",
-  prompt: "Document test cases for API endpoints following qa-writer guidelines",
-  model: "balanced"
-)
-
-# Test execution
-Task(
-  subagent_type: "general-purpose",
-  prompt: "Execute integration tests and report results following qa-engineer guidelines",
-  model: "balanced"
-)
-```
-
-## Display Format
-
-### Full QA Cycle
-
-```
-[Planning] Delegating to qa-planner...
-  → Test plan created (15 scenarios)
-
-[Documentation] Delegating to qa-writer...
-  → 15 test cases documented
-
-[Execution] Delegating to qa-engineer...
-  → 13 passed, 2 failed
-
-[Report] Generating summary...
-  Coverage: 85%
-  Pass Rate: 87%
-  Defects: 2 (1 High, 1 Medium)
-
-[Done] QA cycle completed
-```
-
-### Parallel Quality Analysis
-
-```
-[Analyzing] Spawning parallel analysis...
-
-[Instance 1] strategy-analysis:balanced → qa-planner
-[Instance 2] results-analysis:balanced → qa-engineer
-
-[Progress] ████████████ 2/2
-
-[Summary]
-  Strategy: Coverage targets met, add edge cases
-  Results: 85% pass rate, 2 critical defects
-
-Analysis completed.
-```
-
-## Integration with Other Agents
-
-- **Receives requirements from**: arch-speckit-agent (sw-architect)
-- **Reports quality status to**: dev-lead
-- **Coordinates with**: Language experts for automated tests
-- **Provides feedback to**: Development team via dev-lead
-
-## Metrics Tracking
-
-QA lead routing should aggregate these metrics:
-
-```yaml
-metrics:
-  test_coverage: percentage
-  pass_rate: percentage
-  defect_count: number
-  defect_severity: [critical, high, medium, low]
-  execution_time: duration
-  test_case_count: number
-```
-
-## Agent Teams Awareness
-
-Before routing via Task tool, check if Agent Teams is available (`CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` or TeamCreate/SendMessage tools present).
-
-**Self-check:** Does this task need 3+ agents, shared state, or inter-agent communication? If yes, prefer Agent Teams over Task tool. See R018 for the full decision matrix.
-
-| Scenario | Preferred |
-|----------|-----------|
-| Single QA phase (plan/write/execute) | Task Tool |
-| Full QA cycle (plan + write + execute + report) | Agent Teams |
-| Quality analysis (parallel strategy + results) | Agent Teams |
-| Quick test validation | Task Tool |
-
-## Usage
-
-This skill is NOT user-invocable. It should be automatically triggered when the main conversation detects QA intent.
-
-Detection criteria:
-- User requests testing
-- User mentions quality assurance
-- User asks for test plan/cases/execution
-- User requests QA metrics/reports
-- System detects need for quality verification

package/templates/.codex/skills/react-best-practices/SKILL.md

@@ -1,101 +0,0 @@
----
-name: react-best-practices
-description: React/Next.js performance optimization with 40+ rules in 8 categories
-user-invocable: false
----
-
-## When to Use
-
-- Writing React/Next.js components
-- Data fetching implementation
-- Performance review
-- Bundle size optimization
-
-## Categories by Priority
-
-### Critical Priority
-
-#### Waterfall Elimination
-```
-- Avoid sequential data fetching
-- Use parallel data fetching
-- Implement proper loading states
-- Prefetch critical data
-```
-
-#### Bundle Optimization
-```
-- Minimize client-side JavaScript
-- Use dynamic imports
-- Tree-shake unused code
-- Analyze bundle with tools
-```
-
-### High Priority
-
-#### Server-Side Performance
-```
-- Use Server Components by default
-- Minimize 'use client' directives
-- Implement streaming where possible
-- Cache server responses
-```
-
-### Medium-High Priority
-
-#### Client-Side Fetching
-```
-- Use SWR or React Query
-- Implement optimistic updates
-- Handle loading/error states
-- Cache API responses
-```
-
-### Medium Priority
-
-#### Rendering
-```
-- Avoid unnecessary re-renders
-- Use React.memo strategically
-- Implement useMemo/useCallback properly
-- Virtualize long lists
-```
-
-#### Caching
-```
-- Implement proper cache headers
-- Use ISR for dynamic content
-- Cache database queries
-- CDN caching strategies
-```
-
-#### Code Splitting
-```
-- Split by route
-- Lazy load below-fold content
-- Dynamic import heavy libraries
-- Preload critical chunks
-```
-
-### Low-Medium Priority
-
-#### Image Optimization
-```
-- Use next/image
-- Implement proper sizing
-- Use modern formats (WebP, AVIF)
-- Lazy load off-screen images
-```
-
-## Execution Flow
-
-```
-1. Identify optimization area
-2. Check relevant category rules
-3. Apply recommendations
-4. Verify improvements
-```
-
-## Scripts
-
-See `scripts/` directory for automation helpers.

package/templates/.codex/skills/redis-best-practices/SKILL.md

@@ -1,83 +0,0 @@
----
-name: redis-best-practices
-description: Redis best practices for caching, data structures, and in-memory data architecture
-user-invocable: false
----
-
-# Redis Best Practices
-
-## Caching Patterns
-
-### Cache-Aside (CRITICAL)
-- Read: check cache → miss → read DB → set cache
-- Write: update DB → invalidate cache
-- Best for read-heavy workloads
-
-### Write-Through
-- Write: update cache AND DB simultaneously
-- Ensures consistency
-- Higher write latency
-
-### Write-Behind
-- Write: update cache → async DB update
-- Lowest latency
-- Risk of data loss
-
-## Data Structures
-
-### String
-- Simple key-value: `SET key value`
-- Counters: `INCR`, `DECR`, `INCRBY`
-- Bit operations: `SETBIT`, `BITCOUNT`
-
-### Hash
-- Object storage: `HSET user:1 name "Alice"`
-- Partial updates: `HINCRBY user:1 visits 1`
-- Memory efficient for small hashes
-
-### List
-- Queues: `LPUSH`, `RPOP` (FIFO)
-- Stacks: `LPUSH`, `LPOP` (LIFO)
-- Capped collections: `LTRIM`
-
-### Set
-- Unique collections: `SADD`, `SMEMBERS`
-- Intersections: `SINTER`
-- Random sampling: `SRANDMEMBER`
-
-### Sorted Set
-- Leaderboards: `ZADD`, `ZRANGEBYSCORE`
-- Rate limiting: `ZADD timestamp`
-- Priority queues
-
-### Stream
-- Event log: `XADD`, `XREAD`
-- Consumer groups: `XGROUP`, `XACK`
-- Pub/Sub with persistence
-
-## Performance
-
-### Memory Optimization
-- Set maxmemory policy: `allkeys-lru`, `volatile-lru`
-- Monitor memory: `INFO memory`
-- Use appropriate data structures (Hash vs String)
-
-### Pipelining
-- Batch multiple commands
-- Reduces round-trip latency
-- Use for bulk operations
-
-## High Availability
-
-### Redis Cluster
-- Horizontal scaling
-- Automatic sharding (16384 slots)
-- Multi-master replication
-
-### Redis Sentinel
-- Automatic failover
-- Monitoring and notifications
-- Configuration provider
-
-## References
-- [Redis Best Practices](https://redis.io/docs/manual/patterns/)