oh-my-codex 0.4.3 → 0.5.0

package/skills/deepinit/SKILL.md

@@ -1,320 +0,0 @@
----
-name: deepinit
-description: Deep codebase initialization with hierarchical AGENTS.md documentation
----
-
-# Deep Init Skill
-
-Creates comprehensive, hierarchical AGENTS.md documentation across the entire codebase.
-
-## Core Concept
-
-AGENTS.md files serve as **AI-readable documentation** that helps agents understand:
-- What each directory contains
-- How components relate to each other
-- Special instructions for working in that area
-- Dependencies and relationships
-
-## Hierarchical Tagging System
-
-Every AGENTS.md (except root) includes a parent reference tag:
-
-```markdown
-<!-- Parent: ../AGENTS.md -->
-```
-
-This creates a navigable hierarchy:
-```
-/AGENTS.md                          ← Root (no parent tag)
-├── src/AGENTS.md                   ← <!-- Parent: ../AGENTS.md -->
-│   ├── src/components/AGENTS.md    ← <!-- Parent: ../AGENTS.md -->
-│   └── src/utils/AGENTS.md         ← <!-- Parent: ../AGENTS.md -->
-└── docs/AGENTS.md                  ← <!-- Parent: ../AGENTS.md -->
-```
-
-## AGENTS.md Template
-
-```markdown
-<!-- Parent: {relative_path_to_parent}/AGENTS.md -->
-<!-- Generated: {timestamp} | Updated: {timestamp} -->
-
-# {Directory Name}
-
-## Purpose
-{One-paragraph description of what this directory contains and its role}
-
-## Key Files
-{List each significant file with a one-line description}
-
-| File | Description |
-|------|-------------|
-| `file.ts` | Brief description of purpose |
-
-## Subdirectories
-{List each subdirectory with brief purpose}
-
-| Directory | Purpose |
-|-----------|---------|
-| `subdir/` | What it contains (see `subdir/AGENTS.md`) |
-
-## For AI Agents
-
-### Working In This Directory
-{Special instructions for AI agents modifying files here}
-
-### Testing Requirements
-{How to test changes in this directory}
-
-### Common Patterns
-{Code patterns or conventions used here}
-
-## Dependencies
-
-### Internal
-{References to other parts of the codebase this depends on}
-
-### External
-{Key external packages/libraries used}
-
-<!-- MANUAL: Any manually added notes below this line are preserved on regeneration -->
-```
-
-## Execution Workflow
-
-### Step 1: Map Directory Structure
-
-```
-spawn_sub_agent(subagent_type="explore", model="haiku",
-  prompt="List all directories recursively. Exclude: node_modules, .git, dist, build, __pycache__, .venv, coverage, .next, .nuxt")
-```
-
-### Step 2: Create Work Plan
-
-Generate todo items for each directory, organized by depth level:
-
-```
-Level 0: / (root)
-Level 1: /src, /docs, /tests
-Level 2: /src/components, /src/utils, /docs/api
-...
-```
-
-### Step 3: Generate Level by Level
-
-**IMPORTANT**: Generate parent levels before child levels to ensure parent references are valid.
-
-For each directory:
-1. Read all files in the directory
-2. Analyze purpose and relationships
-3. Generate AGENTS.md content
-4. Write file with proper parent reference
-
-### Step 4: Compare and Update (if exists)
-
-When AGENTS.md already exists:
-
-1. **Read existing content**
-2. **Identify sections**:
-   - Auto-generated sections (can be updated)
-   - Manual sections (`<!-- MANUAL -->` preserved)
-3. **Compare**:
-   - New files added?
-   - Files removed?
-   - Structure changed?
-4. **Merge**:
-   - Update auto-generated content
-   - Preserve manual annotations
-   - Update timestamp
-
-### Step 5: Validate Hierarchy
-
-After generation, run validation checks:
-
-| Check | How to Verify | Corrective Action |
-|-------|--------------|-------------------|
-| Parent references resolve | Read each AGENTS.md, check `<!-- Parent: -->` path exists | Fix path or remove orphan |
-| No orphaned AGENTS.md | Compare AGENTS.md locations to directory structure | Delete orphaned files |
-| Completeness | List all directories, check for AGENTS.md | Generate missing files |
-| Timestamps current | Check `<!-- Generated: -->` dates | Regenerate outdated files |
-
-Validation script pattern:
-```bash
-# Find all AGENTS.md files
-find . -name "AGENTS.md" -type f
-
-# Check parent references
-grep -r "<!-- Parent:" --include="AGENTS.md" .
-```
-
-## Smart Delegation
-
-| Task | Agent |
-|------|-------|
-| Directory mapping | `explore` |
-| File analysis | `architect-low` |
-| Content generation | `writer` |
-| AGENTS.md writes | `writer` |
-
-## Empty Directory Handling
-
-When encountering empty or near-empty directories:
-
-| Condition | Action |
-|-----------|--------|
-| No files, no subdirectories | **Skip** - do not create AGENTS.md |
-| No files, has subdirectories | Create minimal AGENTS.md with subdirectory listing only |
-| Has only generated files (*.min.js, *.map) | Skip or minimal AGENTS.md |
-| Has only config files | Create AGENTS.md describing configuration purpose |
-
-Example minimal AGENTS.md for directory-only containers:
-```markdown
-<!-- Parent: ../AGENTS.md -->
-# {Directory Name}
-
-## Purpose
-Container directory for organizing related modules.
-
-## Subdirectories
-| Directory | Purpose |
-|-----------|---------|
-| `subdir/` | Description (see `subdir/AGENTS.md`) |
-```
-
-## Parallelization Rules
-
-1. **Same-level directories**: Process in parallel
-2. **Different levels**: Sequential (parent first)
-3. **Large directories**: Spawn dedicated agent per directory
-4. **Small directories**: Batch multiple into one agent
-
-## Quality Standards
-
-### Must Include
-- [ ] Accurate file descriptions
-- [ ] Correct parent references
-- [ ] Subdirectory links
-- [ ] AI agent instructions
-
-### Must Avoid
-- [ ] Generic boilerplate
-- [ ] Incorrect file names
-- [ ] Broken parent references
-- [ ] Missing important files
-
-## Example Output
-
-### Root AGENTS.md
-```markdown
-<!-- Generated: 2024-01-15 | Updated: 2024-01-15 -->
-
-# my-project
-
-## Purpose
-A web application for managing user tasks with real-time collaboration features.
-
-## Key Files
-| File | Description |
-|------|-------------|
-| `package.json` | Project dependencies and scripts |
-| `tsconfig.json` | TypeScript configuration |
-| `.env.example` | Environment variable template |
-
-## Subdirectories
-| Directory | Purpose |
-|-----------|---------|
-| `src/` | Application source code (see `src/AGENTS.md`) |
-| `docs/` | Documentation (see `docs/AGENTS.md`) |
-| `tests/` | Test suites (see `tests/AGENTS.md`) |
-
-## For AI Agents
-
-### Working In This Directory
-- Always install dependencies after modifying the project manifest
-- Use TypeScript strict mode
-- Follow ESLint rules
-
-### Testing Requirements
-- Run tests before committing
-- Ensure >80% coverage
-
-### Common Patterns
-- Use barrel exports (index.ts)
-- Prefer functional components
-
-## Dependencies
-
-### External
-- React 18.x - UI framework
-- TypeScript 5.x - Type safety
-- Vite - Build tool
-
-<!-- MANUAL: Custom project notes can be added below -->
-```
-
-### Nested AGENTS.md
-```markdown
-<!-- Parent: ../AGENTS.md -->
-<!-- Generated: 2024-01-15 | Updated: 2024-01-15 -->
-
-# components
-
-## Purpose
-Reusable React components organized by feature and complexity.
-
-## Key Files
-| File | Description |
-|------|-------------|
-| `index.ts` | Barrel export for all components |
-| `Button.tsx` | Primary button component |
-| `Modal.tsx` | Modal dialog component |
-
-## Subdirectories
-| Directory | Purpose |
-|-----------|---------|
-| `forms/` | Form-related components (see `forms/AGENTS.md`) |
-| `layout/` | Layout components (see `layout/AGENTS.md`) |
-
-## For AI Agents
-
-### Working In This Directory
-- Each component has its own file
-- Use CSS modules for styling
-- Export via index.ts
-
-### Testing Requirements
-- Unit tests in `__tests__/` subdirectory
-- Use React Testing Library
-
-### Common Patterns
-- Props interfaces defined above component
-- Use forwardRef for DOM-exposing components
-
-## Dependencies
-
-### Internal
-- `src/hooks/` - Custom hooks used by components
-- `src/utils/` - Utility functions
-
-### External
-- `clsx` - Conditional class names
-- `lucide-react` - Icons
-
-<!-- MANUAL: -->
-```
-
-## Triggering Update Mode
-
-When running on an existing codebase with AGENTS.md files:
-
-1. Detect existing files first
-2. Read and parse existing content
-3. Analyze current directory state
-4. Generate diff between existing and current
-5. Apply updates while preserving manual sections
-
-## Performance Considerations
-
-- **Cache directory listings** - Don't re-scan same directories
-- **Batch small directories** - Process multiple at once
-- **Skip unchanged** - If directory hasn't changed, skip regeneration
-- **Parallel writes** - Multiple agents writing different files simultaneously

package/skills/learn-about-omx/SKILL.md

@@ -1,37 +0,0 @@
----
-name: learn-about-omx
-description: Learn about your OMX usage patterns and get personalized recommendations
----
-
-# Learn About OMX
-
-Analyze your OMX usage patterns and provide personalized recommendations for getting more out of oh-my-codex.
-
-## Usage
-
-```
-/learn-about-omx
-```
-
-## Behavior
-
-1. **Scan usage data** from:
-   - `.omx/sessions/` for session history
-   - `.omx/state/` for mode usage patterns
-   - `.omx/notepad.md` for working memory
-   - `.omx/project-memory.json` for project context
-   - Agent flow traces for tool and agent usage
-2. **Analyze patterns**:
-   - Most-used modes and skills
-   - Agent types spawned most frequently
-   - Common workflows and task types
-   - Session durations and completion rates
-3. **Generate recommendations**:
-   - Underused features that match your workflow
-   - More efficient skill combinations
-   - Configuration optimizations
-   - Tips based on your usage profile
-
-## Output
-
-A personalized report with usage statistics and actionable recommendations for improving your OMX workflow.

package/skills/learner/SKILL.md

@@ -1,135 +0,0 @@
----
-name: learner
-description: Extract a learned skill from the current conversation
----
-
-# Learner Skill
-
-## The Insight
-
-Reusable skills are not code snippets to copy-paste, but **principles and decision-making heuristics** that teach Codex HOW TO THINK about a class of problems.
-
-**The difference:**
-- BAD (mimicking): "When you see ConnectionResetError, add this try/except block"
-- GOOD (reusable skill): "In async network code, any I/O operation can fail independently due to client/server lifecycle mismatches. The principle: wrap each I/O operation separately, because failure between operations is the common case, not the exception."
-
-A good skill changes how Codex APPROACHES problems, not just what code it produces.
-
-## Why This Matters
-
-Before extracting a skill, ask yourself:
-- "Could someone Google this in 5 minutes?" → If yes, STOP. Don't extract.
-- "Is this specific to THIS codebase?" → If no, STOP. Don't extract.
-- "Did this take real debugging effort to discover?" → If no, STOP. Don't extract.
-
-If a potential skill fails any of these questions, it's not worth saving.
-
-## Recognition Pattern
-
-Use /learner ONLY after:
-- Solving a tricky bug that required deep investigation
-- Discovering a non-obvious workaround specific to this codebase
-- Finding a hidden gotcha that wastes time when forgotten
-- Uncovering undocumented behavior that affects this project
-
-## The Approach
-
-### Extraction Process
-
-**Step 1: Gather Required Information**
-
-- **Problem Statement**: The SPECIFIC error, symptom, or confusion that occurred
-  - Include actual error messages, file paths, line numbers
-  - Example: "TypeError in src/hooks/session.ts:45 when sessionId is undefined after restart"
-
-- **Solution**: The EXACT fix, not general advice
-  - Include code snippets, file paths, configuration changes
-  - Example: "Add null check before accessing session.user, regenerate session on 401"
-
-- **Triggers**: Keywords that would appear when hitting this problem again
-  - Use error message fragments, file names, symptom descriptions
-  - Example: ["sessionId undefined", "session.ts TypeError", "401 session"]
-
-- **Scope**: Almost always Project-level unless it's a truly universal insight
-
-**Step 2: Quality Validation**
-
-The system REJECTS skills that are:
-- Too generic (no file paths, line numbers, or specific error messages)
-- Easily Googleable (standard patterns, library usage)
-- Vague solutions (no code snippets or precise instructions)
-- Poor triggers (generic words that match everything)
-
-**Step 3: Save Location**
-
-- **User-level**: ~/.codex/skills/omc-learned/ - Rare. Only for truly portable insights.
-- **Project-level**: .omx/skills/ - Default. Version-controlled with repo.
-
-### What Makes a USEFUL Skill
-
-**CRITICAL**: Not every solution is worth saving. A good skill is:
-
-1. **Non-Googleable**: Something you couldn't easily find via search
-   - BAD: "How to read files in TypeScript" ❌
-   - GOOD: "This codebase uses custom path resolution in ESM that requires fileURLToPath + specific relative paths" ✓
-
-2. **Context-Specific**: References actual files, error messages, or patterns from THIS codebase
-   - BAD: "Use try/catch for error handling" ❌
-   - GOOD: "The aiohttp proxy in server.py:42 crashes on ClientDisconnectedError - wrap StreamResponse in try/except" ✓
-
-3. **Actionable with Precision**: Tells you exactly WHAT to do and WHERE
-   - BAD: "Handle edge cases" ❌
-   - GOOD: "When seeing 'Cannot find module' in dist/, check tsconfig.json moduleResolution matches package.json type field" ✓
-
-4. **Hard-Won**: Took significant debugging effort to discover
-   - BAD: Generic programming patterns ❌
-   - GOOD: "Race condition in worker.ts - the Promise.all at line 89 needs await before the map callback returns" ✓
-
-### Anti-Patterns (DO NOT EXTRACT)
-
-- Generic programming patterns (use documentation instead)
-- Refactoring techniques (these are universal)
-- Library usage examples (use library docs)
-- Type definitions or boilerplate
-- Anything a junior dev could Google in 5 minutes
-
-## Skill Format
-
-Skills are saved as markdown with this structure:
-
-### YAML Frontmatter
-
-Standard metadata fields:
-- id, name, description, source, triggers, quality
-
-### Body Structure (Required)
-
-```markdown
-# [Skill Name]
-
-## The Insight
-What is the underlying PRINCIPLE you discovered? Not the code, but the mental model.
-Example: "Async I/O operations are independently failable. Client lifecycle != server lifecycle."
-
-## Why This Matters
-What goes wrong if you don't know this? What symptom led you here?
-Example: "Proxy server crashes on client disconnect, taking down other requests."
-
-## Recognition Pattern
-How do you know when this skill applies? What are the signs?
-Example: "Building any long-lived connection handler (proxy, websocket, SSE)"
-
-## The Approach
-The decision-making heuristic, not just code. How should Codex THINK about this?
-Example: "For each I/O operation, ask: what if this fails right now? Handle it locally."
-
-## Example (Optional)
-If code helps, show it - but as illustration of the principle, not copy-paste material.
-```
-
-**Key**: A skill is REUSABLE if Codex can apply it to NEW situations, not just identical ones.
-
-## Related Commands
-
-- /note - Save quick notes that survive compaction (less formal than skills)
-- /ralph - Start a development loop with learning capture