Add: Regulation Monitor

[JagmeetChabraMSFT (jchha001)]

Add: Regulation Monitor

Adds a new skill that turns a user-specified regulation into a repeatable,
scheduled monitoring workflow. On first run, walks the user through a
one-time setup (topics, jurisdictions, cadence), auto-discovers the top 5
authoritative sources per topic and stops for explicit confirmation
before starting the monitoring sweep. Captures a light WorkIQ-derived team
profile, locks everything into a saved config, and renders a self-contained
HTML dashboard with client-side sortable columns on every run.

Why

Regulatory monitoring is one of those tasks that's important but tedious:
someone has to remember what to watch, keep an updated list of authoritative
sources, sweep them on a cadence, and organize what's new for the team. This
skill makes it configurable once, then runs on the platform's scheduler
without any hand-holding.

Highlights

• Domain-agnostic. Tax, privacy, AI/ML, healthcare, finance, ESG, labor —
  the user picks the topics at setup. The references/sources-and-taxonomy.md
  covers reputable regulators, standard-setting bodies, and trackers across
  all these domains.
• Auto-source-discovery with an explicit confirmation checkpoint. The
  skill proposes up to 5 authoritative sources per topic (regulator page,
  official journal, multilateral body, reputable tracker, professional-firm
  alert) and cannot start the monitoring sweep until the user has
  approved the list. User can swap sources, lower the target, or add
  their own seed URLs.
• Locked source list at runtime. Every subsequent run visits only the
  confirmed sources. A tightly-bounded fallback web search (max 2 per run,
  allowlist-filtered) is used only when a source went silent in the window.
  Runtime budget block in the config caps items, searches, and fetches.
• WorkIQ-derived team-relevance flag (not an impact rubric). At setup,
  the skill uses workiq_get_my_profile / workiq_get_my_manager /
  workiq_get_relevant_people to propose 5–15 function-area keywords the
  user confirms. Items whose title/summary matches those keywords get a
  soft team-relevant badge in the dashboard. If WorkIQ isn't available on
  the platform, the user supplies keywords manually.
• Self-contained HTML dashboard with real client-side sorting. KPI
  tiles (total items, count per topic, team-relevant count), a table
  color-coded by stage where every column header is clickable (and
  keyboard-accessible via Enter/Space) to sort ascending/descending,
  team-relevant badges, per-row source links (URL scheme sanitized — only
  http/https/mailto are rendered), and a "Quiet this period" section
  that lists every watch topic that produced zero items as "No
  significant developments this period".
• Strict guardrails. Never fabricate. No speculation, rumors, or
  unofficial sources — items must trace to a named official source. Public
  sources only, no paywall bypass. Monitoring, not advice. Empty categories
  are reported explicitly, never padded.
• Scheduling lives outside the skill. Setup, scheduling walkthroughs
  (Scout and Cowork), tips, and everything else human-facing lives in the
  submission's README.md sidecar — not bundled, does not consume agent
  context.

Platforms

Cowork, Scout. Helper script is Python stdlib only.

Local validation (per CONTRIBUTING.md)

Ran locally against the repo before opening this PR:

• npm run check:submissions → 14 submission(s) passed validation.
• npm run import:submissions → imported cleanly; produced
  src/content/skills/regulation-monitor.md and
  public/bundles/regulation-monitor.zip.
• Dashboard generator smoke-tested end-to-end on multiple profiles — verified
  the "Quiet this period" section renders, the "No significant developments
  this period" copy appears exactly as specified, the URL-scheme sanitizer
  strips javascript: payloads, the initial sort puts newer items first
  within each (relevance, stage) group, and the client-side sorter reorders
  rows correctly by every column.

Files

submissions/regulation-monitor/
├── SKILL.md                           # agent-facing runtime instructions
├── README.md                          # human-facing overview + scheduling walkthrough (sidecar, not bundled)
├── metadata.json                      # catalog sidecar
├── scripts/build_dashboard.py         # self-contained HTML dashboard generator (stdlib only, embeds a small vanilla-JS sorter)
└── references/
    └── sources-and-taxonomy.md        # reputable-domain allowlist + taxonomy + query templates

[Copilot]

Pull request overview

Adds a new submissions/regulation-monitor/ skill entry that defines an agent-run workflow for configuring and running recurring regulatory monitoring, including producing a self-contained HTML dashboard from collected items.

Changes:

• Adds the Regulation Monitor skill instructions (SKILL.md) and submission metadata (metadata.json).
• Adds a Python (stdlib-only) dashboard generator script to render a standalone HTML report from a run’s JSON items.
• Adds reference materials for source allowlisting/taxonomy and scheduling guidance.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
submissions/regulation-monitor/SKILL.md	Defines the monitoring workflow, setup/config schema, and run-time guardrails/output expectations.
submissions/regulation-monitor/scripts/build_dashboard.py	Generates a self-contained HTML dashboard from config + items JSON.
submissions/regulation-monitor/references/sources-and-taxonomy.md	Provides the allowlist + taxonomy + query templates used by the skill.
submissions/regulation-monitor/references/automation-template.md	Documents how to schedule runs on Scout / Copilot Studio / Cowork.
submissions/regulation-monitor/metadata.json	Registers the new skill in the gallery catalog (name/description/platforms/tags/author/version/dates).

Comments suppressed due to low confidence (3)

submissions/regulation-monitor/SKILL.md:120

• The PR description says the skill “stops for explicit confirmation before doing any research,” but Step 1 describes a bounded discovery pass that performs web searches before confirmation. To avoid confusion, the checkpoint wording should clarify that confirmation is required before the monitoring sweep (not before the discovery pass that generates the proposed source list).

**This is an interactive checkpoint. Do not proceed to any research or
monitoring until the user has explicitly confirmed the source list.**

submissions/regulation-monitor/references/automation-template.md:22

• The example scheduled prompt says “Send silently if no items were found,” which contradicts the skill’s stated behavior of always producing an explicit empty-state (“No significant developments this period”) and the PR description’s “Quiet this period” section. This would cause scheduled runs to skip sending the dashboard even though it’s designed to be useful when empty.

  Run the regulation-monitor skill for profile "<profile-name>".
  Load the profile's config.json, sweep the window since the last run,
  build the dashboard, and email the digest to the user per the
  delivery block. Send silently if no items were found.
teamsNotify: auto

submissions/regulation-monitor/SKILL.md:181

• Step 1 describes seed sources as if they are topic-scoped (“a topic can end up with 5 auto-discovered + N user seeds”), but the saved schema later shows seed_sources as a single global list (not keyed by topic). That mismatch makes it unclear how seeds relate to topics and how to evaluate “every locked source returned zero items” per-topic for fallback search.

  - Add their own seed URLs → merge them into `seed_sources` in the config.
    Seed sources are **not** counted against the "top 5" — a topic can end
    up with 5 auto-discovered + N user seeds.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (2)

submissions/regulation-monitor/references/sources-and-taxonomy.md:37

• The allowlist is described as domain-matching, but this entry includes a path (ec.europa.eu/competition), which will not match a domain-only filter and is easy to misinterpret. Keep allowlist entries to domains only.

Competition: `justice.gov`, `ftc.gov`, `ec.europa.eu/competition`, `cma.gov.uk`,
`bundeskartellamt.de`, `competitionbureau.gc.ca`.

submissions/regulation-monitor/SKILL.md:28

• SKILL.md contains substantial human-facing documentation (e.g., “Overview”/“Quick Start”/scheduling guidance). Repo guidance expects setup/adoption/overview content to live in a README.md sidecar (see CONTRIBUTING.md:77-85 and submissions/README.md:74-82), keeping SKILL.md focused on runtime instructions for the agent.

## Overview

Turns a saved "watch profile" — topics, jurisdictions, source list, cadence —
into a repeatable regulatory sweep. On each run the skill visits **only** the
sources locked into the profile at setup: the top authoritative sources the

[JagmeetChabraMSFT (jchha001)]

Thanks for the pass copilot-pull-request-reviewer. Addressed in 8b9432d — summary of what I took and what I left, with reasoning:

Fixed

• URL-scheme sanitizer. Real security fix. source_url is now filtered through a safe_url() helper that only accepts http://, https://, and mailto:. javascript:, data:, vbscript: etc. get dropped from the href while the item title still renders. Anchor tags also get rel="noopener nofollow". Verified with a javascript:alert(1) payload — dashboard renders the item name but strips the href.
• ec.europa.eu/competition path segment in the domain allowlist → stripped to ec.europa.eu. Correct catch.
• build_dashboard.py header step reference. "Step 4" → "Step 7" to match SKILL.md. Also added a schema note that only http/https/mailto renders.
• "Send silently if no items were found" in automation-template.md — contradicted the empty-state rule. Rewrote the example prompt so scheduled runs always send the dashboard, with quiet topics explicitly rendered as "No significant developments this period."
• "Exactly 5 authoritative sources" wording conflicted with the "user can lower the target" option. Softened to "up to 5 (default target 5; use fewer if the user asks or the domain has fewer canonical sources)."
• Confirmation-checkpoint wording. Clarified that the blocking checkpoint gates the monitoring sweep (Step 5), not the small discovery pass that generates the proposed shortlist — the discovery pass is exactly the point of Step 1.
• seed_sources schema mismatch. Real inconsistency. Renamed the field to seed_sources_by_topic and keyed it the same way as sources_by_topic, so the per-topic "every locked source returned zero" check for fallback search is unambiguous. Updated Step 1, Step 5, the config schema example, and the guardrails.

Left as-is (with reasoning)

• "SKILL.md contains substantial human-facing content." Established, merged skills use this structure. My own presentation-talk-track-builder (already merged in main) has Overview / When to Use / When NOT to Use / Quick Start / Core Instructions / Output / Guardrails, and redlining-content has Requirements / Inputs / Steps / How it works / Per-input guidance / v1 limitations. _template/SKILL.md shows a minimal Instructions / Guardrails / Tone shape but is explicitly minimal; established skills use richer agent-facing structures. The Overview, When to Use, and When NOT to Use sections are agent-facing invocation guidance, not human docs. Would rather match precedent than restructure.
• references/automation-template.md "moved to README.md sidecar." Per submissions/README.md, README.md in the submission folder is explicitly disallowed ("No READMEs or other human-facing files"). references/ is the correct home for content the agent reads on demand — this file gets read when the user asks "how do I schedule this?" Keeping it in references/.

npm run check:submissions still passes (14/14). URL-sanitizer smoke test confirmed.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

submissions/regulation-monitor/SKILL.md:33

• The content under "## Overview" is human-facing (product overview) rather than runtime instructions for the agent. Per repo guidance, human-oriented overview/setup/examples should live in an optional submission README.md (not bundled) while SKILL.md stays agent-executable instructions (see submissions/README.md:36-45 and 74-82). Please move this overview material into submissions/regulation-monitor/README.md and keep SKILL.md focused on the step-by-step procedure the agent must follow at runtime.

## Overview

Turns a saved "watch profile" — topics, jurisdictions, source list, cadence —
into a repeatable regulatory sweep. On each run the skill visits **only** the
sources locked into the profile at setup: the top authoritative sources the
skill discovered for each watch topic plus any seed sources the user added.
It classifies each new item, flags items likely relevant to the user's team
using a light org profile derived once from WorkIQ, and produces a
self-contained HTML dashboard.

submissions/regulation-monitor/references/automation-template.md:5

• This file is entirely scheduling/how-to content for humans. Because everything under references/ is bundled verbatim and read as agent-facing context, this increases the agent payload with human docs. Repo guidance recommends putting human-facing overview/setup/scheduling info in a submission README.md sidecar instead (see submissions/README.md:36-45 and 74-82).

# Scheduling the regulation monitor

The core skill has no schedule of its own — it just runs. To put it on a
cadence, wire it to a scheduler on your platform.

[JagmeetChabraMSFT (jchha001)]

Round 2 fixes in the latest commit. Good catches on this pass — I was working off an older reading of submissions/README.md last time. Rechecked and it now explicitly supports an optional README.md sidecar ("becomes the main content on the detail page, is not bundled, agent never reads it"). Accepting.

Fixed

• README.md sidecar added. Human-facing overview, setup walkthrough, scheduling (Scout + Cowork), and tips. Not bundled, doesn't cost the agent any tokens.
• references/automation-template.md deleted. All that content moved to README.md. Agreed: keeping it under references/ was bundling human docs into agent context.
• SKILL.md ## Scheduling section slimmed to a one-liner pointing at the README sidecar.
• SKILL.md ## References updated to drop the automation-template bullet.
• Input validation in build_dashboard.py: if items[] is not a list the script now errors out cleanly with exit 2 and a helpful message; if the list contains non-dict entries they're dropped with a stderr warning instead of crashing at sort/render time. Verified with two smoke tests.

Kept as-is (my earlier reasoning still holds)

• SKILL.md ## Overview / ## When to Use / ## When NOT to Use sections. These are agent-facing invocation guidance — the model reads them to decide whether to invoke and how to frame the response. Merged skills including my presentation-talk-track-builder and redlining-content follow the same pattern. The new README.md covers the human-facing overview separately, so nothing is duplicated for the human either.

Local validation still passes (14/14).

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

submissions/regulation-monitor/SKILL.md:33

• The SKILL.md body includes human-facing/marketing-style sections (e.g., “Overview”, “When to Use/When NOT to Use”, “Quick Start”) that restate invocation guidance and speak to the user. Repo convention (see submissions/_template/SKILL.md:9-14) is that the body should go straight into imperative agent instructions; adoption/setup walkthrough content should live in the README sidecar instead.

# Regulation Monitor

## Overview

Turns a saved "watch profile" — topics, jurisdictions, source list, cadence —
into a repeatable regulatory sweep. On each run the skill visits **only** the
sources locked into the profile at setup: the top authoritative sources the
skill discovered for each watch topic plus any seed sources the user added.
It classifies each new item, flags items likely relevant to the user's team
using a light org profile derived once from WorkIQ, and produces a
self-contained HTML dashboard.

submissions/regulation-monitor/SKILL.md:66

• This bullet claims scheduled runs are produced by a “bundled automation template”, but the submission folder doesn’t include the references/automation-template.md file described in the PR. Either add the referenced template file or adjust this copy to match what’s actually shipped (the README currently contains the scheduling walkthrough).

- Scheduled: the unattended weekly (or user-chosen cadence) run produced by
  the bundled automation template — no user prompt needed

submissions/regulation-monitor/scripts/build_dashboard.py:120

• The sorting logic/comment is internally inconsistent and more complex than needed: sort_key() returns date_key but the final ordering is actually produced by two additional stable sorts. This makes it harder to verify that the table is ordered as intended (team-relevant first, then stage order, then newest-first date within each group).

    # Sort: team-relevant first, then stage order, then date desc.
    def sort_key(item: dict[str, Any]) -> tuple[int, int, str]:
        stage_idx = (
            STAGE_ORDER.index(item.get("stage", ""))
            if item.get("stage") in STAGE_ORDER

[JagmeetChabraMSFT (jchha001)]

Round 3 fixes in the latest commit. Both real.

Fixed

• metadata.json description mismatch. Previous copy read "seed sources plus a reputable-domain web search", which implied web_search runs every time. That contradicted the SKILL.md behavior. Rewrote to reflect the actual pattern: locked source list at setup (auto-discovered + user-confirmed + user seeds), with web_search only as a tightly-bounded fallback when a locked source is silent in the window. Sets correct gallery expectations.
• build_dashboard.py dead per_stage Counter. Removed. Stages are surfaced as color-coded pills on each row (per-item), not aggregated in a KPI tile — no reason to compute the per-stage count.

npm run check:submissions still passes.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Comments suppressed due to low confidence (2)

submissions/regulation-monitor/SKILL.md:12

• SKILL.md contains human-facing sections (e.g., "Overview" and other adopter-oriented framing). Per repo guidance, SKILL.md should be lean, agent-facing runtime instructions; move human-facing overview/quick-start/setup guidance into README.md and keep only execution steps/decision rules here.

# Regulation Monitor

## Overview

Turns a saved "watch profile" — topics, jurisdictions, source list, cadence —
into a repeatable regulatory sweep. On each run the skill visits **only** the
sources locked into the profile at setup: the top authoritative sources the

submissions/regulation-monitor/SKILL.md:341

• The dashboard HTML produced by build_dashboard.py doesn't currently provide user-sortable columns, so the output description shouldn't claim the table is "sortable" unless sorting is implemented.

- **Dashboard**: `output/regulation-dashboard.html` — KPI tiles, sortable
  color-coded table, team-relevant badges, per-row source links.

[JagmeetChabraMSFT (jchha001)]

Round 4 fixes in 8e2edf6. Real ones, especially the sort-behavior mismatch — thanks for catching it.

Fixed

• Client-side sorting is now actually implemented. Each column header is clickable, toggles ascending/descending, updates aria-sort for accessibility, and sorts by a data-sort key on each cell. Stage sorts by taxonomy order (numeric via data-type="number"), date sorts as ISO strings (lexicographic = chronological, data-type="date"), text columns sort case-insensitively. The server-side pre-sort (team-relevant first → stage order → date desc) still runs so first paint is meaningful, and users can override with a click. A "click any column header to sort" hint next to the Items heading makes the interactivity discoverable.
• SKILL.md frontmatter description was corrupted — had been truncated to "Monitors user-specified regulations, laws, and regulatory guidance on a" somewhere along the way. Rebuilt SKILL.md from scratch with the intended multi-line description.
• Stale references/automation-template.md references still lingered in three places in SKILL.md ("bundled automation template" in Quick Start, "See references/automation-template.md" in Scheduling, and the bullet in the References section). All three now point at README.md (the human-facing sidecar) or the file has been dropped. Same fix in README.md.
• Sort logic simplified. Replaced the two-pass stable-sort trick with a single sorted_items() function returning a tuple key (relevant_first, stage_idx, date_str). Same effective ordering, easier to read.
• sortable wording in both SKILL.md and README.md updated to "client-side sortable" so the description matches the actual behavior.

npm run check:submissions still passes (14/14). Smoke-tested with a 3-item / 2-topic profile — all sort attributes, aria labels, and script hooks render correctly, and the URL-scheme sanitizer still strips javascript: payloads.

Kept as-is (recycled comments)

• The "Overview / When to Use / When NOT to Use" is-human-facing comment came around again. Same answer as rounds 2/3: these are agent-facing invocation guidance the model reads to decide when to invoke; merged skills (presentation-talk-track-builder, redlining-content) follow this shape; the new README.md covers the human-facing overview separately so nothing is duplicated for the human reader either.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

submissions/regulation-monitor/SKILL.md:34

• SKILL.md includes human-facing sections (e.g., "Overview", "When to Use", and the quoted "Quick Start" dialogue) that duplicate the sidecar README and add non-executable narrative. Per repo guidelines, SKILL.md should be lean, agent-facing run instructions; consider moving/removing these sections and starting the skill directly at "Core Instructions" / the step-by-step procedure.

## Overview

Turns a saved "watch profile" — topics, jurisdictions, source list, cadence —
into a repeatable regulatory sweep. On each run the skill visits only the
sources locked into the profile at setup: the top authoritative sources the
skill proposed for each watch topic plus any seed sources the user added.
It classifies each new item, flags items likely relevant to the user's team
using a light org profile derived once from WorkIQ, and produces a
self-contained HTML dashboard with sortable columns.

submissions/regulation-monitor/SKILL.md:399

• This guardrail appears to be leftover presenter guidance ("state the pace assumption" / "presenter can recalibrate") and is unrelated to a regulation monitoring + dashboard workflow. Removing or rewriting it will avoid confusing the agent about the expected outputs.

- **Compute timings with code**, not by hand; state the pace assumption
  so the presenter can recalibrate.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

Comments suppressed due to low confidence (2)

submissions/regulation-monitor/SKILL.md:75

• Same issue as above for firm alert pages: these aren’t ‘official sources’ themselves. Without an explicit rule to follow through and cite the primary official document, the skill’s ‘authoritative-only’ guardrail becomes ambiguous.

5. Public alert pages from major professional-services or specialist
   firms that cover the domain (public URLs only, never subscriber
   content). Examples: KPMG / EY / PwC / Deloitte / BDO insight pages
   for tax and financial regulation; DLA Piper, Hogan Lovells, Wilson
   Sonsini, Cooley for tech / privacy / AI; Ropes & Gray for healthcare;

submissions/regulation-monitor/SKILL.md:285

• This guardrail weakens the ‘named official source’ requirement by also allowing fallback-search allowlist results, which currently includes non-official domains (e.g., think tanks). To keep the rule enforceable, require that each recorded item can be tied to a named official document/announcement (and treat trackers/alerts only as pointers).

  named official source. If an item cannot be tied to a specific
  document or announcement from a source on the profile's locked list
  (or the reputable-domain allowlist for fallback search), drop it.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (4)

submissions/regulation-monitor/scripts/build_dashboard.py:158

• The Team-relevant KPI currently counts any truthy relevant_to_your_team value (e.g., the string "false"), which can inflate the tile count if the items JSON isn’t perfectly typed. Consider counting only literal true.

    total = len(items)
    per_topic = Counter(item.get("topic", "") for item in items)
    team_relevant = sum(1 for item in items if item.get("relevant_to_your_team"))

submissions/regulation-monitor/scripts/build_dashboard.py:201

• The team-relevant badge rendering uses bool(...), which will mark values like the string "false" as relevant. To keep badge display consistent with strict boolean semantics, treat only literal true as relevant.

            "<tr>"
            f'<td data-sort="{esc(date_str)}">{esc(date_str or "-")}</td>'
            f'<td data-sort="{esc(topic_display.lower())}">{esc(topic_display)} {relevant_badge(bool(item.get("relevant_to_your_team")))}</td>'
            f'<td data-sort="{esc(jurisdiction.lower())}">{esc(jurisdiction)}</td>'

submissions/regulation-monitor/scripts/build_dashboard.py:217

• Similar to the row rendering, topics_with_items will include the literal string "None" if any item has topic: null, which can prevent correctly listing quiet topics. Normalize null/empty topics before adding to the set.

    # Empty-topic callout: list any watch topic that produced zero items.
    topics_with_items = {str(item.get("topic", "")) for item in items}
    empty_topics: list[str] = []

submissions/regulation-monitor/SKILL.md:16

• This section lists “reputable trade press” as part of the authoritative-source shortlist, but later guidance/guardrails emphasize using official sources and the allowlist doesn’t include trade-press domains. Tightening this wording helps avoid accidentally treating trade press as an approved monitoring source.

1. Run a small **discovery pass** to identify the top 5 authoritative
   sources per watch topic (regulators, official trackers, reputable
   trade press).
2. **Present the shortlist to the user and stop.** No monitoring runs

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

submissions/regulation-monitor/SKILL.md:15

• This section describes the discovery shortlist as “authoritative sources” and includes “reputable trade press”. That contradicts later guardrails that items must trace to an official primary source and risks encouraging locked sources that aren’t authoritative. Recommend tightening this wording to prioritize primary/official sources and treat trackers/alerts as pointers only.

1. Run a small **discovery pass** to identify the top 5 authoritative
   sources per watch topic (regulators, official trackers, reputable
   trade press).

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

submissions/regulation-monitor/SKILL.md:15

• The setup blurb lists “reputable trade press” as part of the “top 5 authoritative sources”, but elsewhere in the skill you require items to trace to an official regulator/journal/court source. Including trade press here can mislead the agent into selecting non-authoritative sources at setup.

1. Run a small **discovery pass** to identify the top 5 authoritative
   sources per watch topic (regulators, official trackers, reputable
   trade press).

submissions/regulation-monitor/references/sources-and-taxonomy.md:11

• This section reads as if the fallback sweep can directly accept/record any allowlisted web_search result domain, but the skill’s guardrails require each recorded item to cite the underlying official document/announcement (not a tracker/think-tank URL). Clarifying this here helps keep fallback search aligned with the “official source only” rule.

The sweep only accepts `web_search` results whose domain matches one of these
patterns (or an extension the user added at setup). Seed sources the user
provided are always honored regardless of domain.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (2)

submissions/regulation-monitor/SKILL.md:256

• Step 8 writes items under working/… and the dashboard under output/…, but earlier steps don’t guarantee those directories exist and they aren’t scoped per-profile. This can fail at runtime and/or cause different profiles to overwrite each other. Use the per-profile ITEMS_PATH / DASHBOARD_PATH paths consistently here (and ensure their parent folders exist).

1. Write items to `working/regulation-items.json` as a JSON object with the
   shape `{"items": [ ... ]}` (not a bare array). Each entry follows the
   Step 6 schema.
2. Run the bundled generator (single-line command):

**submissions/regulation-monitor/SKILL.md:15**
* This section says the top 5 authoritative sources may include “reputable trade press”, but elsewhere the skill explicitly avoids non-regulatory news monitoring and requires items to trace back to named official sources. Including trade press here is inconsistent and risks the agent selecting news sites as “authoritative” sources. Suggest removing trade press from this definition and keeping discovery focused on official issuers/journals plus (optional) public trackers/firm alerts only as pointers.

1. Run a small discovery pass to identify the top 5 authoritative
   sources per watch topic (regulators, official trackers, reputable
   trade press).

</details>