copilot-tap-extension 2.0.6 → 2.0.8

package/README.md

@@ -212,13 +212,15 @@ The prompt fires immediately, then re-fires after each idle period. It stops aft
 
 **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.
+Use `/tap-goal` to create a goal loop that keeps advancing a concrete objective until it finishes, hits a blocker, or reaches its iteration budget. Goals are explicit completion contracts, control commands are user-owned, and the loop should stop itself only when the objective is actually complete, blocked, or budget-limited.
 
 ```
 /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.
+The skill creates a temporary PromptEmitter with a self-contained goal prompt. Conservative goals use an idle schedule; autopilot-style goals use a timed backoff schedule so the objective can keep nudging the session even when Copilot stays busy. Each iteration inspects its own emitter state, works against a six-part goal contract, records structured progress to its EventStream, validates when relevant, and stops the emitter when the goal is complete, blocked, or budget-limited.
+
+A strong goal names the outcome, verification surface, constraints, boundaries, iteration policy, and blocked stop condition. Completion requires an evidence audit against concrete files, tests, logs, benchmark output, generated artifacts, or research evidence.
 
 Goal loops default to 50 iterations unless you specify another budget.
 
@@ -228,7 +230,7 @@ Use `/tap-goal stop <name>` or `/tap-goal clear <name>` to stop a specific goal
 
 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.
+Because `/tap-goal` can use either idle or timed PromptEmitters, choose idle for conservative continuation and timed-autopilot mode for always-busy flows. Timed prompt deferrals do not consume the run budget; budget exhaustion still means "handoff needed," not success.
 
 **Tune the filter live**
 
@@ -286,6 +288,9 @@ PLAN.md                         # ubiquitous language and design decisions
 | [Provider guide](./docs/providers.md) | Add external tools to Copilot via the WebSocket provider interface |
 | [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/bin/install.mjs

@@ -268,6 +268,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

@@ -145,20 +145,36 @@ If the work is mostly reasoning rather than data collection, prefer a PromptEmit
 
 - prompt once for a background check (oneTime)
 - prompt + `every="<interval>"` for a fixed maintenance loop (timed)
-- prompt + `every="idle"` + `maxRuns` for autonomous goal loops with explicit iteration budgets (`/tap-goal`)
+- prompt + `every="idle"` + `maxRuns` for conservative autonomous goal loops with explicit iteration budgets (`/tap-goal`)
+- prompt + `everySchedule=[...]` + `maxRuns` for autopilot-compatible goals that need timed nudges while the session may stay busy
 
 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.
+PromptEmitter with a self-contained goal prompt and an explicit `maxRuns`
+budget. A strong goal is a six-part completion contract: outcome, verification
+surface, constraints, boundaries, iteration policy, and blocked stop condition.
+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`,
+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), prefer a timed PromptEmitter or hook-driven/session-injector delivery
-instead of relying on idle to trigger the next goal step.
+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.
+
+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