oh-my-customcodex 0.1.0

package/templates/.claude/rules/MUST-agent-teams.md

@@ -0,0 +1,293 @@
+# [MUST] Agent Teams Rules (Conditional)
+
+> **Priority**: MUST | **ID**: R018
+> **Condition**: Agent Teams enabled (`OMCODEX_AGENT_TEAMS=1`)
+> **Fallback**: When disabled, R009/R010 apply
+
+## Detection
+
+Available when `OMCODEX_AGENT_TEAMS=1` or TeamCreate/SendMessage tools present.
+
+## Decision Matrix
+
+| Scenario | Preferred | Reason |
+|----------|-----------|--------|
+| Simple independent subtasks | Agent Tool | Lower cost, no coordination overhead |
+| Sequential-dependency init/scaffolding | Agent Tool | Blocked agents waste tokens polling; single agent faster |
+| Multi-step with shared state | **Agent Teams** | Shared task list, peer messaging |
+| Research requiring discussion | **Agent Teams** | Iterative discovery, synthesis |
+| Cost-sensitive batch ops | Agent Tool | Minimal token overhead |
+| Complex debugging across modules | **Agent Teams** | Cross-module state sharing |
+| Code review + fix cycle | **Agent Teams** | Review → fix → re-review loop |
+| Single file operations | Agent Tool | Overkill for simple tasks |
+| Dynamic agent creation + usage | **Agent Teams** | Create → test → iterate cycle |
+| Multi-issue release batch | **Agent Teams** | Shared task tracking, coordinated release |
+
+**When Agent Teams is enabled and criteria are met, usage is required.**
+
+### Scope: Intra-Session vs Cross-Session
+
+| Scope | Tool | Protocol | Use Case |
+|-------|------|----------|----------|
+| Intra-session | `SendMessage` (Agent Teams) | Peer-to-peer within team | Multi-agent collaboration in one session |
+| Cross-session | `send_message` (claude-peers-mcp) | Broker-mediated | Multi-terminal/project coordination |
+
+These are distinct mechanisms. Agent Teams `SendMessage` requires `TeamCreate` and operates within a single Claude Code session. claude-peers-mcp `send_message` operates across separate Claude Code processes via a localhost broker.
+
+## Self-Check (Before Agent Tool)
+
+Before using Agent tool for 2+ agent tasks, complete this check:
+Quick rule: 3+ agents OR review cycle → use Agent Teams. Sequential deps / scaffolding → Agent Tool. 2+ issues in same batch → prefer Agent Teams.
+
+<!-- DETAIL: Self-Check (Before Agent Tool)
+╔══════════════════════════════════════════════════════════════════╗
+║  BEFORE USING Agent TOOL FOR 2+ AGENTS:                          ║
+║                                                                   ║
+║  1. Is Agent Teams available?                                    ║
+║     YES → check criteria #2-#4                                  ║
+║     NO  → Proceed with Agent tool                               ║
+║                                                                   ║
+║  2. Will 3+ agents be involved?                                  ║
+║     YES → use Agent Teams                                        ║
+║     NO  → Check #3                                               ║
+║                                                                   ║
+║  3. Is there a review → fix → re-review cycle?                  ║
+║     YES → use Agent Teams                                        ║
+║     NO  → Check #4                                               ║
+║                                                                   ║
+║  4. Are 2+ issues being fixed in the same release batch?        ║
+║     YES → prefer Agent Teams (coordination benefit)              ║
+║     NO  → Check #5                                               ║
+║                                                                   ║
+║  5. Are tasks sequentially dependent (init/scaffold)?            ║
+║     YES → prefer Agent Tool (single agent, no coordination)     ║
+║     NO  → Continue with Agent Teams                              ║
+║                                                                   ║
+║  Simple rule: 3+ agents OR review cycle → use Agent Teams        ║
+║  Sequential deps / scaffolding → Agent Tool (single agent)       ║
+║  2+ issues in same batch → prefer Agent Teams                    ║
+║  Everything else → Agent tool                                    ║
+╚══════════════════════════════════════════════════════════════════╝
+-->
+
+### Spawn Completeness Check
+
+All members must be spawned in a single message. Partial spawning needs correction per R018 and R009.
+
+<!-- DETAIL: Self-Check (Spawn Completeness)
+╔══════════════════════════════════════════════════════════════════╗
+║  BEFORE SPAWNING TEAM MEMBERS:                                   ║
+║                                                                   ║
+║  1. How many members does this team need?  N = ___               ║
+║  2. Am I spawning ALL N members in THIS message?                 ║
+║     YES → Good. Continue.                                        ║
+║     NO  → Spawn all N members in this message before proceeding. ║
+║                                                                   ║
+║  Partial spawn (e.g., 1/3) = needs correction                    ║
+║  Sequential spawn (one per message) = needs correction           ║
+║  All at once in single message = correct                         ║
+╚══════════════════════════════════════════════════════════════════╝
+-->
+
+<!-- DETAIL: External Skill Conflict Resolution
+When an external skill instructs using Agent tool but R018 criteria are met:
+
+| Skill says | R018 requires | Resolution |
+|------------|--------------|------------|
+| "Use Agent tool for N tasks" | 3+ agents → Teams | Use Agent Teams, follow skill logic |
+| "Sequential agent spawning" | Independent tasks → parallel | Parallelize per R009 |
+| "Skip coordination" | Shared state → Teams | Use Teams for coordination |
+
+Rule: External skills define the WORKFLOW. R018 defines the EXECUTION METHOD.
+The skill's steps are followed, but agent spawning uses Teams when criteria are met.
+-->
+
+## Common Violations
+
+```
+❌ WRONG: 3+ tasks using Agent tool instead of Agent Teams
+   Agent(Explore):haiku → Analysis 1
+   Agent(Explore):haiku → Analysis 2
+   Agent(Explore):haiku → Analysis 3
+
+✓ CORRECT: TeamCreate → spawn researchers → coordinate via shared task list
+   TeamCreate("research-team") + Agent(researcher-1/2/3) + SendMessage(coordinate)
+```
+
+<!-- DETAIL: Common Violations (full examples)
+❌ WRONG: Agent Teams enabled, 3+ research tasks using Agent tool
+   Agent(Explore):haiku → Analysis 1
+   Agent(Explore):haiku → Analysis 2
+   Agent(Explore):haiku → Analysis 3
+
+✓ CORRECT: TeamCreate → spawn researchers → coordinate via shared task list
+   TeamCreate("research-team")
+   Agent(researcher-1) → Analysis 1  ┐
+   Agent(researcher-2) → Analysis 2  ├─ Spawned as team members
+   Agent(researcher-3) → Analysis 3  ┘
+   SendMessage(coordinate)
+
+❌ WRONG: Code review + fix as independent Agents
+   Agent(reviewer) → "Review code"
+   (receive result)
+   Agent(implementer) → "Fix issues"
+   (receive result)
+   Agent(reviewer) → "Re-review"
+
+✓ CORRECT: Agent Teams for review-fix cycle
+   TeamCreate("review-fix")
+   Agent(reviewer) + Agent(implementer) → team members
+   reviewer → SendMessage(implementer, "issues found")
+   implementer → fixes → SendMessage(reviewer, "fixed")
+   reviewer → re-reviews → done
+
+❌ WRONG: Spawning team members one at a time
+   TeamCreate("research-team")
+   Message 1: Agent(researcher-1) → Analysis 1   (only 1/3 spawned)
+   Message 2: Agent(researcher-2) → Analysis 2   (late spawn)
+   Message 3: Agent(researcher-3) → Analysis 3   (late spawn)
+
+✓ CORRECT: All members in a single message
+   TeamCreate("research-team")
+   Single message:
+     Agent(researcher-1) → Analysis 1  ┐
+     Agent(researcher-2) → Analysis 2  ├─ ALL spawned together
+     Agent(researcher-3) → Analysis 3  ┘
+
+❌ WRONG: Completed member modifies other member's files
+   svelte-projects completes task → browses TaskList → edits agent-teams-advisor.sh (hook-fixer's scope)
+
+✓ CORRECT: Completed member reports and waits
+   svelte-projects completes task → SendMessage("Task complete") → waits silently
+-->
+
+## Cost Guidelines
+
+| Criteria | Agent Tool | Agent Teams |
+|----------|-----------|-------------|
+| Agent count | 1-2 | 3+ |
+| Inter-task dependency | None | Present |
+| Iteration cycles | None | Present (review→fix→re-review) |
+| Estimated duration | < 3 min | > 3 min |
+| Shared state needed | No | Yes |
+
+## Team Patterns
+
+Standard: Research (researcher-1 + researcher-2 + synthesizer), Development (implementer + reviewer + tester), Debug (investigator-1 + investigator-2 + fixer).
+Hybrid: Review+Fix, Create+Validate, Multi-Expert, Dynamic Creation, Codex Hybrid.
+
+<!-- DETAIL: Team Patterns
+### Standard Patterns
+- Research: researcher-1 + researcher-2 + synthesizer
+- Development: implementer + reviewer + tester
+- Debug: investigator-1 + investigator-2 + fixer
+
+### Hybrid Patterns
+- Review+Fix: reviewer + implementer (reviewer finds issues → implementer fixes → reviewer re-checks)
+- Create+Validate: mgr-creator + qa-engineer (create agent → validate → iterate)
+- Multi-Expert: expert-1 + expert-2 + coordinator (cross-domain tasks requiring multiple specialties)
+
+### Dynamic Patterns
+- Dynamic Creation: mgr-creator + domain-expert (create new agent → immediately use for pending task)
+- Codex Hybrid: codex-exec-agent + claude-reviewer (Codex generates → Claude reviews/refines)
+
+### Codex-Exec Integration
+When both Agent Teams and codex-exec are available:
+  1. Claude agent analyzes requirements
+  2. codex-exec generates implementation (Codex strength: code generation)
+  3. Claude agent reviews and refines (Claude strength: reasoning, quality)
+  4. Iterate via team messaging until quality meets standards
+
+| Step | Agent | Model |
+|------|-------|-------|
+| Analysis | Claude team member | sonnet/opus |
+| Generation | codex-exec | (Codex default) |
+| Review | Claude team member | sonnet |
+| Refinement | Appropriate expert | sonnet |
+
+### Dynamic Agent Creation in Teams
+When Agent Teams creates a new agent via mgr-creator:
+1. Team lead identifies missing expertise
+2. Spawns mgr-creator as team member
+3. mgr-creator creates agent with auto-discovered skills
+4. New agent joins team immediately
+5. Team continues with expanded capabilities
+-->
+
+## Blocked Agent Behavior
+
+When a team member is blocked: prefer Deferred spawn (no wasted tokens) > Silent wait (short waits) > Reassign (blocked >2 min).
+Post-completion: report via SendMessage, wait silently. Do NOT browse TaskList or modify files outside scope.
+
+<!-- DETAIL: Blocked Agent Behavior
+| Strategy | When | Benefit |
+|----------|------|---------|
+| Deferred spawn | Dependency chain is clear | No wasted tokens; spawn after blocker completes |
+| Silent wait | Agent already spawned, short wait expected | Minimal overhead |
+| Reassign | Agent blocked >2 min with no progress | Reuse agent for unblocked work |
+
+### Prompt Guidelines for Team Members
+When spawning agents that may be blocked:
+1. Include explicit instruction: "If your task is blocked, wait silently. Do NOT send periodic status messages."
+2. Set check interval: "Check TaskList once per minute, not continuously."
+3. Prefer deferred spawn when the dependency resolution time is unpredictable.
+4. Post-completion instruction: "After completing your task, report via SendMessage and wait. Do NOT explore or modify files outside your scope."
+5. Explicit scope boundary: "Your scope is limited to: {file list or directory}. Do NOT modify files outside this scope."
+
+### Anti-Pattern: Idle Polling
+❌ WRONG: Blocked agent sends repeated status messages
+   docker-dev: "Task #1 still pending..."  (×5 messages, wasting tokens)
+
+✓ CORRECT: Deferred spawn after dependency resolves
+   (Task #1 completes) → then spawn docker-dev for Task #3
+
+✓ ALSO CORRECT: Silent wait with infrequent checks
+   docker-dev spawned with: "Wait silently if blocked. Check TaskList once per minute."
+
+### Post-Completion Scope Constraint
+| Behavior | Correct | Wrong |
+|----------|---------|-------|
+| Task completed | Report completion via SendMessage, wait silently | Browse TaskList for other work |
+| No more tasks | Exit or wait for team shutdown | Explore/modify files outside original scope |
+| See unfinished work | Report to team lead, do NOT self-assign | Edit files that belong to other members |
+
+### Self-Check (After Task Completion)
+╔══════════════════════════════════════════════════════════════════╗
+║  AFTER COMPLETING YOUR ASSIGNED TASK:                            ║
+║                                                                   ║
+║  1. Did I complete ONLY my assigned task?                        ║
+║     YES → Report completion                                      ║
+║     NO  → Revert scope-violation changes                         ║
+║                                                                   ║
+║  2. Are there files modified outside my task scope?              ║
+║     YES → This is a violation — revert                           ║
+║     NO  → Good                                                    ║
+║                                                                   ║
+║  3. Am I about to explore/modify files for "other tasks"?        ║
+║     YES → STOP. Report to team lead instead                      ║
+║     NO  → Good. Wait silently or exit                            ║
+╚══════════════════════════════════════════════════════════════════╝
+-->
+
+## Lifecycle
+
+```
+TeamCreate → TaskCreate → Agent(spawn members) → SendMessage(coordinate)
+  → TaskUpdate(progress) → ... → shutdown members → TeamDelete
+```
+
+## Fallback
+
+When Agent Teams unavailable: use Agent tool with R009/R010 rules.
+When Agent Teams available: actively prefer it for qualifying tasks.
+
+## Cost Awareness
+
+Agent Teams actively preferred for qualifying collaborative tasks. Use Agent tool only when:
+- 1-2 agents with no inter-dependency
+- No review → fix cycles
+- Simple independent subtasks
+
+Do NOT avoid Agent Teams solely for cost reasons when criteria are met.
+
+**Active preference rule**: When Agent Teams is available, default to using it for any multi-step or multi-issue work. Only fall back to Agent tool for truly simple, single-issue tasks with no verification needs.

package/templates/.claude/rules/MUST-completion-verification.md

@@ -0,0 +1,112 @@
+# [MUST] Completion Verification Rules
+
+> **Priority**: MUST | **ID**: R020
+
+## Core Rule
+
+Before declaring any task `[Done]`, verify completion against task-type-specific criteria. False completion declarations erode trust and cause downstream failures.
+
+## Task-Type Completion Matrix
+
+| Task Type | REQUIRED Verification Before [Done] |
+|-----------|-------------------------------------|
+| Release | All issues closed, version bumped, PR merged, GitHub Release created; **External automation verified**: `.github/workflows/` listed AND `gh run list --limit 10` checked for auto-publish workflows |
+| Implementation | Code compiles/passes lint, tests pass (if exist), no TODO markers left |
+| Documentation | Links valid, counts accurate, cross-references updated |
+| Git Operations | Operation succeeded (check exit code), working tree clean |
+| Code Review | All findings addressed or explicitly deferred with justification |
+| Agent/Skill Creation | Frontmatter valid, referenced skills exist, routing updated |
+
+## Self-Check (Before Declaring Done)
+
+Before [Done]: (1) Verify ACTUAL outcome not just attempt — "ran command" ≠ "succeeded". (2) Check task-type criteria above. (3) No unchecked items. (4) Would bet $100 it's complete.
+
+<!-- DETAIL: Self-Check box
+1. Did I verify ACTUAL outcome? "I ran the command" ≠ "the command succeeded" → YES: Continue / NO: Verify first
+2. Does task type have specific criteria? YES: Check each / NO: Apply general verification
+3. Any unchecked items? YES: Complete or defer with reason / NO: Proceed to [Done]
+4. Would I bet $100 this is truly complete? YES: Declare [Done] / NO: Identify uncertain and verify
+-->
+
+## Subagent Self-Report Verification — Verify "pre-existing" claims against base branch before acceptance. See details via Read tool.
+
+<!-- DETAIL: Subagent Self-Report Verification
+
+Subagents often report failures as "pre-existing", "baseline", or "unchanged". These claims MUST be verified against the base branch before acceptance.
+
+| Subagent Claim | Required Verification |
+|----------------|----------------------|
+| "X test already failing on base" | `git stash && git checkout {base} && run test X && compare` |
+| "This warning is pre-existing" | `git log -S "warning-text" {base}` or run on clean checkout |
+| "File was unchanged" | `git diff {base}..HEAD -- {file}` |
+| "Dependency issue not from this PR" | `git show {base}:package.json` compare |
+
+Never accept "pre-existing" without direct base-branch evidence. A false "pre-existing" claim can mask a regression introduced by the current change.
+-->
+
+## Common False Completion Patterns — 7 anti-patterns including "Command executed" without exit code check, "Waiting for manual publish" when CI auto-publishes. See full table via Read tool.
+
+<!-- DETAIL: Common False Completion Patterns
+
+| Pattern | Reality | Fix |
+|---------|---------|-----|
+| "Command executed" | Exit code not checked | Check `$?` or tool output |
+| "File created" | Content not verified | Read file back, verify content |
+| "PR created" | CI not checked | Wait for CI, verify green |
+| "Issue closed" | Related issues not updated | Check parent epic, cross-refs |
+| "Tests pass" | Only ran subset | Run full test suite |
+| "Waiting for manual publish" | External CI/CD auto-publishes on merge | Check `.github/workflows/` BEFORE assuming manual step |
+| "Subagent said pre-existing" | Claim not verified against base branch | Run test on base branch, compare directly |
+-->
+
+## Completion Contract Format — [Contract] + [Done] with criterion/evidence pairs. See template via Read tool.
+
+<!-- DETAIL: Completion Contract Format
+
+For complex tasks, declare completion contract upfront:
+
+```
+[Contract] Task: {name}
+├── Criterion 1: {specific, verifiable condition}
+├── Criterion 2: {specific, verifiable condition}
+└── Criterion N: {specific, verifiable condition}
+```
+
+Then at completion:
+
+```
+[Done] Task: {name}
+├── ✓ Criterion 1: {evidence}
+├── ✓ Criterion 2: {evidence}
+└── ✓ Criterion N: {evidence}
+```
+-->
+
+## Autonomous Mode Entry Checklist — 5-step inventory (workflows, runs, publish targets, manual points, cross-reference). See full checklist via Read tool.
+
+<!-- DETAIL: Autonomous Mode Entry Checklist
+
+When entering autonomous mode (user grants extended execution without per-step confirmation), perform this inventory BEFORE first action:
+
+1. **Workflow inventory**: `ls .github/workflows/` — identify auto-publish, auto-tag, release, docs-sync, CI workflows
+2. **Recent runs**: `gh run list --limit 10` — check success/failure patterns of automated workflows
+3. **External publish targets**: Check if npm/PyPI/Docker Hub/GitHub Releases are auto-triggered on merge
+4. **Manual intervention points**: Identify which steps require human approval vs. fully automated
+5. **Cross-reference with task**: Which workflows will the planned work trigger?
+
+Record findings in session context. Failure to inventory automation is a R020 violation (unknown external state = unverifiable completion).
+
+### Cross-reference
+
+Related memory records:
+- `feedback_github_workflows_inventory.md` — original incident (v0.87.2~v0.88.0 session)
+- `feedback_subagent_pre_existing_claims.md` — subagent false-positive pattern
+-->
+
+## Integration
+
+| Rule | Interaction |
+|------|-------------|
+| R003 | [Done] status format now requires verification evidence |
+| R010 | Orchestrator verifies subagent completion claims |
+| R017 | Structural changes require sauron verification before [Done] |

package/templates/.claude/rules/MUST-continuous-improvement.md

@@ -0,0 +1,69 @@
+# [MUST] Continuous Improvement Rules
+
+> **Priority**: MUST | **ID**: R016 | **Trigger**: User points out rule violation
+
+## Core Rule
+
+When user points out a violation: update the relevant rule → commit → then continue original task.
+
+Update the relevant rule rather than just acknowledging the violation.
+
+## Workflow
+
+1. Acknowledge violation
+2. Identify root cause (which rule was weak/unclear?)
+3. Update the rule (add clarity, examples, self-checks)
+4. Commit the change
+5. Continue original task following updated rules
+
+## Integration
+
+| Situation | Action |
+|-----------|--------|
+| User points out violation | Update rule → Continue |
+| Self-detected violation | Fix immediately, consider rule update |
+| Ambiguous situation | Ask user, then update if needed |
+
+## Defect Response Matrix
+
+| Defect Type | Rule Update | Memory | Issue |
+|-------------|:-----------:|:------:|:-----:|
+| Rule violation (agent behavior) | ✅ | — | — |
+| CI/infra defect | — | ✅ | ✅ |
+| Process gap (workflow hole) | ✅ | ✅ | ✅ |
+| Repeatable system bug | — | ✅ | ✅ |
+| Agent selection failure (wrong agent routed) | — | ✅ | — |
+
+When CI failure, process gap, or repeatable system defect is found:
+1. Record feedback memory (defend current session)
+2. Register GitHub issue (trackable improvement item)
+3. Both required — memory alone is NOT sufficient for system-level defects
+
+### Adaptive Harness Integration
+
+When repeating agent failures or suboptimal routing is detected:
+1. Record as feedback memory (immediate session defense)
+2. Run `/omcodex:adaptive-harness --learn` to update project profile with failure patterns
+3. Profile updates improve future agent selection and harness optimization
+
+This connects R016's continuous improvement loop with the adaptive-harness skill's learning capability.
+
+## Anti-Patterns — 4 patterns: "I'll update later", "one-time exception", "doesn't cover this", "finish task first". See table via Read tool.
+
+<!-- DETAIL: Anti-Patterns
+| Anti-Pattern | Why It's Wrong | Correct Action |
+|-------------|----------------|----------------|
+| "I'll update the rule later" | Deferred fixes are forgotten | Update rule NOW, before continuing |
+| "This is a one-time exception" | Exceptions become patterns | If the rule is wrong, fix it; if it's right, follow it |
+| "The rule doesn't cover this case" | Missing coverage = rule gap | Add the case to the rule immediately |
+| "Let me finish the task first" | Rule violations compound | Fix rule first (5 min), then continue (prevents N future violations) |
+-->
+
+## Timing — Rule updates MUST happen before continuing original task, in the same session.
+
+<!-- DETAIL: Timing
+Rule updates MUST happen:
+- **Before** continuing the original task
+- **In the same session** as the violation
+- **Not** as a separate TODO or follow-up issue
+-->

package/templates/.claude/rules/MUST-enforcement-policy.md

@@ -0,0 +1,50 @@
+# [MUST] Enforcement Policy
+
+> **Priority**: MUST | **ID**: R021
+
+## Core Policy
+
+oh-my-customcodex uses an **advisory-first enforcement model**. Most rules are enforced through prompt engineering (AGENTS.md, rules/, PostCompact hook) rather than hard-blocking hooks. This is intentional — it preserves agent flexibility while maintaining behavioral standards.
+
+## Enforcement Tiers
+
+| Tier | Mechanism | Rules | Behavior |
+|------|-----------|-------|----------|
+| Hard Block | PreToolUse hook, exit 2 | stage-blocker, dev-server tmux, rule-deletion-guard | Prevents tool execution |
+| Soft Block | Stop hook prompt | R011 session-end saves | Auto-performs then approves |
+| Advisory | PostToolUse hooks | R007, R008, R009, R010, R018 | Warns via stderr, never blocks |
+| Prompt-based | AGENTS.md + rules/ + PostCompact | All MUST rules | Behavioral guidance in context |
+
+## Why Advisory-First
+
+1. **Agent flexibility**: Hard blocks can trap agents in unrecoverable states
+2. **Graceful degradation**: Missing dependencies (jq, etc.) don't break the session
+3. **Composability**: External skills and internal rules can coexist without deadlocks
+4. **PostCompact reinforcement**: R007/R008/R009/R010/R018 are re-injected after context compaction
+
+## Hard Enforcement Candidates — R010 git-delegation-guard (conditional), R007/R008 (conditional). Promoted: rule-deletion-guard.sh (2026-04-08). See details via Read tool.
+
+<!-- DETAIL: Hard Enforcement Candidates (Future)
+If advisory enforcement proves insufficient for specific rules, these are candidates for promotion to hard-block:
+
+| Rule | Candidate Hook | Condition for Promotion |
+|------|---------------|------------------------|
+| R010 | git-delegation-guard.sh | If orchestrator-direct-write violations exceed 3/session |
+| R007/R008 | (new hook) | If identification omission rate exceeds 20% |
+
+Promotion requires: (1) measured violation rate data, (2) user approval, (3) rollback plan.
+
+### Promoted to Hard Block
+
+| Hook | Date | Justification |
+|------|------|---------------|
+| `rule-deletion-guard.sh` | 2026-04-08 | User-requested: rule files must require individual confirmation before deletion. Prevents accidental bulk deletion of project rules. |
+-->
+
+## Integration
+
+| Rule | Interaction |
+|------|-------------|
+| R010 | git-delegation-guard.sh is advisory; could promote to blocking |
+| R016 | Violations trigger rule updates, not enforcement changes |
+| PostCompact | Re-injects critical rules to combat context compaction amnesia |

package/templates/.claude/rules/MUST-intent-transparency.md

@@ -0,0 +1,74 @@
+# [MUST] Intent Transparency Rules
+
+> **Priority**: MUST | **ID**: R015
+
+## Core Rule
+
+Display reasoning when routing to agents. Users must always know which agent was selected, why, and how to override.
+
+## Display Format
+
+```
+[Intent Detected]
+├── Input: "{user input}"
+├── Agent: {detected-agent}
+├── Confidence: {percentage}%
+└── Reason: {explanation}
+```
+
+## Confidence Thresholds
+
+| Confidence | Action |
+|------------|--------|
+| >= 90% | Auto-execute with display |
+| 70-89% | Request confirmation, show alternatives |
+| < 70% | List options for user to choose |
+
+## Detection Factors — Weights: Keywords 40%, File patterns 30%, Action verbs 20%, Context 10%. See table via Read tool.
+
+<!-- DETAIL: Detection Factors
+| Factor | Weight | Examples |
+|--------|--------|---------|
+| Keywords | 40% | "Go", "Python", "리뷰" |
+| File patterns | 30% | "*.go", "main.py" |
+| Action verbs | 20% | "review", "create", "fix" |
+| Context | 10% | Previous agent, working directory |
+-->
+
+## Override
+
+Users can specify agent directly with `@{agent-name} {command}`. Override bypasses detection.
+
+## User Directive Persistence — Named tool/skill/workflow preferences persist entire session. Anti-pattern: treating autonomous mode as clean slate. See full spec via Read tool.
+
+<!-- DETAIL: User Directive Persistence
+When a user explicitly names a tool, skill, or workflow (e.g., "use /pipeline auto-dev", "always run tests with bun test"), this preference persists for the entire session — including after autonomous mode transitions.
+
+### Persistence Triggers
+
+| User Statement Pattern | Persistence Scope |
+|------------------------|-------------------|
+| "use X for development" | Entire session |
+| "always / every time" | Entire session |
+| "from now on" | Entire session + memory save candidate |
+| "for this task" | Current task only |
+| Named slash command | Subsequent similar invocations |
+
+### Cycle Start Self-Check
+
+At the start of every work cycle (issue, task, release, or autonomous sub-loop):
+1. Review recent user messages in the conversation
+2. Identify any named tool/skill/workflow directives
+3. Apply those directives unless explicitly rescinded
+4. If unsure whether a directive applies, default to the stated preference
+
+**Anti-pattern**: Treating autonomous mode as a clean slate that discards earlier user preferences. Autonomous mode means "continue without per-step confirmation" — NOT "reset user directives".
+
+### Cross-reference
+
+- Related memory: session v0.87.2~v0.88.0 (issue #869) — `/pipeline auto-dev` preference was lost after autonomous mode transition
+-->
+
+## Agent Triggers
+
+Defined in `.codex/skills/intent-detection/patterns/agent-triggers.yaml`. Each agent has keywords, file patterns, actions, and base confidence.

package/templates/.claude/rules/MUST-language-policy.md

@@ -0,0 +1,28 @@
+# [MUST] Language & Delegation Policy
+
+> **Priority**: MUST | **ID**: R000
+
+## Output Language
+
+| Context | Language |
+|---------|----------|
+| User communication | Korean |
+| Code, file contents, commits | English |
+| Error messages to user | Korean |
+| PR title/body, GitHub issues | Korean (default, overridable in project AGENTS.md) |
+
+## Delegation Model
+
+User delegates ALL file operations to AI agent. User does NOT directly edit files.
+
+```
+User -> (Korean prompt) -> Agent -> (file operations in English)
+```
+
+## File Naming
+
+| Type | Convention | Example |
+|------|------------|---------|
+| Rules | `{PRIORITY}-{name}.md` | `MUST-safety.md` |
+| Agents | `{name}.md` (kebab-case) | `lang-golang-expert.md` |
+| Skills | `SKILL.md` | - |