oh-my-copilot 4.13.2 → 4.13.21

package/skills/team/SKILL.md

@@ -1,13 +1,14 @@
 ---
 name: team
-description: N coordinated agents on shared task list using Copilot CLI native teams
+description: N coordinated agents on shared task list using Claude Code native teams
 argument-hint: "[N:agent-type] [ralph] <task description>"
 aliases: []
+level: 4
 ---
 
 # Team Skill
 
-Spawn N coordinated agents working on a shared task list using Copilot CLI's native team tools. Replaces the legacy `/swarm` skill (SQLite-based) with built-in team management, inter-agent messaging, and task dependencies -- no external dependencies required.
+Spawn N coordinated agents working on a shared task list using Claude Code's native team tools. Replaces the legacy `/swarm` skill (SQLite-based) with built-in team management, inter-agent messaging, and task dependencies -- no external dependencies required.
 
 The `swarm` compatibility alias was removed in #1131.
 
@@ -38,7 +39,7 @@ The `swarm` compatibility alias was removed in #1131.
 /team 2:codex "review architecture and suggest improvements"
 # With Gemini CLI workers (requires: npm install -g @google/gemini-cli)
 /team 2:gemini "redesign the UI components"
-# Mixed: Codex for backend analysis, Gemini for frontend (use /cccg instead for this)
+# Mixed: Codex for backend analysis, Gemini for frontend (use /ccg instead for this)
 ```
 
 ## Architecture
@@ -76,9 +77,9 @@ User: "/team 3:executor fix all TypeScript errors"
                       -> rm .omcp/state/team-state.json
 ```
 
-**Storage layout (managed by Copilot CLI):**
+**Storage layout (managed by Claude Code):**
 ```
-~/.copilot/
+~/.claude/
   teams/fix-ts-errors/
     config.json          # Team metadata + members array
   tasks/fix-ts-errors/
@@ -110,7 +111,7 @@ Each pipeline stage uses **specialized agents** -- not just executors. The lead
 **Routing rules:**
 
 1. **The lead picks agents per stage, not the user.** The user's `N:agent-type` parameter only overrides the `team-exec` stage worker type. All other stages use stage-appropriate specialists.
-2. **Specialist agents complement executor agents.** Route analysis/review to architect/critic Copilot agents and UI work to designer agents. Tmux CLI workers are one-shot and don't participate in team communication.
+2. **Specialist agents complement executor agents.** Route analysis/review to architect/critic Claude agents and UI work to designer agents. Tmux CLI workers are one-shot and don't participate in team communication.
 3. **Cost mode affects model tier.** In downgrade: `opus` agents to `sonnet`, `sonnet` to `haiku` where quality permits. `team-verify` always uses at least `sonnet`.
 4. **Risk level escalates review.** Security-sensitive or >20 file changes must include `security-reviewer` + `code-reviewer` (opus) in `team-verify`.
 
@@ -221,7 +222,7 @@ Call `TeamCreate` with a slug derived from the task:
 ```json
 {
   "team_name": "fix-ts-errors",
-  "team_file_path": "~/.copilot/teams/fix-ts-errors/config.json",
+  "team_file_path": "~/.claude/teams/fix-ts-errors/config.json",
   "lead_agent_id": "team-lead@fix-ts-errors"
 }
 ```
@@ -477,7 +478,7 @@ Do NOT mark the task as completed. Leave it in_progress so the lead can reassign
 == RULES ==
 - NEVER spawn sub-agents or use the Task tool
 - NEVER run tmux pane/session orchestration commands (for example `tmux split-window`, `tmux new-session`)
-- NEVER run team spawning/orchestration skills or commands (for example `$team`, `$ultrawork`, `$autopilot`, `$ralph`, `omcp team ...`, `omx team ...`)
+- NEVER run team spawning/orchestration skills or commands (for example `$team`, `$ultrawork`, `$autopilot`, `$ralph`, `omc team ...`, `omx team ...`)
 - ALWAYS use absolute file paths
 - ALWAYS report progress via SendMessage to "team-lead"
 - Use SendMessage with type "message" only -- never "broadcast"
@@ -488,7 +489,7 @@ Do NOT mark the task as completed. Leave it in_progress so the lead can reassign
 When composing teammate prompts, append a short addendum based on worker type:
 
 - `claude_worker`: Emphasize strict TaskList/TaskUpdate/SendMessage loop and no orchestration commands.
-- `codex_worker`: Emphasize CLI API lifecycle (`omcp team api ... --json`) and explicit failure ACKs with stderr.
+- `codex_worker`: Emphasize CLI API lifecycle (`omc team api ... --json`) and explicit failure ACKs with stderr.
 - `gemini_worker`: Emphasize bounded file ownership and milestone ACKs after each completed sub-step.
 
 This addendum must preserve the core rule: **worker = executor only, never leader/orchestrator**.
@@ -575,7 +576,7 @@ After approval:
 
 Check for agent processes that survived TeamDelete:
 ```bash
-node "${PLUGIN_ROOT}/scripts/cleanup-orphans.mjs" --team-name fix-ts-errors
+node "${CLAUDE_PLUGIN_ROOT}/scripts/cleanup-orphans.mjs" --team-name fix-ts-errors
 ```
 
 This scans for processes matching the team name whose config no longer exists, and terminates them (SIGTERM → 5s wait → SIGKILL). Supports `--dry-run` for inspection.
@@ -588,7 +589,7 @@ This scans for processes matching the team name whose config no longer exists, a
 
 ## CLI Workers (Codex and Gemini)
 
-The team skill supports **hybrid execution** combining Copilot agent teammates with external CLI workers (Codex CLI and Gemini CLI). Both types can make code changes -- they differ in capabilities and cost. These are standalone CLI tools, not MCP servers.
+The team skill supports **hybrid execution** combining Claude agent teammates with external CLI workers (Codex CLI and Gemini CLI). Both types can make code changes -- they differ in capabilities and cost. These are standalone CLI tools, not MCP servers.
 
 ### Execution Modes
 
@@ -596,7 +597,7 @@ Tasks are tagged with an execution mode during decomposition:
 
 | Execution Mode | Provider | Capabilities |
 |---------------|----------|-------------|
-| `claude_worker` | Copilot agent | Full Copilot CLI tool access (Read/Write/Edit/Bash/Task). Best for tasks needing Copilot's reasoning + iterative tool use. |
+| `claude_worker` | Claude agent | Full Claude Code tool access (Read/Write/Edit/Bash/Task). Best for tasks needing Claude's reasoning + iterative tool use. |
 | `codex_worker` | Codex CLI (tmux pane) | Full filesystem access in working_directory. Runs autonomously via tmux pane. Best for code review, security analysis, refactoring, architecture. Requires `npm install -g @openai/codex`. |
 | `gemini_worker` | Gemini CLI (tmux pane) | Full filesystem access in working_directory. Runs autonomously via tmux pane. Best for UI/design work, documentation, large-context tasks. Requires `npm install -g @google/gemini-cli`. |
 
@@ -610,8 +611,8 @@ Tmux CLI workers run in dedicated tmux panes with filesystem access. They are **
 4. Results/summary are written to an output file
 5. Lead reads the output, marks the task complete, and feeds results to dependent tasks
 
-**Key difference from Copilot teammates:**
-- CLI workers operate via tmux, not Copilot CLI's tool system
+**Key difference from Claude teammates:**
+- CLI workers operate via tmux, not Claude Code's tool system
 - They cannot use TaskList/TaskUpdate/SendMessage (no team awareness)
 - They run as one-shot autonomous jobs, not persistent teammates
 - The lead manages their lifecycle (spawn, monitor, collect results)
@@ -620,14 +621,14 @@ Tmux CLI workers run in dedicated tmux panes with filesystem access. They are **
 
 | Task Type | Best Route | Why |
 |-----------|-----------|-----|
-| Iterative multi-step work | Copilot teammate | Needs tool-mediated iteration + team communication |
+| Iterative multi-step work | Claude teammate | Needs tool-mediated iteration + team communication |
 | Code review / security audit | CLI worker or specialist agent | Autonomous execution, good at structured analysis |
-| Architecture analysis / planning | architect Copilot agent | Strong analytical reasoning with codebase access |
+| Architecture analysis / planning | architect Claude agent | Strong analytical reasoning with codebase access |
 | Refactoring (well-scoped) | CLI worker or executor agent | Autonomous execution, good at structured transforms |
-| UI/frontend implementation | designer Copilot agent | Design expertise, framework idioms |
-| Large-scale documentation | writer Copilot agent | Writing expertise + large context for consistency |
-| Build/test iteration loops | Copilot teammate | Needs Bash tool + iterative fix cycles |
-| Tasks needing team coordination | Copilot teammate | Needs SendMessage for status updates |
+| UI/frontend implementation | designer Claude agent | Design expertise, framework idioms |
+| Large-scale documentation | writer Claude agent | Writing expertise + large context for consistency |
+| Build/test iteration loops | Claude teammate | Needs Bash tool + iterative fix cycles |
+| Tasks needing team coordination | Claude teammate | Needs SendMessage for status updates |
 
 ### Example: Hybrid Team with CLI Workers
 
@@ -642,13 +643,13 @@ Task decomposition:
 #5 [gemini_worker] Final code review of all changes
 ```
 
-The lead runs #1 (Codex security analysis), then #2 and #3 in parallel (Codex refactors backend, designer agent redesigns frontend), then #4 (Copilot teammate handles test iteration), then #5 (Gemini final review).
+The lead runs #1 (Codex security analysis), then #2 and #3 in parallel (Codex refactors backend, designer agent redesigns frontend), then #4 (Claude teammate handles test iteration), then #5 (Gemini final review).
 
 ### Pre-flight Analysis (Optional)
 
 For large ambiguous tasks, run analysis before team creation:
 
-1. Spawn `Task(subagent_type="oh-my-copilot:planner", name="planner-1", ...)` with task description + codebase context
+1. Spawn `Task(subagent_type="oh-my-copilot:planner", ...)` with task description + codebase context
 2. Use the analysis to produce better task decomposition
 3. Create team and tasks with enriched context
 
@@ -712,18 +713,7 @@ if (status.taskSummary.pending === 0 && status.taskSummary.inProgress === 0) {
 | `shutdown_ack` | Worker acknowledged shutdown -- safe to remove from team |
 | `heartbeat` | Update liveness tracking (redundant with heartbeat files but useful for latency monitoring) |
 
-This approach complements the existing `SendMessage`-based communication by providing a pull-based mechanism for MCP workers that cannot use Copilot CLI's team messaging tools.
-
-## Failure Recovery
-
-When a teammate agent fails, the structured recovery manager classifies the failure and determines the action:
-- **rate_limited**: Retry with exponential backoff
-- **auth_failure**: Escalate immediately (needs user credentials/permissions)
-- **build_error**: Retry with additional context about the error
-- **circular_fix**: Stop retrying and generate escalation report
-- **unknown**: Retry up to 3 times, then escalate
-
-The recovery manager integrates with the circular fix detector — if the same error recurs 3+ times across iterations, it escalates rather than continuing to retry.
+This approach complements the existing `SendMessage`-based communication by providing a pull-based mechanism for MCP workers that cannot use Claude Code's team messaging tools.
 
 ## Error Handling
 
@@ -822,13 +812,13 @@ This prevents duplicate teams and allows graceful recovery from lead failures.
 
 | Aspect | Team (Native) | Swarm (Legacy SQLite) |
 |--------|--------------|----------------------|
-| **Storage** | JSON files in `~/.copilot/teams/` and `~/.copilot/tasks/` | SQLite in `.omcp/state/swarm.db` |
+| **Storage** | JSON files in `~/.claude/teams/` and `~/.claude/tasks/` | SQLite in `.omcp/state/swarm.db` |
 | **Dependencies** | `better-sqlite3` not needed | Requires `better-sqlite3` npm package |
 | **Task claiming** | `TaskUpdate(owner + in_progress)` -- lead pre-assigns | SQLite IMMEDIATE transaction -- atomic |
 | **Race conditions** | Possible if two agents claim same task (mitigate by pre-assigning) | None (SQLite transactions) |
 | **Communication** | `SendMessage` (DM, broadcast, shutdown) | None (fire-and-forget agents) |
 | **Task dependencies** | Built-in `blocks` / `blockedBy` arrays | Not supported |
-| **Heartbeat** | Automatic idle notifications from Copilot CLI | Manual heartbeat table + polling |
+| **Heartbeat** | Automatic idle notifications from Claude Code | Manual heartbeat table + polling |
 | **Shutdown** | Graceful request/response protocol | Signal-based termination |
 | **Agent lifecycle** | Auto-tracked via internal tasks + config members | Manual tracking via heartbeat table |
 | **Progress visibility** | `TaskList` shows live status with owner | SQL queries on tasks table |
@@ -836,7 +826,7 @@ This prevents duplicate teams and allows graceful recovery from lead failures.
 | **Crash recovery** | Lead detects via missing messages, reassigns | Auto-release after 5-min lease timeout |
 | **State cleanup** | `TeamDelete` removes everything | Manual `rm` of SQLite database |
 
-**When to use Team over Swarm:** Always prefer `/team` for new work. It uses Copilot CLI's built-in infrastructure, requires no external dependencies, supports inter-agent communication, and has task dependency management.
+**When to use Team over Swarm:** Always prefer `/team` for new work. It uses Claude Code's built-in infrastructure, requires no external dependencies, supports inter-agent communication, and has task dependency management.
 
 ## Cancellation
 
@@ -857,7 +847,7 @@ When team is linked to ralph, cancellation follows dependency order:
 - **Cancel triggered from Team context:** Clear Team state, then mark Ralph as cancelled. Ralph's stop hook will detect the missing team and stop iterating.
 - **Force cancel (`--force`):** Clears both `team` and `ralph` state unconditionally via `state_clear`.
 
-If teammates are unresponsive, `TeamDelete` may fail. In that case, the cancel skill should wait briefly and retry, or inform the user to manually clean up `~/.copilot/teams/{team_name}/` and `~/.copilot/tasks/{team_name}/`.
+If teammates are unresponsive, `TeamDelete` may fail. In that case, the cancel skill should wait briefly and retry, or inform the user to manually clean up `~/.claude/teams/{team_name}/` and `~/.claude/tasks/{team_name}/`.
 
 ## Runtime V2 (Event-Driven)
 
@@ -882,7 +872,7 @@ When `OMC_TEAM_SCALING_ENABLED=1` is set, the team supports mid-session scaling:
 
 ## Configuration
 
-Optional settings live in `.copilot/omg.jsonc` (project) or `~/.config/copilot-omg/config.jsonc` (user). Project values override user values; `OMCP_TEAM_ROLE_OVERRIDES` (env JSON) supersedes both.
+Optional settings live in `.copilot/omg.jsonc` (project) or `~/.config/copilot-omg/config.jsonc` (user). Project values override user values; `OMC_TEAM_ROLE_OVERRIDES` (env JSON) supersedes both.
 
 ```jsonc
 {
@@ -902,7 +892,7 @@ Optional settings live in `.copilot/omg.jsonc` (project) or `~/.config/copilot-o
 - **ops.monitorIntervalMs** - How often to poll `TaskList` (default: 30s)
 - **ops.shutdownTimeoutMs** - How long to wait for shutdown responses (default: 15s)
 
-> **Note:** Team members do not have a hardcoded model default. Each teammate is a separate Copilot CLI session that inherits the user's configured model. Since teammates can spawn their own subagents, the session model acts as the orchestration layer while subagents can use any model tier.
+> **Note:** Team members do not have a hardcoded model default. Each teammate is a separate Claude Code session that inherits the user's configured model. Since teammates can spawn their own subagents, the session model acts as the orchestration layer while subagents can use any model tier.
 
 ## Per-Role Provider & Model Routing
 
@@ -945,13 +935,41 @@ Declare which provider (`claude`, `codex`, `gemini`) and which model tier should
 
 User-friendly aliases normalize via `normalizeDelegationRole()` — e.g. `reviewer` → `code-reviewer`, `quality-reviewer` → `code-reviewer`, `harsh-critic` → `critic`, `build-fixer` → `debugger`. Accepted alias keys are honored during resolved snapshot creation and later stage routing, not just validation. Unknown roles fail validation at parse time.
 
+### Spec fields (`TeamRoleAssignmentSpec`)
+
+- **provider** — `"claude" | "codex" | "gemini"`. Omitted → defaults to `claude`.
+- **model** — tier name (`"HIGH" | "MEDIUM" | "LOW"`) or an explicit model ID. Tiers resolve through `routing.tierModels`.
+- **agent** — optional Claude agent name (e.g. `"critic"`, `"executor"`). Only honored when the resolved provider is `claude`.
+
+`orchestrator` is pinned to `claude`; only `model` is user-configurable. Any other key on `orchestrator` is rejected by the validator.
+
+### Env override
+
+```bash
+OMC_TEAM_ROLE_OVERRIDES='{"critic":{"provider":"codex"},"code-reviewer":{"provider":"gemini"}}'
+```
+
+Precedence: `OMC_TEAM_ROLE_OVERRIDES` > `.copilot/omg.jsonc` (project) > `~/.config/copilot-omg/config.jsonc` (user) > built-in defaults. Invalid JSON logs a warning and is ignored — env overrides are best-effort and never abort the run.
+
+### Fallback when a CLI is missing
+
+If the CLI for a configured provider is absent from `PATH` at spawn time, `buildLaunchArgs()` throws, the team lead emits a visible `SendMessage` warning, and the runtime falls back to a deterministic Claude assignment pre-computed by `buildResolvedRoutingSnapshot` (same tier + same agent, `provider: "claude"`). Fallback is loud by design — silent fallback is a test failure. Probe provider availability with `omc doctor --team-routing`.
+
+### Stickiness — resolved once, reused everywhere
+
+Resolved routing is immutable per team. Editing config mid-team-lifetime does not affect running teams; a new `/team` invocation picks up the new mapping. This guarantees that spawn, scale-up, and worker-restart all see identical routing, including across worktree detaches (the snapshot travels with `TeamConfig`).
+
+### Zero-config behavior
+
+An empty `team.roleRouting` preserves pre-patch behavior: every worker is Claude, model tiers follow `routing.tierModels`, and `/team 3:executor ...` still spawns three Claude Sonnet executors.
+
 ## State Cleanup
 
 On successful completion:
 
-1. `TeamDelete` handles all Copilot CLI state:
-   - Removes `~/.copilot/teams/{team_name}/` (config)
-   - Removes `~/.copilot/tasks/{team_name}/` (all task files + lock)
+1. `TeamDelete` handles all Claude Code state:
+   - Removes `~/.claude/teams/{team_name}/` (config)
+   - Removes `~/.claude/tasks/{team_name}/` (all task files + lock)
 2. OMC state cleanup via MCP tools:
    ```
    state_clear(mode="team")
@@ -1019,4 +1037,4 @@ MCP workers can operate in isolated git worktrees to prevent file conflicts betw
 
 10. **Broadcast is expensive** -- Each broadcast sends a separate message to every teammate. Use `message` (DM) by default. Only broadcast for truly team-wide critical alerts.
 
-11. **CLI workers are one-shot, not persistent** -- Tmux CLI workers have full filesystem access and CAN make code changes. However, they run as autonomous one-shot jobs -- they cannot use TaskList/TaskUpdate/SendMessage. The lead must manage their lifecycle: write prompt_file, spawn CLI worker, read output_file, mark task complete. They don't participate in team communication like Copilot teammates do.
+11. **CLI workers are one-shot, not persistent** -- Tmux CLI workers have full filesystem access and CAN make code changes. However, they run as autonomous one-shot jobs -- they cannot use TaskList/TaskUpdate/SendMessage. The lead must manage their lifecycle: write prompt_file, spawn CLI worker, read output_file, mark task complete. They don't participate in team communication like Claude teammates do.

package/skills/ultraqa/SKILL.md

@@ -2,6 +2,7 @@
 name: ultraqa
 description: QA cycling workflow - test, verify, fix, repeat until goal met
 argument-hint: "[--tests|--build|--lint|--typecheck|--custom <pattern>] [--interactive]"
+level: 3
 ---
 
 # UltraQA Skill
@@ -75,7 +76,6 @@ If no structured goal provided, interpret the argument as a custom goal.
 | **Goal Met** | Exit with success: "ULTRAQA COMPLETE: Goal met after N cycles" |
 | **Cycle 5 Reached** | Exit with diagnosis: "ULTRAQA STOPPED: Max cycles. Diagnosis: ..." |
 | **Same Failure 3x** | Exit early: "ULTRAQA STOPPED: Same failure detected 3 times. Root cause: ..." |
-| **Circular Fix Detected** | Exit with escalation report: Generate structured report at `.omcp/escalation-report.md` with error pattern hash, occurrence count, error timeline, and recommended manual interventions. Set ultraqa state to stopped. |
 | **Environment Error** | Exit: "ULTRAQA ERROR: [tmux/port/dependency issue]" |
 
 ## Observability
@@ -118,7 +118,6 @@ User can cancel with `/oh-my-copilot:cancel` which clears the state file.
 3. **EARLY EXIT on pattern** - 3x same failure = stop and surface
 4. **CLEAR OUTPUT** - User should always know current cycle and status
 5. **CLEAN UP** - Clear state file on completion or cancellation
-6. **CIRCULAR FIX DETECTION** - The system tracks error hashes across cycles. If the same normalized error appears 3+ times within a 2-hour window, stop immediately and generate an escalation report at `.omcp/escalation-report.md` instead of continuing to retry. This prevents wasting cycles on fundamentally broken fixes.
 
 ## STATE CLEANUP ON COMPLETION
 

package/skills/ultrawork/SKILL.md

@@ -2,10 +2,11 @@
 name: ultrawork
 description: Parallel execution engine for high-throughput task completion
 argument-hint: "<task description with parallel work items>"
+level: 4
 ---
 
 <Purpose>
-Ultrawork is a parallel execution engine that runs multiple agents simultaneously for independent tasks. It is a component, not a standalone persistence mode -- it provides parallelism and smart model routing but not persistence, verification loops, or state management.
+Ultrawork is a parallel execution engine and execution protocol for independent work. It emphasizes intent grounding, parallel context gathering, dependency-aware task graphs for non-trivial work, and concise evidence-backed execution summaries. It is a component, not a standalone persistence mode -- it provides parallelism and routing guidance, but not persistence, verification loops, or long-lived state management.
 </Purpose>
 
 <Use_When>
@@ -28,26 +29,38 @@ Sequential task execution wastes time when tasks are independent. Ultrawork enab
 
 <Execution_Policy>
 - Fire all independent agent calls simultaneously -- never serialize independent work
-- **Stagger parallel launches**: When firing N parallel tasks, stagger launches by 1 second between each (e.g., fire task 1, wait 1s, fire task 2, wait 1s, fire task 3). This prevents thundering herd rate limits. The system will inject stagger advisories if launches are too rapid.
 - Always pass the `model` parameter explicitly when delegating
 - Read `docs/shared/agent-tiers.md` before first delegation for agent selection guidance
 - Use `run_in_background: true` for operations over ~30 seconds (installs, builds, tests)
 - Run quick commands (git status, file reads, simple checks) in the foreground
+- Resolve intent and uncertainty before implementation; explore first, ask only when still blocked
+- For non-trivial tasks, produce a dependency-aware plan with parallel waves before execution
+- Keep delegated-task reports concise: short summary, files touched, verification status, blockers
+- Manual QA is required for implemented behavior, not just diagnostics
 </Execution_Policy>
 
 <Steps>
 1. **Read agent reference**: Load `docs/shared/agent-tiers.md` for tier selection
-2. **Classify tasks by independence**: Identify which tasks can run in parallel vs which have dependencies
-3. **Route to correct tiers**:
+2. **Ground intent first**: Confirm whether the request is implementation, investigation, evaluation, or research; do not code before that is clear
+3. **Gather context in parallel**:
+   - direct tools for quick reads/searches
+   - exploration/docs agents for broad context
+4. **Classify tasks by independence**: Identify which tasks can run in parallel vs which have dependencies
+5. **Create a task graph for non-trivial work**:
+   - Parallel Execution Waves
+   - Dependency Matrix
+   - acceptance criteria and verification steps per task
+6. **Route to correct tiers**:
    - Simple lookups/definitions: LOW tier (Haiku)
    - Standard implementation: MEDIUM tier (Sonnet)
    - Complex analysis/refactoring: HIGH tier (Opus)
-4. **Fire independent tasks simultaneously**: Launch all parallel-safe tasks at once
-5. **Run dependent tasks sequentially**: Wait for prerequisites before launching dependent work
-6. **Background long operations**: Builds, installs, and test suites use `run_in_background: true`
-7. **Verify when all tasks complete** (lightweight):
+7. **Fire independent tasks simultaneously**: Launch all parallel-safe tasks at once
+8. **Run dependent tasks sequentially**: Wait for prerequisites before launching dependent work
+9. **Background long operations**: Builds, installs, and test suites use `run_in_background: true`
+10. **Verify when all tasks complete** (lightweight):
    - Build/typecheck passes
    - Affected tests pass
+   - Manual QA completed for implemented behavior
    - No new errors introduced
 </Steps>
 
@@ -63,9 +76,9 @@ Sequential task execution wastes time when tasks are independent. Ultrawork enab
 <Good>
 Three independent tasks fired simultaneously:
 ```
-Task(subagent_type="oh-my-copilot:executor", model="haiku", name="executor-1", prompt="Add missing type export for Config interface")
-Task(subagent_type="oh-my-copilot:executor", model="sonnet", name="executor-2", prompt="Implement the /api/users endpoint with validation")
-Task(subagent_type="oh-my-copilot:executor", model="sonnet", name="executor-3", prompt="Add integration tests for the auth middleware")
+Task(subagent_type="oh-my-copilot:executor", model="haiku", prompt="Add missing type export for Config interface")
+Task(subagent_type="oh-my-copilot:executor", model="sonnet", prompt="Implement the /api/users endpoint with validation")
+Task(subagent_type="oh-my-copilot:executor", model="sonnet", prompt="Add integration tests for the auth middleware")
 ```
 Why good: Independent tasks at appropriate tiers, all fired at once.
 </Good>
@@ -73,8 +86,8 @@ Why good: Independent tasks at appropriate tiers, all fired at once.
 <Good>
 Correct use of background execution:
 ```
-Task(subagent_type="oh-my-copilot:executor", model="sonnet", name="executor-1", prompt="npm install && npm run build", run_in_background=true)
-Task(subagent_type="oh-my-copilot:executor", model="haiku", name="executor-2", prompt="Update the README with new API endpoints")
+Task(subagent_type="oh-my-copilot:executor", model="sonnet", prompt="npm install && npm run build", run_in_background=true)
+Task(subagent_type="oh-my-copilot:executor", model="haiku", prompt="Update the README with new API endpoints")
 ```
 Why good: Long build runs in background while short task runs in foreground.
 </Good>
@@ -92,7 +105,7 @@ Why bad: These tasks are independent. Running them sequentially wastes time.
 <Bad>
 Wrong tier selection:
 ```
-Task(subagent_type="oh-my-copilot:executor", model="opus", name="executor-1", prompt="Add a missing semicolon")
+Task(subagent_type="oh-my-copilot:executor", model="opus", prompt="Add a missing semicolon")
 ```
 Why bad: Opus is expensive overkill for a trivial fix. Use executor with Haiku instead.
 </Bad>
@@ -101,7 +114,7 @@ Why bad: Opus is expensive overkill for a trivial fix. Use executor with Haiku i
 <Escalation_And_Stop_Conditions>
 - When ultrawork is invoked directly (not via ralph), apply lightweight verification only -- build passes, tests pass, no new errors
 - For full persistence and comprehensive architect verification, recommend switching to `ralph` mode
-- If a task fails, use the structured recovery manager: classify the failure (rate_limited, auth_failure, build_error, etc.) and follow the mapped recovery action (retry with backoff, escalate, retry with context). After 3 retries for the same task, escalate rather than continuing. If the circular fix detector triggers, stop immediately and generate an escalation report.
+- If a task fails repeatedly across retries, report the issue rather than retrying indefinitely
 - Escalate to the user when tasks have unclear dependencies or conflicting requirements
 </Escalation_And_Stop_Conditions>
 
@@ -126,10 +139,4 @@ autopilot (autonomous execution)
 ```
 
 Ultrawork is the parallelism layer. Ralph adds persistence and verification. Autopilot adds the full lifecycle pipeline.
-
-## Stagger Delay
-
-When launching multiple parallel agents, a 1-second stagger delay is applied between launches to prevent rate limiting. This is advisory — the system injects guidance when rapid-fire Task calls are detected.
-
-Configuration: The stagger delay can be customized via the `stagger_delay_ms` field in ultrawork state (default: 1000ms).
 </Advanced>

package/skills/verify/SKILL.md

@@ -8,7 +8,7 @@ description: Verify that a change really works before you claim completion
 Use this skill when the user wants confidence that a feature, fix, or refactor actually works.
 
 ## Goal
-Turn vague "it should work" claims into concrete evidence.
+Turn vague “it should work” claims into concrete evidence.
 
 ## Workflow
 1. Identify the exact behavior that must be proven.
@@ -34,3 +34,4 @@ Turn vague "it should work" claims into concrete evidence.
 - Which commands/tests were run
 - What passed
 - What failed or remains unverified
+

package/skills/writer-memory/SKILL.md

@@ -2,6 +2,7 @@
 name: writer-memory
 description: Agentic memory system for writers - track characters, relationships, scenes, and themes
 argument-hint: "init|char|rel|scene|query|validate|synopsis|status|export [args]"
+level: 7
 ---
 
 # Writer Memory - Agentic Memory System for Writers
@@ -10,7 +11,7 @@ Persistent memory system designed for creative writers, with first-class support
 
 ## Overview
 
-Writer Memory maintains context across Copilot sessions for fiction writers. It tracks:
+Writer Memory maintains context across Claude sessions for fiction writers. It tracks:
 
 - **Characters (캐릭터)**: Emotional arcs (감정궤도), attitudes (태도), dialogue tone (대사톤), speech levels
 - **World (세계관)**: Settings, rules, atmosphere, constraints

package/templates/hooks/pre-tool-use.mjs

@@ -16,6 +16,150 @@ const __dirname = dirname(__filename);
 // Dynamic import for the shared stdin module
 const { readStdin } = await import(pathToFileURL(path.join(__dirname, 'lib', 'stdin.mjs')).href);
 
+// ---------------------------------------------------------------------------
+// Skill Active State (issue #1033)
+// Writes skill-active-state.json so the persistent-mode Stop hook can prevent
+// premature session termination while a skill is executing.
+// ---------------------------------------------------------------------------
+
+/**
+ * Skill protection levels: none/light/medium/heavy.
+ * - 'none': Already has dedicated mode state (ralph, autopilot) or instant/read-only
+ * - 'light': Quick agent shortcuts (3 reinforcements, 5 min TTL)
+ * - 'medium': Review/planning skills that run multiple agents (5 reinforcements, 15 min TTL)
+ * - 'heavy': Long-running skills (10 reinforcements, 30 min TTL)
+ */
+const PROTECTION_CONFIGS = {
+  none:   { maxReinforcements: 0,  staleTtlMs: 0 },
+  light:  { maxReinforcements: 3,  staleTtlMs: 5 * 60 * 1000 },
+  medium: { maxReinforcements: 5,  staleTtlMs: 15 * 60 * 1000 },
+  heavy:  { maxReinforcements: 10, staleTtlMs: 30 * 60 * 1000 },
+};
+
+const SKILL_PROTECTION = {
+  // Already have mode state → no protection needed
+  autopilot: 'none', ralph: 'none', ultrawork: 'none', team: 'none',
+  'omc-teams': 'none', ultraqa: 'none', cancel: 'none',
+  // Instant / read-only → no protection needed
+  trace: 'none', hud: 'none', 'omc-doctor': 'none', 'omc-help': 'none',
+  'learn-about-omc': 'none', note: 'none',
+  // Light protection (3 reinforcements)
+  tdd: 'light', 'build-fix': 'light', analyze: 'light', skill: 'light',
+  'configure-notifications': 'light',
+  // Medium protection (5 reinforcements)
+  'code-review': 'medium', 'security-review': 'medium', plan: 'medium',
+  ralplan: 'medium', review: 'medium', 'external-context': 'medium',
+  sciomc: 'medium', skillify: 'medium', learner: 'medium', 'omc-setup': 'medium',
+  'mcp-setup': 'medium', 'project-session-manager': 'medium',
+  'writer-memory': 'medium', 'ralph-init': 'medium', ccg: 'medium',
+  // Heavy protection (10 reinforcements)
+  deepinit: 'heavy',
+};
+
+function getSkillProtection(skillName) {
+  const normalized = (skillName || '').toLowerCase().replace(/^oh-my-(?:claudecode|copilot):/, '');
+  return SKILL_PROTECTION[normalized] || 'light';
+}
+
+function getInvokedSkillName(toolInput) {
+  if (!toolInput || typeof toolInput !== 'object') return null;
+  const rawSkill = toolInput.skill || toolInput.skill_name || toolInput.skillName || toolInput.command || null;
+  if (typeof rawSkill !== 'string' || !rawSkill.trim()) return null;
+  const normalized = rawSkill.trim();
+  return normalized.includes(':') ? normalized.split(':').at(-1).toLowerCase() : normalized.toLowerCase();
+}
+
+const SESSION_ID_ALLOWLIST = /^[a-zA-Z0-9][a-zA-Z0-9_-]{0,255}$/;
+
+function writeSkillActiveState(directory, skillName, sessionId) {
+  const protection = getSkillProtection(skillName);
+  if (protection === 'none') return;
+
+  const config = PROTECTION_CONFIGS[protection];
+  const now = new Date().toISOString();
+  const normalized = (skillName || '').toLowerCase().replace(/^oh-my-(?:claudecode|copilot):/, '');
+
+  const state = {
+    active: true,
+    skill_name: normalized,
+    session_id: sessionId || undefined,
+    started_at: now,
+    last_checked_at: now,
+    reinforcement_count: 0,
+    max_reinforcements: config.maxReinforcements,
+    stale_ttl_ms: config.staleTtlMs,
+  };
+
+  const stateDir = path.join(directory, '.omc', 'state');
+
+  // Write to session-scoped path when sessionId is available (must match persistent-mode.mjs reads)
+  const safeSessionId = sessionId && SESSION_ID_ALLOWLIST.test(sessionId) ? sessionId : '';
+  const targetDir = safeSessionId
+    ? path.join(stateDir, 'sessions', safeSessionId)
+    : stateDir;
+  const targetPath = path.join(targetDir, 'skill-active-state.json');
+
+  try {
+    if (!existsSync(targetDir)) {
+      mkdirSync(targetDir, { recursive: true });
+    }
+    const tmpPath = targetPath + '.tmp';
+    writeFileSync(tmpPath, JSON.stringify(state, null, 2), { mode: 0o600 });
+    renameSync(tmpPath, targetPath);
+  } catch {
+    // Best-effort; don't fail the hook
+  }
+}
+
+
+function clearAwaitingConfirmationFlag(directory, stateName, sessionId) {
+  const stateDir = path.join(directory, '.omc', 'state');
+  const safeSessionId = sessionId && SESSION_ID_ALLOWLIST.test(sessionId) ? sessionId : '';
+  const paths = [
+    safeSessionId ? path.join(stateDir, 'sessions', safeSessionId, `${stateName}-state.json`) : null,
+    path.join(stateDir, `${stateName}-state.json`),
+    path.join(homedir(), '.omc', 'state', `${stateName}-state.json`),
+  ].filter(Boolean);
+
+  for (const statePath of paths) {
+    try {
+      if (!existsSync(statePath)) continue;
+      const state = JSON.parse(readFileSync(statePath, 'utf-8'));
+      if (!state || typeof state !== 'object' || !state.awaiting_confirmation) continue;
+      delete state.awaiting_confirmation;
+      const tmpPath = statePath + '.tmp';
+      writeFileSync(tmpPath, JSON.stringify(state, null, 2), { mode: 0o600 });
+      renameSync(tmpPath, statePath);
+    } catch {
+      // Best-effort; don't fail the hook
+    }
+  }
+}
+
+function confirmSkillModeStates(directory, skillName, sessionId) {
+  switch (skillName) {
+    case 'ralph':
+      clearAwaitingConfirmationFlag(directory, 'ralph', sessionId);
+      clearAwaitingConfirmationFlag(directory, 'ultrawork', sessionId);
+      break;
+    case 'ultrawork':
+      clearAwaitingConfirmationFlag(directory, 'ultrawork', sessionId);
+      break;
+    case 'autopilot':
+      clearAwaitingConfirmationFlag(directory, 'autopilot', sessionId);
+      break;
+    case 'ralplan':
+      clearAwaitingConfirmationFlag(directory, 'ralplan', sessionId);
+      break;
+    default:
+      break;
+  }
+}
+
+// ---------------------------------------------------------------------------
+// Delegation enforcement
+// ---------------------------------------------------------------------------
+
 // Allowed path patterns (no warning)
 // Paths are normalized to forward slashes before matching
 const ALLOWED_PATH_PATTERNS = [
@@ -87,51 +231,6 @@ function workerCommandViolation(command) {
   return null;
 }
 
-const SESSION_ID_ALLOWLIST = /^[a-zA-Z0-9][a-zA-Z0-9_-]{0,255}$/;
-
-function clearAwaitingConfirmationFlag(directory, stateName, sessionId) {
-  const stateDir = path.join(directory, '.omcp', 'state');
-  const safeSessionId = sessionId && SESSION_ID_ALLOWLIST.test(sessionId) ? sessionId : '';
-  const paths = [
-    safeSessionId ? path.join(stateDir, 'sessions', safeSessionId, `${stateName}-state.json`) : null,
-    path.join(stateDir, `${stateName}-state.json`),
-    path.join(homedir(), '.omcp', 'state', `${stateName}-state.json`),
-  ].filter(Boolean);
-
-  for (const statePath of paths) {
-    try {
-      if (!existsSync(statePath)) continue;
-      const state = JSON.parse(readFileSync(statePath, 'utf-8'));
-      if (!state || typeof state !== 'object' || !state.awaiting_confirmation) continue;
-      delete state.awaiting_confirmation;
-      const tmpPath = statePath + '.tmp';
-      writeFileSync(tmpPath, JSON.stringify(state, null, 2), { mode: 0o600 });
-      renameSync(tmpPath, statePath);
-    } catch {
-      // Best-effort; don't fail the hook
-    }
-  }
-}
-
-function confirmSkillModeStates(directory, skillName, sessionId) {
-  switch (skillName) {
-    case 'ralph':
-      clearAwaitingConfirmationFlag(directory, 'ralph', sessionId);
-      clearAwaitingConfirmationFlag(directory, 'ultrawork', sessionId);
-      break;
-    case 'ultrawork':
-      clearAwaitingConfirmationFlag(directory, 'ultrawork', sessionId);
-      break;
-    case 'autopilot':
-      clearAwaitingConfirmationFlag(directory, 'autopilot', sessionId);
-      break;
-    case 'ralplan':
-      clearAwaitingConfirmationFlag(directory, 'ralplan', sessionId);
-      break;
-    default:
-      break;
-  }
-}
 
 function checkBashCommand(command) {
   // Check if command might modify files