oh-my-githubcopilot 1.4.1 → 1.8.0-alpha.f50f59a

package/skills/omp-reference/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: omp-reference
+description: OMP agent catalog, available tools, team pipeline routing, commit protocol, and skills registry. Auto-loads when delegating to agents, using OMP tools, orchestrating teams, making commits, or invoking skills.
+user-invocable: false
+---
+
+# OMP Reference
+
+Use this built-in reference when you need detailed OMP catalog information that does not need to live in every session context.
+
+## Agent Catalog
+
+Prefix: `omp:`. See `agents/*.md` for full prompts.
+
+| # | ID | Tier | Tools | Role |
+|---|-----|------|-------|------|
+| 1 | `orchestrator` | high | TaskList, SendMessage, Glob, Grep | Top-level coordinator; never writes |
+| 2 | `explorer` | standard | Glob, Grep, Read | Fast codebase surveys, pattern finding |
+| 3 | `planner` | high | Read, Write, TaskCreate | Architecture, sequencing, risk assessment |
+| 4 | `executor` | standard | Read, Write, Edit, Bash | Implementation, refactoring, complex changes |
+| 5 | `verifier` | standard | Bash, Read, Glob | Testing, diagnostics, evidence collection |
+| 6 | `writer` | standard | Read, Write, Glob | Documentation, README, API docs |
+| 7 | `reviewer` | high | Read, Glob, Grep, LSP | Code review, quality gates |
+| 8 | `designer` | high | WebFetch, Figma tools | UI/UX, design system, Figma integration |
+| 9 | `researcher` | standard | WebSearch, WebFetch | External docs, benchmarking, options analysis |
+| 10 | `tester` | standard | Bash, Read, Write | Test writing, execution, CI integration |
+| 11 | `debugger` | high | Bash, Read, LSP, Grep | Error diagnosis, crash analysis |
+| 12 | `architect` | high | Read, Write, Glob | System design, cross-cutting concerns |
+| 13 | `security-reviewer` | high | Grep, Glob, Read | Vulnerability scanning, dependency audit |
+| 14 | `simplifier` | high | Read, Edit, Grep | Code reuse, quality, efficiency improvements |
+| 15 | `test-engineer` | standard | Bash, Read, Write | Test authoring, coverage analysis |
+| 16 | `critic` | high | Read, Grep, Write | Plan review, gap analysis, improvement suggestions |
+| 17 | `tracer` | high | Bash, Read, Grep | Causal investigation, root cause analysis |
+| 18 | `scientist` | high | Read, Write, Bash | Experimental design, hypothesis testing |
+| 19 | `code-reviewer` | standard | Read, Glob, LSP | PR reviews, style enforcement |
+| 20 | `document-specialist` | standard | Read, Write, Grep | Technical docs, API docs, guides |
+| 21 | `qa-tester` | standard | Bash, Read, Write | QA testing, regression verification |
+| 22 | `git-master` | standard | Bash, Read, Grep | Atomic commits, history management |
+| 23 | `analyst` | high | Read, Grep | Requirements analysis, gap identification |
+
+## Model Routing
+
+| Tier | When to use |
+|------|-------------|
+| high (opus) | Security, architecture, complex multi-file refactors, PR reviews, plan challenges |
+| standard (sonnet) | Feature implementation, testing, documentation, debugging |
+| fast (haiku) | Quick lookups, simple edits, documentation updates, glob/grep passes |
+
+## Tools Reference
+
+### Team runtime
+- `TaskCreate`, `TaskList`, `TaskGet`, `TaskUpdate`
+- `SendMessage`
+
+### OMP state
+- `state_read`, `state_write`, `state_clear`, `state_list_active`, `state_get_status`
+
+### Notepad
+- `notepad_read`, `notepad_write_priority`, `notepad_write_working`, `notepad_write_manual`
+
+### Project memory
+- `project_memory_read`, `project_memory_write`, `project_memory_add_note`, `project_memory_add_directive`
+
+### Code intelligence
+- LSP: `lsp_hover`, `lsp_goto_definition`, `lsp_find_references`, `lsp_diagnostics`, and related helpers
+- AST: `ast_grep_search`, `ast_grep_replace`
+- Utility: `python_repl`
+
+## Skills Registry
+
+Invoke built-in workflows via `/omp:<name>`.
+
+### Workflow skills
+- `autopilot` — full autonomous execution from idea to working code
+- `ralph` — persistence loop until completion with verification
+- `ultrawork` — high-throughput parallel execution
+- `team` — coordinated team orchestration
+- `ultraqa` — QA cycle: test, verify, fix, repeat
+- `omp-plan` — planning workflow
+- `pipeline` — sequential pipeline mode with strict phase ordering
+- `swarm` — swarm orchestration with multiple agents and shared state
+- `ecomode` — token budget mode; prioritize completion over expansion
+- `trace` — evidence-driven causal tracing lane
+- `deep-interview` — Socratic ambiguity-gated requirements workflow
+- `graphify` — knowledge graph generation from any input
+- `graphwiki` — LLM wiki with graph-backed knowledge base
+
+### Utility skills
+- `research` / `autoresearch:` — research and investigation workflow
+- `omp-doctor` — diagnose and fix omp installation issues
+- `omp-setup` — install or refresh omp plugin
+- `setup` — install routing entrypoint
+- `mcp-setup` — configure MCP servers
+- `hud` — HUD display options
+- `note` — quick note capture
+- `learner` — extract learned skill from session
+- `spending` — token spend tracking
+- `release` — release assistant
+- `configure-notifications` — notification integrations
+- `wiki` — persistent LLM wiki
+- `psm` — Plugin State Manager control
+
+### Keyword triggers
+- `"autopilot"→autopilot`
+- `"ralph"→ralph`
+- `"ulw"→ultrawork`
+- `"ralplan"→omp-plan`
+- `"deep interview"→deep-interview`
+- `"autoresearch:"→research`
+- `"pipeline"→pipeline`
+- `"swarm"→swarm`
+- `"eco"→ecomode`
+- `"plan"→omp-plan`
+- Team orchestration is explicit via `/team`.
+
+## Team Pipeline
+
+Stages: `team-plan` → `team-prd` → `team-exec` → `team-verify` → `team-fix` (loop).
+
+- Use `team-fix` for bounded remediation loops.
+- Prefer team mode when independent parallel lanes justify the coordination overhead.
+
+## Execution Mode Handling
+
+| Mode | Trigger | Behavior |
+|------|---------|----------|
+| `autopilot` | `/autopilot:` | Autonomous end-to-end execution |
+| `ralph` | `/ralph:` | Self-referential loop with verification |
+| `ultrawork` | `/ulw:` | Parallel execution engine |
+| `team` | `/team:` | Coordinated multi-agent session on shared task list |
+| `ecomode` | `/eco:` | Token budget mode |
+| `swarm` | `/swarm:` | Multiple agents with shared state |
+| `pipeline` | `/pipeline:` | Sequential pipeline with strict phase ordering |
+| `plan` | `/plan:` | Strategic planning via planner agent |
+
+## Commit Protocol
+
+Use git trailers to preserve decision context in every commit message.
+
+### Format
+- Intent line first: why the change was made
+- Optional body with context and rationale
+- Structured trailers when applicable
+
+### Common trailers
+- `Constraint:` active constraint shaping the decision
+- `Rejected:` alternative considered | reason for rejection
+- `Directive:` forward-looking warning or instruction
+- `Confidence:` `high` | `medium` | `low`
+- `Scope-risk:` `narrow` | `moderate` | `broad`
+- `Not-tested:` known verification gap
+
+### Example
+```text
+feat(skills): add research skill to omp plugin
+
+Adds autoresearch workflow with structured output format and
+agent routing to researcher/explorer/architect as appropriate.
+
+Constraint: No model routing parameters allowed in omp skills
+Confidence: high
+Scope-risk: narrow
+```
+
+## State Paths
+
+All OMP runtime state uses `.omp/` prefix:
+- `.omp/state/` — active state files
+- `.omp/state/sessions/{sessionId}/` — per-session state
+- `.omp/notepad.md` — shared notepad
+- `.omp/project-memory.json` — persistent project memory
+- `.omp/plans/` — planning artifacts
+- `.omp/research/` — research outputs
+- `.omp/logs/` — execution logs

package/skills/omp-setup/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: omp-setup
+description: OMP onboarding and configuration wizard
+trigger: "setup:, /setup, /omp:setup, /omp-setup"
+autoinvoke: false
+---
 # Skill: OMP-Setup
 
 ## Metadata
@@ -13,6 +19,8 @@
 
 Orchestrates the OMP setup wizard:
 - Phase 1: Base OMP setup (directory structure, first-run guidance)
+- Phase 1.5: Merge required Copilot experimental features into `~/.copilot/config.json`
+- Phase 1.5: Ensure Copilot `statusLine` points at OMP's packaged status-line script without overwriting an existing custom command
 - Phase 2: MCP server configuration
 
 ## Interface
@@ -34,4 +42,10 @@ export function deactivate(): void
 
 ## Implementation
 
-Spawns `bin/omp.mjs setup [args]`. No persistent resources are maintained.
+Spawns `bin/omp.mjs setup [args]` from the packaged plugin root so setup works from arbitrary workspaces.
+The spawned process receives default OMP Copilot setup env values:
+
+- `OMP_COPILOT_REQUIRED_EXPERIMENTAL_FEATURES`
+- `OMP_COPILOT_STATUS_LINE_COMMAND`
+
+No persistent resources are maintained by the skill wrapper itself.

package/skills/pipeline/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: pipeline
+description: Sequential stage-based execution pipeline
+trigger: "pipeline:, /pipeline, /omp:pipeline"
+autoinvoke: false
+---
 # Skill: Pipeline
 
 ## Metadata

package/skills/psm/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: psm
+description: Plugin State Manager operations
+trigger: "psm:, /psm, /omp:psm"
+autoinvoke: false
+---
 # Skill: PSM
 
 ## Metadata

package/skills/ralph/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: ralph
+description: Persistence loop with architect verification gate
+trigger: "ralph:, /ralph, /omp:ralph"
+autoinvoke: false
+---
 # Skill: Ralph
 
 ## Metadata

package/skills/ralplan/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: ralplan
+description: Consensus planning entrypoint that auto-gates vague ralph/autopilot/team requests before execution
+trigger: "/omp:ralplan"
+autoinvoke: false
+---
+
+# Ralplan (Consensus Planning Alias)
+
+Ralplan is a shorthand alias for `/omp: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
+
+```
+/omp:ralplan "task description"
+```
+
+## Flags
+
+- `--interactive`: Enables user prompts at key decision points (draft review in step 2 and final approval in step 6). Without this flag the workflow runs fully automated — Planner → Architect → Critic loop — and outputs the final plan without asking for confirmation.
+- `--deliberate`: Forces deliberate mode for high-risk work. Adds pre-mortem (3 scenarios) and expanded test planning (unit/integration/e2e/observability). Without this flag, deliberate mode can still auto-enable when the request explicitly signals high risk (auth/security, migrations, destructive changes, production incidents, compliance/PII, public API breakage).
+
+## Usage with interactive mode
+
+```
+/omp:ralplan --interactive "task description"
+```
+
+## Behavior
+
+This skill invokes the Plan skill in consensus mode:
+
+```
+/omp:plan --consensus <arguments>
+```
+
+The consensus workflow:
+1. **Planner** creates initial plan and a compact **RALPLAN-DR summary** before review:
+   - Principles (3-5)
+   - Decision Drivers (top 3)
+   - Viable Options (>=2) with bounded pros/cons
+   - If only one viable option remains, explicit invalidation rationale for alternatives
+   - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)
+2. **User feedback** *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the draft plan **plus the Principles / Drivers / Options summary** before review (Proceed to review / Request changes / Skip review). Otherwise, automatically proceed to review.
+3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and (when possible) synthesis — **await completion before step 4**. In deliberate mode, Architect should explicitly flag principle violations.
+
+   > Adopt the Architect role: "Review this plan for architectural soundness. Provide the strongest steelman antithesis against the favored option, at least one real tradeoff tension, and a synthesis path where possible."
+
+4. **Critic** evaluates against quality criteria — run only after step 3 completes. Critic must enforce principle-option consistency, fair alternatives, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. In deliberate mode, Critic must reject missing/weak pre-mortem or expanded test plan.
+
+   > Adopt the Critic role: "Evaluate this plan. Verify principle-option consistency, fair alternative exploration, risk mitigation clarity, testable acceptance criteria, and concrete verification steps. Explicitly reject shallow alternatives, driver contradictions, vague risks, or weak verification."
+
+5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict (`ITERATE` or `REJECT`) MUST run the same full closed loop:
+   a. Collect Architect + Critic feedback
+   b. Revise the plan with Planner
+   c. Return to Architect review
+   d. Return to Critic evaluation
+   e. Repeat this loop until Critic returns `APPROVE` or 5 iterations are reached
+   f. If 5 iterations are reached without `APPROVE`, present the best version to the user
+6. On Critic approval *(--interactive only)*: If `--interactive` is set, use `AskUserQuestion` to present the plan with approval options:
+   - **Approve and implement via team** (Recommended) — proceed via `omp:team`
+   - **Approve and execute via ralph** — proceed via `omp:ralph`
+   - **Clear context and implement** — compact context first, then `omp:ralph` with the saved plan file
+   - **Request changes** — return to step 1
+   - **Reject** — discard the plan entirely
+   Final plan must include ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups).
+   Otherwise (non-interactive), output the final plan and stop.
+7. *(--interactive only)* User chooses: Approve (team or ralph), Request changes, or Reject
+8. *(--interactive only)* On approval: invoke `omp:team` for parallel team execution (recommended) or `omp:ralph` for sequential execution — never implement directly
+
+> **Important:** Steps 3 and 4 MUST run sequentially. Do NOT issue both agent reviews in the same parallel batch. Always await the Architect result before issuing the Critic evaluation.
+
+Follow the omp-plan skill's full documentation for consensus mode details.
+
+---
+
+## Pre-Execution Gate
+
+### Why the Gate Exists
+
+Execution modes (omp:ralph, omp:autopilot, omp:team, omp:ultrawork) spin up heavy multi-agent orchestration. When launched on a vague request like "ralph improve the app", agents have no clear target — they waste cycles on scope discovery that should happen during planning, often delivering partial or misaligned work that requires rework.
+
+The ralplan-first gate intercepts underspecified execution requests and redirects them through the ralplan consensus planning workflow. This ensures:
+- **Explicit scope**: A PRD defines exactly what will be built
+- **Test specification**: Acceptance criteria are testable before code is written
+- **Consensus**: Planner, Architect, and Critic agree on the approach
+- **No wasted execution**: Agents start with a clear, bounded task
+
+### Good vs Bad Prompts
+
+**Passes the gate** (specific enough for direct execution):
+- `ralph fix the null check in src/hooks/bridge.ts:326`
+- `autopilot implement issue #42`
+- `team add validation to function processKeywordDetector`
+- `ralph do:\n1. Add input validation\n2. Write tests\n3. Update README`
+- `ultrawork add the user model in src/models/user.ts`
+
+**Gated — redirected to ralplan** (needs scoping first):
+- `ralph fix this`
+- `autopilot build the app`
+- `team improve performance`
+- `ralph add authentication`
+- `ultrawork make it better`
+
+**Bypass the gate** (when you know what you want):
+- `force: ralph refactor the auth module`
+- `! autopilot optimize everything`
+
+### When the Gate Does NOT Trigger
+
+The gate auto-passes when it detects **any** concrete signal. You do not need all of them — one is enough:
+
+| Signal Type | Example prompt | Why it passes |
+|---|---|---|
+| File path | `ralph fix src/hooks/bridge.ts` | References a specific file |
+| Issue/PR number | `ralph implement #42` | Has a concrete work item |
+| camelCase symbol | `ralph fix processKeywordDetector` | Names a specific function |
+| PascalCase symbol | `ralph update UserModel` | Names a specific class |
+| snake_case symbol | `team fix user_model` | Names a specific identifier |
+| Test runner | `ralph npm test && fix failures` | Has an explicit test target |
+| Numbered steps | `ralph do:\n1. Add X\n2. Test Y` | Structured deliverables |
+| Acceptance criteria | `ralph add login - acceptance criteria: ...` | Explicit success definition |
+| Error reference | `ralph fix TypeError in auth` | Specific error to address |
+| Code block | `ralph add: \`\`\`ts ... \`\`\`` | Concrete code provided |
+| Escape prefix | `force: ralph do it` or `! ralph do it` | Explicit user override |
+
+### End-to-End Flow Example
+
+1. User types: `ralph add user authentication`
+2. Gate detects: execution keyword (`ralph`) + underspecified prompt (no files, functions, or test spec)
+3. Gate redirects to **ralplan** with message explaining the redirect
+4. Ralplan consensus runs:
+   - **Planner** creates initial plan (which files, what auth method, what tests)
+   - **Architect** reviews for soundness
+   - **Critic** validates quality and testability
+5. On consensus approval, user chooses execution path:
+   - **omp:team**: parallel coordinated agents (recommended)
+   - **omp:ralph**: sequential execution with verification
+6. Execution begins with a clear, bounded plan
+
+### Troubleshooting
+
+| Issue | Solution |
+|-------|----------|
+| Gate fires on a well-specified prompt | Add a file reference, function name, or issue number to anchor the request |
+| Want to bypass the gate | Prefix with `force:` or `!` (e.g., `force: ralph fix it`) |
+| Gate does not fire on a vague prompt | The gate only catches prompts with <=15 effective words and no concrete anchors; add more detail or use `/omp:ralplan` explicitly |
+| Redirected to ralplan but want to skip planning | In the ralplan workflow, say "just do it" or "skip planning" to transition directly to execution |

package/skills/release/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: release
+description: Guided release workflow and automation
+trigger: "release:, /release, /omp:release"
+autoinvoke: false
+---
 # Skill: Release
 
 ## Metadata

package/skills/research/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: research
+description: Research and investigation skills. Use for "research this", "investigate", "find out", "autoresearch:", and "deep dive".
+trigger: /omp:research
+autoinvoke: false
+---
+
+## Skill: research
+
+Conduct thorough research and investigation on topics.
+
+## When to Use
+
+- Unknown or unfamiliar topics
+- Need comprehensive understanding
+- Fact-finding missions
+- Competitive analysis
+- Technology evaluation
+
+## Research Process
+
+### 1. Define Scope
+- What do we need to know?
+- How deep to go?
+- What sources to check?
+- Timeline constraints
+
+### 2. Gather Sources
+- Official documentation
+- Expert opinions
+- Community discussions
+- Real-world usage
+
+### 3. Synthesize
+- Extract key information
+- Identify patterns
+- Note contradictions
+- Build understanding
+
+### 4. Analyze
+- Compare options
+- Evaluate trade-offs
+- Assess quality
+- Rate confidence
+
+### 5. Present
+- Clear findings
+- Source attribution
+- Confidence levels
+- Recommendations
+
+## Source Types
+
+### Primary Sources
+- Official documentation
+- Source code
+- API specifications
+- Original research
+
+### Secondary Sources
+- Expert blogs
+- Technical articles
+- Tutorial content
+- Community posts
+
+### Social Proof
+- Usage statistics
+- Adoption rates
+- Community size
+- Support availability
+
+## Research Methods
+
+### Code Archaeology
+- Read source code
+- Trace execution
+- Find patterns
+- Understand internals
+
+### Documentation Mining
+- API docs
+- README files
+- Change logs
+- Migration guides
+
+### Web Research
+- Search engines
+- Specialized forums
+- Stack Overflow
+- GitHub issues
+
+### Expert Consultation
+- Ask practitioners
+- Find case studies
+- Get benchmarks
+- Collect opinions
+
+## Agent Routing
+
+Delegate research tasks to the `researcher` agent (standard tier). For deep code archaeology, use the `explorer` agent. For architecture trade-offs, escalate to the `architect` agent.
+
+State for in-progress research is stored under `.omp/research/`.
+
+## Output Format
+
+```
+## Research: {topic}
+
+### Scope
+**Questions:** {what we need to know}
+**Depth:** {surface/deep/comprehensive}
+**Timeline:** {constraints}
+
+### Sources Consulted
+| Source | Type | Relevance | Confidence |
+|--------|------|-----------|------------|
+| {source} | {type} | High | High |
+
+### Findings
+
+#### Topic 1: {title}
+**Summary:** {what we learned}
+**Source:** {source}
+**Confidence:** {level}
+
+#### Topic 2: {title}
+...
+
+### Analysis
+{comparisons and synthesis}
+
+### Recommendations
+1. **{rec}** — {rationale}
+
+### Confidence
+- **Overall:** {level}
+- **Gaps:** {what we don't know}
+
+### Further Research
+{what would improve confidence}
+```
+
+## Constraints
+
+- Verify information independently
+- Note source quality
+- Be clear about confidence
+- Avoid bias in selection
+- Cite your sources