oh-my-customcode 0.7.0 → 0.9.0

package/templates/.codex/rules/MUST-parallel-execution.md

@@ -0,0 +1,469 @@
+# [MUST] Parallel Execution Rules
+
+> **Priority**: MUST - ENFORCED for 2+ independent tasks
+> **ID**: R009
+> **Violation**: Sequential execution of parallelizable tasks = Rule violation
+
+## CRITICAL
+
+**When 2 or more tasks are INDEPENDENT, they MUST be executed in parallel.**
+
+```
+╔══════════════════════════════════════════════════════════════════╗
+║  ⚠️  ABSOLUTE RULE: 2+ INDEPENDENT FILES = PARALLEL              ║
+║                                                                   ║
+║  If you are about to Write/Edit 2 or more independent files:     ║
+║  → STOP                                                          ║
+║  → Use Task tool to spawn parallel agents                        ║
+║  → Each agent handles a subset of files                          ║
+║                                                                   ║
+║  NO EXCEPTIONS for:                                              ║
+║  - Project scaffolding (package.json, tsconfig, src/*.ts)        ║
+║  - Multiple module creation                                       ║
+║  - Batch file updates                                            ║
+║  - Any multi-file operation                                      ║
+║                                                                   ║
+║  VIOLATION = Using Write/Edit 2+ times in sequence               ║
+║              when files are independent                          ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+
+```
+Detection criteria for parallel execution:
+- Tasks don't share mutable state
+- Tasks don't have sequential dependencies
+- Tasks can complete independently
+
+If ALL criteria met → MUST execute in parallel (max 4 instances)
+```
+
+### How to Detect Independent Tasks
+
+```
+Independent (MUST parallelize):
+✓ "Create agents A, B, C" → 3 separate creations
+✓ "Read files X, Y, Z" → 3 separate reads
+✓ "Review code in src/, test/, docs/" → 3 separate reviews
+
+Dependent (sequential OK):
+✗ "Create agent then configure it" → depends on creation
+✗ "Build then test" → test depends on build
+✗ "Read file then edit it" → edit depends on read content
+```
+
+Failure to parallelize independent tasks = Rule violation = Must be corrected.
+
+### Self-Check Before Every Multi-File Operation
+
+```
+╔══════════════════════════════════════════════════════════════════╗
+║  BEFORE writing/creating multiple files, ASK YOURSELF:          ║
+║                                                                   ║
+║  1. Are these files independent of each other?                   ║
+║     → YES: Use Task tool to spawn parallel agents                ║
+║     → NO: Sequential is OK                                       ║
+║                                                                   ║
+║  2. Am I using Write/Edit sequentially for 3+ files?            ║
+║     → STOP. This is likely a violation.                         ║
+║     → Spawn parallel agents instead.                             ║
+║                                                                   ║
+║  3. Are there domain-specific experts available?                 ║
+║     → YES: Delegate to them (lang-kotlin-expert, be-springboot-expert) ║
+║     → NO: Create general-purpose parallel agents                 ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+
+### Common Violations to Avoid
+
+```
+❌ WRONG: Writing files one by one
+   Write(file1.kt) → Write(file2.kt) → Write(file3.kt) → Write(file4.kt)
+
+✓ CORRECT: Spawn parallel agents
+   Task(agent1 → file1.kt)  ┐
+   Task(agent2 → file2.kt)  ├─ All in single message
+   Task(agent3 → file3.kt)  │
+   Task(agent4 → file4.kt)  ┘
+
+❌ WRONG: Project scaffolding sequentially
+   Write(package.json) → Write(tsconfig.json) → Write(src/index.ts) → ...
+
+✓ CORRECT: Parallel scaffolding
+   Task(agent1 → "Create package.json, tsconfig.json")  ┐
+   Task(agent2 → "Create src/cli.ts, src/index.ts")     ├─ Parallel
+   Task(agent3 → "Create src/analyzer/*.ts")            │
+   Task(agent4 → "Create src/converter/*.ts")           ┘
+
+❌ WRONG: Secretary doing all the work
+   Secretary writes domain/, usecase/, infrastructure/ sequentially
+
+✓ CORRECT: Delegate to specialists
+   Task(lang-kotlin-expert → domain layer)
+   Task(be-springboot-expert → infrastructure layer)
+   Task(lang-kotlin-expert → usecase layer)
+
+❌ WRONG: Single Task delegating to multiple agents
+   Task(dev-lead → "coordinate lang-kotlin-expert and be-springboot-expert")
+
+   This creates a SEQUENTIAL bottleneck inside the Task!
+
+✓ CORRECT: Multiple Tasks in parallel, one per agent
+   Task(lang-kotlin-expert → usecase commands)    ┐
+   Task(lang-kotlin-expert → usecase queries)     ├─ All spawned together
+   Task(be-springboot-expert → persistence)       │
+   Task(be-springboot-expert → security)          ┘
+```
+
+### Parallel Task Spawning Rule
+
+```
+╔══════════════════════════════════════════════════════════════════╗
+║  PARALLEL MEANS PARALLEL AT THE TOOL CALL LEVEL                  ║
+║                                                                   ║
+║  When spawning Tasks for parallel work:                          ║
+║  - Each independent unit of work = separate Task tool call       ║
+║  - All Task calls in the SAME message = truly parallel           ║
+║  - One Task that "coordinates" others = still sequential inside  ║
+║                                                                   ║
+║  Rule: If work can be split, split it into separate Tasks.       ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+
+### Large Task Decomposition (MANDATORY)
+
+```
+╔══════════════════════════════════════════════════════════════════╗
+║  LARGE TASKS MUST BE SPLIT INTO PARALLEL SUB-TASKS               ║
+║                                                                   ║
+║  Before spawning a single large Task, ASK:                       ║
+║                                                                   ║
+║  1. Can this work be divided into independent parts?             ║
+║     → Query tests, Security tests, Exception tests               ║
+║     → Domain A, Domain B, Domain C                               ║
+║     → Layer 1, Layer 2, Layer 3                                  ║
+║                                                                   ║
+║  2. How many parallel slots available? (max 4)                   ║
+║     → If 3 slots free, split into 3 parallel Tasks              ║
+║     → Maximize parallelism to minimize total time                ║
+║                                                                   ║
+║  3. Is estimated Task duration > 3 minutes?                      ║
+║     → MUST split if work is decomposable                        ║
+║     → 12 min single Task → 4 min with 3 parallel Tasks          ║
+╚══════════════════════════════════════════════════════════════════╝
+
+Example - WRONG:
+  Task("Add tests for Query, Security, Exception, Domain")
+  → Single agent works 12+ minutes sequentially
+
+Example - CORRECT (3 parallel Tasks):
+  Task(agent1 → "Add Query usecase tests")      ┐
+  Task(agent2 → "Add Security tests")           ├─ ~4 min total
+  Task(agent3 → "Add Exception + Domain tests") ┘
+```
+
+## Purpose
+
+Enable parallel execution of agents as separate instances to improve throughput for batch operations and independent tasks.
+
+## Core Concept
+
+Each agent (except orchestrators) can be instantiated multiple times to work on independent tasks in parallel.
+
+```
+Agent (Template)
+    │
+    ├── Instance 1 → Task A
+    ├── Instance 2 → Task B
+    ├── Instance 3 → Task C
+    └── Instance 4 → Task D
+```
+
+## Rules
+
+### 1. Maximum Parallel Instances
+
+```yaml
+limit: 4
+reason: Balance between throughput and resource usage
+```
+
+### 2. Exclusions
+
+```yaml
+not_parallelizable:
+  - orchestrator/* (must remain singleton for coordination)
+
+reason: |
+  Orchestrator agents manage other agents and must maintain
+  a single point of coordination to prevent conflicts.
+```
+
+### 3. Instance Independence
+
+```yaml
+requirements:
+  - Tasks must be independent (no shared state)
+  - No cross-instance communication required
+  - Each instance has isolated context
+```
+
+### 4. Subagent Visibility (MANDATORY)
+
+```
+╔══════════════════════════════════════════════════════════════════╗
+║  TASK TOOL MUST USE SPECIFIC subagent_type (NOT general-purpose) ║
+║                                                                   ║
+║  When a specialized agent exists for the task:                   ║
+║    → MUST use that agent's subagent_type                         ║
+║    → DO NOT use "general-purpose" as a catch-all                 ║
+║                                                                   ║
+║  The HUD hook displays: [Spawn] {subagent_type}:{model} | {desc}║
+║  Using "general-purpose" makes all spawns look identical.        ║
+║                                                                   ║
+║  WRONG:                                                          ║
+║    Task(subagent_type: "general-purpose", desc: "Update agents") ║
+║    Task(subagent_type: "general-purpose", desc: "Update agents") ║
+║    → HUD shows: [Spawn] general-purpose:sonnet | Update agents   ║
+║    → HUD shows: [Spawn] general-purpose:sonnet | Update agents   ║
+║    → User cannot distinguish which is which                      ║
+║                                                                   ║
+║  CORRECT:                                                        ║
+║    Task(subagent_type: "mgr-creator", desc: "Create Go agent")   ║
+║    Task(subagent_type: "lang-golang-expert", desc: "Review code")║
+║    → HUD shows: [Spawn] mgr-creator:sonnet | Create Go agent    ║
+║    → HUD shows: [Spawn] lang-golang-expert:sonnet | Review code  ║
+║                                                                   ║
+║  When NO specialized agent exists (truly generic work):          ║
+║    → Use "general-purpose" but with UNIQUE descriptions          ║
+║    → Description MUST identify the specific batch/scope           ║
+║                                                                   ║
+║    Task(subagent_type: "general-purpose",                        ║
+║         desc: "batch1: lang-* agents")                           ║
+║    Task(subagent_type: "general-purpose",                        ║
+║         desc: "batch2: be-* fe-* agents")                        ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+
+### 5. Model Specification (RECOMMENDED)
+
+```
+╔══════════════════════════════════════════════════════════════════╗
+║  USE MODEL PARAMETER FOR COST/PERFORMANCE OPTIMIZATION           ║
+║                                                                   ║
+║  Task tool supports `model` parameter:                           ║
+║                                                                   ║
+║    Task(                                                         ║
+║      subagent_type: "general-purpose",                           ║
+║      prompt: "...",                                              ║
+║      model: "haiku"  ← Specify model                             ║
+║    )                                                             ║
+║                                                                   ║
+║  Model Selection:                                                ║
+║    - opus   : Complex reasoning (expensive, powerful)            ║
+║    - sonnet : General tasks (default, balanced)                  ║
+║    - haiku  : Simple tasks (fast, cheap)                         ║
+║                                                                   ║
+║  Parallel Task Optimization:                                     ║
+║    - Use haiku for file search/validation tasks                  ║
+║    - Use sonnet for code generation tasks                        ║
+║    - Use opus only when deep reasoning is required               ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+
+Example with model specification:
+```
+# Parallel tasks with appropriate models
+Task(prompt: "Search for auth files", model: "haiku")      ┐
+Task(prompt: "Implement feature A", model: "sonnet")       ├─ Optimized
+Task(prompt: "Implement feature B", model: "sonnet")       │
+Task(prompt: "Analyze architecture", model: "opus")        ┘
+```
+
+## Instance Model
+
+### Instantiation
+
+```
+┌─────────────────────────────────────────────────────────┐
+│                   Agent Template                         │
+│  (agents/{type}/{name}/)                                │
+├─────────────────────────────────────────────────────────┤
+│  AGENT.md    - Role definition                          │
+│  index.yaml  - Configuration                            │
+│  refs/       - Skill/guide references                   │
+└────────────────────────┬────────────────────────────────┘
+                         │
+        ┌────────────────┼────────────────┐
+        │                │                │
+        ▼                ▼                ▼
+┌──────────────┐ ┌──────────────┐ ┌──────────────┐
+│ Instance #1  │ │ Instance #2  │ │ Instance #3  │
+│   Task: A    │ │   Task: B    │ │   Task: C    │
+│ Context: ... │ │ Context: ... │ │ Context: ... │
+└──────────────┘ └──────────────┘ └──────────────┘
+```
+
+### Instance Properties
+
+```yaml
+instance:
+  id: "{agent-name}-{uuid}"
+  template: "{agent-path}"
+  task: "{assigned-task}"
+  context: "{isolated-context}"
+  status: "pending|running|completed|failed"
+```
+
+## Usage Patterns
+
+### Batch Agent Creation
+
+```
+User: "Create golang, python, rust, typescript expert agents"
+
+Orchestrator (secretary):
+  │
+  ├── [lang-golang-expert] mgr-creator instance #1
+  ├── [lang-python-expert] mgr-creator instance #2
+  ├── [lang-rust-expert] mgr-creator instance #3
+  └── [lang-typescript-expert] mgr-creator instance #4
+
+Execution: Parallel (4 instances)
+```
+
+### Batch Code Review
+
+```
+User: "/dev:review src/*.go src/*.py src/*.ts"
+
+Orchestrator:
+  │
+  ├── [src/*.go] lang-golang-expert instance #1
+  ├── [src/*.py] lang-python-expert instance #2
+  └── [src/*.ts] lang-typescript-expert instance #3
+
+Execution: Parallel (3 instances)
+```
+
+### Batch Audit
+
+```
+User: "Audit all agents"
+
+Orchestrator (secretary):
+  │
+  ├── [agent-1] mgr-supplier instance #1
+  ├── [agent-2] mgr-supplier instance #2
+  ├── [agent-3] mgr-supplier instance #3
+  └── [agent-4] mgr-supplier instance #4
+
+Execution: Parallel (4 instances, batched if > 4)
+```
+
+## Coordination
+
+### Task Distribution
+
+```yaml
+strategy: round_robin
+max_instances: 4
+queue: remaining tasks wait for available instance
+```
+
+### Result Aggregation
+
+```
+Instance Results:
+  #1: ✓ Success (agent-a created)
+  #2: ✓ Success (agent-b created)
+  #3: ✗ Failed (agent-c: skill not found)
+  #4: ✓ Success (agent-d created)
+
+Aggregated Result:
+  Total: 4 tasks
+  Succeeded: 3
+  Failed: 1
+  Details: [...]
+```
+
+## Implementation Notes
+
+### For Orchestrators
+
+```yaml
+responsibilities:
+  - Identify parallelizable tasks
+  - Spawn instances (max 4)
+  - Monitor instance status
+  - Aggregate results
+  - Handle failures
+```
+
+### For Worker/Manager Agents
+
+```yaml
+requirements:
+  - Stateless task execution
+  - Isolated context per instance
+  - No shared mutable state
+  - Clear success/failure reporting
+```
+
+## Display Format
+
+When parallel execution occurs, MUST display `Task({subagent_type}):{model}` format:
+
+```
+┌─ Agent: secretary (orchestrator)
+└─ Task: Batch agent creation
+
+[Parallel] Spawning 4 instances...
+
+[Instance 1] Task(mgr-creator):sonnet → lang-golang-expert
+[Instance 2] Task(mgr-creator):sonnet → lang-python-expert
+[Instance 3] Task(mgr-creator):sonnet → lang-rust-expert
+[Instance 4] Task(mgr-creator):sonnet → lang-typescript-expert
+
+[Progress] ████████░░░░ 2/4
+
+[Instance 1] Task(mgr-creator):sonnet ✓ lang-golang-expert created
+[Instance 2] Task(mgr-creator):sonnet ✓ lang-python-expert created
+[Instance 3] Task(mgr-creator):sonnet ✓ lang-rust-expert created
+[Instance 4] Task(mgr-creator):sonnet ✓ lang-typescript-expert created
+
+[Summary] 4/4 tasks completed successfully
+```
+
+### Display Format Rules
+
+```
+╔══════════════════════════════════════════════════════════════════╗
+║  PARALLEL AGENT DISPLAY FORMAT (MANDATORY)                       ║
+║                                                                   ║
+║  When announcing parallel agents, MUST show:                     ║
+║                                                                   ║
+║    Task({subagent_type}):{model}                                 ║
+║                                                                   ║
+║  Examples:                                                       ║
+║    [Instance 1] Task(general-purpose):sonnet → R006 업데이트      ║
+║    [Instance 2] Task(lang-golang-expert):sonnet → Go 코드 리뷰    ║
+║    [Instance 3] Task(Explore):haiku → 코드베이스 탐색              ║
+║    [Instance 4] Task(mgr-gitnerd):sonnet → git commit            ║
+║                                                                   ║
+║  The subagent_type MUST match the Task tool's subagent_type      ║
+║  parameter. Custom names are NOT allowed.                        ║
+║                                                                   ║
+║  This allows users to:                                           ║
+║    - See which model is used for each task                       ║
+║    - See the exact subagent_type used                            ║
+║    - Understand cost implications                                ║
+║    - Debug model selection issues                                ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+
+## Benefits
+
+1. **Throughput**: N tasks complete in ~1/N time
+2. **Efficiency**: Better resource utilization
+3. **User Experience**: Faster batch operations
+4. **Scalability**: Handles large workloads

package/templates/.codex/rules/MUST-permissions.md

@@ -0,0 +1,84 @@
+# [MUST] Permission Rules
+
+> **Priority**: MUST - Never violate
+> **Principle**: Least privilege, explicit approval
+
+## Tool Permission Tiers
+
+### Tier 1: Always Allowed
+```yaml
+always_allowed:
+  - Read        # Read files
+  - Glob        # Search files
+  - Grep        # Search content
+```
+
+### Tier 2: Default Allowed (Use with care)
+```yaml
+default_allowed:
+  - Write       # Create files
+  - Edit        # Modify files
+```
+→ State changes explicitly
+→ Notify before modifying important files
+
+### Tier 3: Requires Approval
+```yaml
+requires_approval:
+  - Bash        # Execute commands
+  - WebFetch    # Web access
+  - WebSearch   # Web search
+```
+→ Request user approval on first use
+→ State command/URL to be accessed
+
+### Tier 4: Explicit Request Only
+```yaml
+explicit_request_only:
+  - Task        # Create subagents
+```
+→ Only when user explicitly requests
+
+## File Access
+
+### Read Access
+```
+✓ All source code in project
+✓ Config files (read-only)
+✓ Documentation files
+```
+
+### Write Access
+```
+✓ Source code in project
+✓ New files in project
+✗ Sensitive configs (.env, .git/config)
+✗ Paths outside project
+```
+
+### Delete Access
+```
+✓ Temp files created by agent
+✗ Existing files (without explicit request)
+✗ Entire directories
+```
+
+## Permission Request Format
+
+```
+[Permission Request]
+Action: {intended action}
+Required: {tool/access needed}
+Reason: {why needed}
+Risk: Low / Medium / High
+
+Approve?
+```
+
+## On Insufficient Permission
+
+```
+1. Do not attempt action
+2. Notify user of insufficient permission
+3. Request permission or suggest alternative
+```

package/templates/.codex/rules/MUST-safety.md

@@ -0,0 +1,69 @@
+# [MUST] Safety Rules
+
+> **Priority**: MUST - Never violate
+> **On violation**: Stop immediately, report to user
+
+## Prohibited Actions
+
+### 1. Data Protection
+```
+[PROHIBITED]
+- Expose API keys, secrets, passwords
+- Collect personal info without consent
+- Log authentication tokens
+```
+
+### 2. File System
+```
+[PROHIBITED]
+- Modify system files (/etc, /usr, /bin)
+- Delete files outside project
+- Modify hidden configs (.env, .git/config) without approval
+```
+
+### 3. Command Execution
+```
+[PROHIBITED]
+- rm -rf / or broad delete commands
+- System shutdown/restart
+- Privilege escalation (sudo, su)
+- Network configuration changes
+```
+
+### 4. External Communication
+```
+[PROHIBITED]
+- Access external URLs without approval
+- Send user data externally
+- Download and execute unknown scripts
+```
+
+## Required Actions
+
+### Before Destructive Operations
+```
+[REQUIRED]
+□ Verify target
+□ Assess impact scope
+□ Check recoverability
+□ Get user approval
+```
+
+### On Risk Detection
+```
+→ Stop immediately
+→ Report risk
+→ Wait for user instruction
+```
+
+## Violation Response
+
+```
+1. Stop all operations
+2. Preserve current state
+3. Report to user:
+   - What was detected
+   - Why it's risky
+   - What action was taken
+4. Wait for instructions
+```