copilot-tap-extension 2.0.6 → 2.0.8

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

@@ -5,22 +5,23 @@ 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.
+Create a PromptEmitter that keeps advancing one explicit objective until the goal is achieved, blocked, stopped, or the iteration budget is reached.
 
-Use these goal-loop rules:
+Use Codex-style 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.
+- A goal is a **thread-scoped completion contract**, not a bigger prompt and not global memory.
+- Goals are explicit; do not infer one from ordinary one-shot tasks.
+- The goal contract should name six things: outcome, verification surface, constraints, boundaries, iteration policy, and blocked stop condition.
+- Completion must be evidence-based. The model may stop a goal as complete only after checking concrete evidence.
+- Runtime budget exhaustion is not proof of completion; it is a budget-limited stop/handoff state.
+- Control commands are user-owned (`status`, `stop`, `pause`, `resume`, `clear`, `replace`).
 
 ## 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`.
+2. A control command — `status`, `stop`, `pause`, `resume`, `clear`, or `replace`.
 3. Otherwise, the full invocation is the goal objective.
 
 Example:
@@ -33,16 +34,49 @@ 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 the objective is missing, ask the user for a concrete objective instead of guessing.
+
+If the objective is weak but the user's intent is clear, help strengthen it before creating the emitter. A strong goal contract has:
+
+```text
+Outcome: <desired end state>
+Verification surface: <test, benchmark, command output, artifact, or source material that proves completion>
+Constraints: <what must not regress>
+Boundaries: <files, tools, data, repos, or resources allowed>
+Iteration policy: <how to choose the next best action between attempts>
+Blocked stop condition: <what to report if no valid path remains and what would unlock progress>
+```
+
+If one of these fields is not explicitly provided but can be safely inferred from the objective and repository context, infer it and show it in the confirmation. If the verification surface or blocked stop condition cannot be inferred, ask for that missing detail.
 
 If another `goal-*` emitter already exists, ask before replacing it unless the user explicitly said `replace`.
 
+## Schedule choice
+
+Use a **PromptEmitter** in one of two modes:
+
+### Default: conservative idle goal
+
+Use `every = "idle"` when the user did not ask for autopilot-style busy-session progress.
+
+This matches Codex's conservative continuation model: continue only at safe idle boundaries.
+
+### Autopilot-compatible timed goal
+
+Use `everySchedule = ["2m", "5m", "10m"]` instead of `every = "idle"` when any of these are true:
+
+- the user mentions autopilot, busy sessions, continuous work, "keep nudging", or "while Copilot stays busy"
+- the user explicitly says to work autonomously in the current session
+- the current session is in autopilot mode and the goal is expected to advance while other work may be active
+
+Timed goal prompts use `session.send()` and can keep the objective visible even when the thread may not become idle often. The runtime preserves the iteration budget when a prompt send is deferred because the session is still busy.
+
 ## What to create
 
-Use `tap_start_emitter` to create a **PromptEmitter**:
+Use `tap_start_emitter`:
 
 - `prompt` — a fully self-contained goal-loop prompt using the template below.
-- `every = "idle"` — the loop advances only when the session is idle.
+- `every = "idle"` for default goals, OR `everySchedule = ["2m", "5m", "10m"]` for autopilot-compatible goals.
 - `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`.
@@ -58,36 +92,88 @@ Write the prompt so it stands alone because it will run later without the origin
 ```text
 You are running a tap-goal autonomous goal loop.
 
-Goal:
-<untrusted_objective>
+Goal contract:
+<untrusted_goal_contract>
+Objective:
 <objective>
-</untrusted_objective>
+
+Outcome:
+<desired end state>
+
+Verification surface:
+<test, benchmark, command output, artifact, or source material that proves completion>
+
+Constraints:
+<what must not regress>
+
+Boundaries:
+<files, tools, data, repos, or resources allowed>
+
+Iteration policy:
+<how to choose the next best action between attempts>
+
+Blocked stop condition:
+<what to report if no defensible path remains and what would unlock progress>
+</untrusted_goal_contract>
 
 Emitter name: <goal-emitter-name>
+EventStream name: <goal-emitter-name>
+Schedule mode: <idle | timed-autopilot>
 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>'.
+1. Call tap_list_emitters and locate the emitter entry 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:
+Continuation rules:
+- Treat the goal as a completion contract: work -> check evidence -> continue, complete, or stop blocked.
 - 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.
+- If only 1 iteration remains and the goal is not complete, do not start broad new work. Produce a budget-limited handoff instead.
+- Do not treat budget exhaustion or a lifecycle "reached run budget" message as success.
+- If this iteration makes no progress-producing tool calls beyond required status/ledger bookkeeping and does not change evidence, call `tap_post` with `channel='<goal-emitter-name>'` and a no-action handoff, then stop the emitter rather than spinning.
+- If the remaining delta is unchanged from the previous ITERATION RECORD, post a STALLED LOOP record and stop rather than spending the rest of the budget.
+
+Evidence-audit rules:
+- Before marking complete, identify the verification surface from the goal contract.
+- Check the evidence directly: test output, benchmark result, file content, diff, generated artifact, source material, or other concrete proof.
+- When the evidence is a workspace file, EventStream entry, or already-run command result, call `tap_verify_goal_output` or `tap_audit_claims` before GOAL COMPLETE.
+- Check listed constraints for regressions.
+- If the verification surface cannot be checked, treat the goal as blocked, not complete.
+- Completion requires an explicit evidence audit in the final response and in the EventStream.
+- Wrap machine-readable EventStream records with explicit markers:
+  `=== BEGIN_ITERATION_RECORD ===` / `=== END_ITERATION_RECORD ===`,
+  `=== BEGIN_GOAL_COMPLETE ===` / `=== END_GOAL_COMPLETE ===`,
+  `=== BEGIN_GOAL_BLOCKED ===` / `=== END_GOAL_BLOCKED ===`.
+
+Research/audit goal rules:
+- For research, reproduction, audit, or investigation goals, maintain a claim ledger.
+- Each ledger item should include: Claim, route attempted, evidence surface, status, and remaining uncertainty.
+- Use statuses such as confirmed, approximate-support, blocked, and uncertain. Do not flatten partial support into 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.
+2. If the goal is already achieved, first call `tap_verify_goal_output` or `tap_audit_claims` against the verification surface. If verification passes, call `tap_post` with `channel='<goal-emitter-name>'` and a marked GOAL COMPLETE evidence audit in `message`, then 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, first call `tap_post` with `channel='<goal-emitter-name>'` and a GOAL BLOCKED report in `message`, then call tap_stop_emitter for '<goal-emitter-name>' with scope='temporary', report the blocker, and stop.
+4. If this is the final iteration and the goal is not complete, do not start substantive new work. Call `tap_post` with `channel='<goal-emitter-name>'` and a BUDGET LIMITED summary in `message`: progress, evidence gathered, remaining work, recommended next `/tap-goal ...` invocation, and suggested fresh budget. Then leave a concise handoff.
+5. Otherwise, choose the next smallest useful action toward the goal that fits the remaining budget and perform it.
+6. Validate the action using the repository's existing checks when relevant.
+7. End by calling `tap_post` with `channel='<goal-emitter-name>'` and an ITERATION RECORD in `message` containing:
+   - iteration and budget used
+   - action taken
+   - evidence checked and result
+   - claim ledger entries when this is a research/audit goal
+   - remaining_delta or unchanged_delta status
+   - current status: progressing, complete, blocked, or budget-limited
+   - next best action
+   - branch, commit SHA, PR URL, run URL, or issue key when relevant
+8. End the user-visible response with the same concise progress update, what remains, and the next best step if the loop stops before completion.
 
 Safety rules:
 - Do not make unrelated changes.
+- Do not modify this goal emitter's own `every`, `everySchedule`, `maxRuns`, event filter, or goal contract while it is running unless the user explicitly asks.
+- Do not spawn additional emitters from this goal unless orchestration is explicitly part of the goal contract.
 - 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.
@@ -95,7 +181,7 @@ Safety rules:
 - 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`.
+Substitute the real objective, goal-contract fields, emitter name, schedule mode, and max iteration count before passing the prompt to `tap_start_emitter`.
 
 ## Required behavior
 
@@ -110,26 +196,36 @@ When this skill is invoked:
    - 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.
+4. If the user is asking to pause an existing goal:
+   - Explain that runtime-native pause is not supported because PromptEmitters do not preserve resumable internal state.
+   - Offer a simulated pause: call `tap_post` with a PAUSED NOTE containing objective, current status, progress, and resume guidance, then call `tap_stop_emitter`.
+   - Only stop the emitter if the user confirms; otherwise leave it running.
+5. If the user is asking to resume a goal:
+   - If they provide an objective, create a new `/tap-goal` loop from it.
+   - If they name a prior goal stream, inspect its history with `tap_stream_history` using `channel='<goal-stream-name>'`, recover the latest PAUSED NOTE or handoff if available, and create a new loop from that objective.
+   - If the objective is not clear, ask for it.
 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.
+7. Choose idle vs timed-autopilot schedule using the schedule rules above.
+8. Create the PromptEmitter using the template above.
 9. Confirm to the user:
    - Goal emitter name
    - EventStream name
    - Objective
+   - Verification surface
+   - Constraints
+   - Schedule mode (`idle` or `timed-autopilot`)
    - Max iteration count
-   - That it will advance when the session is idle and stop itself when complete or blocked
+   - That it will stop itself when complete, blocked, or budget-limited
 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`.
+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.
+- Budget exhaustion is a handoff state, not success.
 
 ## Persistence
 

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

@@ -7,6 +7,12 @@ user-invocable: true
 
 Create a timed or idle PromptEmitter with `tap_start_emitter`.
 
+If the request includes a completion condition such as "until", "keep going
+until", "stop when", "work until done", or "iterate until complete", do not
+create a plain loop. Redirect to `/tap-goal` semantics instead, because the
+user is asking for a completion contract with evidence, budget, and stop
+conditions rather than a recurring prompt.
+
 ## Expected input
 
 Interpret the invocation as:

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

@@ -63,9 +63,25 @@ Steps:
    - Lines that indicate important events (errors, warnings, state changes) → candidates for `{ "match": "...", "outcome": "inject" }`.
    - Lines that are never relevant at all → candidates for tighter keep/drop rules.
 4. Compare what you see against the current filter patterns for emitter '<command-emitter-name>'.
-5. Only update if the evidence clearly justifies a change (signal-to-noise is poor or a pattern is clearly wrong).
-6. If an update is needed, call tap_set_event_filter with the revised patterns for emitter '<command-emitter-name>'.
-7. Do not report your findings to the user unless you made a change. If you made a change, send one short message describing what you updated and why.
+5. Use this shared contract when judging the stream:
+   - stream_purpose: <why the user wanted this monitor>
+   - signal_vocabulary: errors, warnings, failures, state changes, explicit success/failure markers
+   - noise_vocabulary: timestamps-only, heartbeat-only, repeated unchanged status, empty pings
+6. Only update if the evidence clearly justifies a change (signal-to-noise is poor or a pattern is clearly wrong).
+7. If an update is needed, call tap_set_event_filter with the revised patterns for emitter '<command-emitter-name>'.
+8. Always call tap_post with channel '<stream-name>' and a REVIEW RECORD wrapped in markers:
+   === BEGIN_REVIEW_RECORD ===
+   {
+     "reviewed_at": "<ISO timestamp>",
+     "entries_examined": <number>,
+     "issue_type": "noise_pattern|missed_signal|over_filtering|duplicate_inject|no_change",
+     "patterns_changed": ["short label for each change"],
+     "remaining_noise_delta": ["what still looks noisy or uncertain"],
+     "signal_vocabulary": ["terms treated as signal"],
+     "noise_vocabulary": ["terms treated as noise"]
+   }
+   === END_REVIEW_RECORD ===
+9. Do not report your findings to the user unless you made a change. If you made a change, send one short message describing what you updated and why.
 ```
 
 Substitute the real emitter name and stream name into the prompt before passing it to `tap_start_emitter`.

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

@@ -0,0 +1,81 @@
+---
+name: tap-orchestrate
+description: "Create a coordinator PromptEmitter for multi-agent tap workflows with role-specific sub-emitters, gated handoffs, and evidence records. Use when the user asks to orchestrate multiple agents, roles, workstreams, or parallel implementation/review/test phases."
+argument-hint: "<objective and roles>"
+user-invocable: true
+---
+
+Create a coordinator PromptEmitter that manages a multi-agent workflow using tap
+emitters and EventStreams.
+
+Use this for work that naturally decomposes into roles such as planner,
+implementer, reviewer, tester, documenter, provider-builder, or release
+coordinator. Do not use it for a single straightforward task.
+
+## What to create
+
+Use `tap_start_emitter` to create a **coordinator PromptEmitter**:
+
+- Name: `orchestrate-<objective-slug>`.
+- Prompt: a self-contained orchestration contract.
+- Schedule: `everySchedule = ["2m", "5m", "10m"]`.
+- `lifespan = "temporary"` unless the user explicitly asks for persistence.
+- `ownership = "modelOwned"`.
+- `subscribe = false`.
+- `maxRuns = 50` unless the user gives a budget.
+
+The coordinator may create role-specific PromptEmitters only when the role has a
+clear deliverable and verification surface. Each role emitter should write its
+handoff to an EventStream with a stable name:
+
+```text
+orchestrate-<objective>-<role>
+```
+
+## Coordinator prompt contract
+
+The coordinator prompt must include:
+
+```text
+Objective: <user objective>
+Roles: <role list, deliverables, and verification surface>
+Gate policy:
+- Do not hand off to the next role until required artifacts or EventStream notes exist.
+- Read role EventStreams with tap_stream_history before deciding a gate is satisfied.
+- If parallel work is safe, create independent role emitters in the same iteration.
+- If a role blocks, post ORCHESTRATION BLOCKED and stop the coordinator.
+Audit trail:
+- After every decision, call tap_post to the coordinator stream with ORCHESTRATION RECORD:
+  role, gate, evidence checked, decision, next handoff.
+Safety:
+- Do not spawn duplicate role emitters.
+- Do not mutate another role's scope unless the coordinator evidence supports it.
+- Stop all role emitters when the orchestration completes or blocks.
+```
+
+## Required behavior
+
+1. Parse the objective and any requested roles.
+2. If roles are missing, infer a minimal role set from the objective:
+   planner, implementer, reviewer, validator.
+3. Create the coordinator PromptEmitter only; do not immediately create role
+   emitters in the setup turn. The coordinator will create them when it runs.
+4. Confirm:
+   - coordinator emitter name and stream
+   - roles
+   - gate policy
+   - max iteration budget
+
+## Good role patterns
+
+- **planner**: produce plan and boundaries; verification is a plan note.
+- **implementer**: make code/doc changes; verification is diff + focused checks.
+- **reviewer**: inspect changes; verification is review note with findings.
+- **validator**: run tests/build/evals; verification is command evidence.
+- **release**: bump/push/publish only after validator passes.
+
+## When not to use
+
+Do not create orchestration for a normal `/tap-goal` objective that one agent can
+complete directly. Orchestration adds coordination cost and should only be used
+when parallel roles or gated handoffs are genuinely useful.

package/dist/version.json

@@ -1,3 +1,3 @@
 {
-  "version": "2.0.6"
+  "version": "2.0.8"
 }

package/package.json

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