oh-my-copilot 4.13.1 → 4.13.21

package/skills/AGENTS.md

@@ -3,7 +3,7 @@
 
 # skills
 
-50 skill directories for workflow automation and specialized behaviors.
+30 skill directories for workflow automation and specialized behaviors.
 
 ## Purpose
 
@@ -31,18 +31,7 @@ Skills are reusable workflow templates that can be invoked via `/oh-my-copilot:s
 | `plan/SKILL.md` | omc-plan | Strategic planning with interview workflow |
 | `ralplan/SKILL.md` | ralplan | Iterative planning (Planner+Architect+Critic) with RALPLAN-DR structured deliberation (`--deliberate` for high-risk) |
 | `deep-interview/SKILL.md` | deep-interview | Socratic deep interview with mathematical ambiguity gating (Ouroboros-inspired) |
-| `deep-dive/SKILL.md` | deep-dive | 2-stage pipeline: trace (causal investigation) → deep-interview (requirements crystallization) |
-
-### Analysis Skills
-
-| File | Skill | Purpose |
-|-----------|-------|---------|
-| `critique/SKILL.md` | critique | Pre-push adversarial critique of unpushed commits via independent devils-advocate agent |
-| `deep-review/SKILL.md` | deep-review | Multi-pass code review with security, quality, structural analysis, and validation |
-| `discover/SKILL.md` | discover | Spawn parallel specialist agents to scan the codebase and produce a prioritized improvement backlog |
-| `trace/SKILL.md` | trace | Evidence-driven causal tracing with competing hypotheses |
-| `verify/SKILL.md` | verify | Verify changes work before claiming completion |
-| `debug/SKILL.md` | debug | Diagnose session or repo state using logs, traces, state, and focused reproduction |
+| `ralph-init/SKILL.md` | ralph-init | Initialize PRD for structured ralph |
 
 ### Exploration Skills
 
@@ -50,8 +39,6 @@ Skills are reusable workflow templates that can be invoked via `/oh-my-copilot:s
 |-----------|-------|---------|
 | `deepinit/SKILL.md` | deepinit | Generate hierarchical AGENTS.md |
 | `sciomc/SKILL.md` | sciomc | Parallel scientist orchestration |
-| `external-context/SKILL.md` | external-context | Parallel document-specialist agents for external web searches and documentation lookup |
-| `self-improve/SKILL.md` | self-improve | Autonomous evolutionary code improvement engine with tournament selection |
 
 ### Visual Skills
 
@@ -59,57 +46,23 @@ Skills are reusable workflow templates that can be invoked via `/oh-my-copilot:s
 |-----------|-------|---------|
 | `visual-verdict/SKILL.md` | visual-verdict | Structured visual QA verdict for screenshot/reference comparisons |
 
-### Orchestration Skills
-
-| File | Skill | Purpose |
-|-----------|-------|---------|
-| `cccg/SKILL.md` | cccg | Quadri-model orchestration — Claude, Codex, Gemini provide independent analysis, Copilot synthesizes |
-| `omc-teams/SKILL.md` | omc-teams | CLI-team runtime for claude, codex, or gemini workers in tmux panes |
-| `omc-reference/SKILL.md` | omc-reference | OMC agent catalog, tools, team pipeline routing, commit protocol, and skills registry |
-
-### Notification Skills
-
-| File | Skill | Purpose |
-|-----------|-------|---------|
-| `configure-notifications/SKILL.md` | configure-notifications | Configure notification integrations (Telegram, Discord, Slack, Teams) |
-
-### Azure DevOps Skills
-
-| File | Skill | Purpose |
-|-----------|-------|---------|
-| `omc-ado-setup/SKILL.md` | omc-ado-setup | Configure Azure DevOps integration |
-| `omc-ado-review/SKILL.md` | omc-ado-review | Review Azure DevOps pull requests |
-| `omc-ado-auto-review/SKILL.md` | omc-ado-auto-review | Automated Azure DevOps PR review |
-| `omc-ado-sprint/SKILL.md` | omc-ado-sprint | Azure DevOps sprint management |
-| `omc-ado-triage/SKILL.md` | omc-ado-triage | Azure DevOps work item triage |
-
-### GitHub Skills
-
-| File | Skill | Purpose |
-|-----------|-------|---------|
-| `omc-gh-setup/SKILL.md` | omc-gh-setup | Configure GitHub integration |
-| `omc-gh-triage/SKILL.md` | omc-gh-triage | Issue/PR/CI triage dashboard |
-| `omc-gh-review/SKILL.md` | omc-gh-review | Interactive PR review |
-| `omc-gh-auto-review/SKILL.md` | omc-gh-auto-review | Automated PR code review |
-| `omc-gh-project/SKILL.md` | omc-gh-project | GitHub Projects board management |
-
 ### Utility Skills
 
 | File | Skill | Purpose |
 |-----------|-------|---------|
 | `ai-slop-cleaner/SKILL.md` | ai-slop-cleaner | Regression-safe cleanup workflow for AI-generated code slop |
-| `learner/SKILL.md` | learner | Extract reusable skill from session |
-| `ask/SKILL.md` | ask | Ask Copilot, Codex, or Gemini via `omcp ask` and capture an artifact |
+| `skillify/SKILL.md` | skillify | Extract reusable skill from session |
+| `learner/SKILL.md` | learner | Deprecated compatibility alias/internal implementation history for skillify |
+| `ask/SKILL.md` | ask | Ask Claude, Codex, or Gemini via `omc ask` and capture an artifact |
+| `note/SKILL.md` | note | Save notes for compaction resilience |
 | `cancel/SKILL.md` | cancel | Cancel any active OMC mode |
-| `hud/SKILL.md` | hud | Configure HUD display options (layout, presets, display elements) |
+| `hud/SKILL.md` | hud | Configure HUD display |
 | `omc-doctor/SKILL.md` | omc-doctor | Diagnose installation issues |
-| `remember/SKILL.md` | remember | Review reusable project knowledge and decide what belongs in project memory, notepad, or docs |
 | `setup/SKILL.md` | setup | Unified setup entrypoint for install, diagnostics, and MCP configuration |
 | `omc-setup/SKILL.md` | omc-setup | One-time setup wizard |
+| `omc-help/SKILL.md` | omc-help | Usage guide |
 | `mcp-setup/SKILL.md` | mcp-setup | Configure MCP servers |
 | `skill/SKILL.md` | skill | Manage local skills |
-| `skillify/SKILL.md` | skillify | Turn a repeatable workflow into a reusable OMC skill draft |
-| `wiki/SKILL.md` | wiki | Persistent markdown knowledge base that compounds across sessions |
 
 ### Domain Skills
 
@@ -117,22 +70,7 @@ Skills are reusable workflow templates that can be invoked via `/oh-my-copilot:s
 |-----------|-------|---------|
 | `project-session-manager/SKILL.md` | project-session-manager (+ `psm` alias) | Isolated dev environments |
 | `writer-memory/SKILL.md` | writer-memory | Agentic memory for writers |
-| `release/SKILL.md` | release | Automated release workflow |
-| `ralph-experiment/SKILL.md` | ralph-experiment | Hypothesis-driven experiment loop with structured notebook and git checkpoints |
-
-## Permission Model
-
-All plugin MCP tools use a **three-tier auto-approval system** so agents can operate without `/yolo`:
-
-- **Tier 1** (read-only): LSP nav, code search, state/memory reads — always auto-approved via `readOnlyHint` annotation
-- **Tier 2** (write): State/memory writes, AST replace, LSP rename — auto-approved via `permissions.allow` in `settings.local.json`
-- **Tier 3** (destructive): `shared_memory_delete`, `shared_memory_cleanup`, `kill_job` — always prompt user
-
-Safe bash patterns (git, npm, dotnet, gh, az, grep, find, ls) are auto-approved by the `permissionRequest` hook. Shell metacharacters are always rejected.
-
-Deny escalation: 3 consecutive or 20 total denials stops the session. All decisions are audit-logged to `.omcp/logs/permissions.log`.
-
-See [permission architecture](../docs/architecture/permissions.md) for details.
+| `release/SKILL.md` | release | Generic release assistant — analyzes repo CI/rules, caches in `.omcp/RELEASE_RULE.md`, guides the release |
 
 ## For AI Agents
 
@@ -149,6 +87,10 @@ triggers:
   - "keyword2"
 agent: executor  # Optional: which agent to use
 model: sonnet    # Optional: model override
+pipeline: [skill-name, follow-up-skill]  # Optional: standardized multi-skill flow
+next-skill: follow-up-skill              # Optional: explicit handoff target
+next-skill-args: --direct                # Optional: arguments for the next skill
+handoff: .omcp/plans/example.md           # Optional: artifact/context handed to next skill
 ---
 
 # Skill Name
@@ -187,7 +129,7 @@ Any configurable options.
 2. Define purpose, workflow, and usage
 3. Add to skill registry (auto-detected from frontmatter)
 4. Optionally add activation triggers
-5. Create corresponding `commands/new-skill.md` file (mirror)
+5. Create corresponding plugin-scoped skill/slash surface via `skills/new-skill/SKILL.md` (and generated artifacts when the build requires them)
 6. Update `docs/REFERENCE.md` (Skills section, count)
 7. If execution mode skill, also create `src/hooks/new-skill/` hook
 
@@ -202,6 +144,8 @@ Any configurable options.
 4. Invoke `qa-tester` for verification
 ```
 
+If `pipeline` / `next-skill` metadata is present, OMC appends a standardized **Skill Pipeline** handoff block to the rendered skill prompt so downstream steps are explicit.
+
 **Conditional behavior:**
 ```markdown
 ## Workflow
@@ -232,18 +176,12 @@ None - pure markdown files.
 
 | Category | Skills | Trigger Keywords |
 |----------|--------|------------------|
-| Execution | autopilot, ultrawork, ralph, team, ultraqa, ralph-experiment, self-improve | "autopilot", "ulw", "ralph", "self-improve" |
-| Planning | omc-plan, ralplan, deep-interview, deep-dive | "ralplan", "deep-interview", "ouroboros" |
-| Analysis | critique, deep-review, discover, debug, trace, verify | "critique", "code review", "security review", "trace", "verify", "debug" |
-| Exploration | deepinit, sciomc, external-context | "deepinit", "sciomc", "external-context" |
-| Orchestration | cccg, omc-teams, omc-reference | "cccg", "ask codex", "ask gemini", "ask claude" |
-| Visual | visual-verdict | screenshot QA |
-| Cleanup | ai-slop-cleaner | "deslop", "anti-slop" |
-| Azure DevOps | omc-ado-setup, omc-ado-review, omc-ado-auto-review, omc-ado-sprint, omc-ado-triage | "ado setup", "ado triage" |
-| GitHub | omc-gh-setup, omc-gh-triage, omc-gh-review, omc-gh-auto-review, omc-gh-project | "gh setup", "gh triage", "gh review" |
-| Notifications | configure-notifications | "configure discord", "setup telegram" |
-| Utility | learner, ask, cancel, setup, omc-doctor, omc-setup, mcp-setup, skill, skillify, wiki, hud, remember | "cancelomc", "stopomc", "wiki", "skillify" |
-| Domain | project-session-manager, writer-memory, release | psm context |
+| Execution | autopilot, ultrawork, ralph, team, ultraqa | "autopilot", "ulw", "ralph", "team" |
+| Cleanup | ai-slop-cleaner | "deslop", "anti-slop", cleanup/refactor + slop smells |
+| Planning | omc-plan, ralplan, deep-interview, ralph-init | "plan this", "interview me", "ouroboros" |
+| Exploration | deepinit, sciomc, external-context | "deepinit", "research" |
+| Utility | skillify, learner (deprecated alias), note, cancel, hud, setup, omc-doctor, omc-setup, omc-help, mcp-setup | "stop", "cancel" |
+| Domain | psm, writer-memory, release | psm context |
 
 ## Auto-Activation
 
@@ -255,13 +193,6 @@ Some skills activate automatically based on context:
 | ultrawork | "ulw", "ultrawork" |
 | ralph | "ralph", "don't stop until" |
 | deep-interview | "deep interview", "interview me", "ouroboros", "don't assume" |
-| critique | "critique", "review before push", "critique my changes" |
-| self-improve | "self-improve" |
-| ai-slop-cleaner | "deslop", "anti-slop", "clean slop" |
-| discover | "discover" |
-| trace | "trace" |
-| verify | "verify" |
-| wiki | "wiki" |
 | cancel | "stop", "cancel", "abort" |
 
 <!-- MANUAL:

package/skills/ai-slop-cleaner/SKILL.md

@@ -1,135 +1,133 @@
 ---
 name: ai-slop-cleaner
-description: Clean AI-generated code slop with a test-first, deletion-first deslop workflow and optional reviewer-only mode
+description: Clean AI-generated code slop with a regression-safe, deletion-first workflow and optional reviewer-only mode
+level: 3
 ---
 
-<Purpose>
-Use this skill to systematically clean AI-generated code slop without changing intended behavior. It focuses on simplifying existing code by deleting dead code, collapsing duplicates, removing needless abstractions, tightening boundaries, and reinforcing tests before and after cleanup.
-</Purpose>
-
-<Use_When>
-- The user explicitly says "deslop", "anti-slop", or "AI slop"
-- The request is to clean up or refactor code that feels bloated, repetitive, or overly abstract
-- The user wants a reviewer-only anti-slop pass via `--review` after cleanup work is drafted
-- The user calls out duplicate code, dead code, wrapper layers, boundary violations, or weak regression coverage
-- The goal is simplification, deletion, and cleanup rather than adding new features
-</Use_When>
-
-<Do_Not_Use_When>
-- The task is primarily a new feature build -- use `autopilot` or direct implementation instead
-- The user wants a broad architecture redesign rather than an incremental cleanup pass
-- The request is a generic refactor with no cleanup/simplification intent
-- Behavior is unclear and there are no tests or concrete anchors -- clarify scope first
-</Do_Not_Use_When>
-
-<Why_This_Exists>
-AI-generated code often works while still adding avoidable complexity: duplicate helpers, dead branches, wrapper layers, inconsistent naming, boundary leaks, and missing tests. This skill enforces a disciplined cleanup workflow so simplification happens deliberately instead of as vague "refactoring" that might expand scope.
-</Why_This_Exists>
-
-<Review_Mode>
-### Review Mode (`--review`)
-`--review` activates an explicit reviewer pass after the cleanup writer pass.
+# AI Slop Cleaner
+
+Use this skill to clean AI-generated code slop without drifting scope or changing intended behavior. In OMC, this is the bounded cleanup workflow for code that works but feels bloated, repetitive, weakly tested, or over-abstracted.
+
+## When to Use
+
+Use this skill when:
+- the user explicitly says `deslop`, `anti-slop`, or `AI slop`
+- the request is to clean up or refactor code that feels noisy, repetitive, or overly abstract
+- follow-up implementation left duplicate logic, dead code, wrapper layers, boundary leaks, or weak regression coverage
+- the user wants a reviewer-only anti-slop pass via `--review`
+- the goal is simplification and cleanup, not new feature delivery
+
+## When Not to Use
+
+Do not use this skill when:
+- the task is mainly a new feature build or product change
+- the user wants a broad redesign instead of an incremental cleanup pass
+- the request is a generic refactor with no simplification or anti-slop intent
+- behavior is too unclear to protect with tests or a concrete verification plan
+
+## OMC Execution Posture
+
+- Preserve behavior unless the user explicitly asks for behavior changes.
+- Lock behavior with focused regression tests first whenever practical.
+- Write a cleanup plan before editing code.
+- Prefer deletion over addition.
+- Reuse existing utilities and patterns before introducing new ones.
+- Avoid new dependencies unless the user explicitly requests them.
+- Keep diffs small, reversible, and smell-focused.
+- Stay concise and evidence-dense: inspect, edit, verify, and report.
+- Treat new user instructions as local scope updates without dropping earlier non-conflicting constraints.
+
+## Scoped File-List Usage
+
+This skill can be bounded to an explicit file list or changed-file scope when the caller already knows the safe cleanup surface.
+
+- Good fit: `oh-my-copilot:ai-slop-cleaner skills/ralph/SKILL.md skills/ai-slop-cleaner/SKILL.md`
+- Good fit: a Ralph session handing off only the files changed in that session
+- Preserve the same regression-safe workflow even when the scope is a short file list
+- Do not silently expand a changed-file scope into broader cleanup work unless the user explicitly asks for it
+
+## Ralph Integration
+
+Ralph can invoke this skill as a bounded post-review cleanup pass.
+
+- In that workflow, the cleaner runs in standard mode (not `--review`)
+- The cleanup scope is the Ralph session's changed files only
+- After the cleanup pass, Ralph re-runs regression verification before completion
+- `--review` remains the reviewer-only follow-up mode, not the default Ralph integration path
+
+## Review Mode (`--review`)
+
+`--review` is a reviewer-only pass after cleanup work is drafted. It exists to preserve explicit writer/reviewer separation for anti-slop work.
 
 - **Writer pass**: make the cleanup changes with behavior locked by tests.
-- **Reviewer pass (`--review`)**: inspect the result for duplication, dead code, boundary violations, missing tests, and unnecessary abstractions.
-- The same pass must not both write and self-approve without a separate review step.
+- **Reviewer pass**: inspect the cleanup plan, changed files, and verification evidence.
+- The same pass must not both write and self-approve high-impact cleanup without a separate review step.
 
 In review mode:
-1. Do **not** make edits first.
-2. Inspect the cleanup plan, changed files, and regression coverage.
+1. Do **not** start by editing files.
+2. Review the cleanup plan, changed files, and regression coverage.
 3. Check specifically for:
    - leftover dead code or unused exports
-   - duplicate logic that was not consolidated
+   - duplicate logic that should have been consolidated
    - needless wrappers or abstractions that still blur boundaries
    - missing tests or weak verification for preserved behavior
-   - risky cleanup that changed behavior without explicit intent
+   - cleanup that appears to have changed behavior without intent
 4. Produce a reviewer verdict with required follow-ups.
-5. If changes are needed, hand them back to a separate writer/executor pass instead of fixing and approving in one pass.
-
-This mode exists to preserve writer/reviewer separation: the authoring pass changes code, the reviewer pass evaluates whether the cleanup actually reduced slop safely.
-</Review_Mode>
-
-<Execution_Policy>
-- Preserve behavior unless the user explicitly asks for behavior changes
-- Lock behavior with regression tests first whenever practical
-- Write a cleanup plan before editing code
-- Prefer deletion over addition
-- Reuse existing utilities and patterns before introducing anything new
-- Avoid new dependencies unless the user explicitly requests them
-- Keep diffs small, reversible, and smell-focused
-- Keep writer/reviewer separation: author in one pass, review in another
-- Verify with lint/typecheck/tests/static analysis relevant to the touched area
-</Execution_Policy>
-
-<Steps>
-1. **Lock behavior first**
-   - Identify the current behavior and add or strengthen regression tests before cleanup when practical
-   - If tests cannot be added first, record the verification plan explicitly before editing
-
-2. **Create a cleanup plan**
-   - Do not start coding immediately
-   - List the targeted smells and the files likely involved
-   - Sequence cleanup passes from lowest-risk deletion to higher-risk consolidation
-
-3. **Categorize the slop**
-   - Duplicate code
-   - Dead or unused code
-   - Needless abstraction / wrapper layers
-   - Boundary violations / misplaced responsibilities
-   - Missing or weak tests
-
-4. **Execute one smell-focused pass at a time**
-   - **Pass 1: Dead code deletion** -- remove unused branches, helpers, exports, and stale comments
-   - **Pass 2: Duplicate removal** -- consolidate repeated logic into existing patterns where possible
-   - **Pass 3: Naming and error-handling cleanup** -- tighten naming, trim noisy plumbing, normalize obvious inconsistencies
-   - **Pass 4: Test reinforcement** -- fill any regression gaps revealed by the cleanup
-
-5. **Run quality gates**
-   - Run the relevant lint, typecheck, unit/integration tests, and any static or security checks already present for the touched area
-   - If a gate fails, fix the underlying issue or revert the risky cleanup instead of forcing it through
-
-6. **Optional `--review` pass**
-   - Run a distinct reviewer pass that checks duplication, dead code, boundary violations, test coverage, and needless abstractions
-   - If the reviewer finds issues, address them in a follow-up cleanup pass before closing the task
-
-7. **Report outcome**
-   - Changed files
-   - Simplifications made
-   - Behavior locked by tests
-   - Remaining risks or slop intentionally left for a later pass
-</Steps>
-
-<Examples>
-<Good>
-User: "deslop this module -- too many wrappers, duplicate helpers, and dead code"
-Why good: Explicit anti-slop intent with concrete cleanup smells.
-</Good>
-
-<Good>
-User: "cleanup the AI slop in src/auth: remove dead code and tighten boundaries"
-Why good: Cleanup/refactor request is clearly about simplification, not feature work.
-</Good>
-
-<Bad>
-User: "refactor auth to support SSO"
-Why bad: This is feature work disguised as refactoring, not anti-slop cleanup.
-</Bad>
-
-<Bad>
-User: "clean up formatting"
-Why bad: Formatting-only work does not need the full anti-slop workflow.
-</Bad>
-</Examples>
-
-<Final_Report>
-Always end with:
-- **Changed files**
-- **Simplifications**
-- **Verification run**
-- **Remaining risks**
-</Final_Report>
-
-<Usage>
+5. Hand needed changes back to a separate writer pass instead of fixing and approving in one step.
+
+## Workflow
+
+1. **Protect current behavior first**
+   - Identify what must stay the same.
+   - Add or run the narrowest regression tests needed before editing.
+   - If tests cannot come first, record the verification plan explicitly before touching code.
+
+2. **Write a cleanup plan before code**
+   - Bound the pass to the requested files or feature area.
+   - List the concrete smells to remove.
+   - Order the work from safest deletion to riskier consolidation.
+
+3. **Classify the slop before editing**
+   - **Duplication** — repeated logic, copy-paste branches, redundant helpers
+   - **Dead code** — unused code, unreachable branches, stale flags, debug leftovers
+   - **Needless abstraction** — pass-through wrappers, speculative indirection, single-use helper layers
+   - **Boundary violations** — hidden coupling, misplaced responsibilities, wrong-layer imports or side effects
+   - **Missing tests** — behavior not locked, weak regression coverage, edge-case gaps
+
+4. **Run one smell-focused pass at a time**
+   - **Pass 1: Dead code deletion**
+   - **Pass 2: Duplicate removal**
+   - **Pass 3: Naming and error-handling cleanup**
+   - **Pass 4: Test reinforcement**
+   - Re-run targeted verification after each pass.
+   - Do not bundle unrelated refactors into the same edit set.
+
+5. **Run the quality gates**
+   - Keep regression tests green.
+   - Run the relevant lint, typecheck, and unit/integration tests for the touched area.
+   - Run existing static or security checks when available.
+   - If a gate fails, fix the issue or back out the risky cleanup instead of forcing it through.
+
+6. **Close with an evidence-dense report**
+   Always report:
+   - **Changed files**
+   - **Simplifications**
+   - **Behavior lock / verification run**
+   - **Remaining risks**
+
+## Usage
+
 - `/oh-my-copilot:ai-slop-cleaner <target>`
 - `/oh-my-copilot:ai-slop-cleaner <target> --review`
-</Usage>
+- `/oh-my-copilot:ai-slop-cleaner <file-a> <file-b> <file-c>`
+- From Ralph: run the cleaner on the Ralph session's changed files only, then return to Ralph for post-cleanup regression verification
+
+## Good Fits
+
+**Good:** `deslop this module: too many wrappers, duplicate helpers, and dead code`
+
+**Good:** `cleanup the AI slop in src/auth and tighten boundaries without changing behavior`
+
+**Bad:** `refactor auth to support SSO`
+
+**Bad:** `clean up formatting`

package/skills/ask/SKILL.md

@@ -1,22 +1,21 @@
 ---
 name: ask
-description: Process-first advisor routing for Copilot, Claude, Codex, or Gemini via `omcp ask`, with artifact capture and no raw CLI assembly
+description: Process-first advisor routing for Claude, Codex, or Gemini via `omc ask`, with artifact capture and no raw CLI assembly
 ---
 
 # Ask
 
-Use OMC's canonical advisor skill to route a prompt through a local CLI (Copilot, Claude, Codex, or Gemini) and persist the result as an ask artifact.
+Use OMC's canonical advisor skill to route a prompt through the local Claude, Codex, or Gemini CLI and persist the result as an ask artifact.
 
 ## Usage
 
 ```bash
-/oh-my-copilot:ask <copilot|claude|codex|gemini> <question or task>
+/oh-my-copilot:ask <claude|codex|gemini> <question or task>
 ```
 
 Examples:
 
 ```bash
-/oh-my-copilot:ask copilot "get a fresh perspective on this design decision"
 /oh-my-copilot:ask codex "review this patch from a security perspective"
 /oh-my-copilot:ask gemini "suggest UX improvements for this flow"
 /oh-my-copilot:ask claude "draft an implementation plan for issue #123"
@@ -27,10 +26,10 @@ Examples:
 **Required execution path — always use this command:**
 
 ```bash
-omcp ask {{ARGUMENTS}}
+omc ask {{ARGUMENTS}}
 ```
 
-**Do NOT manually construct raw provider CLI commands.** Never run `copilot`, `codex`, `claude`, or `gemini` directly to fulfill this skill. The `omcp ask` wrapper handles correct flag selection, artifact persistence, and provider-version compatibility automatically. Manually assembling provider CLI flags will produce incorrect or outdated invocations.
+**Do NOT manually construct raw provider CLI commands.** Never run `codex`, `claude`, or `gemini` directly to fulfill this skill. The `omc ask` wrapper handles correct flag selection, artifact persistence, and provider-version compatibility automatically. Manually assembling provider CLI flags will produce incorrect or outdated invocations.
 
 ## Requirements
 
@@ -38,7 +37,6 @@ omcp ask {{ARGUMENTS}}
 - Verify availability with the matching command:
 
 ```bash
-copilot --version
 claude --version
 codex --version
 gemini --version
@@ -46,7 +44,7 @@ gemini --version
 
 ## Artifacts
 
-`omcp ask` writes artifacts to:
+`omc ask` writes artifacts to:
 
 ```text
 .omcp/artifacts/ask/<provider>-<slug>-<timestamp>.md

package/skills/autopilot/SKILL.md

@@ -28,20 +28,6 @@ Autopilot takes a brief product idea and autonomously handles the full lifecycle
 Most non-trivial software tasks require coordinated phases: understanding requirements, designing a solution, implementing in parallel, testing, and validating quality. Autopilot orchestrates all of these phases automatically so the user can describe what they want and receive working code without managing each step.
 </Why_This_Exists>
 
-<Complexity_Gate>
-Before starting Phase 0, classify the task complexity:
-
-1. **Heuristic check** (zero-cost): The system's complexity classifier runs pattern matching on your prompt
-2. **AI assessment** (if heuristic inconclusive): Spawn an `explore` agent (haiku) to assess complexity
-
-**Routing by complexity:**
-- **SIMPLE** (e.g., "fix typo", "rename variable", "bump version"): Skip Phase 0 and Phase 1 entirely. Jump directly to Phase 2 (Execution) with a minimal plan.
-- **STANDARD** (default): Run the normal autopilot flow (all phases)
-- **COMPLEX** (e.g., auth systems, migrations, distributed architecture): Run all phases AND add Critic review after Phase 0 and Phase 1 for additional quality gates
-
-Complexity result is stored in `.omcp/state/sessions/{sessionId}/complexity.json` for downstream phases to reference.
-</Complexity_Gate>
-
 <Execution_Policy>
 - Each phase must complete before the next begins
 - Parallel execution is used within phases where possible (Phase 2 and Phase 4)
@@ -58,27 +44,23 @@ Complexity result is stored in `.omcp/state/sessions/{sessionId}/complexity.json
    - **If input is vague** (no file paths, function names, or concrete anchors): Offer redirect to `/deep-interview` for Socratic clarification before expanding
    - **Otherwise**: Analyst (Opus) extracts requirements, Architect (Opus) creates technical specification
    - Output: `.omcp/autopilot/spec.md`
-   - **Context capture**: Phase 0 output (spec summary) is captured for injection into Phase 1
 
 2. **Phase 1 - Planning**: Create an implementation plan from the spec
    - **If ralplan consensus plan exists**: Skip — already done in the 3-stage pipeline
    - Architect (Opus): Create plan (direct mode, no interview)
    - Critic (Opus): Validate plan
    - Output: `.omcp/plans/autopilot-impl.md`
-   - **Context capture**: Phase 1 output (plan summary) is captured for injection into Phase 2
 
 3. **Phase 2 - Execution**: Implement the plan using Ralph + Ultrawork
    - Executor (Haiku): Simple tasks
    - Executor (Sonnet): Standard tasks
    - Executor (Opus): Complex tasks
    - Run independent tasks in parallel
-   - **Context capture**: Phase 2 output (implementation summary: files changed, decisions made) is captured for injection into Phase 3
 
 4. **Phase 3 - QA**: Cycle until all tests pass (UltraQA mode)
    - Build, lint, test, fix failures
    - Repeat up to 5 cycles
    - Stop early if the same error repeats 3 times (indicates a fundamental issue)
-   - **Context capture**: Phase 3 output (QA results) is captured for injection into Phase 4
 
 5. **Phase 4 - Validation**: Multi-perspective review in parallel
    - Architect: Functional completeness
@@ -95,7 +77,7 @@ Complexity result is stored in `.omcp/state/sessions/{sessionId}/complexity.json
 - Use `Task(subagent_type="oh-my-copilot:architect", ...)` for Phase 4 architecture validation
 - Use `Task(subagent_type="oh-my-copilot:security-reviewer", ...)` for Phase 4 security review
 - Use `Task(subagent_type="oh-my-copilot:code-reviewer", ...)` for Phase 4 quality review
-- Agents form their own analysis first, then spawn Copilot Task agents for cross-validation
+- Agents form their own analysis first, then spawn Claude Task agents for cross-validation
 - Never block on external tools; proceed with available agents if delegation fails
 </Tool_Usage>
 
@@ -138,15 +120,6 @@ Why bad: This is an exploration/brainstorming request. Respond conversationally
 </Final_Checklist>
 
 <Advanced>
-## Context Accumulation
-
-Autopilot captures key outputs from each phase and injects them into the next phase's agent prompt as a `<prior-phase-context>` block. This ensures downstream agents have context from earlier phases without needing to re-read files.
-
-- Phase outputs are truncated to 12KB each
-- Context is session-scoped and cleared on `/cancel`
-- Includes: spec summaries, plan summaries, implementation decisions, QA results
-- Stored in `.omcp/state/sessions/{sessionId}/phase-context.json`
-
 ## Configuration
 
 Optional settings in `.copilot/omg.jsonc` (project) or `~/.config/copilot-omg/config.jsonc` (user):

package/skills/autoresearch/SKILL.md

@@ -12,14 +12,14 @@ Autoresearch is a stateful skill for bounded, evaluator-driven iterative improve
 <Use_When>
 - You already have a mission and evaluator from `/deep-interview --autoresearch`
 - You want persistent single-mission improvement with strict evaluation
-- You need durable experiment logs under `.omc/autoresearch/`
+- You need durable experiment logs under `.omcp/autoresearch/`
 - You want a supported path for periodic reruns via Claude Code native cron
 </Use_When>
 
 <Do_Not_Use_When>
 - You need evaluator generation at runtime — use `/deep-interview --autoresearch` first
 - You need multiple missions orchestrated together — v1 forbids that
-- You want the deprecated `omcp autoresearch` CLI flow — it is no longer authoritative
+- You want the deprecated `omc autoresearch` CLI flow — it is no longer authoritative
 </Do_Not_Use_When>
 
 <Contract>
@@ -31,7 +31,7 @@ Autoresearch is a stateful skill for bounded, evaluator-driven iterative improve
 </Contract>
 
 <Required_Artifacts>
-Canonical persistent storage lives under `.omc/autoresearch/<mission-slug>/` and/or `.omc/logs/autoresearch/<run-id>/`.
+Canonical persistent storage lives under `.omcp/autoresearch/<mission-slug>/` and/or `.omcp/logs/autoresearch/<run-id>/`.
 
 Minimum required artifacts:
 - mission spec
@@ -41,7 +41,7 @@ Minimum required artifacts:
 
 Recommended canonical shape:
 ```text
-.omc/autoresearch/<mission-slug>/
+.omcp/autoresearch/<mission-slug>/
   mission.md
   evaluator.json
   runs/<run-id>/
@@ -83,7 +83,7 @@ If cron is used:
 </Cron_Integration>
 
 <Execution_Policy>
-- Do not hand execution back to `omcp autoresearch`
+- Do not hand execution back to `omc autoresearch`
 - Do not create multi-mission orchestration
 - Prefer reusing `src/autoresearch/*` runtime/schema helpers where they already match the stricter contract
 - Keep logs useful to humans, not only machines