copilot-tap-extension 2.0.0 → 2.0.2

package/README.md

@@ -62,7 +62,7 @@ npx copilot-tap-extension
 npx copilot-tap-extension --local
 ```
 
-This installs the bundled extension, the `/tap-loop` skill, the `/tap-monitor` skill, and the agent instructions to the appropriate Copilot directory. Run `npx copilot-tap-extension --help` for all options.
+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.
 
 To update to the latest version, re-run the same command with `--force`:
 
@@ -111,6 +111,8 @@ Once inside the session, describe what you want in natural language. You can als
 
 > _"/tap-monitor tail -f /var/log/app.log"_
 
+> _"/tap-goal migrate the repo to the new API and keep going until tests pass"_
+
 > _"Tail the API logs, inject errors, drop health checks"_
 
 The agent translates these into emitter and filter configurations behind the scenes.
@@ -205,6 +207,26 @@ Use `/tap-loop idle` to re-run a prompt whenever the session has nothing else to
 
 The prompt fires immediately, then re-fires after each idle period. It stops after reaching the iteration limit.
 
+**Work toward a goal autonomously**
+
+Use `/tap-goal` to create an idle goal loop that keeps advancing a concrete objective until it finishes, hits a blocker, or reaches its iteration budget. Goals are explicit, control commands are user-owned, and the loop should stop itself only when the objective is actually complete or blocked.
+
+```
+/tap-goal migrate the repo to the new API and keep going until tests pass
+```
+
+The skill creates a temporary idle PromptEmitter with a self-contained goal prompt. Each iteration inspects its own emitter state, assesses progress, takes the next small action, validates when relevant, and stops the emitter when the goal is complete or blocked. As the remaining iteration budget gets low, the prompt shifts into wrap-up mode so it leaves a useful handoff instead of starting broad new work.
+
+Goal loops default to 50 iterations unless you specify another budget.
+
+Use `/tap-goal status` to list current goal emitters.
+
+Use `/tap-goal stop <name>` or `/tap-goal clear <name>` to stop a specific goal emitter. If there is exactly one active `goal-*` emitter, the skill can stop it without a name; otherwise run `/tap-goal status` first and then stop the goal by name.
+
+Use `/tap-goal resume <objective>` to start a new loop from an objective. Stopped goal loops do not preserve resumable internal state; resuming creates a new emitter from the supplied objective.
+
+Because `/tap-goal` uses an idle PromptEmitter, it is best when the session has natural idle gaps. For always-busy autopilot-style flows, prefer a timed prompt loop or hook/session-injector based delivery so follow-up context can still reach the session.
+
 **Tune the filter live**
 
 The recommended approach is a **keep-all bootstrap**: start with no EventFilter rules so all output flows into the stream. Read the stream history to learn what the output looks like, then add rules progressively:
@@ -224,6 +246,7 @@ Rules can be added or changed while the emitter is running. You never need to re
   extensions/tap/extension.mjs  # extension entry point (loads the runtime)
   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-create-provider/       # /tap-create-provider skill for scaffolding external tool providers
   copilot-instructions.md       # agent guidance for using this extension
 src/

package/bin/install.mjs

@@ -42,6 +42,7 @@ Installs:
   skills/tap-loop/SKILL.md            The /tap-loop skill for prompt-based loops
   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
   copilot-instructions.md         Agent instructions for using ※ tap
 `);
 }
@@ -218,6 +219,11 @@ function install(flags) {
       dest: path.join(targetRoot, "skills", "tap-monitor", "SKILL.md"),
       label: "skills/tap-monitor/SKILL.md"
     },
+    {
+      src: path.join(distDir, "skills", "tap-goal", "SKILL.md"),
+      dest: path.join(targetRoot, "skills", "tap-goal", "SKILL.md"),
+      label: "skills/tap-goal/SKILL.md"
+    },
     {
       src: path.join(distDir, "copilot-instructions.md"),
       dest: path.join(targetRoot, "copilot-instructions.md"),

package/dist/copilot-instructions.md

@@ -38,7 +38,7 @@ Reach for **PromptEmitters** when the user wants the agent itself to periodicall
    - add `{ "match": "<noise>", "outcome": "drop" }` rules first
    - add `{ "match": "<signal>", "outcome": "inject" }` rules for important events
    - use `{ "match": ".*", "outcome": "keep" }` as a catch-all to store everything else
-8. If the work should repeat inside the session, add `runInterval`.
+8. If the work should repeat inside the session, add `every="<interval>"` or `everySchedule=[...]`.
 9. If the emitter proves useful across sessions, persist it and switch ownership to `ownership="userOwned"` unless the user explicitly wants ongoing model control.
 
 ## Recommended tool sequence
@@ -65,7 +65,7 @@ Use these tools in roughly this order:
 ### For prompt-driven maintenance
 
 - use `prompt` instead of `command` (creates a PromptEmitter)
-- add `runInterval` for a fixed session-scoped timed schedule
+- add `every="<interval>"` for a fixed session-scoped timed schedule
 - use oneTime PromptEmitter when the user wants a background check only once
 - keep the first prompt concise and action-oriented
 
@@ -144,17 +144,29 @@ Prefer normalized output over raw dumps. EventFilters work much better when each
 If the work is mostly reasoning rather than data collection, prefer a PromptEmitter:
 
 - prompt once for a background check (oneTime)
-- prompt + `runInterval` for a fixed maintenance loop (timed)
+- prompt + `every="<interval>"` for a fixed maintenance loop (timed)
+- prompt + `every="idle"` + `maxRuns` for autonomous goal loops with explicit iteration budgets (`/tap-goal`)
 
 This is the closest analogue to Claude's session-scoped `/tap-loop` behavior in this extension.
 
+For "keep working until done" requests, prefer `/tap-goal`: create an
+idle PromptEmitter with a self-contained goal prompt, an explicit `maxRuns`
+budget, and instructions to stop itself when complete or blocked. Goals must be
+explicit user requests; do not infer them from ordinary one-shot tasks, and do
+not treat budget exhaustion as successful completion. Goal prompts should
+self-steer by reading their own emitter state with `tap_list_emitters` and
+switching into wrap-up mode when the remaining iteration budget is low.
+If the session may stay continuously busy (for example in autopilot-heavy
+flows), prefer a timed PromptEmitter or hook-driven/session-injector delivery
+instead of relying on idle to trigger the next goal step.
+
 ## Borrow from the official SDK examples
 
 When working on the extension itself, not just using its emitter tools, prefer these SDK patterns:
 
 - use `session.log()` for user-visible diagnostics; never rely on `console.log()`
 - use hooks such as `onUserPromptSubmitted`, `onPreToolUse`, `onPostToolUse`, and `onErrorOccurred` to shape behavior
-- use `session.on(...)` listeners for tool lifecycle, assistant messages, session idle, and errors when you need event-driven behavior
+- use `session.on(...)` listeners for event-driven behavior such as `session.idle`, `assistant.message`, `tool.execution_start`, `tool.execution_complete`, `session.error`, and `session.start`/`session.resume` when resuming persistent goal state
 - use `session.send()` for asynchronous follow-up prompts and `session.sendAndWait()` only when the extension must wait for an answer
 - use `onPermissionRequest` and `onUserInputRequest` for guarded flows instead of custom ad hoc prompting
 - use `fs.watch` or `watchFile` when the extension should react to manual file edits or workspace artifacts such as `plan.md`

package/dist/extension.mjs

@@ -3736,13 +3736,21 @@ var SOURCE = Object.freeze({
 // src/session/port.mjs
 function createSessionPort(initialSession = null) {
   let session2 = initialSession;
+  let idle = false;
   function attach(nextSession) {
     session2 = nextSession ?? null;
+    idle = false;
     return session2;
   }
   function current() {
     return session2;
   }
+  function setIdle(nextIdle) {
+    idle = nextIdle === true;
+  }
+  function isIdle() {
+    return Boolean(session2) && idle === true;
+  }
   async function safeLog(message, options) {
     if (!session2) {
       return;
@@ -3787,6 +3795,8 @@ function createSessionPort(initialSession = null) {
   return {
     attach,
     current,
+    setIdle,
+    isIdle,
     log,
     send,
     sendAndWait,
@@ -3797,7 +3807,7 @@ function createSessionPort(initialSession = null) {
 
 // src/util/normalize.mjs
 function normalizeName(value, fallback = "") {
-  const normalized = String(value ?? "").trim().toLowerCase().replace(/[^a-z0-9._-]+/g, "-").replace(/^-+|-+$/g, "");
+  const normalized = String(value ?? "").normalize("NFKC").trim().toLowerCase().replace(/[^\p{L}\p{N}\p{M}._-]+/gu, "-").replace(/^-+|-+$/g, "");
   return normalized || fallback;
 }
 function normalizeLifespan(value, fallback = LIFESPAN.TEMPORARY) {
@@ -4543,6 +4553,24 @@ function readLines(input, onLine) {
 
 // src/emitter/lifecycle.mjs
 function createLifecycle({ lineRouter, sessionPort }) {
+  function isIdleEmitter(emitter) {
+    return emitter?.runSchedule === RUN_SCHEDULE.IDLE;
+  }
+  function shouldSkipIdleScheduling(emitter) {
+    return emitter.stopRequested || emitter.inFlight || !isIdleEmitter(emitter) || isTerminalEmitterStatus(emitter.status);
+  }
+  function shouldSkipActivityCancellation(emitter) {
+    return !isIdleEmitter(emitter) || isTerminalEmitterStatus(emitter.status);
+  }
+  function waitForNextIdle(emitter) {
+    emitter.status = EMITTER_STATUS.WAITING;
+  }
+  function prepareIdleEmitter(emitter) {
+    waitForNextIdle(emitter);
+    if (sessionPort.isIdle()) {
+      scheduleIteration(emitter, IDLE_PROMPT_DELAY_MS);
+    }
+  }
   function wireStreams(emitter) {
     const child = emitter.process;
     emitter.stdoutReader = readLines(child.stdout, (line) => {
@@ -4671,6 +4699,10 @@ function createLifecycle({ lineRouter, sessionPort }) {
     if (emitter.stopRequested || emitter.inFlight) {
       return;
     }
+    if (isIdleEmitter(emitter) && !sessionPort.isIdle()) {
+      emitter.status = EMITTER_STATUS.WAITING;
+      return;
+    }
     emitter.inFlight = true;
     emitter.status = EMITTER_STATUS.RUNNING;
     emitter.runCount += 1;
@@ -4703,6 +4735,10 @@ function createLifecycle({ lineRouter, sessionPort }) {
         );
         return;
       }
+      if (isIdleEmitter(emitter)) {
+        waitForNextIdle(emitter);
+        return;
+      }
       emitter.status = EMITTER_STATUS.WAITING;
       scheduleIteration(emitter, nextDelay(emitter));
       return;
@@ -4746,6 +4782,10 @@ function createLifecycle({ lineRouter, sessionPort }) {
       emitter,
       `Emitter '${emitter.name}' queued ${emitter.emitterType} work (${scheduleLabel}) with ${describeEmitterWork(emitter)}.${firstRunLabel}`
     );
+    if (isIdleEmitter(emitter)) {
+      prepareIdleEmitter(emitter);
+      return;
+    }
     scheduleIteration(emitter, initialDelayMs);
   }
   function start(emitter) {
@@ -4778,7 +4818,25 @@ function createLifecycle({ lineRouter, sessionPort }) {
       emitter.process.kill();
     }
   }
-  return { start, stop };
+  function onSessionIdle(emitter) {
+    if (shouldSkipIdleScheduling(emitter)) {
+      return;
+    }
+    scheduleIteration(emitter, IDLE_PROMPT_DELAY_MS);
+  }
+  function onSessionActivity(emitter) {
+    if (shouldSkipActivityCancellation(emitter)) {
+      return;
+    }
+    if (emitter.timer) {
+      clearTimeout(emitter.timer);
+      emitter.timer = null;
+    }
+    if (!emitter.inFlight) {
+      emitter.status = EMITTER_STATUS.WAITING;
+    }
+  }
+  return { start, stop, onSessionIdle, onSessionActivity };
 }
 
 // src/emitter/supervisor.mjs
@@ -4914,6 +4972,16 @@ function createEmitterSupervisor({ streams, configStore, notifications, sessionP
   function list() {
     return [...emitters.values()].sort((left, right) => left.name.localeCompare(right.name));
   }
+  function onSessionIdle() {
+    for (const emitter of emitters.values()) {
+      lifecycle.onSessionIdle(emitter);
+    }
+  }
+  function onSessionActivity() {
+    for (const emitter of emitters.values()) {
+      lifecycle.onSessionActivity(emitter);
+    }
+  }
   function has(name) {
     return emitters.has(normalizeName(name));
   }
@@ -4927,7 +4995,9 @@ function createEmitterSupervisor({ streams, configStore, notifications, sessionP
     updateEventFilter,
     list,
     has,
-    get
+    get,
+    onSessionIdle,
+    onSessionActivity
   };
 }
 
@@ -6352,6 +6422,13 @@ function createProviderGateway(options = {}) {
 // src/tap-runtime.mjs
 function createCopilotChannelsRuntime(options = {}) {
   let baseCwd = options.cwd ?? process.cwd();
+  let cleanupSessionListeners = () => {
+  };
+  const resetSessionListeners = () => {
+    cleanupSessionListeners();
+    cleanupSessionListeners = () => {
+    };
+  };
   const getBaseCwd = () => baseCwd;
   const setBaseCwd = (next) => {
     baseCwd = next;
@@ -6386,9 +6463,41 @@ function createCopilotChannelsRuntime(options = {}) {
     sessionPort.registerTools(mergedTools);
     void sessionPort.reloadExtension();
   });
+  const wireSessionListeners = (session2) => {
+    resetSessionListeners();
+    const unsubscribers = [
+      session2.on("session.idle", () => {
+        sessionPort.setIdle(true);
+        supervisor.onSessionIdle();
+      })
+    ];
+    for (const eventType of [
+      "session.start",
+      "session.resume",
+      "user.message",
+      "assistant.message",
+      "tool.execution_start",
+      "tool.execution_complete",
+      "session.error"
+    ]) {
+      unsubscribers.push(session2.on(eventType, () => {
+        sessionPort.setIdle(false);
+        supervisor.onSessionActivity();
+      }));
+    }
+    cleanupSessionListeners = () => {
+      for (const unsubscribe of unsubscribers) {
+        try {
+          unsubscribe?.();
+        } catch {
+        }
+      }
+    };
+  };
   return {
     attachSession: (nextSession) => {
       sessionPort.attach(nextSession);
+      wireSessionListeners(nextSession);
       if (!gateway.isRunning()) {
         try {
           gateway.start();
@@ -6399,6 +6508,7 @@ function createCopilotChannelsRuntime(options = {}) {
     tools,
     hooks,
     stopAllEmitters: async () => {
+      resetSessionListeners();
       gateway.stop();
       await supervisor.stopAll();
     },

package/dist/skills/tap-goal/SKILL.md

@@ -0,0 +1,136 @@
+---
+name: tap-goal
+description: "Run an autonomous goal loop. Use when the user says 'goal', 'keep working until done', 'work autonomously', 'iterate until complete', or wants long-horizon progress toward an objective."
+argument-hint: "<objective>"
+user-invocable: true
+---
+
+Create an idle PromptEmitter with `tap_start_emitter` that keeps advancing one explicit objective until the goal is achieved, blocked, stopped, or the iteration limit is reached.
+
+Use these goal-loop rules:
+
+- Goals are explicit; do not infer one from ordinary user tasks.
+- A bare goal command reports the current goal state.
+- Control commands are user-owned (`status`, `stop`, `resume`, `clear`, `replace`).
+- The model can complete a goal only when the objective is actually achieved.
+- Runtime budget exhaustion is not proof of completion; only achieving the objective marks completion.
+
+## Expected input
+
+Interpret the invocation as one of:
+
+1. No arguments — show current `goal-*` emitters with `tap_list_emitters`.
+2. A control command — `status`, `stop`, `resume`, `clear`, or `replace`.
+3. Otherwise, the full invocation is the goal objective.
+
+Example:
+
+```text
+/tap-goal migrate the repo to the new API and keep going until tests pass
+```
+
+means:
+
+- `objective = "migrate the repo to the new API and keep going until tests pass"`
+
+If the objective is missing or too vague, ask the user for a concrete objective instead of guessing.
+
+If another `goal-*` emitter already exists, ask before replacing it unless the user explicitly said `replace`.
+
+## What to create
+
+Use `tap_start_emitter` to create a **PromptEmitter**:
+
+- `prompt` — a fully self-contained goal-loop prompt using the template below.
+- `every = "idle"` — the loop advances only when the session is idle.
+- `scope = "temporary"`, `managedBy = "modelOwned"`.
+- `subscribe = false` — PromptEmitter output already reaches the session through `session.send()`.
+- `maxRuns` — use the user's requested budget if provided; otherwise default to `50`.
+- Name the emitter after the objective, prefixed with `goal-` (for example `goal-api-migration`).
+- The EventStream is created automatically with the same name.
+
+Do not set EventFilter rules. PromptEmitters dispatch their prompts fire-and-forget through `session.send()`, so their output bypasses line filtering. EventFilter rules would not affect goal-loop output.
+
+## Goal-loop prompt template
+
+Write the prompt so it stands alone because it will run later without the original chat context:
+
+```text
+You are running a tap-goal autonomous goal loop.
+
+Goal:
+<untrusted_objective>
+<objective>
+</untrusted_objective>
+
+Emitter name: <goal-emitter-name>
+Iteration budget: <max-runs>
+
+At the start of each iteration:
+1. Call tap_list_emitters and locate the emitter entry in the returned list whose name is exactly '<goal-emitter-name>'.
+2. Read its current runs and maxRuns values.
+3. If the emitter is missing, report that the goal loop is no longer running and stop.
+4. Estimate remaining iterations.
+
+Auto-steering rules:
+- If remaining iterations are low (3 or fewer), switch into wrap-up mode.
+- In wrap-up mode, prefer finishing the smallest high-value task, validating what changed, and leaving a precise handoff.
+- If only 1 iteration remains and the goal is not complete, do not start broad new work. Leave the best concise handoff you can.
+- Do not treat budget exhaustion as success.
+
+On this iteration:
+1. Briefly assess current progress toward the goal and the remaining iteration budget.
+2. If the goal is already achieved, call tap_stop_emitter for '<goal-emitter-name>' with scope='temporary', report that the goal is complete, and stop.
+3. If the goal is blocked by missing information, permissions, failing external systems, or an unsafe action, report the blocker, call tap_stop_emitter for '<goal-emitter-name>' with scope='temporary', and stop.
+4. Otherwise, choose the next smallest useful action toward the goal that fits the remaining budget and perform it.
+5. Validate the action using the repository's existing checks when relevant.
+6. End with a concise progress update, what remains, and the best next step if the loop stops before completion.
+
+Safety rules:
+- Do not make unrelated changes.
+- Do not mark the goal complete unless the objective is actually achieved and no required work remains.
+- Do not treat reaching the iteration budget as success.
+- Do not continue if the next step requires explicit user approval.
+- Prefer small reversible steps.
+- Stop yourself when done or blocked; do not rely on the user to notice.
+```
+
+Substitute the real objective, emitter name, and max iteration count before passing the prompt to `tap_start_emitter`.
+
+## Required behavior
+
+When this skill is invoked:
+
+1. Parse the goal objective and any explicit iteration budget.
+2. For a bare `/tap-goal` or `/tap-goal status`, call `tap_list_emitters`, summarize any `goal-*` emitters, and stop.
+3. If the user is asking to stop, cancel, or clear an existing goal:
+   - call `tap_list_emitters` and look for `goal-*` emitters
+   - if the user named a specific goal emitter, stop that one
+   - otherwise, if exactly one `goal-*` emitter exists, stop it
+   - if none exist, report that no goal loop is running
+   - if multiple exist and the user did not name one, ask them to choose one after showing `/tap-goal status`
+   - when you do stop one, call `tap_stop_emitter` with its exact name and confirm that it will not fire again
+4. If the user is asking to pause an existing goal, explain that pausing is not supported for goal loops because idle PromptEmitters do not preserve resumable internal state. Offer to stop the loop instead. Only call `tap_stop_emitter` if they confirm; otherwise take no action and leave the goal loop running.
+5. If the user is asking to resume a goal, create a new `/tap-goal` loop with the resumed objective; ask for the objective if it is not clear.
+6. Before creating a new goal, check for existing `goal-*` emitters. If one exists and the user did not explicitly ask to replace it, ask for confirmation before starting another goal loop.
+7. If the user wants the loop to keep nudging the session even while Copilot stays busy in autopilot-style work, explain that idle goal loops may not fire until the session becomes idle. Suggest a timed PromptEmitter or hook/session-injector based delivery instead.
+8. Otherwise, create the idle PromptEmitter using the template above.
+9. Confirm to the user:
+   - Goal emitter name
+   - EventStream name
+   - Objective
+   - Max iteration count
+   - That it will advance when the session is idle and stop itself when complete or blocked
+10. Stop there. Do not immediately perform the first goal iteration unless the user explicitly asks you to start working now.
+
+## Iteration budget
+
+Idle goal loops must always have `maxRuns`.
+
+- If the user gives a budget, use it.
+- Otherwise, default to `50`.
+- If the objective is large, tell the user they can invoke `/tap-goal` again with a higher budget.
+
+## Persistence
+
+Default goal loops are temporary. If the user explicitly asks for a goal to survive future sessions, set `scope = "persistent"` and `autoStart = true`, but warn that long-running persistent goals should be used carefully because they will resume automatically on the next session start.

package/dist/skills/tap-loop/SKILL.md

@@ -36,7 +36,7 @@ means:
 - `every = "idle"` (re-runs whenever the session is idle)
 - `prompt = "check the deploy"`
 
-Timed emitters fire immediately, then repeat on the interval. Idle emitters fire immediately, then re-fire whenever the session becomes idle again (with a short delay between runs to avoid monopolizing the session).
+Timed emitters fire immediately, then repeat on the interval. Idle emitters wait for the session to become idle, then re-fire on later `session.idle` transitions (with a short delay between runs to avoid monopolizing the session).
 
 ## Max iterations
 

package/dist/version.json

@@ -1,3 +1,3 @@
 {
-  "version": "2.0.0"
+  "version": "2.0.2"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "copilot-tap-extension",
-  "version": "2.0.0",
+  "version": "2.0.2",
   "description": "Copilot CLI extension for background event emitters, event streams, and session injection.",
   "type": "module",
   "license": "MIT",