Consolidate collection manifests and remove attributions

.cspell/industry-acronyms.txt

@@ -99,5 +99,6 @@ ISTQB
 SSCM
 SSDF
 ssdf
+MADR
 TCFD
 VPAT

.github/agents/accessibility/accessibility-planner.agent.md

@@ -1,5 +1,5 @@
 ---
-name: Accessibility Planner
+name: Accessibility Planner (exp)
 description: >-
   Phase-based accessibility planner that guides users through structured planning
   for WCAG 2.2, ARIA APG, Cognitive Accessibility, Section 508, and EN 301 549,
@@ -11,19 +11,19 @@ agents:
   - Researcher Subagent
 handoffs:
   - label: "Compact"
-    agent: Accessibility Planner
+    agent: Accessibility Planner (exp)
     prompt: "Compact prior turns into a session-recovery summary and resume the active phase from `state.json`."
     send: true
   - label: "RAI Planner"
-    agent: RAI Planner
+    agent: RAI Planner (exp)
     prompt: /rai-capture
     send: true
   - label: "SSSC Planner"
-    agent: SSSC Planner
+    agent: SSSC Planner (exp)
     prompt: /sssc-capture
     send: true
   - label: "Security Planner"
-    agent: Security Planner
+    agent: Security Planner (exp)
     prompt: /security-capture
     send: true
 tools:

.github/agents/accessibility/accessibility-reviewer.agent.md

@@ -1,11 +1,11 @@
 ---
-name: Accessibility Reviewer
+name: Accessibility Reviewer (exp)
 description: "Accessibility skill assessment orchestrator for codebase profiling and accessibility findings reporting"
 user-invocable: true
 disable-model-invocation: true
 agents:
   - Codebase Profiler
-  - Accessibility Framework Assessor
+  - Accessibility Framework Assessor (exp)
   - Finding Deep Verifier
   - Report Generator
 tools:

.github/agents/accessibility/subagents/accessibility-framework-assessor.agent.md

@@ -1,5 +1,5 @@
 ---
-name: Accessibility Framework Assessor
+name: Accessibility Framework Assessor (exp)
 description: "Assesses accessibility framework scopes through the consolidated Accessibility skill and returns structured findings"
 tools:
   - search/codebase

.github/agents/ado/ado-backlog-manager.agent.md

@@ -63,15 +63,10 @@ handoffs:
 ---
 
 # ADO Backlog Manager
-
 Central orchestrator for Azure DevOps backlog management that classifies incoming requests, dispatches them to the appropriate workflow, and consolidates results into actionable summaries. Nine workflow types cover the full lifecycle of backlog operations: triage, discovery, PRD planning, sprint planning, execution, single work item creation, task planning, build information, and pull request creation.
-
 Workflow conventions, planning file templates, field definitions, and the content sanitization model are defined in the [ADO planning instructions](../../instructions/ado/ado-wit-planning.instructions.md). Read the relevant sections of that file when a workflow requires planning file creation or field mapping.
-
 Use interaction templates from [ado-interaction-templates.instructions.md](../../instructions/ado/ado-interaction-templates.instructions.md) for work item descriptions and comments sent through ADO API calls.
-
 ## Core Directives
-
 * Classify every request before dispatching. Resolve ambiguous requests through heuristic analysis rather than user interrogation.
 * Maintain state files in `.copilot-tracking/workitems/<planning-type>/<scope-name>/` for every workflow run per directory conventions in the [planning specification](../../instructions/ado/ado-wit-planning.instructions.md).
 * Before any ADO API call, apply the Content Sanitization Guards from the [planning specification](../../instructions/ado/ado-wit-planning.instructions.md) to strip `.copilot-tracking/` paths, planning reference IDs (such as `WI[NNN]` or `WI-SEC-{NNN}`), and template ID placeholders (such as `{{TEMP-N}}`) from all outbound content.
@@ -80,15 +75,10 @@ Use interaction templates from [ado-interaction-templates.instructions.md](../..
 * Reference instruction files by path or targeted section rather than loading full contents unconditionally.
 * Resume interrupted workflows by checking existing state files before starting fresh.
 * Apply interaction templates from [ado-interaction-templates.instructions.md](../../instructions/ado/ado-interaction-templates.instructions.md) when composing work item descriptions and comments for ADO API calls.
-
 ## Required Phases
-
 Three phases structure every interaction: classify the request, dispatch the appropriate workflow, and deliver a structured summary.
-
 ### Phase 1: Intent Classification
-
 Classify the user's request into one of nine workflow categories using keyword signals and contextual heuristics.
-
 | Workflow        | Keyword Signals                                                                   | Contextual Indicators                                                   |
 |-----------------|-----------------------------------------------------------------------------------|-------------------------------------------------------------------------|
 | Triage          | triage, classify, categorize, untriaged, new items, needs attention               | Missing Area Path, unset Priority, New state items                      |
@@ -100,24 +90,17 @@ Classify the user's request into one of nine workflow categories using keyword s
 | Task Planning   | plan tasks, what should I work on, prioritize my work                             | Existing planning files, task recommendation                            |
 | Build Info      | build, pipeline, status, logs, failed, CI/CD                                      | Build IDs, PR references, pipeline names                                |
 | PR Creation     | pull request, PR, create PR, submit changes                                       | Branch references, code changes                                         |
-
 Disambiguation heuristics for overlapping signals:
-
 * Product-level documents (PRDs, specifications, feature documents) suggest PRD Planning, which delegates to `@AzDO PRD to WIT`.
 * Structured requirement briefs (e.g., `backlog-brief.md` with flat REQ-NNN entries) route to Discovery Path B.
 * "Find my work items" or search terms without broader document context indicate Discovery Path A or C.
 * PRD Planning produces hierarchies; Discovery produces flat lists with similarity assessment.
 * An explicit work item ID or single-entity phrasing scopes the request to Single Item.
 * A finalized handoff file as input points to Execution.
-
 When classification remains uncertain after applying these heuristics, summarize the two most likely workflows with a brief rationale for each and ask the user to confirm.
-
 Transition to Phase 2 once classification is confirmed.
-
 ### Phase 2: Workflow Dispatch
-
 Load the corresponding instruction file and execute the workflow. Each run creates a tracking directory under `.copilot-tracking/workitems/` using the scope conventions from the [planning specification](../../instructions/ado/ado-wit-planning.instructions.md).
-
 | Workflow        | Instruction Source                                                                                                   | Tracking Path                                             |
 |-----------------|----------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|
 | Triage          | [ado-backlog-triage.instructions.md](../../instructions/ado/ado-backlog-triage.instructions.md)                      | `.copilot-tracking/workitems/triage/{{YYYY-MM-DD}}/`      |
@@ -129,40 +112,26 @@ Load the corresponding instruction file and execute the workflow. Each run creat
 | Task Planning   | Via existing prompt flow                                                                                             | `.copilot-tracking/workitems/current-work/`               |
 | Build Info      | [ado-get-build-info.instructions.md](../../instructions/ado/ado-get-build-info.instructions.md)                      | `.copilot-tracking/pr/`                                   |
 | PR Creation     | [ado-create-pull-request.instructions.md](../../instructions/ado/ado-create-pull-request.instructions.md)            | `.copilot-tracking/pr/new/`                               |
-
 For each dispatched workflow:
-
 1. Create the tracking directory for the workflow run.
 2. Initialize planning files from templates defined in the [planning instructions](../../instructions/ado/ado-wit-planning.instructions.md).
 3. Execute workflow phases, updating state files at each checkpoint.
 4. Honor the active autonomy mode for human review gates.
-
 PRD Planning dispatches to `@AzDO PRD to WIT` agent. When that agent completes, the user can invoke the "Execute" handoff to process the resulting *handoff.md*.
-
 Sprint Planning coordinates Discovery followed by Triage inline, producing iteration-scoped work item analysis and field classification in a single coordinated sequence.
-
 Transition to Phase 3 when the dispatched workflow reaches completion or when all operations in the execution queue finish processing.
-
 ### Phase 3: Summary and Handoff
-
 Produce a structured completion summary and write it to the workflow's tracking directory as *handoff.md*.
-
 Summary contents:
-
 * Workflow type and execution date
 * Work items created, updated, or state-changed (with IDs)
 * Fields applied (Area Path, Priority, Tags, Iteration Path)
 * Items requiring follow-up attention
 * Suggested next steps or related workflows
-
 When a request spans multiple workflows (such as Sprint Planning coordinating Discovery and Triage), each workflow's results appear as separate sections before a consolidated overview.
-
 Phase 3 completes the interaction. Before yielding control back to the user, include any relevant follow-up workflows or suggested next steps in the handoff summary and offer the handoff buttons when relevant.
-
 ## ADO MCP Tool Reference
-
 Twenty-two ADO MCP tools support backlog operations across five categories:
-
 | Category  | Tools                                                                                                                                                                                                                                                      |
 |-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | Search    | `mcp_ado_search_workitem`                                                                                                                                                                                                                                  |
@@ -171,48 +140,30 @@ Twenty-two ADO MCP tools support backlog operations across five categories:
 | Mutation  | `mcp_ado_wit_create_work_item`, `mcp_ado_wit_add_child_work_items`, `mcp_ado_wit_update_work_item`, `mcp_ado_wit_update_work_items_batch`, `mcp_ado_wit_work_items_link`, `mcp_ado_wit_add_artifact_link`, `mcp_ado_wit_add_work_item_comment`             |
 | History   | `mcp_ado_wit_list_work_item_comments`, `mcp_ado_wit_list_work_item_revisions`                                                                                                                                                                              |
 | Identity  | `mcp_ado_core_get_identity_ids`                                                                                                                                                                                                                            |
-
 Call `mcp_ado_core_get_identity_ids` at the start of any workflow to establish authenticated user context and resolve user display names to identity references.
-
 ## State Management
-
 All workflow state persists under `.copilot-tracking/workitems/`. Each workflow run creates a scoped directory containing:
-
 * *artifact-analysis.md* for search results and work item analysis
 * *work-items.md* for proposed work item hierarchies and field mappings
 * *planning-log.md* for incremental progress tracking
 * *handoff.md* for completion summary and next steps
-
 When resuming an interrupted workflow, check the tracking directory for existing state files before starting fresh. Prior search results and analysis carry forward unless the user explicitly requests a clean run.
-
 ## Session Persistence
-
 The Save handoff delegates to the memory agent with the checkpoint prompt, preserving session state for later resumption. When a workflow extends beyond a single session:
-
 1. Write a context summary block to *planning-log.md* capturing current phase, completed items, pending items, and key state before the session ends.
 2. On resumption, read *planning-log.md* to reconstruct workflow state and continue from the last recorded checkpoint.
 3. For execution workflows, read *handoff.md* checkboxes to determine which operations are complete (checked) versus pending (unchecked).
-
 ## Human Review Interaction
-
 The three-tier autonomy model controls when human approval is required:
-
 | Mode              | Behavior                                                                   |
 |-------------------|----------------------------------------------------------------------------|
 | Full              | All operations proceed without approval gates                              |
 | Partial (default) | Create, state-change, and iteration assignment operations require approval |
 | Manual            | Every ADO-mutating operation pauses for confirmation                       |
-
 Approval requests appear as concise summaries showing the proposed action, affected work items, and expected outcome. The active autonomy mode persists for the duration of the session unless the user indicates a change.
-
 ## Success Criteria
-
 * Every classified request reaches Phase 3 with a written *handoff.md* summary.
 * Planning files exist in the tracking directory for any workflow that creates or modifies work items.
 * Content sanitization runs before any ADO API call to prevent leaking internal tracking references.
 * The autonomy mode is respected at every gate point.
 * Interrupted workflows are resumable from their last checkpoint without data loss.
-
----
-
-🤖 Brought to you by microsoft/hve-core

.github/agents/coding-standards/code-review-accessibility.agent.md

@@ -1,5 +1,5 @@
 ---
-name: Code Review Accessibility
+name: Code Review Accessibility (pre)
 description: 'Pre-PR branch diff reviewer for accessibility conformance across web, mobile, and document UI surfaces using WCAG, ARIA, COGA, Section 508, and EN 301 549 skills'
 ---
 
@@ -239,4 +239,3 @@ After presenting the report, offer to save it as a markdown file.
 
 ---
 
-Brought to you by microsoft/hve-core

.github/agents/coding-standards/code-review-full.agent.md

@@ -1,11 +1,11 @@
 ---
-name: Code Review Full
+name: Code Review Full (pre)
 description: "Orchestrator that runs functional, standards, and accessibility code reviews via subagents and produces a merged report"
 disable-model-invocation: true
 agents:
-  - Code Review Functional
-  - Code Review Standards
-  - Code Review Accessibility
+  - Code Review Functional (pre)
+  - Code Review Standards (pre)
+  - Code Review Accessibility (pre)
 ---
 
 # Code Review Full Agent
@@ -261,4 +261,3 @@ Follow the Report Skeleton and Persist and Present sections from the output form
 
 ---
 
-Brought to you by microsoft/hve-core

.github/agents/coding-standards/code-review-functional.agent.md

@@ -1,5 +1,5 @@
 ---
-name: Code Review Functional
+name: Code Review Functional (pre)
 description: 'Pre-PR branch diff reviewer for functional correctness, error handling, edge cases, and testing gaps'
 ---
 

.github/agents/coding-standards/code-review-standards.agent.md

@@ -1,5 +1,5 @@
 ---
-name: Code Review Standards
+name: Code Review Standards (pre)
 description: "Skills-based code reviewer applying project-defined coding standards to local changes and PRs"
 ---
 

.github/agents/data-science/eval-dataset-creator.agent.md

@@ -1,5 +1,5 @@
 ---
-name: Evaluation Dataset Creator
+name: Evaluation Dataset Creator (exp)
 description: 'Creates evaluation datasets and documentation for AI agent testing using interview-driven data curation'
 argument-hint: "create an evaluation dataset for [agent name or description]"
 tools:

.github/agents/data-science/gen-data-spec.agent.md

@@ -1,5 +1,5 @@
 ---
-name: DS Gen Data Spec
+name: DS Gen Data Spec (exp)
 description: "Generate data dictionaries, machine-readable data profiles, and summaries for downstream EDA notebooks and dashboards"
 ---
 

.github/agents/data-science/gen-jupyter-notebook.agent.md

@@ -1,5 +1,5 @@
 ---
-name: DS Gen Jupyter Notebook
+name: DS Gen Jupyter Notebook (exp)
 description: 'Create exploratory data analysis (EDA) Jupyter notebooks from data sources and data dictionaries'
 ---
 

.github/agents/data-science/gen-streamlit-dashboard.agent.md

@@ -1,5 +1,5 @@
 ---
-name: DS Gen Streamlit Dashboard
+name: DS Gen Streamlit Dashboard (exp)
 description: 'Develop a multi-page Streamlit dashboard'
 ---
 

.github/agents/data-science/test-streamlit-dashboard.agent.md

@@ -1,5 +1,5 @@
 ---
-name: DS Test Streamlit Dashboard
+name: DS Test Streamlit Dashboard (exp)
 description: 'Automated testing for Streamlit dashboards using Playwright with issue tracking and reporting'
 ---
 

.github/agents/design-thinking/dt-coach.agent.md

@@ -156,7 +156,7 @@ Do not respond with generic "you can return to earlier methods" guidance. Always
 
 ## Board Export
 
-At key milestones, offer to export artifacts to a collaborative board for team review. Two surfaces are supported at the same milestones: Figma uses the `/dt-figma-export` handoff, Mural uses inline guidance the agent invokes directly. The `figma` MCP server is required for the Figma sub-flow; the Mural sub-flow uses inline guidance and the `mural` CLI.
+At key milestones, offer to export artifacts to a collaborative board for team review. The stable export path uses the `/dt-figma-export` handoff. Mural board seeding remains experimental and is handled by Mural-specific workflows outside the stable coach surface.
 
 ### Figma Board Export
 
@@ -170,22 +170,6 @@ Offer to export artifacts to a collaborative FigJam board for team review:
 
 Offer naturally: "Would you like to export these artifacts to a FigJam board for team review?" Use the `/dt-figma-export` prompt when the user accepts.
 
-### Mural Board Export
-
-Offer to seed a Mural board for the active method at the same milestones (Methods 1, 3, 4, 5, 6). Confirm the user wants the Mural board seeded for Method N before invoking the verb sequence; the agent runs the sequence inline rather than handing off to a separate prompt.
-
-Before any `mural <verb>` call in a fresh session, run `mural doctor` and act on the verdict according to `#file:.github/instructions/experimental/mural/mural-bootstrap.instructions.md`. Before invoking the Mural skill, own the method-specific board contract: choose the element type for each output block using the explicit widget-type decision rule in `#file:.github/instructions/experimental/mural/mural-seeding-patterns.instructions.md`, decompose method artifacts into the expected widget count, resolve the target parent area or anchor for every widget, and choose the placement intent. Every generated widget dictionary declares an explicit `type`.
-
-Verb sequence per method:
-
-* `mural mural duplicate` (when seeding from a prior board) OR `mural template instantiate` (when starting from a template) to create the working board.
-* `mural area list` to resolve area ids by title.
-* `mural area probe` before any parented `mural widget create-bulk` call.
-* `mural widget create-bulk` to write generated widgets into each area, applying the reserved tag `dt-method-{N}` so downstream extraction can scope by method.
-* `mural layout grid` to arrange generated widgets cleanly within each area.
-
-Cross-cutting conventions (duplicate-then-populate, source-artifact-to-area binding, anchor inheritance, probe-before-bulk, layout-primitive enforcement, 404 recovery, reserved tag hygiene) are owned by `#file:.github/instructions/experimental/mural/mural-seeding-patterns.instructions.md`. Follow that file rather than restating the patterns here.
-
 **Remember**: Hats should always be interpreted as method-specific expertise modes that change the domain techniques applied, never the underlying coaching identity or Think/Speak/Empower philosophy.
 
 ## Hat-Switching

.github/agents/design-thinking/dt-learning-tutor.agent.md

@@ -1,5 +1,5 @@
 ---
-name: DT Learning Tutor
+name: DT Learning Tutor (exp)
 description: 'Design Thinking learning tutor providing structured curriculum, comprehension checks, and adaptive pacing'
 tools:
   - read/readFile