oh-my-customcode 0.7.0 → 0.9.0

package/templates/.codex/skills/pipeline-architecture-patterns/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: pipeline-architecture-patterns
+description: Data pipeline architecture patterns for ETL/ELT design, orchestration, and data quality frameworks
+user-invocable: false
+---
+
+# Data Pipeline Architecture Patterns
+
+## Pipeline Architectures
+
+### ETL vs ELT (CRITICAL)
+- **ETL**: Extract → Transform (staging) → Load
+  - Traditional, on-premise data warehouses
+  - Pre-aggregation, complex transformations
+- **ELT**: Extract → Load (raw) → Transform (in warehouse)
+  - Cloud warehouses (Snowflake, BigQuery)
+  - Leverage warehouse compute power
+
+### Lambda Architecture
+- Batch layer: historical data processing
+- Speed layer: real-time stream processing
+- Serving layer: merge batch + real-time views
+- Complexity: maintain two codebases
+
+### Kappa Architecture
+- Stream-only processing
+- Single codebase for batch + real-time
+- Reprocessing via replay
+- Simpler than Lambda
+
+### Medallion Architecture
+- **Bronze**: Raw data (append-only)
+- **Silver**: Cleaned, conformed data
+- **Gold**: Business-level aggregations
+- Databricks pattern
+
+## Orchestration Patterns
+
+### DAG-Based Orchestration
+- Airflow, Prefect, Dagster
+- Task dependencies as DAG
+- Retries, backfills, scheduling
+
+### Event-Driven Orchestration
+- Kafka, Pub/Sub triggers
+- Real-time, low-latency
+- Decoupled producers/consumers
+
+### Hybrid Orchestration
+- Scheduled batch + event-driven streams
+- Example: Airflow DAG triggered by Kafka event
+
+## Data Quality Frameworks
+
+### Data Contracts (CRITICAL)
+- Define schema, freshness, volume expectations
+- Producer-consumer agreement
+- Break build on violation
+
+### Validation Frameworks
+- **Great Expectations**: Python-based expectations
+- **dbt tests**: SQL-based tests
+- **Soda**: YAML-based checks
+
+### Data Lineage
+- Track data origin and transformations
+- Debug data quality issues
+- Compliance and auditing
+
+## Idempotency Patterns
+
+### Idempotent Design (CRITICAL)
+- Same input → same output (no side effects)
+- Upserts instead of inserts
+- Partition replacement instead of append
+
+### Deduplication
+- Use unique keys
+- Window-based deduplication
+- Consumer group offset management
+
+## References
+- [Data Engineering Design Patterns](https://www.oreilly.com/library/view/data-engineering-design/9781098130725/)

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

@@ -0,0 +1,66 @@
+---
+name: postgres-best-practices
+description: PostgreSQL best practices for database design, query optimization, and performance tuning
+user-invocable: false
+---
+
+# PostgreSQL Best Practices
+
+## Query Optimization
+
+### EXPLAIN ANALYZE (CRITICAL)
+- Use `EXPLAIN ANALYZE` to understand query plans
+- Identify slow operations: Seq Scan, Nested Loop
+- Check row estimates vs actual rows
+- Monitor buffers: shared hit vs read
+
+### Indexing (CRITICAL)
+- B-tree: default, most use cases
+- GIN: JSONB, arrays, full-text search
+- GiST: geometry, range types
+- BRIN: large sequential tables (time-series)
+- Partial indexes: filtered queries
+- Covering indexes (INCLUDE): avoid heap fetches
+
+### Index Maintenance
+- Create indexes concurrently: `CREATE INDEX CONCURRENTLY`
+- Monitor usage: `pg_stat_user_indexes`
+- Remove unused indexes
+- Reindex bloated indexes
+
+## Table Design
+
+### Partitioning (HIGH)
+- Range partitioning: time-series data
+- List partitioning: categorical data
+- Hash partitioning: even distribution
+- Declarative partitioning (PG 10+)
+
+### Data Types
+- Use appropriate types (int vs bigint, varchar vs text)
+- JSONB for semi-structured data
+- Arrays for multi-value columns
+- UUIDs for distributed IDs
+
+## Performance Tuning
+
+### Vacuum and Autovacuum
+- Autovacuum: default enabled
+- Monitor bloat: `pg_stat_user_tables`
+- Tune autovacuum thresholds
+- Manual VACUUM for large updates
+
+### Connection Pooling
+- Use pgBouncer or PgPool
+- Transaction pooling for short transactions
+- Session pooling for long transactions
+- Max connections: tune based on workload
+
+### Configuration
+- `shared_buffers`: 25% of RAM
+- `work_mem`: per operation, tune carefully
+- `effective_cache_size`: 50-75% of RAM
+- `random_page_cost`: 1.1 for SSD
+
+## References
+- [PostgreSQL Performance Optimization](https://wiki.postgresql.org/wiki/Performance_Optimization)

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

@@ -0,0 +1,222 @@
+---
+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

@@ -0,0 +1,277 @@
+---
+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: "sonnet")
+
+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: "sonnet")
+
+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: "sonnet")
+
+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: "sonnet")
+  Task(qa-engineer role → analyze results, model: "sonnet")
+
+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: "sonnet")
+  2. Task(qa-writer role → document test cases, model: "sonnet")
+  3. Task(qa-engineer role → execute tests, model: "sonnet")
+  4. Task(qa-writer role → generate report, model: "sonnet")
+
+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: "sonnet")
+  Task(qa-engineer role → test module B, model: "sonnet")
+  Task(qa-engineer role → test module C, model: "sonnet")
+```
+
+## Sub-agent Model Selection
+
+### Model Mapping
+
+| Agent | Recommended Model | Reason |
+|-------|-------------------|--------|
+| qa-planner | `sonnet` | Strategy requires balanced reasoning |
+| qa-writer | `sonnet` | Documentation quality matters |
+| qa-engineer | `sonnet` | Test execution needs accuracy |
+
+All QA agents typically use `sonnet` 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: "sonnet"
+)
+
+# Test documentation
+Task(
+  subagent_type: "general-purpose",
+  prompt: "Document test cases for API endpoints following qa-writer guidelines",
+  model: "sonnet"
+)
+
+# Test execution
+Task(
+  subagent_type: "general-purpose",
+  prompt: "Execute integration tests and report results following qa-engineer guidelines",
+  model: "sonnet"
+)
+```
+
+## 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:sonnet → qa-planner
+[Instance 2] results-analysis:sonnet → 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
+```
+
+## 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