oh-my-copilot 5.1.0 → 5.6.1

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "oh-my-copilot",
       "description": "Multi-agent orchestration for GitHub Copilot CLI with intelligent model routing across agents and skills. Zero learning curve. Maximum power.",
-      "version": "5.1.0",
+      "version": "5.6.1",
       "author": {
         "name": "Robin Norberg"
       },
@@ -25,5 +25,5 @@
       ]
     }
   ],
-  "version": "5.1.0"
+  "version": "5.6.1"
 }

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "oh-my-copilot",
-  "version": "5.1.0",
+  "version": "5.6.1",
   "description": "Multi-agent orchestration system for GitHub Copilot CLI",
   "author": {
     "name": "oh-my-copilot contributors"
@@ -18,7 +18,10 @@
   ],
   "skills": [
     "./skills/ai-slop-cleaner/",
+    "./skills/agent-doc-discipline/",
+    "./skills/architecture-survey/",
     "./skills/ask/",
+    "./skills/intent/",
     "./skills/ask-navigator/",
     "./skills/autopilot/",
     "./skills/autoresearch/",
@@ -29,15 +32,19 @@
     "./skills/deep-interview/",
     "./skills/deep-review/",
     "./skills/deepinit/",
+    "./skills/diagram/",
     "./skills/discover/",
     "./skills/drydock/",
     "./skills/execute/",
     "./skills/external-context/",
     "./skills/graph/",
+    "./skills/harbor/",
     "./skills/hud/",
     "./skills/launch/",
     "./skills/loft/",
+    "./skills/map/",
     "./skills/minimal-code-discipline/",
+    "./skills/minimal-prose-discipline/",
     "./skills/omc-ado-auto-review/",
     "./skills/omc-ado-review/",
     "./skills/omc-ado-setup/",
@@ -51,10 +58,12 @@
     "./skills/omc-gh-triage/",
     "./skills/omc-setup/",
     "./skills/plan/",
+    "./skills/pr/",
     "./skills/project-session-manager/",
     "./skills/ralph/",
     "./skills/ralph-experiment/",
     "./skills/ralplan/",
+    "./skills/refit/",
     "./skills/release/",
     "./skills/remember/",
     "./skills/research/",
@@ -62,6 +71,7 @@
     "./skills/self-improve/",
     "./skills/skill/",
     "./skills/skillify/",
+    "./skills/tdd/",
     "./skills/team/",
     "./skills/trace/",
     "./skills/ultragoal/",

package/README.md

@@ -28,18 +28,24 @@
 [![License: MIT](https://img.shields.io/badge/License-MIT-green.svg)](https://opensource.org/licenses/MIT)
 <br/>This work is based on [oh-my-claudecode](https://github.com/Yeachan-Heo/oh-my-claudecode) by Yeachan Heo, but with a Copilot CLI focus.
 
-> **v5.0.0** rebases the fork onto upstream oh-my-claudecode v5.0.2 and renames the
+> **v5.6.1** brings the software factory, headless intake and `omg ralph afk` to Copilot under a scoped AFK permission profile ([upgrade guide](docs/MIGRATION.md#v550--v561-fork-upgrade-guide)).
+> **v5.5.0** makes the fork a native GitHub Copilot CLI plugin (hooks, agents,
+> `copilot` team workers) and renames `COPILOT_CONFIG_DIR` to `COPILOT_HOME`.
+> **v5.0.0** rebased the fork onto upstream oh-my-claudecode v5.0.2 and renamed the
 > CLI to **`omg`**. Runtime state moved to `.omg/` and configuration to
-> `.copilot/omg.jsonc`. Upgrading from v4? Read the
+> `.copilot/omg.jsonc`. Upgrading? Read the
 > [Migration Guide](docs/MIGRATION.md).
 
 ## Quick Start
 
 ```bash
-# Step 1: Install
+# Step 1: Install (inside a Copilot CLI session)
 /plugin marketplace add https://github.com/RobinNorberg/oh-my-copilot
 /plugin install oh-my-copilot@omc
-# or
+# or from your shell
+copilot plugin marketplace add RobinNorberg/oh-my-copilot
+copilot plugin install oh-my-copilot@omc
+# plus the terminal CLI (omg)
 npm i -g oh-my-copilot@latest
 
 # Step 2: Setup
@@ -54,6 +60,12 @@ autopilot: build a todo-app
 # If you enjoy the output, give the repo a ⭐ and tell a friend
 ```
 
+> **Requirements:** Node.js on PATH (every hook runs `node`; under Copilot a
+> hook that cannot start blocks the tool call). The host config directory is
+> `~/.copilot`, or `$COPILOT_HOME` when set; OMC follows Copilot's own
+> variable. Update with `copilot plugin update oh-my-copilot@omc`; uninstall
+> with `copilot plugin uninstall oh-my-copilot@omc`.
+
 > **Known npm warning:** `npm i -g oh-my-copilot@latest` may print `deprecated prebuild-install@7.1.3`.
 > This comes from the `better-sqlite3` native-addon dependency
 > (`better-sqlite3 -> prebuild-install`); `prebuild-install@7.1.3` is still the latest

package/agents/debugger.md

@@ -31,7 +31,12 @@ level: 3
   <Constraints>
     - Reproduce BEFORE investigating. If you cannot reproduce, find the conditions first.
     - Read error messages completely. Every word matters, not just the first line.
+    - Before testing any hypothesis, write 3-5 ranked candidates with the evidence for each; then test them one at a time. Ranking prevents anchoring on the first plausible story.
     - One hypothesis at a time. Do not bundle multiple fixes.
+    - Tag temporary debug output with a unique marker (`[DEBUG-<4hex>]`) so cleanup at the end is a single grep.
+    - Redact secrets and credentials (`<REDACTED>`) from logs and traces before they enter any report, issue, or commit.
+    - If the bug cannot be covered by a regression test at any correct seam, report that absence as the finding — do not invent a seam to make the test pass; hand it to architecture-survey (or refit) as a deepening candidate.
+    - Where the repo's commit conventions allow, record the confirmed hypothesis in the fix's commit message so the next debugger starts from it.
     - Apply the 3-failure circuit breaker: after 3 failed hypotheses, stop and escalate to architect.
     - No speculation without evidence. "Seems like" and "probably" are not findings.
     - Fix with minimal diff. Do not refactor, rename variables, add features, optimize, or redesign.
@@ -44,7 +49,7 @@ level: 3
     ### Runtime Bug Investigation
     1) REPRODUCE: Can you trigger it reliably? What is the minimal reproduction? Consistent or intermittent?
     2) GATHER EVIDENCE (parallel): Read full error messages and stack traces. Check recent changes with git log/blame. Find working examples of similar code. Read the actual code at error locations.
-    3) HYPOTHESIZE: Compare broken vs working code. Trace data flow from input to error. Document hypothesis BEFORE investigating further. Identify what test would prove/disprove it.
+    3) HYPOTHESIZE: Compare broken vs working code. Trace data flow from input to error. Rank 3-5 candidate hypotheses by evidence fit BEFORE testing any, then test them one at a time. Identify what test would prove/disprove each.
     4) FIX: Recommend ONE change. Predict the test that proves the fix. Check for the same pattern elsewhere in the codebase.
     5) CIRCUIT BREAKER: After 3 failed hypotheses, stop. Question whether the bug is actually elsewhere. Escalate to architect for architectural analysis.
 
@@ -124,6 +129,7 @@ level: 3
     - Refactoring while fixing: "While I'm fixing this type error, let me also rename this variable and extract a helper." No. Fix the type error only.
     - Architecture changes: "This import error is because the module structure is wrong, let me restructure." No. Fix the import to match the current structure.
     - Incomplete verification: Fixing 3 of 5 errors and claiming success. Fix ALL errors and show a clean build.
+    - Seam invention: Forcing a regression test through internals because no seam fits. Report the missing seam as a finding instead.
     - Over-fixing: Adding extensive null checking, error handling, and type guards when a single type annotation would suffice. Minimum viable fix.
     - Wrong language tooling: Running `tsc` on a Go project. Always detect language first.
   </Failure_Modes_To_Avoid>
@@ -145,6 +151,8 @@ level: 3
     - Does the build command exit with code 0 (for build errors)?
     - Did I change the minimum number of lines?
     - Did I avoid refactoring, renaming, or architectural changes?
+    - Did I redact secrets from all pasted logs and traces?
+    - If no correct seam exists for a regression test, did I report that as the finding?
     - Are all errors fixed (not just some)?
   </Final_Checklist>
 </Agent_Prompt>

package/agents/explore.md

@@ -46,8 +46,10 @@ disallowedTools: Write, Edit
     Reading entire large files is the fastest way to exhaust the context window. Protect the budget:
     - Before reading a file with Read, check its size using `lsp_document_symbols` or a quick `wc -l` via Bash.
     - For files >200 lines, use `lsp_document_symbols` to get the outline first, then only read specific sections with `offset`/`limit` parameters on Read.
-    - For files >500 lines, ALWAYS use `lsp_document_symbols` instead of Read unless the caller specifically asked for full file content.
+    - For files >500 lines, ALWAYS use `lsp_document_symbols` instead of Read.
     - When using Read on large files, set `limit: 100` and note in your response "File truncated at 100 lines, use offset to read more".
+    - This is enforced, not advisory: a Read with no `offset`/`limit` against a file over either configured budget (`context.readBudget.maxBytes`, default 45000; `context.readBudget.maxLines`, default 1500) is warned once and denied afterwards. Binaries (images, archives, PDFs, and anything with NUL bytes in its first 8 KB) are skipped by the gate, and a PDF read carrying `pages` counts as targeted. A bare `cat <file>` via Bash is treated the same way; piped or redirected `cat` and `sed -n '1,200p'` are targeted reads and stay allowed.
+    - When a full read is genuinely required, allowlist the path via `context.readBudget.allowPaths` or set `OMC_READ_BUDGET=off` for the run. Read caps its own output at 25,000 tokens, so a full read of a very large file returns a partial view that still reads like a complete answer.
     - Batch reads must not exceed 5 files in parallel. Queue additional reads in subsequent rounds.
     - Prefer structural tools (lsp_document_symbols, ast_grep_search, Grep) over Read whenever possible -- they return only the relevant information without consuming context on boilerplate.
   </Context_Budget>

package/bridge/claude-md-coordinator.cjs

@@ -875,8 +875,8 @@ function executeClaudeMdTransaction(request) {
 
 // src/cli/claude-md-coordinator.ts
 var CLAUDE_MD_COORDINATOR_SCHEMA_VERSION = 1;
-var COMPILED_ENGINE_VERSION = true ? "5.1.0" : "";
-var COMPILED_SOURCE_SHA256 = true ? "5d7782a036d51a8d5ed54e55ac68b809d6ba9dd41c273577e4ace8ed751f87a5" : "";
+var COMPILED_ENGINE_VERSION = true ? "5.6.1" : "";
+var COMPILED_SOURCE_SHA256 = true ? "fb6c0d0edbe4a7d3cc1f71af3f52e1cfebb00acce7ac344ed91b16b4edd3f1c1" : "";
 function runClaudeMdCoordinatorHandshake() {
   if (!COMPILED_ENGINE_VERSION || !COMPILED_SOURCE_SHA256) {
     return { exitCode: 2, response: coordinatorError(2, "Coordinator build handshake is unavailable") };