oh-my-customcodex 0.1.0

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

@@ -0,0 +1,84 @@
+---
+name: pipeline-architecture-patterns
+description: Data pipeline architecture patterns for ETL/ELT design, orchestration, and data quality frameworks
+scope: core
+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/.claude/skills/pipeline-guards/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: pipeline-guards
+description: Safety constraints and quality gates for pipeline and workflow execution
+scope: core
+context: fork
+user-invocable: false
+---
+
+# Pipeline Guards Skill
+
+Defines mandatory safety constraints for all pipeline, workflow, and iterative execution within the oh-my-customcodex system. Prevents infinite loops, enforces timeouts, and establishes quality gates.
+
+**System-wide** — these guards apply to dag-orchestration, worker-reviewer-pipeline, and any iterative process.
+
+## Guard Limits
+
+| Guard | Default | Hard Cap | Applies To |
+|-------|---------|----------|------------|
+| Max iterations | 3 | 5 | worker-reviewer-pipeline |
+| Max DAG nodes | 20 | 30 | dag-orchestration |
+| Max parallel agents | 4 | 5 | R009 (all pipelines) |
+| Timeout per node | 300s | 600s | dag-orchestration nodes |
+| Timeout per pipeline | 900s | 1800s | worker-reviewer-pipeline |
+| Max retry count | 2 | 3 | Failure retry strategies |
+| Max PR improvement items | 20 | 50 | pr-auto-improve |
+| Max auto-improve items | 20 | 50 | omcodex:auto-improve |
+
+## Enforcement
+
+Guards are enforced at two levels:
+
+### Level 1: Skill-Level (Soft)
+Each skill checks guard limits before execution:
+
+```
+Before starting pipeline:
+  1. Check max_iterations ≤ hard cap
+  2. Check timeout ≤ hard cap
+  3. Check node count ≤ hard cap
+  If any exceeded → warn user, use hard cap value
+```
+
+### Level 2: Hook-Level (Hard)
+The stuck-detector hook monitors for guard violations:
+
+```
+PostToolUse → check:
+  - Iteration count > max_iterations?
+  - Elapsed time > timeout?
+  - Same error repeated > max_retry?
+  If any → emit advisory to stderr
+```
+
+## Quality Gates
+
+### Pipeline Quality Gate
+```
+[Quality Gate Check]
+├── Critical issues: {count} (must be 0)
+├── Major issues: {count} (must be ≤ threshold)
+├── Minor issues: {count} (informational)
+└── Gate: PASS | FAIL
+```
+
+### DAG Completion Gate
+```
+[DAG Completion Gate]
+├── Nodes completed: {n}/{total}
+├── Nodes failed: {count}
+├── Nodes skipped: {count}
+└── Gate: PASS | PARTIAL | FAIL
+```
+
+## Escalation Integration
+
+When guards are triggered, they integrate with existing advisory systems:
+
+| Event | Action |
+|-------|--------|
+| Max iterations reached | → stuck-recovery advisory |
+| Repeated failures | → model-escalation advisory |
+| Timeout approaching (80%) | → warn user, suggest early termination |
+| Hard cap hit | → force stop, report to user |
+
+## Guard Configuration
+
+Pipelines can override defaults (within hard caps):
+
+```yaml
+# In pipeline/workflow spec
+guards:
+  max_iterations: 4          # Override default 3, cannot exceed 5
+  timeout_per_node: 120      # Override default 300s
+  timeout_pipeline: 600      # Override default 900s
+  quality_gate: all_pass     # all_pass | majority_pass
+```
+
+## Kill Switch
+
+When a pipeline or workflow must be terminated:
+
+```
+[Kill Switch] Activated
+├── Reason: {max_iterations | timeout | user_request | stuck_detected}
+├── Pipeline: {name}
+├── Progress: {completed}/{total} steps
+├── Preserved state: /tmp/.codex-pipeline-$PPID.json
+└── Action: Stopped gracefully, state saved for resume
+```
+
+The kill switch:
+1. Signals all running agents to complete current operation
+2. Does NOT terminate mid-write (waits for current tool call)
+3. Saves pipeline state for potential resume
+4. Reports final status to user
+
+## State Preservation
+
+On guard-triggered termination:
+
+```json
+{
+  "pipeline": "feature-review",
+  "terminated_at": "2026-03-07T10:15:00Z",
+  "reason": "max_iterations_reached",
+  "completed_iterations": 3,
+  "last_verdict": "FAIL",
+  "remaining_issues": [
+    {"severity": "major", "file": "src/auth.ts", "line": 42, "description": "..."}
+  ],
+  "worker_last_output": "...",
+  "resumable": true
+}
+```
+
+## Display Format
+
+Guard warnings appear inline:
+
+```
+[Guard] ⚠ Iteration 3/3 — final attempt
+[Guard] ⚠ Timeout 80% (240s/300s) — consider early termination
+[Guard] 🛑 Max iterations reached — pipeline stopped
+[Guard] 🛑 Hard timeout (600s) — force stop
+```
+
+## Integration
+
+| Rule/Skill | Integration |
+|------------|-------------|
+| R009 | Max parallel agents enforced (hard cap: 5, soft default: 4) |
+| R010 | Guards run in orchestrator only |
+| R015 | Guard warnings displayed transparently |
+| dag-orchestration | Node count and timeout limits |
+| worker-reviewer-pipeline | Iteration and pipeline timeout limits |
+| pr-auto-improve | Improvement item count limits |
+| omcodex:auto-improve | Auto-improve item count limits |
+| stuck-recovery | Guard triggers feed into stuck detection |
+| model-escalation | Repeated failures trigger escalation advisory |
+
+## Override Policy
+
+- Defaults can be overridden in pipeline spec (within hard caps)
+- Hard caps can ONLY be changed by modifying this skill file
+- User cannot bypass hard caps at runtime
+- All overrides are logged and displayed (R015)
+
+## Limitations
+
+- Guards are advisory at skill level, hard at hook level
+- Cannot prevent infinite loops in agent reasoning (only tool call patterns)
+- State preservation is best-effort (process crash = state loss)
+- Resume from saved state requires user confirmation

package/templates/.claude/skills/post-release-followup/SKILL.md

@@ -0,0 +1,134 @@
+---
+name: post-release-followup
+description: Analyze release workflow findings and recommend follow-up actions — execute immediately or register as issues
+scope: harness
+user-invocable: false
+effort: medium
+---
+
+# Post-Release Follow-up
+
+## Purpose
+
+After PR creation in the auto-dev release workflow, collect unaddressed findings and present actionable follow-up recommendations. The user chooses: execute now, register as issues, or skip.
+
+## Workflow
+
+### 1. Collect Follow-up Candidates
+
+Gather unfinished work from multiple sources:
+
+**Source A — Remaining open issues**:
+- Run: `gh issue list --label verify-done --state open --json number,title,labels`
+- These are triaged issues NOT included in the current release
+
+**Source B — Deep-verify findings**:
+- Read the latest deep-verify output from `.codex/outputs/sessions/{today}/`
+- Extract any MEDIUM or LOW severity findings that were flagged but not fixed
+
+**Source C — Triage deferred items**:
+- Read the latest professor-triage output from `.codex/outputs/sessions/{today}/`
+- Extract items explicitly marked as deferred or P3
+
+**Source D — TODO markers in changed files**:
+- Run: `git diff develop...HEAD --name-only` to get changed files
+- Search changed files for `TODO`, `FIXME`, `HACK` markers added in this release
+
+**Source E — PR review feedback**:
+- Run: `gh api repos/{owner}/{repo}/pulls/{pr_number}/comments` and `gh api repos/{owner}/{repo}/issues/{pr_number}/comments`
+- Parse omc_pr_analyzer bot comments (Senior Architect, Project Colleague, Professor Synthesis)
+- Extract findings categorized as Critical, High, Medium
+- Identify: required fixes, recommended improvements, structural concerns
+
+### 2. Deduplicate and Categorize
+
+Remove duplicates (same issue referenced from multiple sources). Categorize:
+
+| Category | Criteria | Default Action |
+|----------|----------|----------------|
+| **Immediate** | P1/P2 remaining issues, MEDIUM+ verify findings, Critical/High PR review findings | Execute now |
+| **Trackable** | P3 issues, LOW verify findings, new TODOs, Medium PR review findings | Register as issue |
+| **Informational** | Already-tracked issues, cosmetic notes | Skip |
+
+### 3. Present to User
+
+Display follow-up summary:
+
+```
+[Follow-up] {n}개 후속 작업 발견
+
+━━━ 즉시 실행 추천 ({count}개) ━━━
+  1. {description} — 출처: {source}
+  2. {description} — 출처: {source}
+
+━━━ 이슈 등록 추천 ({count}개) ━━━
+  3. {description} — 출처: {source}
+  4. {description} — 출처: {source}
+
+━━━ 참고 사항 ({count}개) ━━━
+  5. {description} — 이미 #{issue_number}로 추적 중
+
+선택:
+  [A] 추천대로 실행 (즉시 실행 + 이슈 등록)
+  [B] 모두 즉시 실행
+  [C] 모두 이슈 등록
+  [D] 개별 선택 (항목별로 질문)
+  [E] 건너뛰기
+```
+
+Use AskUserQuestion (or equivalent user prompt) to get the choice.
+
+### 4. Process User Choice
+
+**Option A (추천대로)**:
+- "Immediate" items → delegate to appropriate specialist agents for execution
+- "Trackable" items → create GitHub issues via `gh issue create`
+- "Informational" items → skip
+
+**Option B (모두 즉시 실행)**:
+- All Immediate + Trackable items → delegate to specialist agents
+- Follow implementation patterns from the release workflow
+
+**Option C (모두 이슈 등록)**:
+- All Immediate + Trackable items → `gh issue create` with appropriate labels
+- Label: `professor` for auto-triage in next workflow run
+
+**Option D (개별 선택)**:
+- For each item, ask: `[{n}] {description} — 실행(E) / 이슈(I) / 건너뛰기(S)?`
+- Process each per user choice
+
+**Option E (건너뛰기)**:
+- Skip all follow-up actions
+- Complete workflow
+
+### 5. Report
+
+```
+[Follow-up Complete]
+├── 즉시 실행: {n}개 완료
+├── 이슈 등록: {n}개 (#{numbers})
+├── 건너뛰기: {n}개
+└── 총 처리: {total}개
+```
+
+## Issue Creation Template
+
+When creating follow-up issues:
+
+```bash
+gh issue create \
+  --title "{concise description}" \
+  --body "## Source\n\nDiscovered during v{version} release workflow.\n\n## Context\n\n{detailed context from triage/verify}\n\n## Suggested Action\n\n{recommendation}" \
+  --label "professor"
+```
+
+Add priority label (`P1`, `P2`, `P3`) based on categorization.
+
+## Notes
+
+- This skill runs in the main conversation context (via workflow skill step)
+- User interaction is expected — this is NOT a fully automated step
+- All file modifications delegated to specialist subagents per R010
+- Issue creation uses `gh` CLI directly (read-only operation pattern)
+- If no follow-up candidates found, report "No follow-up actions needed" and complete
+- PR review feedback is available shortly after PR creation — the omc_pr_analyzer bot comments automatically

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

@@ -0,0 +1,67 @@
+---
+name: postgres-best-practices
+description: PostgreSQL best practices for database design, query optimization, and performance tuning
+scope: core
+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/.claude/skills/pr-auto-improve/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: pr-auto-improve
+description: Opt-in post-PR analysis and improvement suggestions for code quality enhancement
+scope: core
+user-invocable: false
+---
+
+# PR Auto-Improvement Skill
+
+Analyzes pull requests after creation and suggests targeted improvements. **Strictly opt-in** — never runs automatically. User must explicitly request PR improvement.
+
+**Advisory-only** — suggests improvements, never force-pushes or modifies PRs without approval (R010).
+
+## Activation
+
+| Trigger | Behavior |
+|---------|----------|
+| User says "improve this PR" | Activate analysis |
+| User says "review PR #N" | Activate analysis |
+| PR created automatically | Do NOT activate (opt-in only) |
+| CI fails on PR | Suggest activation, do not auto-run |
+
+## Analysis Pipeline
+
+```
+1. Fetch PR diff (gh pr diff)
+2. Categorize changes by type:
+   - New code → check patterns, naming, structure
+   - Modified code → check consistency, regression risk
+   - Deleted code → check for orphaned references
+3. Run improvement checks (see checklist below)
+4. Generate improvement report
+5. User approves → create follow-up commit(s)
+```
+
+## Improvement Checklist
+
+| Category | Checks |
+|----------|--------|
+| **Code Quality** | Naming consistency, dead code, duplication, complexity |
+| **Type Safety** | Missing types, `any` usage, assertion safety |
+| **Error Handling** | Unhandled promises, missing try-catch, error propagation |
+| **Testing** | Missing test coverage for new functions, edge cases |
+| **Documentation** | Missing JSDoc for public APIs, outdated README refs |
+| **Security** | Hardcoded values, injection risks, permission checks |
+| **Performance** | Unnecessary re-renders, N+1 queries, missing indexes |
+
+## Report Format
+
+```
+[PR Auto-Improve] PR #{number} — {title}
+├── Files analyzed: {count}
+├── Improvements found: {count}
+│
+├── [Code Quality] ({count} items)
+│   ├── {file:line} — {description}
+│   └── {file:line} — {description}
+│
+├── [Testing] ({count} items)
+│   └── {file} — Missing test for {function}
+│
+├── [Documentation] ({count} items)
+│   └── {file:line} — {description}
+│
+└── Estimated effort: {low|medium|high}
+
+Apply improvements? [Y/n/select]
+```
+
+## Improvement Modes
+
+| Mode | Behavior |
+|------|----------|
+| `all` | Apply all suggested improvements |
+| `select` | User picks which improvements to apply |
+| `report` | Report only, no changes (default) |
+
+## Implementation Flow
+
+```
+User: "improve PR #215"
+  → Orchestrator activates pr-auto-improve
+  → Fetch PR diff via mgr-gitnerd
+  → Analyze with appropriate expert agent(s)
+  → Generate report
+  → User selects improvements
+  → Delegate fixes to specialist agents (R010)
+  → mgr-gitnerd creates follow-up commit
+```
+
+## Agent Selection for Fixes
+
+| File Type | Agent |
+|-----------|-------|
+| *.ts, *.tsx | lang-typescript-expert |
+| *.py | lang-python-expert |
+| *.go | lang-golang-expert |
+| *.kt | lang-kotlin-expert |
+| *.java | lang-java21-expert |
+| *.rs | lang-rust-expert |
+| Test files | qa-engineer |
+| Docs, README | arch-documenter |
+| Mixed | Multiple agents in parallel (R009) |
+
+## Integration
+
+| Rule | Integration |
+|------|-------------|
+| R009 | Multiple file fixes execute in parallel |
+| R010 | Orchestrator coordinates analysis and fix delegation |
+| R015 | Full transparency on what improvements are suggested and why |
+| R018 | 3+ fix agents → Agent Teams for coordination |
+| worker-reviewer-pipeline | Can chain: auto-improve → worker-reviewer for critical fixes |
+| pipeline-guards | Improvement count capped by guard limits |
+
+## Opt-In Safeguards
+
+- **NEVER** auto-activates on PR creation
+- **NEVER** pushes changes without user approval
+- **NEVER** modifies PR description or labels without approval
+- Report mode is default; changes require explicit "apply" command
+- All git operations go through mgr-gitnerd (R010)
+
+## Limitations
+
+- Analyzes only the PR diff, not the entire codebase
+- Cannot detect architectural issues (use dev-review for that)
+- Max 50 files per analysis (skip larger PRs with warning)
+- Does not run tests (delegates to qa-engineer if needed)