copilot-tap-extension 2.0.7 → 2.0.9

package/README.md

@@ -63,7 +63,7 @@ npx copilot-tap-extension
 npx copilot-tap-extension --local
 ```
 
-This installs the bundled extension, the `/tap-loop` skill, the `/tap-monitor` skill, the `/tap-goal` skill, and the agent instructions to the appropriate Copilot directory. Run `npx copilot-tap-extension --help` for all options.
+This installs the bundled extension, `/tap-loop`, `/tap-monitor`, `/tap-goal`, `/tap-orchestrate`, and the agent instructions to the appropriate Copilot directory. Run `npx copilot-tap-extension --help` for all options.
 
 To update to the latest version, re-run the same command with `--force`:
 
@@ -258,6 +258,7 @@ The canvas is bounded and redacted: it keeps recent diagnostic evidence without
   skills/tap-loop/                  # /tap-loop skill for scheduled and idle prompts
   skills/tap-monitor/               # /tap-monitor skill for self-tuning command monitors
   skills/tap-goal/                  # /tap-goal skill for autonomous goal loops
+  skills/tap-orchestrate/           # /tap-orchestrate skill for coordinator/role workflows
   skills/tap-create-provider/       # /tap-create-provider skill for scaffolding external tool providers
   copilot-instructions.md       # agent guidance for using this extension
 src/
@@ -289,6 +290,8 @@ PLAN.md                         # ubiquitous language and design decisions
 | [Use cases and patterns](./docs/use-cases.md) | Recipes for deploy watchers, PR monitors, log tailers, and more |
 | [Copilot SDK canvas surfaces](./docs/recipes/copilot-sdk-canvas.md) | Local SDK findings for extension-owned canvas UI surfaces |
 | [Codex Goals lessons for tap-goal](./docs/recipes/codex-goals-for-tap-goal.md) | Goal-loop contract, evidence audit, and autopilot scheduling guidance |
+| [Tap control-plane roadmap](./docs/recipes/tap-control-plane-roadmap.md) | Implemented and deferred control-plane slices from the Codex/Copilot audit |
+| [Provider integration patterns](./docs/recipes/provider-integration-patterns.md) | Jira/GitHub, CI auto-fix, code review, SAST, and browser/Detour provider recipes |
 | [Evals](./docs/evals.md) | Run or extend the automated test suite |
 | [Copilot instructions](./src/copilot-instructions.md) | Understand or customize how the agent uses this extension |
 | [Implementation plan](./PLAN.md) | Ubiquitous language and naming conventions for contributors |

package/SOUL.md

@@ -0,0 +1,51 @@
+# Why this repository exists
+
+This repository is an agentic operating layer for Copilot CLI.
+
+It is not just a collection of tap tools. It is a substrate that turns Copilot
+from a turn-by-turn chat agent into a persistent, observable, interruptible, and
+extensible worker that can notice background signals, remember live state, react
+to events, and keep working against explicit goals.
+
+## What it represents
+
+1. **A nervous system for Copilot CLI**
+
+   EventEmitters, EventStreams, EventFilters, and SessionInjectors are sensory
+   and routing infrastructure. They let Copilot perceive background reality:
+   logs, builds, PRs, providers, browser state, goals, and diagnostics.
+
+2. **A control plane for safe autonomy**
+
+   The point is not blind autonomy. The point is bounded autonomy with budgets,
+   evidence checks, filters, ownership, persistence, diagnostics, and stop
+   conditions. This is why `/tap-goal`, diagnostics, event filters, and
+   ownership rules matter.
+
+3. **A research lab for extensibility**
+
+   The repository is where discoveries from Codex, Copilot CLI, the SDK,
+   canvases, autopilot, tasks, providers, MCP, and runtime RPCs become working
+   primitives.
+
+4. **A bridge between external systems and the agent**
+
+   Providers, Detour, command emitters, browser integrations, CI watchers,
+   Jira/GitHub workflows, and local scripts all point to the same idea: Copilot
+   should not be trapped inside the terminal transcript. It should be connected
+   to the developer environment.
+
+5. **A portable personal agent runtime**
+
+   Publishing matters because this behavior should survive sessions, machines,
+   reloads, and CLI upgrades. This is not a scratchpad; it is a reusable
+   extension layer.
+
+## The underlying thesis
+
+Copilot CLI is powerful, but too episodic by default. This repository gives it
+durable senses, live workflow memory, safe autonomy, and extension points so it
+can operate like a real engineering assistant inside the user's environment.
+
+In short: **tap is the middleware between raw Copilot intelligence and real-world
+engineering operations.**

package/bin/install.mjs

@@ -43,6 +43,7 @@ Installs:
   skills/tap-create-provider/SKILL.md The /tap-create-provider skill for scaffolding providers
   skills/tap-monitor/SKILL.md         The /tap-monitor skill for self-tuning command monitors
   skills/tap-goal/SKILL.md            The /tap-goal skill for autonomous goal loops
+  skills/tap-orchestrate/SKILL.md     The /tap-orchestrate skill for multi-agent workflows
   copilot-instructions.md         Agent instructions for using ※ tap
 `);
 }
@@ -139,7 +140,7 @@ function removeDeprecatedSkills(targetRoot) {
   }
 
   if (state.removedAny) {
-    console.log(`\n  Use the new namespaced commands: /tap-loop  /tap-monitor  /tap-create-provider`);
+    console.log(`\n  Use the new namespaced commands: /tap-loop  /tap-monitor  /tap-goal  /tap-orchestrate  /tap-create-provider`);
   }
 
   return state.allOk;
@@ -268,6 +269,11 @@ function buildAncillaryArtifacts(targetRoot) {
       dest: path.join(targetRoot, "skills", "tap-goal", "SKILL.md"),
       label: "skills/tap-goal/SKILL.md"
     },
+    {
+      src: path.join(distDir, "skills", "tap-orchestrate", "SKILL.md"),
+      dest: path.join(targetRoot, "skills", "tap-orchestrate", "SKILL.md"),
+      label: "skills/tap-orchestrate/SKILL.md"
+    },
     {
       src: path.join(distDir, "copilot-instructions.md"),
       dest: path.join(targetRoot, "copilot-instructions.md"),

package/dist/copilot-instructions.md

@@ -161,11 +161,26 @@ switching into wrap-up mode when the remaining iteration budget is low, posting
 structured iteration records to their EventStream with `tap_post`, and stopping
 themselves when complete or blocked. Completion requires an evidence audit
 against concrete files, tests, logs, benchmark output, or generated artifacts.
+Use `tap_verify_goal_output` and `tap_audit_claims` when the verification surface
+is a workspace file, stream entry, or already-run command result.
 If the session may stay continuously busy (for example in autopilot-heavy
 flows), use a timed PromptEmitter with a backoff schedule such as
 `everySchedule=["2m","5m","10m"]` instead of relying on idle to trigger the next
 goal step.
 
+Use `tap_get_session_state` before mode-sensitive work. It reads the current
+Copilot mode, model/reasoning effort, tasks, schedules, open canvases, and UI
+capabilities without mutating the session.
+Use `tap_set_session_mode` only when the user has explicitly requested a mode
+change or the goal contract requires it; it requires confirmation text and
+should be treated as a user-visible safety-sensitive action.
+Use `tap_query_records` to inspect structured session-workspace records such as
+`traces` and `stream-posts` when EventStream prose is not precise enough.
+
+For genuinely multi-role work, prefer `/tap-orchestrate`: create one coordinator
+PromptEmitter that gates role-specific sub-emitters using EventStream handoffs.
+Do not use orchestration for tasks a single `/tap-goal` loop can complete.
+
 ## Borrow from the official SDK examples
 
 When working on the extension itself, not just using its emitter tools, prefer these SDK patterns: