oh-my-customcodex 0.1.0

package/templates/.claude/rules/MUST-orchestrator-coordination.md

@@ -0,0 +1,399 @@
+# [MUST] Orchestrator Coordination Rules
+
+> **Priority**: MUST | **ID**: R010
+
+## Core Rule
+
+The main conversation is the **sole orchestrator**. It uses routing skills to delegate tasks to subagents via the Agent tool (formerly Task tool). Subagents CANNOT spawn other subagents.
+
+**Agent Teams Exception**: Agent Teams members are peers, not hierarchical subagents. Teams members CAN spawn sub-agents via the Agent tool to execute complex workflows (e.g., research teams, verification teams). This enables Teams-compatible skills like `/research` and `/deep-plan` to run inside Team members. The Teams member acts as a local orchestrator for its own sub-tasks.
+
+**The orchestrator MUST NEVER directly write, edit, or create files. ALL file modifications MUST be delegated to appropriate subagents.**
+
+<!-- DETAIL: Self-Check (Before File Modification)
+```
+╔══════════════════════════════════════════════════════════════════╗
+║  BEFORE MODIFYING ANY FILE, ASK YOURSELF:                        ║
+║                                                                   ║
+║  1. Am I the orchestrator (main conversation)?                   ║
+║     YES → delegate file writes to a subagent                    ║
+║     NO  → I am a subagent, proceed with task                    ║
+║                                                                   ║
+║  2. Have I identified the correct specialized agent?             ║
+║     YES → Delegate via Agent tool                                ║
+║     NO  → Check delegation table below                          ║
+║                                                                   ║
+║  3. Am I about to use Write/Edit tool from orchestrator?         ║
+║     YES → Delegate to the appropriate specialist instead.        ║
+║     NO  → Good. Continue.                                        ║
+║                                                                   ║
+║  4. Am I justifying direct modification as "temporary" or        ║
+║     "debugging"?                                                  ║
+║     YES → Still delegate. Temporary/debugging changes are        ║
+║           NOT exempt.                                            ║
+║     NO  → Good. Continue.                                        ║
+║                                                                   ║
+║  If any answer points to a problem → resolve before proceeding   ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+-->
+
+<!-- DETAIL: Self-Check (Before Delegating Tasks)
+```
+╔══════════════════════════════════════════════════════════════════╗
+║  BEFORE DELEGATING A TASK TO ANY AGENT, ASK YOURSELF:            ║
+║                                                                   ║
+║  1. Does the task prompt contain git commands?                   ║
+║     (commit, push, revert, merge, rebase, checkout, branch,     ║
+║      reset, cherry-pick, tag)                                    ║
+║     YES → The git part goes to mgr-gitnerd                      ║
+║     NO  → Proceed                                                ║
+║                                                                   ║
+║  2. Am I bundling git operations with file editing?              ║
+║     YES → Split into separate delegations:                       ║
+║           - File editing → appropriate specialist                ║
+║           - Git operations → mgr-gitnerd                         ║
+║     NO  → Good. Continue.                                        ║
+║                                                                   ║
+║  3. Is the target agent mgr-gitnerd for ALL git operations?     ║
+║     YES → Good. Continue.                                        ║
+║     NO  → Re-route git operations to mgr-gitnerd.               ║
+║                                                                   ║
+║  4. Am I about to spawn 2+ agents in parallel?                   ║
+║     YES → Check R018: Agent Teams may be required                ║
+║           3+ agents → use Agent Teams                            ║
+║           2+ issues in batch → prefer Agent Teams                ║
+║     NO  → Proceed                                                ║
+║                                                                   ║
+║  If any answer points to a problem → split the task first        ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+-->
+
+<!-- DETAIL: Architecture Diagram
+```
+Main Conversation (orchestrator)
+  ├─ secretary-routing → mgr-creator, mgr-updater, mgr-supplier, mgr-gitnerd, sys-memory-keeper
+  ├─ dev-lead-routing  → lang-*/be-*/fe-* experts
+  ├─ de-lead-routing   → de-* experts
+  └─ qa-lead-routing   → qa-planner, qa-writer, qa-engineer
+      ↓
+  Agent tool spawns subagents (flat, no hierarchy)
+```
+-->
+
+## Common Violations
+
+Key violations to avoid (file writes, git commands, bundled operations — all must be delegated):
+
+```
+❌ WRONG: Orchestrator writes files directly
+   Main conversation → Write("src/main.go", content)
+
+✓ CORRECT: Orchestrator delegates to specialist
+   Main conversation → Agent(lang-golang-expert) → Write("src/main.go", content)
+
+❌ WRONG: External skill creates agent/skill/guide via general-purpose agent
+   Skill(brainstorming) → Agent(general-purpose) → Write(".codex/agents/new.md")
+
+✓ CORRECT: Agent/skill/guide creation routed through mgr-creator
+   Skill(brainstorming) → Agent(mgr-creator) → Write(".codex/agents/new.md")
+```
+
+<!-- DETAIL: Common Violations (extended)
+```
+❌ WRONG: Orchestrator runs git commands directly
+   Main conversation → Bash("git commit -m 'fix'")
+   Main conversation → Bash("git push origin main")
+
+✓ CORRECT: Orchestrator delegates to mgr-gitnerd
+   Main conversation → Agent(mgr-gitnerd) → git commit
+   Main conversation → Agent(mgr-gitnerd) → git push
+
+❌ WRONG: Orchestrator creates files "just this once"
+   "It's just a small config file, I'll write it directly..."
+
+✓ CORRECT: Always delegate, no matter how small
+   Agent(appropriate-agent) → create config file
+
+❌ WRONG: Bundling git operations with file editing in non-gitnerd agent
+   Main conversation → Agent(general-purpose) → "git revert + edit file + git commit"
+   Main conversation → Agent(lang-typescript-expert) → "fix bug and commit"
+   Agent(general-purpose, prompt="revert the last commit, edit the file, then commit the fix")
+
+✓ CORRECT: Separate file editing from git operations, split delegations
+   Agent(mgr-gitnerd, prompt="revert the last commit")
+   Agent(appropriate-expert, prompt="edit the file to fix the issue")
+   Agent(mgr-gitnerd, prompt="commit the fix")
+
+❌ WRONG: Orchestrator runs server deployment commands directly
+   Main conversation → Bash("docker compose restart worker")
+   Main conversation → Bash("scp worker.py server:/app/")
+
+✓ CORRECT: Orchestrator delegates to infrastructure specialist
+   Main conversation → Agent(infra-docker-expert) → docker compose restart
+   Main conversation → Agent(infra-docker-expert) → deploy files to server
+
+❌ WRONG: External skill creates agent/skill/guide via general-purpose agent
+   Skill(brainstorming) → Agent(general-purpose) → Write(".codex/agents/new-agent.md")
+   Skill(any-skill) → Agent(general-purpose) → Write(".codex/skills/new-skill/SKILL.md")
+
+✓ CORRECT: Agent/skill/guide creation always routed through mgr-creator
+   Skill(brainstorming) → Agent(mgr-creator) → Write(".codex/agents/new-agent.md")
+   Skill(any-skill) → Agent(mgr-creator) → Write(".codex/skills/new-skill/SKILL.md")
+
+   The skill defines WHAT to create; mgr-creator handles HOW (R006 validation,
+   skill auto-discovery, frontmatter integrity).
+```
+-->
+
+<!-- DETAIL: Autonomous Execution Mode
+
+## Autonomous Execution Mode
+
+When the user explicitly signals full-delegation intent, the orchestrator operates in a lightweight mode that reduces delegation overhead while preserving safety.
+
+### Activation Signals
+
+| Signal (Korean) | Signal (English) | Confidence |
+|-----------------|------------------|------------|
+| "알아서 해" | "just do it" | High |
+| "다 해" | "do it all" | High |
+| "전부 처리해" | "handle everything" | High |
+| "중간에 묻지 말고" | "don't ask, just do" | High |
+| "자율적으로 진행" | "proceed autonomously" | High |
+
+### Activation Protocol
+
+1. User gives explicit autonomous signal (not inferred from task complexity)
+2. Verify stage-blocker is NOT active (`/tmp/.codex-dev-stage` must not exist)
+3. Create marker: `echo 1 > /tmp/.codex-autonomous-$PPID`
+4. Announce: `[Autonomous Mode] Activated for current task scope`
+
+### Lightweight Delegation Table
+
+| Operation | Normal Mode | Autonomous Mode |
+|-----------|-------------|-----------------|
+| File Write/Edit | MUST delegate to specialist | MUST delegate to specialist |
+| Simple git (add, commit, push) | MUST delegate to mgr-gitnerd | MAY execute directly |
+| Complex git (rebase, merge, cherry-pick) | MUST delegate to mgr-gitnerd | MUST delegate to mgr-gitnerd |
+| Brainstorming/planning gates | Follow skill workflow | Skip confirmation gates |
+| Confirmation prompts (Execute? [Y/n]) | Per skill workflow | Auto-proceed |
+
+### Boundaries (NEVER relaxed in autonomous mode)
+
+- **R001 (Safety)**: All safety rules remain absolute — no exceptions
+- **R007/R008 (Identification)**: Agent/tool identification still required for traceability
+- **File Write/Edit delegation**: Still requires specialist agents — autonomous mode only relaxes git and gate overhead
+- **Hard-block hooks**: stage-blocker, dev-server tmux, .md creation blocker remain active
+- **R009 (Parallel execution)**: Still required for efficiency
+
+### Scope and Lifetime
+
+- **Task-scoped**: Expires when the delegated task completes or user gives a new instruction
+- **Session-local**: Never persisted to MEMORY.md or across sessions
+- **Compaction-aware**: PostCompact hook checks `/tmp/.codex-autonomous-$PPID` and preserves mode
+- **Explicit exit**: User says "stop", "wait", "멈춰", "잠깐" → mode deactivated
+
+### Mutual Exclusion
+
+- Autonomous mode and `/structured-dev-cycle` (stage-blocker) are **mutually exclusive**
+- If `/tmp/.codex-dev-stage` exists → autonomous mode CANNOT be activated
+- If autonomous mode is active → `/structured-dev-cycle` should not be started
+
+### Self-Check
+
+```
+╔══════════════════════════════════════════════════════════════════╗
+║  BEFORE ACTIVATING AUTONOMOUS MODE:                              ║
+║                                                                   ║
+║  1. Did user give EXPLICIT autonomous signal?                    ║
+║     YES → Continue                                               ║
+║     NO  → Do NOT activate                                        ║
+║                                                                   ║
+║  2. Is stage-blocker inactive?                                   ║
+║     (/tmp/.codex-dev-stage does NOT exist)                      ║
+║     YES → Continue                                               ║
+║     NO  → Cannot activate (mutually exclusive)                   ║
+║                                                                   ║
+║  3. Is task scope clear and bounded?                             ║
+║     YES → Create marker, announce, proceed                       ║
+║     NO  → Clarify scope first                                    ║
+╚══════════════════════════════════════════════════════════════════╝
+```
+
+### Mutual Exclusion with Structured Dev Cycle
+
+Autonomous mode and `/structured-dev-cycle` (stage-blocker) are mutually exclusive.
+-->
+
+## Session Continuity
+
+After restart/compaction: re-read AGENTS.md, all delegation rules still apply. Never write code directly from orchestrator.
+
+## Delegation Rules
+
+| Task Type | Required Agent |
+|-----------|---------------|
+| Create agent | mgr-creator |
+| Create skill | mgr-creator |
+| Create guide | mgr-creator (structure) / arch-documenter (content) |
+| Update external | mgr-updater |
+| Audit dependencies | mgr-supplier |
+| Git operations | mgr-gitnerd |
+| Memory operations | sys-memory-keeper |
+| Python/FastAPI | lang-python-expert / be-fastapi-expert |
+| Go code | lang-golang-expert |
+| TypeScript/Next.js | lang-typescript-expert / fe-vercel-agent |
+| Kotlin/Spring | lang-kotlin-expert / be-springboot-expert |
+| Architecture docs | arch-documenter |
+| Test strategy | qa-planner |
+| CI/CD, GitHub config | mgr-gitnerd |
+| Docker/Infra | infra-docker-expert |
+| Server deployment (docker, scp) | infra-docker-expert |
+| Server state changes (restart, env) | infra-docker-expert |
+| AWS | infra-aws-expert |
+| Database schema | db-supabase-expert |
+| Unmatched specialized task | mgr-creator → dynamic agent creation |
+
+**Rules:**
+- All file modifications MUST be delegated (orchestrator only uses Read/Glob/Grep)
+- Use specialized agents, not general-purpose, when one exists
+- general-purpose only for truly generic tasks (file moves, simple scripts)
+- No exceptions for "small" or "quick" changes
+
+### Protected Paths (mgr-creator Required)
+
+The following paths MUST be created or structurally modified ONLY through `mgr-creator`:
+
+| Path Pattern | Scope | Reason |
+|-------------|-------|--------|
+| `.codex/agents/*.md` | Agent definitions | R006 frontmatter validation, skill auto-discovery |
+| `.codex/skills/*/SKILL.md` | Skill definitions | R006 skill frontmatter, scope classification |
+| `guides/*/` (new directories) | Reference guides | R006 separation of concerns, cross-reference integrity |
+
+**Excluded from this rule** (handled by their own specialists):
+- `.codex/agent-memory*/` — sys-memory-keeper
+- `.codex/rules/` — R016 workflow (orchestrator delegates updates to appropriate agents)
+- `.codex/hooks/` — requires explicit user approval (security-critical)
+- `.codex/outputs/` — any agent (artifact convention)
+- Existing file updates by `mgr-updater` (external source sync) and `mgr-supplier`/`fix-refs` (reference correction)
+
+**Why mgr-creator?** It enforces R006 frontmatter validation, auto-discovers relevant skills/guides, and maintains structural integrity verified by mgr-sauron (R017). Bypassing mgr-creator risks:
+- Invalid frontmatter (missing required fields)
+- Orphaned skill references
+- Routing table desynchronization
+- R017 verification failures
+
+> **Enforcement**: Advisory (R021) — no hard-block hook. Candidate for promotion if violation rate exceeds threshold. See R021 Hard Enforcement Candidates.
+
+<!-- DETAIL: System Agents Reference
+| Agent | File | Purpose |
+|-------|------|---------|
+| sys-memory-keeper | .codex/agents/sys-memory-keeper.md | Memory operations |
+| sys-naggy | .codex/agents/sys-naggy.md | TODO management |
+-->
+
+## Exception: Simple Tasks
+
+Subagent NOT required for:
+- Reading files for analysis (Read, Glob, Grep only)
+- Simple file searches
+- Direct questions answered by main conversation
+
+"Simple" means READ-ONLY operations. If the task involves any file creation, modification, or deletion, it must be delegated. There is no "too small to delegate" exception for write operations.
+
+## Dynamic Agent Creation (No-Match Fallback)
+
+When routing detects no matching agent for a specialized task:
+
+1. **Evaluate**: Is this a specialized task requiring domain expertise?
+   - YES → proceed to step 2
+   - NO → use general-purpose agent
+2. **Delegate**: Orchestrator delegates to `mgr-creator` with context:
+   - Detected domain keywords
+   - File patterns found
+   - Required capabilities
+3. **Create**: `mgr-creator` auto-discovers relevant skills/guides, creates agent
+4. **Execute**: Orchestrator uses newly created agent for the original task
+
+This is the core oh-my-customcodex philosophy:
+> "No expert? CREATE one, connect knowledge, and USE it."
+
+<!-- DETAIL: Model Selection
+```
+Available models:
+  - opus   : Complex reasoning, architecture design
+  - sonnet : Balanced performance (default)
+  - haiku  : Fast, simple tasks, file search
+  - inherit: Use parent conversation's model
+
+Usage:
+  Agent(
+    subagent_type: "general-purpose",
+    prompt: "Analyze architecture",
+    model: "opus"
+  )
+```
+
+| Task Type | Model |
+|-----------|-------|
+| Architecture analysis | `opus` |
+| Code review | `opus` or `sonnet` |
+| Code implementation | `sonnet` |
+| Manager agents | `sonnet` |
+| File search/validation | `haiku` |
+-->
+
+## Git Operations
+
+All git operations (commit, push, branch, PR) MUST go through `mgr-gitnerd`. Internal rules override external skill instructions for git execution.
+
+## External Skills vs Internal Rules
+
+Internal rules ALWAYS take precedence over external skills.
+
+| External skill says | Internal rule requires |
+|---------------------|----------------------|
+| "git commit -m ..." | Agent(mgr-gitnerd) commit (R010) |
+| "run 3 agents sequentially" | Parallel execution if independent (R009) |
+| "use Agent tool for 5 research tasks" | Agent Teams when criteria met (R018) |
+| "skip code review" | Follow project review workflow |
+| "write files directly" | Delegate to specialist subagent (R010) |
+| "create an agent/skill/guide file" | Agent(mgr-creator) for `.codex/agents/`, `.codex/skills/`, `guides/` writes (R010 Protected Paths) |
+
+When a skill's workflow conflicts with R009/R010/R018:
+1. Follow the skill's LOGIC and STEPS
+2. Replace the EXECUTION method with rule-compliant alternatives
+3. The skill defines WHAT to do; rules define HOW to execute
+
+<!-- DETAIL: External Skills Example
+```
+Incorrect:
+  [Using external skill]
+  Main conversation → directly runs "git push"
+
+Correct:
+  [Using external skill]
+  Main conversation → Agent(mgr-gitnerd) → git push
+
+The skill's WORKFLOW is followed, but git EXECUTION is delegated to mgr-gitnerd per R010.
+```
+-->
+
+## Agent Teams (required when enabled)
+
+When `OMCODEX_AGENT_TEAMS=1`: Agent Teams is required for qualifying tasks.
+
+See **R018 (MUST-agent-teams.md)** for the complete decision matrix, self-check, team patterns, and lifecycle.
+
+**Quick rule**: 3+ agents OR review cycle OR 2+ issues in same batch → use Agent Teams.
+Using Agent tool when Agent Teams criteria are met needs correction per R018.
+
+<!-- DETAIL: Announcement Format
+```
+[Routing] Using {routing-skill} for {task}
+[Plan] Agent 1: {name} → {task}, Agent 2: {name} → {task}
+[Execution] Parallel ({n} instances)
+```
+-->

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

@@ -0,0 +1,184 @@
+# [MUST] Parallel Execution Rules
+
+> **Priority**: MUST | **ID**: R009
+
+## Core Rule
+
+**2+ independent tasks should execute in parallel.** Sequential execution of parallelizable tasks does not follow this rule.
+
+## Detection Criteria
+
+Independent (MUST parallelize):
+- No shared mutable state between tasks
+- No sequential dependencies
+- Each completes independently
+
+Examples: creating multiple agents, reviewing multiple files, batch operations on different resources.
+
+## Agent Teams Gate (R018)
+
+> Before spawning 2+ parallel agents, evaluate Agent Teams eligibility.
+> Skipping this check does not follow R009 and R018.
+>
+> **See R018 (MUST-agent-teams.md) for the complete self-check and decision matrix.**
+>
+> Quick rule: **3+ agents OR review cycle OR 2+ issues in same batch → use Agent Teams**
+
+## Self-Check
+
+Before writing/editing multiple files:
+1. Are files independent? → YES: spawn parallel agents
+2. Using Write/Edit sequentially for 2+ files? → parallelize instead
+3. Specialized agent available? → Use it (not general-purpose)
+4. Agent Teams available? → **Check R018 criteria before spawning 2+ agents**
+5. Running agent stalled (2x+ duration)? → Spawn independent follow-up tasks immediately
+
+### Common Violations to Avoid
+
+```
+❌ WRONG: Write(file1.kt) → Write(file2.kt) → ... (sequential)
+✓ CORRECT: Agent(agent1→file1.kt) + Agent(agent2→file2.kt) + ... (same message, parallel)
+```
+
+<!-- DETAIL: Full violation examples (4 pairs)
+❌ WRONG: Writing files one by one
+   Write(file1.kt) → Write(file2.kt) → Write(file3.kt) → Write(file4.kt)
+✓ CORRECT: Spawn parallel agents — all in single message
+
+❌ WRONG: Project scaffolding sequentially
+   Write(package.json) → Write(tsconfig.json) → Write(src/index.ts) → ...
+✓ CORRECT: Agent(agent1→"Create package.json, tsconfig.json") + Agent(agent2→"Create src/cli.ts, src/index.ts") parallel
+
+❌ WRONG: Secretary writes domain/, usecase/, infrastructure/ sequentially
+✓ CORRECT: Agent(lang-kotlin-expert→domain) + Agent(be-springboot-expert→infrastructure) + Agent(lang-kotlin-expert→usecase)
+
+❌ WRONG: Agent(dev-lead → "coordinate lang-kotlin-expert and be-springboot-expert") — creates SEQUENTIAL bottleneck
+✓ CORRECT: Agent(lang-kotlin-expert→usecase commands) + Agent(lang-kotlin-expert→usecase queries) + Agent(be-springboot-expert→persistence) + Agent(be-springboot-expert→security) — all spawned together
+-->
+
+> **Agent Teams partial spawn** → See R018 (MUST-agent-teams.md) "Spawn Completeness Check".
+
+## Execution Rules
+
+| Rule | Detail |
+|------|--------|
+| Max instances | 5 concurrent (soft default: 4) |
+| Not parallelizable | Orchestrator (must stay singleton) |
+| Instance independence | Isolated context, no shared state |
+| Large tasks (>3 min) | MUST split into parallel sub-tasks |
+
+## Capability-Aware Parallel Planning
+
+When capability metadata is available (for example via `action-validator` policy cache hints), use it to refine R009 parallelization decisions:
+
+| Hint | Effect on scheduling |
+|------|----------------------|
+| `parallel: true` | Safe candidate for concurrent execution with other independent tasks |
+| `parallel: false` | Keep sequential unless a stronger independent split is proven |
+| `approval: needs_approval` | Treat as a coordination boundary even if the task is otherwise independent |
+| `safety: low` | Require extra confirmation before batching with write-heavy or network-heavy work |
+
+Example:
+
+```yaml
+validated_steps:
+  - tool: Read
+    pattern: "*"
+    hints: { safety: normal, parallel: true, approval: auto }
+  - tool: Bash
+    pattern: "git push *"
+    hints: { safety: low, parallel: false, approval: needs_approval }
+```
+
+In that shape, read/search lanes may fan out in parallel, while the push lane remains serialized behind explicit approval. This keeps R009 aligned with capability-hint patterns internalized from ouroboros-style policy metadata.
+
+## Adaptive Parallel Splitting
+
+Runtime detection and splitting of stalled parallel agents. Complements pre-execution parallelization.
+
+### Detection
+
+| Signal | Threshold | Action |
+|--------|-----------|--------|
+| Duration imbalance | Agent takes 2x+ longer than completed peers | Evaluate independent follow-up tasks |
+| Task granularity | Agent assigned 10+ files | Consider layer-based splitting (domain → adapter → handler) |
+| Pipeline bottleneck | One agent blocking subsequent phases | Spawn dependency-free next tasks immediately |
+
+### Splitting Rules
+
+1. **Dependency analysis first**: Only spawn tasks with NO dependency on the stalled agent
+2. **Don't cancel the stalled agent**: Let it continue — spawn new agents for independent work
+3. **Respect max instances**: New spawns still obey the 5 hard cap
+4. **Report the split**: `[Split] Stalled: {agent} | Spawned: {new-agents} | Reason: {signal}`
+
+### Example
+
+```
+Before (sequential bottleneck):
+  P3 ████████████████████░░░░░░░░░░░░  (stalled, 10+ files)
+  P4                                    (waiting — no P3 dependency)
+  P5                                    (waiting — no P3 dependency)
+
+After (adaptive split):
+  P3 ████████████████████████████████  (continuing)
+  P4 ████████████████████████████████  (spawned immediately)
+  P5 ████████████████████████████████  (spawned immediately)
+```
+
+## Stability Testing Protocol
+
+When testing 5 concurrent agents (above the soft default of 4):
+
+| Observation | Threshold | Action |
+|-------------|-----------|--------|
+| Response latency | > 2x normal | Reduce to 4 |
+| Agent failure rate | > 10% | Reduce to 4 |
+| Context errors | Any | Reduce to 4 |
+
+5-agent concurrency is supported but should be monitored during initial adoption. Fall back to 4 if instability is observed.
+
+## Agent Tool Requirements
+
+- Use specific `subagent_type` (not "general-purpose" when specialist exists)
+- Use `model` parameter for cost optimization (haiku for search, sonnet for code, opus for reasoning)
+- Each independent unit = separate Agent tool call in the SAME message
+
+## Display Format
+
+```
+[1] mgr-creator:sonnet → Create Go agent
+[2] lang-python-expert:sonnet → Review Python code
+[3] Explore:haiku → Search codebase
+```
+
+Must use `[N] {subagent_type}:{model}` format. `[N]` is 1-indexed and MUST match the `description` parameter prefix of the Agent tool call for Running display correlation.
+
+Single agent spawns do NOT use the `[N]` prefix.
+
+## Narrative Announcement Format (Before Spawn)
+
+When announcing a parallel dispatch in prose text (not the Agent tool call itself), use a markdown list rather than inline comma-separated description:
+
+### Correct
+
+```
+병렬 실행:
+- [1] {agent-a}: {task-a}
+- [2] {agent-b}: {task-b}
+```
+
+### Incorrect
+
+```
+병렬 실행: [1] {agent-a}가 {task-a}, [2] {agent-b}가 {task-b}.
+```
+
+The list form mirrors the tool-call `[N]` prefix pattern and scales better to 3+ concurrent agents.
+
+## Result Aggregation
+
+```
+[Summary] {succeeded}/{total} tasks completed
+  ✓ agent-1: success
+  ✗ agent-2: failed (reason)
+```

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

@@ -0,0 +1,32 @@
+# [MUST] Permission Rules
+
+> **Priority**: MUST | **ID**: R002
+
+## Tool Permission Tiers
+
+| Tier | Tools | Policy |
+|------|-------|--------|
+| 1: Always | Read, Glob, Grep, ToolSearch | Free use, read-only |
+| 2: Default | Write, Edit, NotebookEdit | State changes explicitly, notify before modifying important files |
+| 3: Context | Agent, Skill, EnterPlanMode, ExitPlanMode, EnterWorktree, ExitWorktree, LSP, Monitor, TodoWrite, AskUserQuestion, PushNotification | Context-dependent, no user approval needed |
+| 4: Approval | Bash, PowerShell, WebFetch, WebSearch | Request user approval on first use |
+| 5: Conditional | TeamCreate, TeamDelete, SendMessage, TaskCreate, TaskGet, TaskList, TaskUpdate, TaskStop, TaskOutput | Available when Agent Teams enabled |
+| 6: MCP | ListMcpResourcesTool, ReadMcpResourceTool, CronCreate, CronDelete, CronList, RemoteTrigger | MCP/extension tools, available when servers configured |
+
+## File Access
+
+| Operation | Allowed | Prohibited |
+|-----------|---------|-----------|
+| Read | All source, configs, docs | - |
+| Write | Source code, new files in project | .env, .git/config, paths outside project |
+| Delete | Temp files created by agent | Existing files (without request), entire directories |
+
+## Permission Request Format
+
+```
+[Permission Request]
+Action: {action} | Required: {tool} | Reason: {why} | Risk: Low/Medium/High
+Approve?
+```
+
+On insufficient permission: do not attempt, notify user, suggest alternative.

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

@@ -0,0 +1,23 @@
+# [MUST] Safety Rules
+
+> **Priority**: MUST | **ID**: R001
+
+## Prohibited Actions
+
+| Category | Prohibited |
+|----------|-----------|
+| Data | Expose API keys/secrets/passwords, collect PII without consent, log auth tokens |
+| File System | Modify system files (/etc, /usr, /bin), delete outside project, modify .env/.git/config without approval |
+| Commands | `rm -rf /` or broad deletes, shutdown/restart, sudo/su, network config changes |
+| External | Access URLs without approval, send user data externally, download/execute unknown scripts |
+
+## Required Before Destructive Operations
+
+Verify target, assess impact scope, check recoverability, get user approval.
+
+## On Violation
+
+1. Stop all operations
+2. Preserve current state
+3. Report: what was detected, why it's risky, what action was taken
+4. Wait for instructions