oh-my-copilot 4.13.21 → 4.13.54

package/skills/deep-interview/SKILL.md

@@ -2,8 +2,8 @@
 name: deep-interview
 description: Socratic deep interview with mathematical ambiguity gating before autonomous execution
 argument-hint: "[--quick|--standard|--deep] [--autoresearch] <idea or vague description>"
-pipeline: [deep-interview, omc-plan, autopilot]
-next-skill: omc-plan
+pipeline: [deep-interview, plan, autopilot]
+next-skill: plan
 next-skill-args: --consensus --direct
 handoff: .omcp/specs/deep-interview-{slug}.md
 level: 3
@@ -39,10 +39,12 @@ Inspired by the [Ouroboros project](https://github.com/Q00/ouroboros) which demo
 <Execution_Policy>
 - Ask ONE question at a time -- never batch multiple questions
 - Target the WEAKEST clarity dimension with each question
+- Before Round 1 ambiguity scoring, run a one-time Round 0 topology enumeration gate that confirms the top-level component list and locks it into state
 - Make weakest-dimension targeting explicit every round: name the weakest dimension, state its score/gap, and explain why the next question is aimed there
 - Gather codebase facts via `explore` agent BEFORE asking the user about them
 - For brownfield confirmation questions, cite the repo evidence that triggered the question (file path, symbol, or pattern) instead of asking the user to rediscover it
 - Score ambiguity after every answer -- display the score transparently
+- When the locked topology has multiple active components, score and target each component explicitly so depth-first clarity on one component cannot hide ambiguity in siblings
 - Keep prompt payloads budgeted: summarize or trim oversized initial context/history before composing question, scoring, spec, or handoff prompts
 - If the user's initial context is oversized, create a concise prompt-safe summary first and wait for that summary before ambiguity scoring, question generation, or downstream execution handoff
 - Do not proceed to execution until ambiguity ≤ the resolved threshold for this run
@@ -103,6 +105,13 @@ When arguments include `--autoresearch`, Deep Interview becomes the zero-learnin
     "current_ambiguity": 1.0,
     "threshold": <resolvedThreshold>,
     "codebase_context": null,
+    "topology": {
+      "status": "pending|confirmed|legacy_missing",
+      "confirmed_at": null,
+      "components": [],
+      "deferrals": [],
+      "last_targeted_component_id": null
+    },
     "challenge_modes_used": [],
     "ontology_snapshots": []
   }
@@ -117,6 +126,69 @@ When arguments include `--autoresearch`, Deep Interview becomes the zero-learnin
 > **Project type:** {greenfield|brownfield}
 > **Current ambiguity:** 100% (we haven't started yet)
 
+## Round 0: Topology Enumeration Gate
+
+Run this gate exactly once after Phase 1 initialization and before any Phase 2 ambiguity scoring. The goal is to lock the **shape** of the user's scope before depth-first Socratic questioning can overfit to the most-described component.
+
+1. **Enumerate candidate top-level components** from the prompt-safe initial idea and brownfield context:
+   - Extract top-level verbs/nouns, workstreams, surfaces, integrations, or deliverables that can succeed or fail independently.
+   - Prefer 1-6 components. If more than 6 candidates appear, group siblings at the highest useful level and note the grouping rationale.
+   - Do not treat implementation tasks, fields, or sub-features as top-level components unless the user framed them as independent outcomes.
+2. **Ask one confirmation question** before Round 1:
+
+```
+Round 0 | Topology confirmation | Ambiguity: not scored yet
+
+I'm reading this as {N} top-level component(s):
+1. {component_name}: {one_sentence_description}
+2. ...
+
+Is that topology right? Should any component be added, removed, merged, split, or explicitly deferred?
+```
+
+Options should include contextually relevant choices such as **Looks right**, **Add/remove/merge components**, **Defer one or more components**, plus free-text. This is the only pre-scoring question and preserves the one-question-per-round rule.
+
+3. **Lock topology into state** after the answer. Store a normalized component list and confirmation timestamp:
+
+```json
+{
+  "topology": {
+    "status": "confirmed",
+    "confirmed_at": "<ISO-8601 timestamp>",
+    "components": [
+      {
+        "id": "component-slug",
+        "name": "Component Name",
+        "description": "Confirmed top-level outcome",
+        "status": "active|deferred",
+        "evidence": ["initial prompt phrase or brownfield citation"],
+        "clarity_scores": {
+          "goal": null,
+          "constraints": null,
+          "criteria": null,
+          "context": null
+        },
+        "weakest_dimension": null
+      }
+    ],
+    "deferrals": [
+      {
+        "component_id": "component-slug",
+        "reason": "User-confirmed deferral reason",
+        "confirmed_at": "<ISO-8601 timestamp>"
+      }
+    ],
+    "last_targeted_component_id": null
+  }
+}
+```
+
+4. **Legacy state migration:** When resuming an existing `deep-interview` state file that lacks `topology`, treat it as `"status": "legacy_missing"`. If no final `spec_path` exists yet, run Round 0 before the next ambiguity scoring pass and then continue with the existing transcript. If a final spec already exists, do not rewrite history; note in any handoff that topology was not captured for that legacy interview.
+
+5. **Single-component pass-through:** If the user confirms one active component, Phase 2 proceeds with the existing flow while still carrying `topology.components[0]` into scoring and spec output.
+
+6. **Four-component fixture shape:** For an initial idea such as "Build an intake pipeline that ingests CSVs, normalizes records, provides a detailed reviewer UI with inline comments and approvals, and exports audit-ready reports," Round 0 should surface all four top-level components — `Ingestion`, `Normalization`, `Review UI`, and `Export` — even though `Review UI` is the one detailed component. The detailed `Review UI` component must not collapse or stand in for the less-detailed sibling components. Phase 2 must ask follow-up questions until every active component has sufficient goal/constraint/criteria clarity. Phase 4 must cover each confirmed component in `## Topology` or explicitly list a user-confirmed deferral for that component.
+
 ## Phase 2: Interview Loop
 
 Repeat until `ambiguity ≤ threshold` OR user exits early:
@@ -129,13 +201,15 @@ Build the question generation prompt with:
 - Current clarity scores per dimension (which is weakest?)
 - Challenge agent mode (if activated -- see Phase 3)
 - Brownfield codebase context (if applicable), summarized to cited paths/symbols/patterns instead of raw dumps
+- Locked topology from Round 0, including active components, deferred components, prior per-component scores, and `last_targeted_component_id`
 
 If any prompt input is too large, summarize it first and then continue from the summary. Do not ask the next `AskUserQuestion`, score ambiguity, or hand off to execution from an over-budget raw transcript.
 
 **Question targeting strategy:**
-- Identify the dimension with the LOWEST clarity score
-- Generate a question that specifically improves that dimension
-- State, in one sentence before the question, why this dimension is now the bottleneck to reducing ambiguity
+- Identify the active component + dimension pair with the LOWEST clarity score across the locked topology
+- When N > 1 active components are tied or similarly weak, rotate targeting across active components rather than asking repeatedly about the last targeted component; update `topology.last_targeted_component_id` after each question
+- Generate a question that specifically improves that component's weakest dimension
+- State, in one sentence before the question, why this component/dimension pair is now the bottleneck to reducing ambiguity
 - Questions should expose ASSUMPTIONS, not gather feature lists
 - If the scope is still conceptually fuzzy (entities keep shifting, the user is naming symptoms, or the core noun is unstable), switch to an ontology-style question that asks what the thing fundamentally IS before returning to feature/detail questions
 
@@ -153,7 +227,7 @@ If any prompt input is too large, summarize it first and then continue from the
 Use `AskUserQuestion` with the generated question. Present it clearly with the current ambiguity context:
 
 ```
-Round {n} | Targeting: {weakest_dimension} | Why now: {one_sentence_targeting_rationale} | Ambiguity: {score}%
+Round {n} | Component: {target_component_name} | Targeting: {weakest_dimension} | Why now: {one_sentence_targeting_rationale} | Ambiguity: {score}%
 
 {question}
 ```
@@ -167,13 +241,18 @@ After receiving the user's answer, score clarity across all dimensions.
 **Scoring prompt** (use opus model, temperature 0.1 for consistency):
 
 ```
-Given the following interview transcript for a {greenfield|brownfield} project, score clarity on each dimension from 0.0 to 1.0. If the initial context or transcript was summarized for prompt safety, score from that summary plus the preserved round decisions/gaps; do not re-expand raw oversized context.
+Given the following interview transcript for a {greenfield|brownfield} project, score clarity on each dimension from 0.0 to 1.0. If the initial context or transcript was summarized for prompt safety, score from that summary plus the preserved round decisions/gaps; do not re-expand raw oversized context. Honor the locked Round 0 topology: score every active component independently and never drop confirmed sibling components just because one component is already clear.
 
 Original idea or prompt-safe initial-context summary: {idea_or_initial_context_summary}
 
 Transcript or prompt-safe transcript summary:
 {all rounds Q&A or summarized transcript}
 
+Locked topology:
+{state.topology.components and state.topology.deferrals}
+
+Score each active component on each dimension, then provide the overall dimension scores as the minimum or coverage-weighted weakest score across active components. Deferred components are excluded from ambiguity math but must remain listed in topology and the final spec.
+
 Score each dimension:
 1. Goal Clarity (0.0-1.0): Is the primary objective unambiguous? Can you state it in one sentence without qualifiers? Can you name the key entities (nouns) and their relationships (verbs) without ambiguity?
 2. Constraint Clarity (0.0-1.0): Are the boundaries, limitations, and non-goals clear?
@@ -186,8 +265,10 @@ For each dimension provide:
 - gap: what's still unclear (if score < 0.9)
 
 Also identify:
-- weakest_dimension: the single lowest-confidence dimension this round
-- weakest_dimension_rationale: one sentence explaining why it is the highest-leverage target for the next question
+- weakest_component_id: the active component with the lowest clarity after applying rotation across components when N > 1
+- weakest_dimension: the single lowest-confidence dimension for that component this round
+- weakest_dimension_rationale: one sentence explaining why this component/dimension pair is the highest-leverage target for the next question
+- component_scores: object keyed by component id, with per-dimension scores and gaps
 
 5. Ontology Extraction: Identify all key entities (nouns) discussed in the transcript.
 
@@ -239,16 +320,18 @@ Round {n} complete.
 | Context (brownfield) | {s} | {w} | {s*w} | {gap or "Clear"} |
 | **Ambiguity** | | | **{score}%** | |
 
+**Topology:** Targeted {target_component_name} | Active: {active_component_count} | Deferred: {deferred_component_count} | Next rotation after: {last_targeted_component_id}
+
 **Ontology:** {entity_count} entities | Stability: {stability_ratio} | New: {new} | Changed: {changed} | Stable: {stable}
 
-**Next target:** {weakest_dimension} — {weakest_dimension_rationale}
+**Next target:** {target_component_name} / {weakest_dimension} — {weakest_dimension_rationale}
 
 {score <= threshold ? "Clarity threshold met! Ready to proceed." : "Focusing next question on: {weakest_dimension}"}
 ```
 
 ### Step 2e: Update State
 
-Update interview state with the new round and scores via `state_write`.
+Update interview state with the new round, global scores, per-component `topology.components[].clarity_scores`, `topology.components[].weakest_dimension`, ontology snapshot, and `topology.last_targeted_component_id` via `state_write`.
 
 ### Step 2f: Check Soft Limits
 
@@ -310,8 +393,15 @@ Spec structure:
 | **Total Clarity** | | | **{total}** |
 | **Ambiguity** | | | **{1-total}** |
 
+## Topology
+{List every Round 0 confirmed top-level component. Active components must have coverage notes; deferred components must include the user-confirmed deferral reason and timestamp.}
+
+| Component | Status | Description | Coverage / Deferral Note |
+|-----------|--------|-------------|--------------------------|
+| {component.name} | {active|deferred} | {component.description} | {covered acceptance criteria or deferral reason} |
+
 ## Goal
-{crystal-clear goal statement derived from interview}
+{crystal-clear goal statement derived from interview, covering every active topology component}
 
 ## Constraints
 - {constraint 1}
@@ -379,7 +469,7 @@ After the spec is written, present execution options via `AskUserQuestion`:
 
 1. **Ralplan → Autopilot (Recommended)**
    - Description: "3-stage pipeline: consensus-refine this spec with Planner/Architect/Critic, then execute with full autopilot. Maximum quality."
-   - Action: Invoke `Skill("oh-my-copilot:omc-plan")` with `--consensus --direct` flags and the spec file path as context. The `--direct` flag skips the omc-plan skill's interview phase (the deep interview already gathered requirements), while `--consensus` triggers the Planner/Architect/Critic loop. When consensus completes and produces a plan in `.omcp/plans/`, invoke `Skill("oh-my-copilot:autopilot")` with the consensus plan as Phase 0+1 output — autopilot skips both Expansion and Planning, starting directly at Phase 2 (Execution).
+   - Action: Invoke `Skill("oh-my-copilot:plan")` with `--consensus --direct` flags and the spec file path as context. The `--direct` flag skips the omc-plan skill's interview phase (the deep interview already gathered requirements), while `--consensus` triggers the Planner/Architect/Critic loop. When consensus completes and produces a plan in `.omcp/plans/`, invoke `Skill("oh-my-copilot:autopilot")` with the consensus plan as Phase 0+1 output — autopilot skips both Expansion and Planning, starting directly at Phase 2 (Execution).
    - Pipeline: `deep-interview spec → omc-plan --consensus --direct → autopilot execution`
 
 2. **Execute with autopilot (skip ralplan)**
@@ -431,6 +521,7 @@ Skipping any stage is possible but reduces quality assurance:
 - Preserve the AskUserQuestion path for OMC-native interaction; do not introduce OMX-only structured-question transport into this skill
 - Use `Task(subagent_type="oh-my-copilot:explore", model="haiku")` for brownfield codebase exploration (run BEFORE asking user about codebase)
 - Use opus model (temperature 0.1) for ambiguity scoring — consistency is critical
+- Round 0 topology confirmation happens before ambiguity scoring; Phase 2 scoring must honor locked topology and rotate targeting across active components when more than one is present
 - Use `state_write` / `state_read` for interview state persistence
 - Use `Write` tool to save the final spec to `.omcp/specs/deep-interview-{slug}.md` exactly; use `.omcp/state/` or `state_write` for ephemeral artifacts
 - Use `Skill()` to bridge to execution modes — never implement directly
@@ -555,14 +646,17 @@ Why bad: 45% ambiguity means nearly half the requirements are unclear. The mathe
 - [ ] Every round explicitly names the weakest dimension and why it is the next target
 - [ ] Challenge agents activated at correct thresholds (round 4, 6, 8)
 - [ ] Spec file written to `.omcp/specs/deep-interview-{slug}.md` exactly; ephemeral artifacts stayed under `.omcp/state/` or `state_write`
-- [ ] Spec includes: goal, constraints, acceptance criteria, clarity breakdown, transcript
+- [ ] Spec includes: topology, goal, constraints, acceptance criteria, clarity breakdown, transcript
 - [ ] Execution bridge presented via AskUserQuestion
 - [ ] Selected execution mode invoked via Skill() (never direct implementation)
 - [ ] If 3-stage pipeline selected: omc-plan --consensus --direct invoked, then autopilot with consensus plan
 - [ ] State cleaned up after execution handoff
 - [ ] Brownfield confirmation questions cite repo evidence (file/path/pattern) before asking the user to decide
 - [ ] Scope-fuzzy tasks can trigger ontology-style questioning to stabilize the core entity before feature elaboration
-- [ ] Per-round ambiguity report includes Ontology row with entity count and stability ratio
+- [ ] Round 0 topology gate completed before ambiguity scoring and persisted `topology.confirmed_at`
+- [ ] Per-round ambiguity report includes Topology target/coverage and Ontology row with entity count and stability ratio
+- [ ] Multi-component interviews rotate targeting across active components when N > 1
+- [ ] Spec includes Topology section with confirmed active components and user-confirmed deferrals
 - [ ] Spec includes Ontology (Key Entities) table and Ontology Convergence section
 </Final_Checklist>
 

package/skills/mcp-setup/SKILL.md

@@ -1,27 +1,26 @@
 ---
 name: mcp-setup
 description: Configure popular MCP servers for enhanced agent capabilities
-level: 2
 ---
 
 # MCP Setup
 
-Configure Model Context Protocol (MCP) servers to extend Claude Code's capabilities with external tools like web search, file system access, and GitHub integration.
+Configure Model Context Protocol (MCP) servers to extend Copilot CLI's capabilities with external tools like web search, token optimization, and DevOps integration.
 
 ## Overview
 
-MCP servers provide additional tools that Claude Code agents can use. This skill helps you configure popular MCP servers using the `claude mcp add` command-line interface.
+MCP servers provide additional tools that Copilot CLI agents can use. This skill helps you configure popular MCP servers using the `copilot mcp add` command-line interface.
 
 ## Step 1: Choose a Setup Path
 
-Use **AskUserQuestion** with **one question at a time** and **no more than 3 options per question**. Recent Claude Code builds reject larger option payloads as invalid tool parameters, so keep the MCP selection flow staged.
+Use **AskUserQuestion** with **one question at a time** and **no more than 3 options per question**. Recent Copilot CLI builds reject larger option payloads as invalid tool parameters, so keep the MCP selection flow staged.
 
 ### Step 1.1: First menu
 
 **Question:** "What kind of MCP setup would you like?"
 
 **Options:**
-1. **Recommended starter setup** - Fast path for the most common OMC MCP additions
+1. **Recommended starter setup** - Fast path for the most common OMCP MCP additions
 2. **Individual popular server** - Pick one built-in server from a short follow-up menu
 3. **Custom server** - Add your own stdio or HTTP MCP server
 
@@ -33,8 +32,8 @@ Ask a follow-up **AskUserQuestion**:
 
 **Options:**
 1. **Context7 only (Recommended)** - Zero-config docs/context server
-2. **Context7 + Exa** - Docs/context plus enhanced web search
-3. **Full recommended bundle** - Context7, Exa, Filesystem, and GitHub
+2. **Context7 + lean-ctx** - Docs/context plus token-saving compression layer
+3. **Full recommended bundle** - Context7, lean-ctx, Exa, and GitHub
 
 Map that choice to the server list you will configure.
 
@@ -46,17 +45,17 @@ Ask a follow-up **AskUserQuestion**:
 
 **Options:**
 1. **Context7 (Recommended)** - Documentation and code context from popular libraries
-2. **Exa Web Search** - Enhanced web search (replaces built-in websearch)
-3. **More server choices** - Filesystem, GitHub, or the full recommended bundle
+2. **lean-ctx** - Token-saving compression layer for Read/Grep/Bash tools
+3. **More server choices** - Exa, GitHub, Azure DevOps, or the full recommended bundle
 
 If the user chooses **More server choices**, ask one more **AskUserQuestion**:
 
 **Question:** "Which additional MCP option do you want?"
 
 **Options:**
-1. **Filesystem (Recommended)** - Extended file system access with additional capabilities
-2. **GitHub** - GitHub API integration for issues, PRs, and repository management
-3. **Full recommended bundle** - Configure Context7, Exa, Filesystem, and GitHub together
+1. **Exa Web Search** - Enhanced web search (replaces built-in websearch)
+2. **GitHub / Azure DevOps** - Repository and project management integration
+3. **Full recommended bundle** - Configure Context7, lean-ctx, Exa, and GitHub together
 
 ### Step 1.4: If the user chooses "Custom server"
 
@@ -75,13 +74,9 @@ Do you have an Exa API key?
 - Enter your API key, or type 'skip' to configure later
 ```
 
-### For Filesystem:
-Ask for allowed directories:
-```
-Which directories should the filesystem MCP have access to?
-Default: Current working directory
-Enter comma-separated paths, or press Enter for default
-```
+### For lean-ctx:
+No API key required. Installs automatically. Saves 60-80% input tokens via caching and compression.
+More info: https://github.com/yvgude/lean-ctx
 
 ### For GitHub:
 Ask for token:
@@ -92,46 +87,64 @@ Do you have a GitHub Personal Access Token?
 - Enter your token, or type 'skip' to configure later
 ```
 
+### For Azure DevOps:
+Ask for organization:
+```
+What is your Azure DevOps organization URL?
+- Example: https://dev.azure.com/my-org
+- Enter your organization URL, or type 'skip' to configure later
+```
+More info: https://github.com/microsoft/azure-devops-mcp
+
 ## Step 3: Add MCP Servers Using CLI
 
-Use the `claude mcp add` command to configure each MCP server. The CLI automatically handles settings.json updates and merging.
+Use the `copilot mcp add` command to configure each MCP server. The CLI automatically handles settings.json updates and merging.
 
 ### Context7 Configuration:
 ```bash
-claude mcp add context7 -- npx -y @upstash/context7-mcp
+copilot mcp add context7 -- npx -y @upstash/context7-mcp
 ```
 
 ### Exa Web Search Configuration:
 ```bash
-claude mcp add -e EXA_API_KEY=<user-provided-key> exa -- npx -y exa-mcp-server
+copilot mcp add -e EXA_API_KEY=<user-provided-key> exa -- npx -y exa-mcp-server
 ```
 
-### Filesystem Configuration:
+### lean-ctx Configuration:
 ```bash
-claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem <allowed-directories>
+npm install -g lean-ctx-bin && lean-ctx setup
 ```
+> Note: lean-ctx uses its own installer (`lean-ctx setup`) which auto-configures shell and all detected editors. It hooks into existing tools (Read, Grep, Bash) to compress and cache results automatically.
+
 
 ### GitHub Configuration:
 
 **Option 1: Docker (local)**
 ```bash
-claude mcp add -e GITHUB_PERSONAL_ACCESS_TOKEN=<user-provided-token> github -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server
+copilot mcp add -e GITHUB_PERSONAL_ACCESS_TOKEN=<user-provided-token> github -- docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN ghcr.io/github/github-mcp-server
 ```
 
 **Option 2: HTTP (remote)**
 ```bash
-claude mcp add --transport http github https://api.githubcopilot.com/mcp/
+copilot mcp add --transport http github https://api.githubcopilot.com/mcp/
 ```
 
 > Note: Docker option requires Docker installed. HTTP option is simpler but may have different capabilities.
 
+### Azure DevOps Configuration:
+```bash
+copilot mcp add azure-devops -- npx -y @microsoft/azure-devops-mcp
+```
+
+> Note: Requires Azure DevOps authentication. Run `az login` first or configure a PAT. See https://github.com/microsoft/azure-devops-mcp for setup details.
+
 ## Step 4: Verify Installation
 
 After configuration, verify the MCP servers are properly set up:
 
 ```bash
 # List configured MCP servers
-claude mcp list
+copilot mcp list
 ```
 
 This will display all configured MCP servers and their status.
@@ -145,26 +158,27 @@ CONFIGURED SERVERS:
 [List the servers that were configured]
 
 NEXT STEPS:
-1. Restart Claude Code for changes to take effect
+1. Restart Copilot CLI for changes to take effect
 2. The configured MCP tools will be available to all agents
-3. Run `claude mcp list` to verify configuration
+3. Run `copilot mcp list` to verify configuration
 
 USAGE TIPS:
 - Context7: Ask about library documentation (e.g., "How do I use React hooks?")
 - Exa: Use for web searches (e.g., "Search the web for latest TypeScript features")
-- Filesystem: Extended file operations beyond the working directory
+- lean-ctx: Automatic — compresses Read/Grep/Bash results to save tokens
 - GitHub: Interact with GitHub repos, issues, and PRs
+- Azure DevOps: Manage work items, pipelines, repos, and wikis
 
 TROUBLESHOOTING:
-- If MCP servers don't appear, run `claude mcp list` to check status
+- If MCP servers don't appear, run `copilot mcp list` to check status
 - Ensure you have Node.js 18+ installed for npx-based servers
 - For GitHub Docker option, ensure Docker is installed and running
 - Run /oh-my-copilot:omc-doctor to diagnose issues
 
 MANAGING MCP SERVERS:
-- Add more servers: /oh-my-copilot:mcp-setup or `claude mcp add ...`
-- List servers: `claude mcp list`
-- Remove a server: `claude mcp remove <server-name>`
+- Add more servers: /oh-my-copilot:mcp-setup or `copilot mcp add ...`
+- List servers: `copilot mcp list`
+- Remove a server: `copilot mcp remove <server-name>`
 ```
 
 ## Custom MCP Server
@@ -179,24 +193,24 @@ Ask for:
 5. Environment variables (optional, key=value pairs)
 6. HTTP headers (optional, for http transport only)
 
-Then construct and run the appropriate `claude mcp add` command:
+Then construct and run the appropriate `copilot mcp add` command:
 
 **For stdio servers:**
 ```bash
 # Without environment variables
-claude mcp add <server-name> -- <command> [args...]
+copilot mcp add <server-name> -- <command> [args...]
 
 # With environment variables
-claude mcp add -e KEY1=value1 -e KEY2=value2 <server-name> -- <command> [args...]
+copilot mcp add -e KEY1=value1 -e KEY2=value2 <server-name> -- <command> [args...]
 ```
 
 **For HTTP servers:**
 ```bash
 # Basic HTTP server
-claude mcp add --transport http <server-name> <url>
+copilot mcp add --transport http <server-name> <url>
 
 # HTTP server with headers
-claude mcp add --transport http --header "Authorization: Bearer <token>" <server-name> <url>
+copilot mcp add --transport http --header "Authorization: Bearer <token>" <server-name> <url>
 ```
 
 ### Company-context convention
@@ -206,7 +220,7 @@ If the custom server is meant to provide organization-specific reference materia
 Example local registration:
 
 ```bash
-claude mcp add company-context -- node examples/vendor-mcp-server/server.mjs
+copilot mcp add company-context -- node examples/vendor-mcp-server/server.mjs
 ```
 
 Then point OMC at the full tool name in `.copilot/omg.jsonc` or `~/.config/copilot-omg/config.jsonc`:
@@ -227,19 +241,20 @@ This remains advisory prompt context, not runtime enforcement.
 ### MCP Server Not Loading
 - Ensure Node.js 18+ is installed
 - Check that npx is available in PATH
-- Run `claude mcp list` to verify server status
+- Run `copilot mcp list` to verify server status
 - Check server logs for errors
 
 ### API Key Issues
 - Exa: Verify key at https://dashboard.exa.ai
 - GitHub: Ensure token has required scopes (repo, read:org)
-- Re-run `claude mcp add` with correct credentials if needed
+- Azure DevOps: Run `az login` or check PAT permissions
+- Re-run `copilot mcp add` with correct credentials if needed
 
 ### Agents Still Using Built-in Tools
-- Restart Claude Code after configuration
+- Restart Copilot CLI after configuration
 - The built-in websearch will be deprioritized when exa is configured
-- Run `claude mcp list` to confirm servers are active
+- Run `copilot mcp list` to confirm servers are active
 
 ### Removing or Updating a Server
-- Remove: `claude mcp remove <server-name>`
+- Remove: `copilot mcp remove <server-name>`
 - Update: Remove the old server, then add it again with new configuration

package/skills/omc-setup/SKILL.md

@@ -79,7 +79,7 @@ EXAMPLES:
   /oh-my-copilot:omc-setup --global  # Update all projects
   /oh-my-copilot:omc-setup --force   # Re-run full setup wizard
 
-For more info: https://github.com/Yeachan-Heo/oh-my-copilot
+For more info: https://github.com/RobinNorberg/oh-my-copilot
 ```
 
 ## Pre-Setup Check: Already Configured?
@@ -156,13 +156,13 @@ bash "${CLAUDE_PLUGIN_ROOT}/scripts/setup-progress.sh" clear
 ## Phase Execution
 
 ### For `--local` or `--global` flags:
-Read the file at `${CLAUDE_PLUGIN_ROOT}/skills/omc-setup/phases/01-install-claude-md.md` and follow its instructions.
+Read the file at `${CLAUDE_PLUGIN_ROOT}/skills/omc-setup/phases/01-install-copilot-instructions.md` and follow its instructions.
 (The phase file handles early exit for flag mode.)
 
 ### For full setup (default or --force):
 Execute phases sequentially. For each phase, read the corresponding file and follow its instructions:
 
-1. **Phase 1 - Install CLAUDE.md**: Read `${CLAUDE_PLUGIN_ROOT}/skills/omc-setup/phases/01-install-claude-md.md` and follow its instructions.
+1. **Phase 1 - Install copilot-instructions.md**: Read `${CLAUDE_PLUGIN_ROOT}/skills/omc-setup/phases/01-install-copilot-instructions.md` and follow its instructions.
 
 2. **Phase 2 - Environment Configuration**: Read `${CLAUDE_PLUGIN_ROOT}/skills/omc-setup/phases/02-configure.md` and follow its instructions. Phase 2 must delegate HUD/statusLine setup to the `hud` skill; do not generate or patch `statusLine` paths inline here.
 

package/skills/omc-setup/phases/01-install-claude-md.md

@@ -46,7 +46,7 @@ For `local` installs inside a git repository, the script also seeds `.git/info/e
 
 **FALLBACK** if curl fails:
 Tell user to manually download from:
-https://raw.githubusercontent.com/Yeachan-Heo/oh-my-copilot/main/docs/CLAUDE.md
+https://raw.githubusercontent.com/RobinNorberg/oh-my-copilot/main/docs/CLAUDE.md
 
 **Note**: The downloaded CLAUDE.md includes Context Persistence instructions with `<remember>` tags for surviving conversation compaction.
 

package/skills/omc-setup/phases/04-welcome.md

@@ -134,7 +134,7 @@ gh auth status &>/dev/null
 **Before prompting, check if the repository is already starred:**
 
 ```bash
-gh api user/starred/Yeachan-Heo/oh-my-copilot &>/dev/null
+gh api user/starred/RobinNorberg/oh-my-copilot &>/dev/null
 ```
 
 **If already starred (exit code 0):**
@@ -147,15 +147,15 @@ Use AskUserQuestion:
 
 **Question:** "If you're enjoying oh-my-copilot, would you like to support the project by starring it on GitHub?"
 
-**Options:**
-1. **Yes, star it!** - Star the repository
-2. **No thanks** - Skip without further prompts
-3. **Maybe later** - Skip without further prompts
+**Options** (list in this exact order — Copilot CLI preselects the first option):
+1. **Yes, star it! (Recommended)** - Star the repository
+2. **Maybe later** - Skip without further prompts
+3. **No thanks** - Skip without further prompts
 
-If user chooses "Yes, star it!":
+If user chooses "Yes, star it! (Recommended)":
 
 ```bash
-gh api -X PUT /user/starred/Yeachan-Heo/oh-my-copilot 2>/dev/null && echo "Thanks for starring!" || true
+gh api -X PUT /user/starred/RobinNorberg/oh-my-copilot 2>/dev/null && echo "Thanks for starring!" || true
 ```
 
 **Note:** Fail silently if the API call doesn't work - never block setup completion.
@@ -165,7 +165,7 @@ gh api -X PUT /user/starred/Yeachan-Heo/oh-my-copilot 2>/dev/null && echo "Thank
 ```bash
 echo ""
 echo "If you enjoy oh-my-copilot, consider starring the repo:"
-echo "  https://github.com/Yeachan-Heo/oh-my-copilot"
+echo "  https://github.com/RobinNorberg/oh-my-copilot"
 echo ""
 ```
 

package/skills/plan/SKILL.md

@@ -2,7 +2,7 @@
 name: omc-plan
 description: Strategic planning with optional interview workflow
 argument-hint: "[--direct|--consensus|--review] [--interactive] [--deliberate] <task description>"
-pipeline: [deep-interview, omc-plan, autopilot]
+pipeline: [deep-interview, plan, autopilot]
 next-skill: autopilot
 handoff: .omcp/plans/ralplan-*.md
 level: 4

package/skills/project-session-manager/SKILL.md

@@ -50,7 +50,7 @@ Supported formats:
 {
   "aliases": {
     "omc": {
-      "repo": "Yeachan-Heo/oh-my-copilot",
+      "repo": "RobinNorberg/oh-my-copilot",
       "local": "~/Workspace/oh-my-copilot",
       "default_base": "main"
     }
@@ -564,7 +564,7 @@ if [[ ! -f ~/.psm/projects.json ]]; then
 {
   "aliases": {
     "omc": {
-      "repo": "Yeachan-Heo/oh-my-copilot",
+      "repo": "RobinNorberg/oh-my-copilot",
       "local": "~/Workspace/oh-my-copilot",
       "default_base": "main"
     }

package/skills/project-session-manager/psm.sh

@@ -85,7 +85,7 @@ Reference formats:
 
 Examples:
   psm review omc#123
-  psm fix Yeachan-Heo/oh-my-copilot#42
+  psm fix RobinNorberg/oh-my-copilot#42
   psm feature omc add-webhooks
   psm list
   psm attach omc:pr-123

package/skills/ralplan/SKILL.md

@@ -7,7 +7,7 @@ level: 4
 
 # Ralplan (Consensus Planning Alias)
 
-Ralplan is a shorthand alias for `/oh-my-copilot:omc-plan --consensus`. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work).
+Ralplan is a shorthand alias for `/oh-my-copilot:plan --consensus`. It triggers iterative planning with Planner, Architect, and Critic agents until consensus is reached, with **RALPLAN-DR structured deliberation** (short mode by default, deliberate mode for high-risk work).
 
 ## Usage
 
@@ -33,7 +33,7 @@ Ralplan is a shorthand alias for `/oh-my-copilot:omc-plan --consensus`. It trigg
 This skill invokes the Plan skill in consensus mode:
 
 ```
-/oh-my-copilot:omc-plan --consensus <arguments>
+/oh-my-copilot:plan --consensus <arguments>
 ```
 
 The consensus workflow: