oh-my-customcode 0.9.2 → 0.9.4

package/templates/.codex/rules/SHOULD-agent-teams.md

@@ -1,183 +1,39 @@
 # [SHOULD] Agent Teams Rules
 
-> **Priority**: SHOULD - Actively use when available
-> **ID**: R018
-> **Condition**: Agent Teams feature is enabled locally
-
-## Purpose
-
-When Claude Code's Agent Teams feature is enabled on the local machine, actively leverage it for tasks that benefit from multi-agent collaboration, shared state, and peer-to-peer communication.
+> **Priority**: SHOULD | **ID**: R018 | **Condition**: Agent Teams enabled locally
 
 ## Detection
 
-Agent Teams availability is determined by:
-- Environment variable: `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1`
-- The presence of TeamCreate, SendMessage, TaskCreate/TaskList (team variants) tools
-
-When detected, Agent Teams becomes the **preferred coordination method** for qualifying tasks.
+Available when `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` or TeamCreate/SendMessage tools present.
 
 ## Decision Matrix
 
-| Scenario | Task Tool | Agent Teams | Preferred |
-|----------|-----------|-------------|-----------|
-| Simple independent subtasks | Low cost | Overkill | **Task Tool** |
-| Multi-step with shared state | Limited | Native support | **Agent Teams** |
-| Research requiring discussion | No peer comm | Peer messaging | **Agent Teams** |
-| Cost-sensitive batch ops | Lower tokens | Higher tokens | **Task Tool** |
-| Complex debugging across modules | Isolated context | Shared context | **Agent Teams** |
-| Code review + fix cycle | Sequential | Collaborative | **Agent Teams** |
-| Single file operations | Fast | Overhead | **Task Tool** |
-
-## When to Use Agent Teams
-
-### SHOULD Use Agent Teams For
-
-```
-Tasks requiring 3+ agents that need to coordinate
-Research tasks where agents need to share findings
-Debugging sessions spanning multiple modules
-Review + implementation cycles
-Any task where inter-agent communication adds value
-```
-
-### SHOULD Keep Task Tool For
-
-```
-Independent parallel subtasks (no shared state)
-Single-agent delegations
-Cost-sensitive batch operations
-Simple file operations
-When Agent Teams is not available
-```
-
-## CRITICAL: Self-Check Before Spawning Task Tool
-
-```
-╔══════════════════════════════════════════════════════════════════╗
-║  BEFORE USING TASK TOOL, ASK YOURSELF:                           ║
-║                                                                   ║
-║  1. Is Agent Teams available? (TeamCreate tool exists?)          ║
-║     → YES: Continue to step 2                                    ║
-║     → NO: Task tool is fine                                      ║
-║                                                                   ║
-║  2. Does this task qualify for Agent Teams?                      ║
-║     - 3+ agents needed?                                          ║
-║     - Shared state or coordination required?                     ║
-║     - Inter-agent communication adds value?                      ║
-║     - Complex workflow (create + review + integrate)?            ║
-║     → ANY YES: MUST use Agent Teams                              ║
-║     → ALL NO: Task tool is fine                                  ║
-║                                                                   ║
-║  3. Am I defaulting to Task tool out of habit?                   ║
-║     → STOP. Evaluate honestly against the decision matrix.       ║
-║                                                                   ║
-║  Using Task tool for Agent Teams-qualifying tasks                ║
-║  when Agent Teams is available = Rule violation                  ║
-╚══════════════════════════════════════════════════════════════════╝
-```
-
-## Team Composition Guidelines
-
-### Standard Team Patterns
-
-#### Research Team
-```
-TeamCreate("research-team")
-+-- researcher-1: Explore codebase area A
-+-- researcher-2: Explore codebase area B
-+-- synthesizer: Aggregate findings
-```
-
-#### Development Team
-```
-TeamCreate("dev-team")
-+-- implementer: Write code
-+-- reviewer: Review changes
-+-- tester: Validate changes
-```
-
-#### Debug Team
-```
-TeamCreate("debug-team")
-+-- investigator-1: Trace issue in module A
-+-- investigator-2: Trace issue in module B
-+-- fixer: Apply fixes based on findings
-```
-
-### Team Lifecycle
-
-```
-1. TeamCreate        -> Create team with purpose
-2. TaskCreate        -> Define tasks for team members
-3. Task(team_name)   -> Spawn team members
-4. SendMessage       -> Coordinate between members
-5. TaskUpdate        -> Track progress
-6. SendMessage(shutdown_request) -> Graceful shutdown
-7. TeamDelete        -> Cleanup
-```
-
-## Fallback Behavior
+| Scenario | Preferred |
+|----------|-----------|
+| Simple independent subtasks | Task Tool |
+| Multi-step with shared state | Agent Teams |
+| Research requiring discussion | Agent Teams |
+| Cost-sensitive batch ops | Task Tool |
+| Complex debugging across modules | Agent Teams |
+| Code review + fix cycle | Agent Teams |
+| Single file operations | Task Tool |
 
-When Agent Teams is NOT available:
-- All team-qualifying tasks fall back to Task tool
-- R009 (Parallel Execution) governs parallel spawning
-- R010 (Orchestrator Coordination) governs delegation
-- No degradation in capability, only in coordination richness
+**Self-check before Task tool:** Is Agent Teams available? Does task need 3+ agents, shared state, or inter-agent communication? If yes, use Agent Teams.
 
-```
-+------------------------------------------------------------------+
-|  GRACEFUL DEGRADATION                                            |
-|                                                                  |
-|  Agent Teams Available:                                          |
-|    Complex task -> TeamCreate -> coordinated agents              |
-|                                                                  |
-|  Agent Teams NOT Available:                                      |
-|    Complex task -> Task tool -> parallel independent agents      |
-|                                                                  |
-|  Both approaches produce results.                                |
-|  Agent Teams adds coordination, not capability.                  |
-+------------------------------------------------------------------+
-```
+## Team Patterns
 
-## Integration with Existing Rules
+- **Research**: researcher-1 + researcher-2 + synthesizer
+- **Development**: implementer + reviewer + tester
+- **Debug**: investigator-1 + investigator-2 + fixer
 
-| Rule | Integration |
-|------|-------------|
-| R009 (Parallel) | Task tool parallel = fallback when no Agent Teams |
-| R010 (Orchestrator) | Agent Teams = alternative coordination model |
-| R012 (HUD) | Team status displayed in HUD |
-| R013 (Ecomode) | Team communications respect ecomode |
+## Lifecycle
 
-## Cost Awareness
+TeamCreate → TaskCreate → Task(spawn) → SendMessage(coordinate) → TaskUpdate → shutdown → cleanup
 
-Agent Teams consume more tokens due to:
-- Full context per team member
-- Inter-agent message passing
-- Shared task list overhead
+## Fallback
 
-```
-Rule of thumb:
-  If task takes < 3 minutes with Task tool -> Use Task tool
-  If task needs inter-agent communication  -> Use Agent Teams
-  If unsure -> Default to Agent Teams when available, downgrade to Task tool only if clearly unqualified
-```
+When Agent Teams unavailable: use Task tool with R009/R010 rules. Both approaches produce results; Agent Teams adds coordination richness.
 
-## Enforcement
+## Cost
 
-```
-╔══════════════════════════════════════════════════════════════════╗
-║  VIOLATION EXAMPLES:                                             ║
-║                                                                   ║
-║  ✗ Agent Teams available + 4 parallel Task() calls for           ║
-║    coordinated work (creating agents + guides + routing skill)   ║
-║  ✗ Spawning Task tool agents that need to share results          ║
-║  ✗ Defaulting to Task tool without checking Agent Teams first    ║
-║                                                                   ║
-║  CORRECT EXAMPLES:                                               ║
-║                                                                   ║
-║  ✓ TeamCreate → TaskCreate → spawn team members for              ║
-║    multi-file coordinated creation                               ║
-║  ✓ Task tool for single independent delegation                   ║
-║  ✓ Task tool when Agent Teams is not available                   ║
-╚══════════════════════════════════════════════════════════════════╝
-```
+Agent Teams uses more tokens (full context per member + message passing). Use Task tool if task < 3 min or no inter-agent communication needed.

package/templates/.codex/rules/SHOULD-ecomode.md

@@ -1,145 +1,37 @@
 # [SHOULD] Ecomode Rules
 
-> **Priority**: SHOULD - Recommended for token efficiency
-> **ID**: R013
+> **Priority**: SHOULD | **ID**: R013
 
-## Purpose
+## Activation
 
-Reduce token usage and improve efficiency during batch operations and parallel execution.
-
-## Activation Conditions
-
-Ecomode is automatically activated when:
-
-```yaml
-conditions:
-  - 4+ parallel tasks spawned
-  - Batch operations requested
-  - Near compaction threshold (80%+ context usage)
-  - Explicit user request: "ecomode on"
-```
+Auto-activates when: 4+ parallel tasks, batch operations, 80%+ context usage, or explicit "ecomode on".
 
 ## Behaviors
 
-### 1. Compact Output Format
-
-When ecomode is active, parallel agents return:
-
-```yaml
-format:
-  - status: success | failed | partial
-  - summary: 1-2 sentences max
-  - key_data: essential results only
-
-skip:
-  - Intermediate steps
-  - Verbose explanations
-  - Repeated context
-  - Full file contents (use paths instead)
-```
-
-### 2. Aggregation Format
-
-Secretary aggregates results in compact format:
+**Compact Output**: Agents return `status + summary (1-2 sentences) + key_data only`. Skip intermediate steps, verbose explanations, repeated context, full file contents.
 
+**Aggregation Format**:
 ```
 [Batch Complete] {n}/{total}
-├── {agent}: {icon} {summary}
-├── {agent}: {icon} {summary}
-└── {agent}: {icon} {summary}
+├── {agent}: ✓/✗/⚠ {summary}
 ```
 
-Icons:
-- ✓ success
-- ✗ failed
-- ⚠ partial/warning
-
-### 3. Result Compression
-
-```yaml
-compress:
-  - File lists → count only unless < 5 files
-  - Error traces → first and last 3 lines
-  - Code snippets → path:line reference only
-  - Long outputs → truncate with "[truncated]"
-```
+**Compression**: File lists -> count only (unless < 5), error traces -> first/last 3 lines, code -> path:line ref only.
 
-## Secretary Ecomode Config
+## Config
 
 ```yaml
 ecomode:
-  enabled: true
-  threshold: 4           # Activate when >= 4 parallel tasks
-  result_format: summary # summary | full
-  max_result_length: 200 # characters per result
-```
-
-## Examples
-
-### Normal Mode Output
-
+  threshold: 4
+  result_format: summary
+  max_result_length: 200
 ```
-┌─ Agent: lang-golang-expert (sw-engineer)
-├─ Skill: go-best-practices
-└─ Task: Reviewing src/main.go
 
-Reading file...
-[lang-golang-expert → Read] src/main.go
+## Example
 
-Analyzing code structure...
-Found 3 functions, 2 structs, 1 interface.
-
-Checking naming conventions...
-Function 'GetUser' follows Go naming conventions.
-Function 'processData' follows Go naming conventions.
-Function 'handle_error' VIOLATION: uses snake_case instead of camelCase.
-
-[...]
-
-Review Complete:
-- 1 naming violation found
-- 2 potential improvements suggested
-- Overall code quality: Good
-```
-
-### Ecomode Output
-
-```
-[lang-golang-expert] ✓ src/main.go reviewed: 1 naming issue (handle_error → handleError)
-```
-
-## Implementation Notes
-
-### For Orchestrator (Secretary)
-
-```yaml
-responsibilities:
-  - Detect ecomode activation conditions
-  - Instruct spawned agents to use compact format
-  - Aggregate results in batch format
-  - Track token savings
-```
-
-### For Worker Agents
-
-```yaml
-when_ecomode_active:
-  - Return status + summary only
-  - Skip intermediate progress updates
-  - Use references instead of full content
-  - Compress error messages
-```
+Normal: Full agent header + step-by-step analysis + detailed results.
+Ecomode: `[lang-golang-expert] ✓ src/main.go reviewed: 1 naming issue (handle_error -> handleError)`
 
 ## Override
 
-User can disable ecomode:
-- "ecomode off"
-- "verbose mode"
-- "show full details"
-
-## Benefits
-
-1. **Token Efficiency**: 60-80% reduction in batch operations
-2. **Faster Response**: Less output processing
-3. **Better Overview**: Aggregated results at a glance
-4. **Context Preservation**: More room for actual work
+Disable with: "ecomode off", "verbose mode", or "show full details".

package/templates/.codex/rules/SHOULD-error-handling.md

@@ -1,102 +1,33 @@
 # [SHOULD] Error Handling Rules
 
-> **Priority**: SHOULD - Strongly recommended
-> **Goal**: Safe failure, fast recovery
+> **Priority**: SHOULD | **ID**: R004
 
 ## Error Classification
 
-### Level 1: Warning
-```
-Symptom: Task completes but needs attention
-Response: Output warning, continue
-Example:
-  - Non-recommended pattern found
-  - Potential performance issue
-  - Better alternative exists
-```
-
-### Level 2: Error
-```
-Symptom: Current task fails, others possible
-Response: Stop task, report cause, suggest alternative
-Example:
-  - File not found
-  - Insufficient permission
-  - Format error
-```
-
-### Level 3: Critical
-```
-Symptom: Cannot proceed at all
-Response: Stop all, preserve state, report immediately
-Example:
-  - System resource exhausted
-  - Missing required dependency
-  - Security violation detected
-```
+| Level | Symptom | Response |
+|-------|---------|----------|
+| Warning | Task completes but needs attention | Output warning, continue |
+| Error | Current task fails, others possible | Stop task, report cause, suggest alternative |
+| Critical | Cannot proceed at all | Stop all, preserve state, report immediately |
 
 ## Error Report Format
 
 ```
-[Error] {error type}
-
-Location: {file:line or task name}
-Cause: {specific cause}
-Impact: {effect of this error}
-
-Attempted:
-1. {attempt 1} → Failed
-2. {attempt 2} → Failed
-
-Recommended:
-- {action 1}
-- {action 2}
-```
-
-## Recovery Strategy
-
-### Retryable Errors
-```
-1. Retry up to 3 times
-2. Wait between retries (1s, 2s, 4s)
-3. Report to user after 3 failures
-```
-
-### Non-recoverable Errors
-```
-1. Save current state
-2. Rollback changes (if possible)
-3. Detailed error report
-4. Wait for user instruction
+[Error] {type} — Location: {file:line} — Cause: {cause} — Impact: {effect}
+Attempted: 1. {try1} -> Failed  2. {try2} -> Failed
+Recommended: {action1}, {action2}
 ```
 
-## Preventive Validation
+## Recovery
 
-### Before Action
-```
-□ Target file/path exists
-□ Required permissions available
-□ Dependencies met
-□ Sufficient resources
-```
-
-### After Action
-```
-□ Expected result matches actual
-□ File integrity verified
-□ No side effects
-```
+| Type | Strategy |
+|------|----------|
+| Retryable | Retry up to 3x with backoff (1s, 2s, 4s), then report |
+| Non-recoverable | Save state, rollback if possible, detailed report, wait for user |
 
-## Error Logging
+## Validation
 
-```yaml
-error_log:
-  timestamp: "2025-01-22T10:30:00Z"
-  level: error
-  code: FILE_NOT_FOUND
-  message: "Config file not found"
-  context:
-    file: "/path/to/config.yaml"
-    action: "read"
-  resolution: "Using default config"
-```
+| When | Checks |
+|------|--------|
+| Before action | Target exists, permissions available, dependencies met |
+| After action | Expected = actual, file integrity, no side effects |

package/templates/.codex/rules/SHOULD-hud-statusline.md

@@ -1,11 +1,6 @@
 # [SHOULD] HUD Statusline Rules
 
-> **Priority**: SHOULD - Recommended for visibility
-> **ID**: R012
-
-## Purpose
-
-Display real-time status information during agent operations for improved visibility and progress tracking.
+> **Priority**: SHOULD | **ID**: R012
 
 ## Format
 
@@ -13,100 +8,25 @@ Display real-time status information during agent operations for improved visibi
 ─── [Agent] {name} | [Progress] {n}/{total} | [Parallel] {count} ───
 ```
 
-## Update Triggers
-
-| Trigger | Description |
-|---------|-------------|
-| Agent activation | When an agent starts handling a task |
-| Task start | When a specific task begins execution |
-| Task complete | When a task finishes (success or failure) |
-| Parallel spawn | When parallel instances are created |
-| Parallel complete | When parallel instances finish |
-
-## Components
-
-| Component | Description | Example |
-|-----------|-------------|---------|
-| Agent | Active agent name | `lang-golang-expert` |
-| Model | Model used (for parallel) | `sonnet` |
-| Progress | Task progress (current/total) | `2/5` |
-| Parallel | Parallel instance count | `3` |
-
-## Display Rules
-
-### Single Agent
-
-```
-─── [Agent] mgr-creator | [Progress] 1/3 ───
-```
-
-### With Parallel Execution (Model Display REQUIRED)
-
-```
-─── [Agent] secretary | [Progress] 0/4 | [Parallel] 4 ───
-
-Instances:
-  [1] Task(general-purpose):sonnet → README update
-  [2] Task(lang-golang-expert):haiku → Code review
-  [3] Task(Explore):opus → Architecture analysis
-  [4] Task(general-purpose):haiku → Validation
-```
-
-### Completion
-
-```
-─── [Agent] mgr-supplier | [Progress] 5/5 | [Done] ───
-```
-
-## Implementation
-
-Status updates via stderr to avoid output pollution:
-
-```bash
-echo "─── [Agent] $AGENT | [Progress] $PROGRESS ───" >&2
-```
-
-## Integration with Other Rules
-
-| Rule | Integration |
-|------|-------------|
-| R007 (Agent ID) | HUD complements agent identification |
-| R008 (Tool ID) | HUD shows overall progress, tool ID shows specific operations |
-| R009 (Parallel) | HUD displays parallel instance count |
-
 ## When to Display
 
-| Situation | Display HUD |
-|-----------|-------------|
-| Single file operation | No (too brief) |
-| Multi-step task | Yes |
-| Parallel execution | Yes |
-| Long-running operations | Yes |
+Multi-step tasks, parallel execution, long-running operations. Skip for single brief operations.
 
-## Hook Usage
+## Hook Implementation
 
-The HUD statusline is implemented as an inline hook in `.codex/hooks/hooks.json` (PreToolUse → Task matcher).
-
-The hook automatically displays subagent details when the Task tool is used:
+Implemented in `.claude/hooks/hooks.json` (PreToolUse → Task matcher):
 
 ```
 ─── [Spawn] {subagent_type}:{model} | {description} ───
 ─── [Resume] {subagent_type}:{model} | {description} ───
 ```
 
-### Examples
+## Display with Parallel
 
 ```
-─── [Spawn] mgr-gitnerd:sonnet | Commit and push ───
-─── [Spawn] lang-golang-expert:sonnet | Review Go code ───
-─── [Spawn] mgr-creator:sonnet | Create new agent ───
-─── [Resume] mgr-gitnerd:sonnet | Continue push ───
+─── [Agent] secretary | [Parallel] 4 ───
+  [1] Task(mgr-creator):sonnet → Create agent
+  [2] Task(lang-golang-expert):haiku → Code review
 ```
 
-### Fields Displayed
-
-| Field | Source | Purpose |
-|-------|--------|---------|
-| `subagent_type` | Task tool parameter | Which agent is running |
-| `model` | Task tool parameter | Which model (opus/sonnet/haiku) |
-| `description` | Task tool parameter | What the agent is doing (max 40 chars) |
+Integrates with R007 (Agent ID), R008 (Tool ID), R009 (Parallel).