oh-my-customcodex 0.4.11 → 0.4.13

package/templates/.claude/skills/deep-plan/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: deep-plan
-description: Research-validated planning — research → plan → verify cycle for high-confidence implementation plans
+description: Research-validated planning - research -> plan -> verify cycle for high-confidence implementation plans
 scope: core
 context: fork
-version: 1.0.0
+version: 1.1.0
 user-invocable: true
 argument-hint: "<topic-or-issue>"
 teams-compatible: true
@@ -11,353 +11,69 @@ teams-compatible: true
 
 # Deep Plan Skill
 
-Research-validated planning that eliminates the gap between research assumptions and actual code. Orchestrates a 3-phase cycle: Discovery Research → Reality-Check Planning → Plan Verification.
+Research-validated planning that eliminates the gap between research assumptions and actual code. It runs Discovery Research, Reality-Check Planning, and Plan Verification before handing off implementation.
 
-**Teams-compatible** — works both from the main conversation (R010) and inside Agent Teams members. When used in Teams, the member directly executes the 3-phase workflow without Skill tool invocation.
+**Full phase detail**: `guides/deep-plan/phases.md`
 
 ## Usage
 
-```
+```bash
 /deep-plan <topic-or-issue>
 /deep-plan "implement caching layer for API responses"
 /deep-plan #325 new authentication system
-/deep-plan Rust async runtime migration
-```
-
-## Problem Solved
-
-Research-only analysis (like `/research`) produces findings based on assumptions about the codebase. These assumptions often diverge from reality:
-
-| Assumption | Reality | Impact |
-|------------|---------|--------|
-| "Feature X is missing" | Already implemented | Wasted effort on duplicate work |
-| "Pattern Y is needed" | Partially exists | Over-engineering existing code |
-| "Library Z is required" | Already a dependency | Unnecessary integration effort |
-
-`/deep-plan` solves this by cross-referencing research findings against actual code before committing to a plan.
-
-## Architecture — 3 Phases
-
-### Phase 1: Discovery Research
-
-Invoke the `/research` skill internally for comprehensive topic analysis.
-
-```
-Phase 1: Discovery Research
-├── Skill(research, args="<topic>")
-├── 10-team parallel analysis (3 batches × 4/4/2)
-├── Cross-verification loop (opus + codex)
-├── ADOPT / ADAPT / AVOID taxonomy
-└── Output: research report (artifact)
-```
-
-**Execution**:
-- **Orchestrator mode**: Delegates to `/research` skill via `Skill(research, args="<topic>")`.
-- **Teams mode**: Executes the research workflow inline (see Teams Mode section). The member spawns research teams directly as sub-agents.
-
-The executor waits for completion before proceeding to Phase 2.
-
-**Output**: Full research report with ADOPT/ADAPT/AVOID taxonomy.
-
-### Phase 2: Reality-Check Planning
-
-Ground-truth the research findings against the actual codebase.
-
-```
-Phase 2: Reality-Check Planning
-├── EnterPlanMode
-├── Explore agents (up to 3 parallel)
-│   ├── Explore 1: Verify ADOPT items exist/don't exist
-│   ├── Explore 2: Check ADAPT items for current state
-│   └── Explore 3: Validate AVOID alternatives
-├── Gap analysis table
-├── Refined plan (real gaps only)
-└── ExitPlanMode → user approval
-```
-
-**Steps**:
-
-1. **Enter Plan Mode**: `EnterPlanMode` to activate planning context
-2. **Codebase Exploration**: Spawn up to 3 Explore agents in parallel to verify research assumptions:
-   - Each ADOPT item: Does it already exist? Partially implemented?
-   - Each ADAPT item: What is the current state to adapt from?
-   - Each AVOID item: Are the alternatives already available?
-3. **Deliverable Dependency Verification**: After exploration, verify inter-deliverable dependencies:
-   - For each deliverable pair, check: do they share files, functions, or modules?
-   - Classify each pair: `independent` (parallel-safe), `sequential` (order required), `shared-state` (synchronization needed)
-   - **Default bias**: Assume `independent` unless exploration finds concrete shared state
-   - Build dependency matrix:
-
-   ```
-   | Deliverable A | Deliverable B | Classification | Evidence |
-   |---------------|---------------|----------------|----------|
-   | D1: Auth      | D2: API       | independent    | No shared files |
-   | D1: Auth      | D3: Tests     | sequential     | D3 tests D1 output |
-   ```
-
-   - **Orchestrator override**: The dependency classification is advisory. The orchestrator or user can reclassify pairs when the automated analysis is overly conservative.
-
-4. **Gap Analysis**: Build a reconciliation table:
-
-   ```
-   | Research Finding | Actual Code State | Gap Type | Action | Dependencies |
-   |-----------------|-------------------|----------|--------|-------------|
-   | "No caching"    | Redis client exists | Overestimate | Remove from plan | — |
-   | "Need auth middleware" | No auth layer | Real gap | Keep in plan | D3 (sequential) |
-   | "Migrate to v3" | Already on v3.1 | Overestimate | Remove from plan | — |
-   | "Add rate limiting" | Basic limiter exists | Partial gap | Adapt existing | independent |
-   ```
-
-5. **Refined Plan**: Write implementation plan containing ONLY real gaps:
-   - Remove overestimates (already implemented)
-   - Adjust partial gaps (adapt, don't rebuild)
-   - Prioritize real gaps by impact
-6. **User Approval**: `ExitPlanMode` presents the refined plan for user review
-   - Include dependency matrix in plan output
-   - Display override option: "Dependency classifications are advisory. Reply with reclassifications if needed."
-
-### Phase 3: Plan Verification Research
-
-Validate the refined plan with focused research before implementation begins.
-
 ```
-Phase 3: Plan Verification Research
-├── 3-team focused verification
-│   ├── T1: Technical feasibility
-│   ├── T2: Conflict/duplication check
-│   └── T3: Test strategy & risk
-├── Verdict: PASS or REVISE
-├── PASS → implementation advisory
-└── REVISE → return to Phase 2
-```
-
-**Teams** (3 parallel, NOT full 10-team):
-
-| Team | Focus | Verifies |
-|------|-------|----------|
-| T1 | Technical feasibility | Can the plan be implemented with current stack/deps? |
-| T2 | Conflict & duplication | Does the plan conflict with in-flight work or duplicate existing code? |
-| T3 | Test strategy & risk | Is the plan testable? What are the failure modes? |
-
-**Invocation**: Phase 3 teams are spawned directly as parallel agents (NOT via `Skill(research)`). The orchestrator creates 3 focused agents, each with a specific verification mandate derived from the Phase 2 plan.
-
-**Model selection**: sonnet for teams, opus for synthesis.
-
-**Verdict**:
-- **PASS**: Plan is verified. Display implementation advisory.
-- **REVISE**: Issues found. Return to Phase 2 with feedback for plan refinement.
-- **REVISE limit**: After 2 REVISE cycles, escalate to user for manual judgment.
-
-## Workflow Diagram
-
-```
-User: /deep-plan "topic"
-  │
-  ├─ Phase 1: Discovery Research
-  │   ├─ Skill(research, args="topic")
-  │   ├─ 10-team analysis → ADOPT/ADAPT/AVOID
-  │   └─ Output: research artifact
-  │
-  ├─ Phase 2: Reality-Check Planning
-  │   ├─ EnterPlanMode
-  │   ├─ Explore agents (up to 3 parallel)
-  │   ├─ Gap analysis: research vs actual code
-  │   ├─ Refined plan (real gaps only)
-  │   └─ ExitPlanMode → user approval
-  │
-  └─ Phase 3: Plan Verification
-      ├─ 3-team focused research
-      ├─ Verdict: PASS or REVISE
-      ├─ PASS → implementation advisory
-      └─ REVISE → loop back to Phase 2 (max 2 cycles)
-```
-
-## Differentiation
 
-| Skill | Scope | Code Verification | Phases |
-|-------|-------|-------------------|--------|
-| `/research` | Analysis only | None — assumption-based | 1 |
-| Plan mode | Planning only | Yes — code exploration | 1 |
-| `/structured-dev-cycle` | Full implementation | Yes — stage-by-stage | 6 |
-| **`/deep-plan`** | **Analysis + Planning + Verification** | **3-pass cross-verification** | **3** |
+## Workflow Contract
 
-`/deep-plan` fills the gap between research (which lacks code grounding) and implementation (which lacks upfront analysis). It produces a **verified plan** ready for execution.
-
-## Display Format
-
-Before execution:
-```
-[Deep Plan] {topic}
-├── Phase 1: Discovery Research (10 teams, 3 batches)
-├── Phase 2: Reality-Check Planning (up to 3 Explore agents)
-└── Phase 3: Plan Verification (3 focused teams)
-
-Estimated phases: 3 | Models: sonnet → opus
-Execute? [Y/n]
-```
-
-Phase transitions:
-```
-[Deep Plan] Phase 1/3 — Discovery Research
-├── Research skill active...
-└── Awaiting 10-team results
-
-[Deep Plan] Phase 2/3 — Reality-Check Planning
-├── Gap analysis: 6 ADOPT items → 2 real gaps, 4 overestimates
-└── Refined plan: 5 action items (down from 12)
-
-[Deep Plan] Phase 3/3 — Plan Verification
-├── T1 (feasibility): ✓ PASS
-├── T2 (conflicts): ✓ PASS
-├── T3 (test/risk): ✓ PASS
-└── Verdict: PASS — ready for implementation
-```
-
-## Post-Completion Advisory
-
-After PASS verdict:
-```
-[Advisory] Verified plan ready for implementation.
-├── For complex implementations (10+ files): /structured-dev-cycle
-├── For parallel task execution: superpowers:subagent-driven-development
-└── For simple tasks (< 3 files): proceed directly
-```
+| Phase | Name | Key Activity |
+|-------|------|--------------|
+| 1 | Discovery Research | Comprehensive research with ADOPT / ADAPT / AVOID taxonomy |
+| 2 | Reality-Check Planning | Explore current code and keep only real gaps |
+| 3 | Plan Verification | Feasibility, duplication, and test-risk verification |
 
 ## Execution Rules
 
 | Rule | Detail |
 |------|--------|
-| Phase 1 | Full `/research` skill invocation (10 teams) |
-| Phase 2 | Max 3 parallel Explore agents (R009) |
-| Phase 3 | Max 3 parallel verification teams (R009) |
-| Orchestrator only | Main conversation manages all phases (R010) |
-| Intent display | Show phase plan before execution (R015) |
-| Ecomode | Auto-activate for team result aggregation (R013) |
+| Phase 1 | Invoke or inline the research workflow, depending on runtime context |
+| Phase 2 | Use up to 3 parallel Explore agents for current-code verification |
+| Phase 3 | Use up to 3 focused verification agents |
+| Orchestrator owns synthesis | The main conversation manages phase transitions and verdicts |
 | REVISE limit | Max 2 cycles before user escalation |
 
-## Agent Teams (R018)
-
-When Agent Teams is enabled, Phase 1 and Phase 3 parallel teams SHOULD use Agent Teams instead of individual Agent tool calls:
-
-| Phase | Without Agent Teams | With Agent Teams |
-|-------|--------------------|--------------------|
-| Phase 1 | Delegates to `/research` (handles internally) | Delegates to `/research` (handles internally) |
-| Phase 2 | Up to 3 Explore agents via Agent tool | Up to 3 Explore agents via Agent tool (below threshold) |
-| Phase 3 | 3 agents via Agent tool | 3 agents — at threshold, prefer Agent Teams for coordination |
-
-Phase 1 delegation to `/research` means Agent Teams decisions are handled by the research skill itself. Phase 3's 3-team verification is at the Agent Teams threshold (3+ agents) and benefits from peer messaging for cross-verification.
-
-## Model Selection
-
-| Phase | Component | Model | Rationale |
-|-------|-----------|-------|-----------|
-| Phase 1 | Research teams | sonnet | Delegated to /research skill |
-| Phase 1 | Verification | opus | Delegated to /research skill |
-| Phase 2 | Explore agents | haiku | Fast codebase search |
-| Phase 2 | Gap analysis | opus | Complex reconciliation reasoning |
-| Phase 3 | Verification teams | sonnet | Balanced analysis |
-| Phase 3 | Synthesis/verdict | opus | Final judgment |
-
-## Cost Estimate
-
-| Phase | Approximate Cost | Driver |
-|-------|-----------------|--------|
-| Phase 1 | High | Full 10-team `/research` invocation |
-| Phase 2 | Low-Medium | Up to 3 Explore agents (haiku) + 1 opus synthesis |
-| Phase 3 | Medium | 3 sonnet verification teams + 1 opus synthesis |
-| **Total** | **High** | Dominated by Phase 1 research cost |
-
-`/deep-plan` is designed for high-stakes decisions where plan quality justifies the cost. For quick planning, use `EnterPlanMode` directly.
-
-## Integration
-
-| Component | Integration |
-|-----------|-------------|
-| `/research` | Phase 1 full invocation (via Skill tool or inline in Teams mode) + Phase 3 reduced invocation pattern |
-| EnterPlanMode/ExitPlanMode | Phase 2 plan creation and user approval |
-| Explore agents | Phase 2 codebase verification (up to 3 parallel) |
-| R009 | Phase 1 (10 teams batched), Phase 2 (3 Explore), Phase 3 (3 teams) |
-| R010 | Orchestrator manages all 3 phases; teams are subagents |
-| R013 | Ecomode for team result aggregation |
-| R015 | Phase transition intent display |
-| result-aggregation | Phase 1 and 3 result formatting |
-| superpowers:subagent-driven-development | Post-PASS implementation advisory (external plugin) |
-
-## Fallback Behavior
-
-| Scenario | Fallback |
-|----------|----------|
-| Phase 1 `/research` fails | Manual analysis, then proceed to Phase 2 |
-| Phase 2 EnterPlanMode unavailable | Perform analysis without plan mode context |
-| Phase 3 REVISE ≥ 2 times | Escalate to user for manual judgment |
-| Explore agent failure | Reduce parallel count, retry with remaining |
-| Partial team failure | Synthesize from available results, note gaps |
-
-## Teams Mode
-
-When running inside an Agent Teams member (not via Skill tool), the deep-plan workflow operates identically but with these adaptations:
-
-### How It Works
-
-The orchestrator reads this SKILL.md and includes the deep-plan instructions directly in the Teams member's prompt. The member then:
+## Differentiation
 
-1. Phase 1: Executes research workflow inline (not via `Skill(research)`) — spawns 10 research teams as sub-agents
-2. Phase 2: Uses EnterPlanMode/ExitPlanMode and Explore agents normally
-3. Phase 3: Spawns 3 verification teams as sub-agents
-4. Delivers final verified plan via `SendMessage` to team lead
+| Skill | Scope | Code Verification |
+|-------|-------|-------------------|
+| `/research` | Analysis only | None by default |
+| Plan mode | Planning only | Yes |
+| `/structured-dev-cycle` | Implementation pipeline | Yes, stage by stage |
+| `/deep-plan` | Analysis + planning + verification | Yes, 3-pass cross-verification |
 
-### Prompt Embedding Pattern
+## Sensitive-path compatibility note
 
-```
-# When spawning a Teams member for deep-plan:
-Agent(
-  name: "planner-1",
-  team_name: "my-team",
-  prompt: """
-  You are a deep-plan agent. Follow the deep-plan skill workflow below:
-  {contents of deep-plan/SKILL.md}
+Codex-native verification artifacts go under `.codex/outputs/sessions/YYYY-MM-DD/deep-plan-HHmmss.md` and may be written with the repo's normal file-write APIs.
 
-  Also follow this research workflow for Phase 1:
-  {contents of research/SKILL.md}
+If any research, planning, or verification delegate must touch `.claude/**`, `.claude/outputs/**`, or `templates/.claude/**`, include this block in that delegate prompt:
 
-  Topic: {user's planning topic}
-  Deliver verified plan via SendMessage to team lead when complete.
-  """
-)
+```text
+Sensitive-path compatibility note:
+1. Keep Codex-native .codex/** artifacts on the normal file-write path.
+2. On Claude Code v2.1.121+ with bypassPermissions, direct writes to .claude/skills/, .claude/agents/, and .claude/commands/ are allowed.
+3. On Claude Code v2.1.126+ with bypassPermissions, broader protected paths such as .claude/**, .git/**, and .vscode/** are also covered.
+4. Use /tmp/deep-plan-<timestamp>.md only as a legacy fallback when the runtime is older or still prompts, then verify the resulting diff.
 ```
 
-### Differences from Orchestrator Mode
-
-| Aspect | Orchestrator Mode | Teams Mode |
-|--------|------------------|------------|
-| Invocation | `Skill(deep-plan)` | Prompt embedding |
-| Phase 1 research | `Skill(research)` | Inline execution |
-| Result delivery | Return to main conversation | `SendMessage` to team lead |
-| Plan approval | User via ExitPlanMode | Team lead via SendMessage |
-| Context isolation | Previously used `context: fork` | Standard context (no fork) |
+The protocol must be copied into delegate prompts. A parent-only mention is insufficient because forked contexts can lose the directive.
 
-### Why No context: fork
+## Agent Teams
 
-`context: fork` was removed to enable Teams compatibility. Fork blocks sub-agent spawning, which is essential for Phase 1 (10 research teams) and Phase 3 (3 verification teams). Without fork, deep-plan operates in the standard context, which is required for both orchestrator and Teams usage.
+When Agent Teams are available and the plan has multiple independent verification lanes, the Phase 3 agents may run as a coordinated team. Otherwise, use bounded parallel subagents and aggregate results in the main conversation.
 
-## Artifact Persistence
-
-Phase 1 research artifact is persisted by the `/research` skill.
+## Post-Completion Advisory
 
-Phase 3 verification report is persisted by the final synthesis agent:
-```
-.codex/outputs/sessions/{YYYY-MM-DD}/deep-plan-{HHmmss}.md
-```
+After PASS, return an implementation-ready plan with file scopes, dependencies, test commands, release gates, rollback notes, and any unresolved risks.
 
-Sensitive-path artifact protocol (mandatory): if any research, planning, or verification delegate must touch `.claude/**`, `.claude/outputs/**`, or `templates/.claude/**`, include the protocol directly in that delegate prompt. The delegate must write artifact bodies to `/tmp/deep-plan-{timestamp}.md` first and must avoid direct Read, Bash, Write, or Edit targets under `.claude/**` in unattended flows.
+## Permission Mode
 
-With metadata header:
-```markdown
----
-skill: deep-plan
-date: {ISO-8601 with timezone}
-query: "{original user query}"
-phases_completed: 3
-verdict: PASS|REVISE
----
-```
+When spawning agents, explicitly pass `mode: "bypassPermissions"` if the runtime supports it. Defaults may override agent frontmatter and reintroduce permission prompts during unattended execution.

package/templates/.claude/skills/deep-verify/SKILL.md

@@ -73,7 +73,7 @@ Each agent receives the full diff and returns findings as structured JSON:
 - Verify all changes align with project's compilation metaphor (Skills=source, Agents=artifacts, Rules=spec)
 - Check separation of concerns: no agents containing skill logic, no skills with agent definitions
 - Verify orchestrator rules: no new file writes from orchestrator context
-- Verify sensitive-path delegation: prompts that touch `.claude/**`, `.claude/outputs/**`, or `templates/.claude/**` include the exact phrase `Sensitive-path artifact protocol (mandatory)`, require an explicit `/tmp/{skill}-{timestamp}.md` artifact body path, mention `Read, Bash, Write, or Edit` coverage, and do not rely on a single vague `/tmp` recommendation
+- Verify sensitive-path compatibility: prompts that touch `.claude/**`, `.claude/outputs/**`, or `templates/.claude/**` include the `Sensitive-path compatibility note`, keep `.codex/**` artifacts on the normal file-write path, and treat `/tmp/{skill}-{timestamp}.md` only as a legacy fallback for older Claude Code versions or sessions that still prompt
 - Check advisory-first: no new hard-blocking hooks introduced
 - Confirm no feature regressions: existing APIs preserved, test coverage maintained
 - Performance sanity: no O(n^2) on large datasets, no missing indexes for new queries

package/templates/.claude/skills/dev-lead-routing/SKILL.md

@@ -10,7 +10,7 @@ context: fork
 
 ## Sensitive-Path Delegation
 
-Sensitive-path artifact protocol (mandatory): if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, include this protocol directly in the delegated prompt. The delegate must produce artifact bodies in `/tmp/{skill}-{timestamp}.md` first and must avoid direct Read, Bash, Write, or Edit targets under `.claude/**` in unattended flows.
+Sensitive-path compatibility note: if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, keep `.codex/**` edits on the normal Codex path. On Claude Code v2.1.121+ with `bypassPermissions`, direct writes to `.claude/skills/`, `.claude/agents/`, and `.claude/commands/` are allowed; on v2.1.126+ that extends to broader protected paths. Only use `/tmp/{skill}-{timestamp}.md` as a legacy fallback when the target runtime is older or still prompts.
 
 ## Engineers
 

package/templates/.claude/skills/dev-review/SKILL.md

@@ -113,6 +113,11 @@ If only PASS/INFO: proceed automatically.
 6. **Artifact persistence** (optional): Review agent saves findings to:
    ```
    .codex/outputs/sessions/{YYYY-MM-DD}/dev-review-{HHmmss}.md
+
+### Compatibility artifact protocol
+
+Sensitive-path compatibility note: when delegated work touches `.claude/outputs/`, `.claude/**`, or `templates/.claude/**`, keep `.codex/**` artifacts on the normal file-write path. On Claude Code v2.1.121+ with `bypassPermissions`, direct compatibility writes are allowed for `.claude/skills/`, `.claude/agents/`, and `.claude/commands/`; on v2.1.126+ broader protected paths are covered. Use `/tmp/<skill>-<timestamp>.md` only as a legacy fallback when the runtime is older or still prompts.
+
    ```
    With metadata header:
    ```markdown

package/templates/.claude/skills/hada-scout/SKILL.md

@@ -15,7 +15,7 @@ high-scoring candidates.
 
 ## Sensitive-Path Delegation
 
-Sensitive-path artifact protocol (mandatory): if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, include this protocol directly in the delegated prompt. The delegate must produce artifact bodies in `/tmp/{skill}-{timestamp}.md` first and must avoid direct Read, Bash, Write, or Edit targets under `.claude/**` in unattended flows.
+Sensitive-path compatibility note: if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, keep `.codex/**` edits on the normal Codex path. On Claude Code v2.1.121+ with `bypassPermissions`, direct writes to `.claude/skills/`, `.claude/agents/`, and `.claude/commands/` are allowed; on v2.1.126+ that extends to broader protected paths. Only use `/tmp/{skill}-{timestamp}.md` as a legacy fallback when the target runtime is older or still prompts.
 
 ## Purpose
 

package/templates/.claude/skills/harness-eval/SKILL.md

@@ -16,7 +16,7 @@ Evaluate agent quality using 15 structured software engineering task definitions
 
 ## Sensitive-Path Delegation
 
-Sensitive-path artifact protocol (mandatory): if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, include this protocol directly in the delegated prompt. The delegate must produce artifact bodies in `/tmp/{skill}-{timestamp}.md` first and must avoid direct Read, Bash, Write, or Edit targets under `.claude/**` in unattended flows.
+Sensitive-path compatibility note: if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, keep `.codex/**` edits on the normal Codex path. On Claude Code v2.1.121+ with `bypassPermissions`, direct writes to `.claude/skills/`, `.claude/agents/`, and `.claude/commands/` are allowed; on v2.1.126+ that extends to broader protected paths. Only use `/tmp/{skill}-{timestamp}.md` as a legacy fallback when the target runtime is older or still prompts.
 
 ## Usage
 

package/templates/.claude/skills/harness-synthesizer/SKILL.md

@@ -93,6 +93,11 @@ harness:
 
 1. **Read target agent frontmatter** — extract `tools`, `domain`, `limitations` fields
 2. **Analyze recent tool call patterns** — check `.codex/outputs/` for prior session logs (if available)
+
+### Compatibility artifact protocol
+
+Sensitive-path compatibility note: when delegated work touches `.claude/outputs/`, `.claude/**`, or `templates/.claude/**`, keep `.codex/**` artifacts on the normal file-write path. On Claude Code v2.1.121+ with `bypassPermissions`, direct compatibility writes are allowed for `.claude/skills/`, `.claude/agents/`, and `.claude/commands/`; on v2.1.126+ broader protected paths are covered. Use `/tmp/<skill>-<timestamp>.md` only as a legacy fallback when the runtime is older or still prompts.
+
 3. **Synthesize validation harness** — generate YAML harness matching agent's declared capabilities
 4. **Refine via evaluator-optimizer loop** — iterate harness against edge cases (3 rounds max)
 5. **Save output** — write to `.codex/outputs/harnesses/{agent-name}-{mode}.yaml`

package/templates/.claude/skills/omcodex-improve-report/SKILL.md

@@ -15,7 +15,7 @@ Surface actionable improvement suggestions gathered by the eval-core analysis en
 
 ## Sensitive-Path Delegation
 
-Sensitive-path artifact protocol (mandatory): if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, include this protocol directly in the delegated prompt. The delegate must produce artifact bodies in `/tmp/{skill}-{timestamp}.md` first and must avoid direct Read, Bash, Write, or Edit targets under `.claude/**` in unattended flows.
+Sensitive-path compatibility note: if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, keep `.codex/**` edits on the normal Codex path. On Claude Code v2.1.121+ with `bypassPermissions`, direct writes to `.claude/skills/`, `.claude/agents/`, and `.claude/commands/` are allowed; on v2.1.126+ that extends to broader protected paths. Only use `/tmp/{skill}-{timestamp}.md` as a legacy fallback when the target runtime is older or still prompts.
 
 ## Usage
 

package/templates/.claude/skills/omcodex-takeover/SKILL.md

@@ -16,7 +16,7 @@ When an agent or skill has evolved organically without a formal spec, `omcodex:t
 
 ## Sensitive-Path Delegation
 
-Sensitive-path artifact protocol (mandatory): if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, include this protocol directly in the delegated prompt. The delegate must produce artifact bodies in `/tmp/{skill}-{timestamp}.md` first and must avoid direct Read, Bash, Write, or Edit targets under `.claude/**` in unattended flows.
+Sensitive-path compatibility note: if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, keep `.codex/**` edits on the normal Codex path. On Claude Code v2.1.121+ with `bypassPermissions`, direct writes to `.claude/skills/`, `.claude/agents/`, and `.claude/commands/` are allowed; on v2.1.126+ that extends to broader protected paths. Only use `/tmp/{skill}-{timestamp}.md` as a legacy fallback when the target runtime is older or still prompts.
 
 ## Usage
 

package/templates/.claude/skills/optimize-analyze/SKILL.md

@@ -24,7 +24,7 @@ target           Build output path or project root (optional, auto-detects)
 
 ## Sensitive-Path Delegation
 
-Sensitive-path artifact protocol (mandatory): if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, include this protocol directly in the delegated prompt. The delegate must produce artifact bodies in `/tmp/{skill}-{timestamp}.md` first and must avoid direct Read, Bash, Write, or Edit targets under `.claude/**` in unattended flows.
+Sensitive-path compatibility note: if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, keep `.codex/**` edits on the normal Codex path. On Claude Code v2.1.121+ with `bypassPermissions`, direct writes to `.claude/skills/`, `.claude/agents/`, and `.claude/commands/` are allowed; on v2.1.126+ that extends to broader protected paths. Only use `/tmp/{skill}-{timestamp}.md` as a legacy fallback when the target runtime is older or still prompts.
 
 ## Workflow
 

package/templates/.claude/skills/optimize-report/SKILL.md

@@ -20,7 +20,7 @@ Generate comprehensive optimization report with analysis, metrics, and recommend
 
 ## Sensitive-Path Delegation
 
-Sensitive-path artifact protocol (mandatory): if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, include this protocol directly in the delegated prompt. The delegate must produce artifact bodies in `/tmp/{skill}-{timestamp}.md` first and must avoid direct Read, Bash, Write, or Edit targets under `.claude/**` in unattended flows.
+Sensitive-path compatibility note: if this skill delegates work that touches `.claude/**`, `.claude/outputs/**`, `templates/.claude/**`, or read-only measurements of those paths, keep `.codex/**` edits on the normal Codex path. On Claude Code v2.1.121+ with `bypassPermissions`, direct writes to `.claude/skills/`, `.claude/agents/`, and `.claude/commands/` are allowed; on v2.1.126+ that extends to broader protected paths. Only use `/tmp/{skill}-{timestamp}.md` as a legacy fallback when the target runtime is older or still prompts.
 
 ## Workflow
 

package/templates/.claude/skills/post-release-followup/SKILL.md

@@ -24,6 +24,11 @@ Gather unfinished work from multiple sources:
 
 **Source B — Deep-verify findings**:
 - Read the latest deep-verify output from `.codex/outputs/sessions/{today}/`
+
+### Compatibility artifact protocol
+
+Sensitive-path compatibility note: when delegated work touches `.claude/outputs/`, `.claude/**`, or `templates/.claude/**`, keep `.codex/**` artifacts on the normal file-write path. On Claude Code v2.1.121+ with `bypassPermissions`, direct compatibility writes are allowed for `.claude/skills/`, `.claude/agents/`, and `.claude/commands/`; on v2.1.126+ broader protected paths are covered. Use `/tmp/<skill>-<timestamp>.md` only as a legacy fallback when the runtime is older or still prompts.
+
 - Extract any MEDIUM or LOW severity findings that were flagged but not fixed
 
 **Source C — Triage deferred items**:
@@ -46,9 +51,9 @@ Remove duplicates (same issue referenced from multiple sources). Categorize:
 
 | Category | Criteria | Default Action |
 |----------|----------|----------------|
-| **Immediate** | P1/P2 remaining issues, MEDIUM+ verify findings, Critical/High PR review findings | Execute now |
-| **Trackable** | P3 issues, LOW verify findings, new TODOs, Medium PR review findings | Register as issue |
-| **Informational** | Already-tracked issues, cosmetic notes | Skip |
+| **즉시 실행** | P1/P2 잔여 이슈, MEDIUM+ 검증 발견사항, Critical/High PR 리뷰 발견사항 | 즉시 실행 |
+| **이슈 등록** | P3 이슈, LOW 검증 발견사항, 새 TODO, Medium PR 리뷰 발견사항 | 이슈로 등록 |
+| **참고** | 이미 추적 중인 이슈, 외관 관련 메모 | 건너뛰기 |
 
 ### 3. Present to User
 
@@ -117,8 +122,8 @@ When creating follow-up issues:
 
 ```bash
 gh issue create \
-  --title "{concise description}" \
-  --body "## Source\n\nDiscovered during v{version} release workflow.\n\n## Context\n\n{detailed context from triage/verify}\n\n## Suggested Action\n\n{recommendation}" \
+  --title "{간결한 설명}" \
+  --body "## 출처\n\nv{version} 릴리즈 워크플로우에서 발견.\n\n## 컨텍스트\n\n{triage/verify에서의 상세 컨텍스트}\n\n## 권장 조치\n\n{권장 사항}" \
   --label "professor"
 ```