oh-my-codex-cli 0.1.0

package/.agent/skills/brainstorming/README.md

@@ -0,0 +1,41 @@
+# Brainstorming
+
+Refine rough ideas into fully-formed designs through structured Socratic questioning and incremental validation.
+
+## Quick Install
+
+```bash
+# Already installed at:
+~/.claude/skills/brainstorming/
+```
+
+## Usage
+
+```
+"Help me brainstorm a solution for real-time sync"
+"Explore different approaches for state management"
+"Design session for notification system"
+```
+
+## What It Does
+
+- ✅ Structured Socratic questioning
+- ✅ Alternative exploration
+- ✅ Incremental validation
+- ✅ Assumption challenging
+- ✅ Design space mapping
+
+## Files
+
+- `SKILL.md` - Complete brainstorming methodology
+- `README.md` - This quick start guide
+- `HOW_TO_USE.md` - Detailed questioning guide (Phase 1)
+- `references/` - Question frameworks (Phase 2)
+
+## When to Use
+
+- Before writing code
+- Before implementation plans
+- Exploring solution space
+- Validating assumptions
+- Design decisions

package/.agent/skills/brainstorming/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: brainstorming
+description: Refine rough ideas into designs through Socratic questioning, alternative exploration, incremental validation. Use before implementation.
+---
+
+# Brainstorming Ideas Into Designs
+
+## Overview
+
+Transform rough ideas into fully-formed designs through structured questioning and alternative exploration.
+
+**Core principle:** Ask questions to understand, explore alternatives, present design incrementally for validation.
+
+**Announce at start:** "I'm using the brainstorming skill to refine your idea into a design."
+
+## Quick Reference
+
+| Phase | Key Activities | Tool Usage | Output |
+|-------|---------------|------------|--------|
+| **1. Understanding** | Ask questions (one at a time) | AskUserQuestion for choices | Purpose, constraints, criteria |
+| **2. Exploration** | Propose 2-3 approaches | AskUserQuestion for approach selection | Architecture options with trade-offs |
+| **3. Design Presentation** | Present in 200-300 word sections | Open-ended questions | Complete design with validation |
+| **4. Design Documentation** | Write design document | writing-clearly-and-concisely skill | Design doc in docs/plans/ |
+| **5. Worktree Setup** | Set up isolated workspace | using-git-worktrees skill | Ready development environment |
+| **6. Planning Handoff** | Create implementation plan | writing-plans skill | Detailed task breakdown |
+
+## The Process
+
+Copy this checklist to track progress:
+
+```
+Brainstorming Progress:
+- [ ] Phase 1: Understanding (purpose, constraints, criteria gathered)
+- [ ] Phase 2: Exploration (2-3 approaches proposed and evaluated)
+- [ ] Phase 3: Design Presentation (design validated in sections)
+- [ ] Phase 4: Design Documentation (design written to docs/plans/)
+- [ ] Phase 5: Worktree Setup (if implementing)
+- [ ] Phase 6: Planning Handoff (if implementing)
+```
+
+### Phase 1: Understanding
+- Check current project state in working directory
+- Ask ONE question at a time to refine the idea
+- **Use AskUserQuestion tool** when you have multiple choice options
+- Gather: Purpose, constraints, success criteria
+
+**Example using AskUserQuestion:**
+```
+Question: "Where should the authentication data be stored?"
+Options:
+  - "Session storage" (clears on tab close, more secure)
+  - "Local storage" (persists across sessions, more convenient)
+  - "Cookies" (works with SSR, compatible with older approach)
+```
+
+### Phase 2: Exploration
+- Propose 2-3 different approaches
+- For each: Core architecture, trade-offs, complexity assessment
+- **Use AskUserQuestion tool** to present approaches as structured choices
+- Ask your human partner which approach resonates
+
+**Example using AskUserQuestion:**
+```
+Question: "Which architectural approach should we use?"
+Options:
+  - "Event-driven with message queue" (scalable, complex setup, eventual consistency)
+  - "Direct API calls with retry logic" (simple, synchronous, easier to debug)
+  - "Hybrid with background jobs" (balanced, moderate complexity, best of both)
+```
+
+### Phase 3: Design Presentation
+- Present in 200-300 word sections
+- Cover: Architecture, components, data flow, error handling, testing
+- Ask after each section: "Does this look right so far?" (open-ended)
+- Use open-ended questions here to allow freeform feedback
+
+### Phase 4: Design Documentation
+After design is validated, write it to a permanent document:
+- **File location:** `docs/plans/YYYY-MM-DD-<topic>-design.md` (use actual date and descriptive topic)
+- **RECOMMENDED SUB-SKILL:** Use elements-of-style:writing-clearly-and-concisely (if available) for documentation quality
+- **Content:** Capture the design as discussed and validated in Phase 3, organized into the sections that emerged from the conversation
+- Commit the design document to git before proceeding
+
+### Phase 5: Worktree Setup (for implementation)
+When design is approved and implementation will follow:
+- Announce: "I'm using the using-git-worktrees skill to set up an isolated workspace."
+- **REQUIRED SUB-SKILL:** Use superpowers:using-git-worktrees
+- Follow that skill's process for directory selection, safety verification, and setup
+- Return here when worktree ready
+
+### Phase 6: Planning Handoff
+Ask: "Ready to create the implementation plan?"
+
+When your human partner confirms (any affirmative response):
+- Announce: "I'm using the writing-plans skill to create the implementation plan."
+- **REQUIRED SUB-SKILL:** Use superpowers:writing-plans
+- Create detailed plan in the worktree
+
+## Question Patterns
+
+### When to Use AskUserQuestion Tool
+
+**Use AskUserQuestion for:**
+- Phase 1: Clarifying questions with 2-4 clear options
+- Phase 2: Architectural approach selection (2-3 alternatives)
+- Any decision with distinct, mutually exclusive choices
+- When options have clear trade-offs to explain
+
+**Benefits:**
+- Structured presentation of options with descriptions
+- Clear trade-off visibility for partner
+- Forces explicit choice (prevents vague "maybe both" responses)
+
+### When to Use Open-Ended Questions
+
+**Use open-ended questions for:**
+- Phase 3: Design validation ("Does this look right so far?")
+- When you need detailed feedback or explanation
+- When partner should describe their own requirements
+- When structured options would limit creative input
+
+**Example decision flow:**
+- "What authentication method?" → Use AskUserQuestion (2-4 options)
+- "Does this design handle your use case?" → Open-ended (validation)
+
+## When to Revisit Earlier Phases
+
+```dot
+digraph revisit_phases {
+    rankdir=LR;
+    "New constraint revealed?" [shape=diamond];
+    "Partner questions approach?" [shape=diamond];
+    "Requirements unclear?" [shape=diamond];
+    "Return to Phase 1" [shape=box, style=filled, fillcolor="#ffcccc"];
+    "Return to Phase 2" [shape=box, style=filled, fillcolor="#ffffcc"];
+    "Continue forward" [shape=box, style=filled, fillcolor="#ccffcc"];
+
+    "New constraint revealed?" -> "Return to Phase 1" [label="yes"];
+    "New constraint revealed?" -> "Partner questions approach?" [label="no"];
+    "Partner questions approach?" -> "Return to Phase 2" [label="yes"];
+    "Partner questions approach?" -> "Requirements unclear?" [label="no"];
+    "Requirements unclear?" -> "Return to Phase 1" [label="yes"];
+    "Requirements unclear?" -> "Continue forward" [label="no"];
+}
+```
+
+**You can and should go backward when:**
+- Partner reveals new constraint during Phase 2 or 3 → Return to Phase 1
+- Validation shows fundamental gap in requirements → Return to Phase 1
+- Partner questions approach during Phase 3 → Return to Phase 2
+- Something doesn't make sense → Go back and clarify
+
+**Don't force forward linearly** when going backward would give better results.
+
+## Key Principles
+
+| Principle | Application |
+|-----------|-------------|
+| **One question at a time** | Phase 1: Single question per message, use AskUserQuestion for choices |
+| **Structured choices** | Use AskUserQuestion tool for 2-4 options with trade-offs |
+| **YAGNI ruthlessly** | Remove unnecessary features from all designs |
+| **Explore alternatives** | Always propose 2-3 approaches before settling |
+| **Incremental validation** | Present design in sections, validate each |
+| **Flexible progression** | Go backward when needed - flexibility > rigidity |
+| **Announce usage** | State skill usage at start of session |

package/.agent/skills/build-fix/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: build-fix
+description: Fix build and TypeScript errors with minimal changes
+---
+
+# Build Fix Skill
+
+
+## Native Subagent Protocol (Codex)
+
+Codex supports native subagents. Delegate with `spawn_agent`, coordinate with `send_input`, collect via `wait`, and clean up with `close_agent`.
+
+Execution preference:
+1. Use native subagents first for independent workstreams (parallel when possible).
+2. Merge results in main thread and run final verification.
+3. Fallback only when delegation is blocked: use the `[ANALYST]`/`[ARCHITECT]`/`[EXECUTOR]`/`[REVIEWER]` structure in a single response.
+
+Minimal orchestration pattern:
+```text
+spawn_agent -> send_input (optional) -> wait -> close_agent
+```
+
+> Codex invocation: use `$build-fix ...` or `build-fix: ...`
+
+
+Fix build and TypeScript errors quickly with minimal code changes. Get the build green without refactoring.
+
+## When to Use
+
+This skill activates when:
+- User says "fix the build", "build is broken"
+- TypeScript compilation fails
+- `npm run build` or `tsc` reports errors
+- User requests "minimal fixes" for errors
+
+## What It Does
+
+Delegates to the `build-fixer` agent (Sonnet model) to:
+
+1. **Collect Errors**
+   - Run `npx tsc --noEmit` to get all TypeScript errors
+   - Or run `npm run build` to get build failures
+   - Categorize errors by type and severity
+
+2. **Fix Strategically**
+   - Add type annotations where missing
+   - Add null checks where needed
+   - Fix import/export statements
+   - Resolve module resolution issues
+   - Fix linter errors blocking build
+
+3. **Minimal Diff Strategy**
+   - NO refactoring of unrelated code
+   - NO architectural changes
+   - NO performance optimizations
+   - ONLY what's needed to make build pass
+
+4. **Verify**
+   - Run `npx tsc --noEmit` after each fix
+   - Ensure no new errors introduced
+   - Stop when build passes
+
+## Agent Delegation
+
+```
+[BUILD-FIXER | sonnet]
+BUILD FIX TASK
+
+Fix all build and TypeScript errors with minimal changes.
+
+Requirements:
+- Run tsc/build to collect errors
+- Fix errors one at a time
+- Verify each fix doesn't introduce new errors
+- NO refactoring, NO architectural changes
+- Stop when build passes
+
+Output: Build error resolution report with:
+- List of errors fixed
+- Lines changed per fix
+- Final build status"
+```
+
+## Stop Conditions
+
+The build-fixer agent stops when:
+- `npx tsc --noEmit` exits with code 0
+- `npm run build` completes successfully
+- No new errors introduced
+
+## Output Format
+
+```
+BUILD FIX REPORT
+================
+
+Errors Fixed: 12
+Files Modified: 8
+Lines Changed: 47
+
+Fixes Applied:
+1. src/utils/validation.ts:15 - Added return type annotation
+2. src/components/Header.tsx:42 - Added null check for props.user
+3. src/api/client.ts:89 - Fixed import path for axios
+...
+
+Final Build Status: ✓ PASSING
+Verification: npx tsc --noEmit (exit code 0)
+```
+
+## Best Practices
+
+- **One fix at a time** - Easier to verify and debug
+- **Minimal changes** - Don't refactor while fixing
+- **Document why** - Comment non-obvious fixes
+- **Test after** - Ensure tests still pass
+
+## Use with Other Skills
+
+Combine with other skills for comprehensive fixing:
+
+**With Ultrawork:**
+```
+$ultrawork fix all build errors
+```
+Spawns multiple build-fixer agents in parallel for different files.
+
+**With Ralph:**
+```
+$ralph fix the build
+```
+Keeps trying until build passes, even if it takes multiple iterations.
+
+**With Pipeline:**
+```
+$pipeline debug "build is failing"
+```
+Uses: explore → architect → build-fixer workflow.
+
+## Imported from everything-codex
+
+---
+name: ecc-build-fix
+description: Imported from everything-codex command build-fix
+---
+
+# Build and Fix
+
+
+## Native Subagent Protocol (Codex)
+
+Codex supports native subagents. Delegate with `spawn_agent`, coordinate with `send_input`, collect via `wait`, and clean up with `close_agent`.
+
+Execution preference:
+1. Use native subagents first for independent workstreams (parallel when possible).
+2. Merge results in main thread and run final verification.
+3. Fallback only when delegation is blocked: use the `[ANALYST]`/`[ARCHITECT]`/`[EXECUTOR]`/`[REVIEWER]` structure in a single response.
+
+Minimal orchestration pattern:
+```text
+spawn_agent -> send_input (optional) -> wait -> close_agent
+```
+
+Incrementally fix TypeScript and build errors:
+
+1. Run build: npm run build or pnpm build
+
+2. Parse error output:
+   - Group by file
+   - Sort by severity
+
+3. For each error:
+   - Show error context (5 lines before/after)
+   - Explain the issue
+   - Propose fix
+   - Apply fix
+   - Re-run build
+   - Verify error resolved
+
+4. Stop if:
+   - Fix introduces new errors
+   - Same error persists after 3 attempts
+   - User requests pause
+
+5. Show summary:
+   - Errors fixed
+   - Errors remaining
+   - New errors introduced
+
+Fix one error at a time for safety!