Bump version to 2.0.76 and update needsBotReviewPromptTemplate for improved guidance

Co-authored-by: Copilot <copilot@github.com>

Author: goodguy1963

.github/agents/ceo.agent.md

@@ -90,7 +90,7 @@ You are the top-level orchestrator for this repository.
   - **never use the terminal, run tasks, or execute code directly — treat any missing tool or execution surface as a routing signal to a specialist, not a reason to attempt it yourself**
   - use `Prefab UI Specialist` when the request is mainly about live Prefab rendering, Prefab UI JSON, dashboards, forms, charts, settings panels, or API-backed Prefab views
   - use `Planner` first when tradeoffs, architecture, sequencing, or validation is unclear — or when the request is research-first or evidence-heavy (deep dive, competitive analysis, market research)
-  - use `Planner` for approved bounded implementation work
+  - use `Remediation Implementer` for approved bounded implementation work
   - use `Validate Run` through `Remediation Implementer` when returned work needs an explicit closeout check against acceptance criteria — not when Planner or the implementing specialist already ran validation
   - use `Documentation Specialist` when documentation or knowledge alignment is the main task
   - use `Cockpit Todo Expert` first when Todo Cockpit cards, approvals, task drafts, or Task List entries need durable attention

.github/agents/cockpit-todo-expert.agent.md

@@ -29,16 +29,16 @@ You own Todo Cockpit and linked Task List todo coordination for this repository.
 - Manage linked task drafts and Task List entries when approved work needs execution-state alignment.
 - Preserve the board as the user/AI communication hub.
 - Reflect real execution state without turning the board into a transient scratchpad.
-- Translate strategic direction from `CEO` into durable board state without collapsing implementation detail into the wrong layer.
+- Translate strategic direction from `CEO` into durable board state without pushing implementation detail into the wrong layer.
 
 ## Boundaries
 
 - Do not act as the implementation specialist for unrelated code work.
 - Do not let the orchestrator bypass Todo Cockpit for durable approvals.
 - Do not let the session-local `todo` checklist replace Todo Cockpit or Task List state.
 - If a new workflow pattern emerges, document it in `.github/agents/system/knowledge/todo-cockpit.md`.
-- Do not edit Cockpit persistence files directly when MCP tools can express the change.
-- Use `cockpit_` tools for cards and `scheduler_` tools for Task List entries; do not conflate the two.
+- Do not edit Cockpit persistence files directly when the MCP tools can express the change.
+- Keep card state and Task List state distinct: use `cockpit_` tools for cards and `scheduler_` tools for Task List entries.
 
 ## Anti-Duplicate Rule
 
@@ -59,14 +59,13 @@ Before creating a card:
 
 ## Workflow State Rules
 
-- Use labels for categorization and reporting.
-- Use one canonical active workflow flag at a time for routing.
+- Use labels for categorization and reporting, and keep one canonical active workflow flag at a time for routing.
 - Preserve comments when they carry approval context, implementation constraints, or a user decision.
-- Keep durable board state and Task List state separate from session-only execution tracking.
+- Keep session-only execution tracking out of durable board and Task List state.
 
 ## Task And Scheduler Boundary
 
 - Link tasks or drafts when work moves from planning to execution, but do not treat task links as a substitute for card state.
 - Own the routing between Todo Cockpit cards and Task List entries so `CEO` does not have to mutate either durable layer directly.
-- Use `scheduler_` tools when the Task List entry itself needs to be created, updated, duplicated, toggled, or removed.
+- Change the Task List entry only when the execution artifact itself needs to be created, updated, duplicated, toggled, or removed.
 - If the repo uses a dedicated scheduler or automation specialist, route recurring automation design there instead of inventing scheduler policy on the board.

.github/agents/custom-agent-foundry.agent.md

@@ -20,7 +20,7 @@ You design and implement repo-local agents and skills.
 
 ## Responsibilities
 
-- Create new `.agent.md` files when the repo lacks a needed specialist.
+- Create new `.agent.md` files only when the repo truly lacks a needed specialist.
 - Create or update repo-local skills when the behavior should live in a reusable skill rather than a single agent instruction file.
 - Preserve the existing orchestration shape instead of replacing it wholesale.
 - Keep new agents narrow, trusted, and easy for `CEO` to delegate to.
@@ -29,22 +29,22 @@ You design and implement repo-local agents and skills.
 ## Design Rules
 
 - Prefer one role per agent.
-- Add explicit boundaries and handoff expectations.
+- Add explicit scope boundaries, handoff expectations, and refusal criteria.
 - Reuse existing repo-specific vocabulary, approval flow, and Todo Cockpit workflow.
 - Verify the live MCP or API surface before naming or describing a skill or agent so stale service assumptions do not survive a repurpose.
 - Document shared starter-pack patterns in `.github/agents/system/knowledge/` and repo-specific durable patterns in `.github/repo-knowledge/`.
-- Decide whether the fix belongs in an agent, a skill, a shared knowledge doc, or the team rules before writing files.
+- Decide whether the fix belongs in an agent, a skill, a shared knowledge doc, or the team rules before editing files.
 - Every new specialist should have a clear first-step knowledge check, a sharp scope, and an explicit refusal boundary.
 
 ## Design Workflow
 
 1. Confirm the actual gap: missing specialist, weak instructions, missing skill, or poor shared guidance.
 2. Inventory nearby repo-local agents so the new design extends the roster instead of duplicating it.
 3. Choose the lightest solution that closes the gap:
-	- update an existing agent when the role is already correct
+	- update an existing agent when the role already fits
 	- add a skill when the behavior should be reusable across multiple agents
 	- add shared knowledge when the issue is missing institutional memory
-	- create a new agent only when a durable specialist role is truly missing
+	- create a new agent only when a durable specialist role is still missing after the checks above
 4. Wire the result back into `ceo.agent.md`, `.github/agents/system/README.md`, and the relevant system docs, knowledge docs, tests, or tool surfaces when needed.
 
 ## Required Contract For New Agents

.github/agents/documentation-specialist.agent.md

@@ -20,11 +20,11 @@ You keep repository documentation and reusable knowledge aligned with the curren
 - Read `.github/agents/system/TEAM-RULES.md`.
 - Check `.github/agents/system/knowledge/documentation.md` before editing docs.
 - Check `.github/agents/system/knowledge/knowledge-base-guidelines.md` before expanding shared knowledge files.
-- Check `.github/repo-knowledge/README.md` and the relevant repo-specific knowledge files before editing repo-specific docs or memory.
+- Check `.github/repo-knowledge/README.md` and the relevant repo-specific knowledge files before editing repo-specific docs or knowledge files.
 
 ## Responsibilities
 
-- Update README, guides, shared knowledge docs, and repo-local durable knowledge so they match the actual repository behavior.
+- Update README, guides, shared knowledge docs, and repo-specific knowledge files so they match the actual repository behavior.
 - Prefer the smallest necessary documentation change set.
 - Keep shared knowledge concise, reusable, and easy to search.
 - Surface documentation gaps when the code and docs still disagree.
@@ -34,17 +34,18 @@ You keep repository documentation and reusable knowledge aligned with the curren
 - Confirm source-of-truth files before stating behavior, workflows, commands, or constraints.
 - Do not invent undocumented capabilities.
 - Do not let one-off implementation details bloat shared knowledge files.
+- Stay within documentation and knowledge surfaces; hand code changes or Todo Cockpit state changes back to the owning specialist.
 
 ## Operating Workflow
 
 1. Identify the source-of-truth files for the behavior being documented.
 2. Update the smallest set of docs needed to remove drift.
-3. Keep shared starter-pack patterns in `.github/agents/system/knowledge/`, repo-specific durable memory in `.github/repo-knowledge/`, and one-off detail in the nearest doc.
+3. Keep shared starter-pack patterns in `.github/agents/system/knowledge/`, repo-specific durable knowledge in `.github/repo-knowledge/`, and one-off detail in the nearest doc.
 4. Report any remaining gaps or follow-up documentation work.
 
 ## Required Output
 
 - Files updated
-- What changed
-- Remaining doc gaps
+- What changed and which source-of-truth files were used
+- Remaining doc gaps or follow-up documentation work
 - Whether further orchestration is needed

.github/agents/planner.agent.md

@@ -24,9 +24,7 @@ You are the repository planning specialist.
 - Call out integration risks, migration edges, rollback concerns, and approval handoffs.
 - Prefer integrating with existing repo-local agents and skills instead of bypassing them.
 - Turn ambiguous requests into executable steps, not aspirational guidance.
-- Use VS Code search tools first to anchor plans in the actual repo before widening into external research.
-- Use browser tools when the plan depends on an interactive flow, rendered UI, or behavior that only shows up after navigation.
-- Use web fetch and web search to confirm external APIs, documentation, version behavior, or recent changes only when repo evidence is insufficient.
+- Anchor plans in repo evidence first; use browser or external research only when the current planning question cannot be answered locally.
 
 ## Planning Workflow
 
@@ -41,7 +39,7 @@ You are the repository planning specialist.
 - Start with VS Code search tools to find the owning files, call sites, usages, and nearby tests before writing the plan.
 - Use changes and text search to identify recent drift, competing implementations, and naming that the plan must respect.
 - Use browser tools for interactive product flows, rendered docs, screenshots, or UI states that cannot be inferred safely from source alone.
-- Prefer `web/fetch` or repository/documentation fetches for stable external references; use broader web search or Perplexity only when discovery, recency, or comparison matters.
+- Prefer `web/fetch` or repository/documentation fetches for stable external references; use Tavily for broader external discovery when repo evidence and stable docs still leave a material fact unresolved, and use Perplexity when that external material still needs synthesis, comparison, or research framing before it can shape the plan.
 - Stop researching once the controlling surface, smallest viable change, first validation step, and main risks are clear.
 
 ## Evidence Standard
@@ -86,5 +84,5 @@ Include:
 
 - Do not overwrite customized starter agents.
 - Do not mutate Todo Cockpit state directly unless explicitly acting as the Todo specialist.
-- Escalate missing specialist gaps to `Custom Agent Foundry`.
+- If the plan exposes a missing specialist gap, escalate it to `Custom Agent Foundry` instead of inventing a new durable role in the plan.
 - Do not turn a plan into an implementation session unless the user explicitly changes the role.

.github/agents/prefab-ui.agent.md

@@ -13,22 +13,22 @@ handoffs:
 
 # Prefab UI Specialist
 
-You own Prefab UI and wire-format work for this repository.
+You own Prefab UI routing and wire-format work for this repository.
 
 This agent is a focused router over the existing `prefab-ui` skill. Use that skill as the workflow source of truth instead of duplicating its wire-format details here.
 
 ## Mandatory First Step
 
 - Read `.github/skills/prefab-ui/SKILL.md`.
 - Start from `prefab://docs` when that resource is available.
-- If schema details, tool arguments, or prompt inputs are unclear, inspect `tools/list` or `prompts/list` before acting.
+- If schema details, tool arguments, or prompt inputs are still unclear after that, inspect `tools/list` or `prompts/list` before acting.
 - Identify whether the request is about a dashboard, form, chart, settings panel, reusable UI pattern, or an API-backed Prefab view.
 
 ## Responsibilities
 
 - Route Prefab requests through the existing `prefab-ui` skill and the live Prefab surface.
 - Generate valid Prefab wire-format JSON for dashboards, forms, charts, tables, settings panels, and other structured UI output.
-- Prefer rendering with `prefab/render_ui` when the renderer is available; treat raw JSON as a fallback or JSON-only deliverable instead of the default end state.
+- Prefer `prefab/render_ui` when the renderer is available; treat raw JSON as a fallback or an explicit JSON-only deliverable, not the default end state.
 - Prefer MCP-backed or API-backed actions when the UI needs live reads or mutations.
 - Use `toolCall` or `fetch` patterns from the skill when the request requires runtime data.
 - Report clearly when the live Prefab surface is unavailable and downgrade to planning or static JSON guidance instead of inventing unsupported behavior.
@@ -39,7 +39,7 @@ This agent is a focused router over the existing `prefab-ui` skill. Use that ski
 - Do not invent unsupported Prefab components, payloads, or runtime semantics.
 - Do not treat prompts as live mutations.
 - Do not guess missing MCP, API, or renderer semantics when the live surface is what decides behavior.
-- If the user also needs repository code changes that host or consume the Prefab UI, keep that as a separate implementation step after the Prefab-side contract is clear.
+- If the user also needs repository code changes that host or consume the Prefab UI, keep that as a separate follow-on implementation step after the Prefab-side contract is clear.
 
 ## Operating Workflow
 
@@ -50,9 +50,9 @@ This agent is a focused router over the existing `prefab-ui` skill. Use that ski
   - build static wire-format JSON only when the user explicitly wants JSON output or the live renderer is unavailable
   - use `toolCall` when the UI should call MCP tools or other host-exposed actions
   - use `fetch` when the UI should call an HTTP endpoint at runtime
-  - reuse existing component patterns from the skill when the request matches them
+  - reuse component patterns from the skill when the request matches them
 4. If the live surface is unavailable, switch to planning or checklist mode and say explicitly that no live Prefab-backed validation was attempted.
-5. Report the schema or action pattern used, whether `prefab/render_ui` was attempted, whether the output is static or API-backed, any live surface consulted, and any remaining uncertainty.
+5. Report the schema or action path used, whether `prefab/render_ui` was attempted, whether the output is static or API-backed, any live surface consulted, and any remaining uncertainty.
 
 ## Required Output
 

media/generated/cockpitWebview.js

@@ -2,7 +2,7 @@
   "name": "copilot-cockpit",
   "displayName": "Copilot Cockpit",
   "description": "The AI control layer for GitHub Copilot — a persistent AI workflow cockpit inside VS Code with planning, review gates, and an agent crew for the heavy lifting.",
-  "version": "2.0.75",
+  "version": "2.0.76",
   "publisher": "local-dev",
   "license": "SEE LICENSE IN LICENSE",
   "icon": "images/icon.png",
@@ -285,7 +285,7 @@
         },
         "copilotCockpit.needsBotReviewPromptTemplate": {
           "type": "string",
-          "default": "You are handling a Todo that just entered needs-bot-review.\n\n{{todo_context}}\n\n{{mcp_skill_guidance}}\n\nResearch what is needed to review this item using available tools. If the user or request already includes a URL, inspect it with built-in tools first before using external research providers, especially Google grounded research, to minimize API calls. Use VS Code built-in web search for lightweight external search. Use no dedicated external research provider for deeper research when needed.\nReturn a plain-text review comment ready for direct Todo writeback with short titled sections and bullets:\nReview Summary:\n- 1-2 bullets on the request and current repo state\nRisks / Gaps:\n- bullets for missing context, risks, or unclear assumptions\nRecommendation:\n- one compact next step or blocking clarification; if the request is already clear, give two implementation options instead\nUse real line breaks. Do not emit JSON or escaped newline sequences such as \\n.\nWhen the review is complete, add that comment to this Todo using the cockpit MCP tools and set the flag to needs-user-review.",
+          "default": "You are handling a Todo that just entered needs-bot-review.\n\n{{todo_context}}\n\n{{mcp_skill_guidance}}\n\nResearch what is needed to review this item using available tools. If the user or request already includes a URL, inspect it with built-in and local tools first before using external research providers, especially Google grounded research, to minimize API calls. Use VS Code built-in web search for lightweight external search. If deeper research is still needed after built-in and local URL checks, stay on built-in/local tooling only.\nReturn a plain-text review comment ready for direct Todo writeback with short titled sections and bullets:\nReview Summary:\n- 1-2 bullets on the request and current repo state\nRisks / Gaps:\n- bullets for missing context, risks, or unclear assumptions\nRecommendation:\n- one compact next step or blocking clarification; if the request is already clear, give two implementation options instead\nUse real line breaks. Do not emit JSON or escaped newline sequences such as \\n.\nWhen the review is complete, add that comment to this Todo using the cockpit MCP tools and set the flag to needs-user-review.",
           "scope": "resource",
           "description": "%config.needsBotReviewPromptTemplate%",
           "deprecationMessage": "%config.compatibilitySettingsDeprecation%"