docs: add Bing Webmaster Tools audit skill

[jessepwj]

Documents Edge CDP authorization, stable BWT routes, authenticated same-origin API reads, Site Scan queue semantics, IndexNow verification, and stale-warning audit traps. Contains no user-specific state or credentials.

---

Summary by cubic

Adds a Bing Webmaster Tools audit skill with authenticated, same‑origin API reads, refined routes, and clear Site Scan/IndexNow guidance. Also hardens browser-harness Edge CDP discovery and Windows inspect flow, with tests.

• New Features

  • Docs for attaching to an authorized Edge profile via CDP.
  • Stable BWT routes with siteUrl rules (preserve scheme/trailing slash) and open a new tab on first navigation.
  • Verified same-origin API reads for SEO, Site Scan, IndexNow, sitemaps, URL submission, and account messages.

• Bug Fixes

  • Fallback to DevToolsActivePort WebSocket when /json/version returns 404.
  • On Windows, open edge://inspect/#remote-debugging using the Edge executable instead of the system protocol handler.
  • Unit tests cover both behaviors.

^{Written for commit 0d73182. Summary will update on new commits.}

[cubic-dev-ai]

3 issues found across 3 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="agent-workspace/domain-skills/bing-webmaster-tools/auditing.md">

<violation number="1" location="agent-workspace/domain-skills/bing-webmaster-tools/auditing.md:61">
P2: An expired or otherwise non-JSON response causes this example to reject before printing any endpoint results, so the audit cannot distinguish an authentication failure from API data and loses successful responses from the other requests. Parsing the response text with a JSON fallback would preserve the reported status and body for each endpoint.</violation>
</file>

<file name="src/browser_harness/admin.py">

<violation number="1" location="src/browser_harness/admin.py:765">
P2: When Chrome and Edge are both running with discoverable local profiles, the recovery opens Edge's authorization page even though the daemon may have selected Chrome first. The user then grants permission to the wrong browser and the retry can continue failing; the inspect page should be selected from the same CDP/profile target as the daemon.</violation>

<violation number="2" location="src/browser_harness/admin.py:779">
P1: On Windows, if neither msedge nor chrome is currently running (or the PowerShell query fails for both), `_open_chrome_inspect()` returns silently without opening any browser window. The user gets no visual feedback and no inspect page opens, which is confusing during first-time setup. The macOS and Linux paths both fall through to `webbrowser.open(url)` as a last resort. The Windows block should do the same — remove the bare `return` (or add a `webbrowser.open` call before it) so that the `chrome://inspect/#remote-debugging` URL is at least attempted when a running process can't be resolved.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P1: On Windows, if neither msedge nor chrome is currently running (or the PowerShell query fails for both), _open_chrome_inspect() returns silently without opening any browser window. The user gets no visual feedback and no inspect page opens, which is confusing during first-time setup. The macOS and Linux paths both fall through to webbrowser.open(url) as a last resort. The Windows block should do the same — remove the bare return (or add a webbrowser.open call before it) so that the chrome://inspect/#remote-debugging URL is at least attempted when a running process can't be resolved.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/browser_harness/admin.py, line 779:

<comment>On Windows, if neither msedge nor chrome is currently running (or the PowerShell query fails for both), `_open_chrome_inspect()` returns silently without opening any browser window. The user gets no visual feedback and no inspect page opens, which is confusing during first-time setup. The macOS and Linux paths both fall through to `webbrowser.open(url)` as a last resort. The Windows block should do the same — remove the bare `return` (or add a `webbrowser.open` call before it) so that the `chrome://inspect/#remote-debugging` URL is at least attempted when a running process can't be resolved.</comment>

<file context>
@@ -761,6 +761,25 @@ def _chrome_running():
+                ).strip()
+                if executable:
+                    subprocess.Popen([executable, f"{scheme}://inspect/#remote-debugging"])
+                    return
+            except Exception:
+                continue
</file context>

[cubic-dev-ai]

P2: An expired or otherwise non-JSON response causes this example to reject before printing any endpoint results, so the audit cannot distinguish an authentication failure from API data and loses successful responses from the other requests. Parsing the response text with a JSON fallback would preserve the reported status and body for each endpoint.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At agent-workspace/domain-skills/bing-webmaster-tools/auditing.md, line 61:

<comment>An expired or otherwise non-JSON response causes this example to reject before printing any endpoint results, so the audit cannot distinguish an authentication failure from API data and loses successful responses from the other requests. Parsing the response text with a JSON fallback would preserve the reported status and body for each endpoint.</comment>

<file context>
@@ -0,0 +1,97 @@
+].map(url => fetch(url, {credentials: 'include'}).then(async response => ({
+  url,
+  status: response.status,
+  body: await response.json()
+})))).then(JSON.stringify)
+""" % (repr(site), repr(site), repr(site))
</file context>

[cubic-dev-ai]

P2: When Chrome and Edge are both running with discoverable local profiles, the recovery opens Edge's authorization page even though the daemon may have selected Chrome first. The user then grants permission to the wrong browser and the retry can continue failing; the inspect page should be selected from the same CDP/profile target as the daemon.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/browser_harness/admin.py, line 765:

<comment>When Chrome and Edge are both running with discoverable local profiles, the recovery opens Edge's authorization page even though the daemon may have selected Chrome first. The user then grants permission to the wrong browser and the retry can continue failing; the inspect page should be selected from the same CDP/profile target as the daemon.</comment>

<file context>
@@ -761,6 +761,25 @@ def _chrome_running():
     """Open chrome://inspect/#remote-debugging so the user can tick the checkbox."""
     import platform, subprocess, webbrowser
+    if platform.system() == "Windows":
+        for process_name, scheme in (("msedge", "edge"), ("chrome", "chrome")):
+            try:
+                executable = subprocess.check_output(
</file context>

[cubic-dev-ai]

1 issue found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="agent-workspace/domain-skills/bing-webmaster-tools/auditing.md">

<violation number="1" location="agent-workspace/domain-skills/bing-webmaster-tools/auditing.md:48">
P2: Properties with more than 25 sitemap rows will only return the first page from this exact URL, so an audit can miss sitemaps and crawl statuses. Label this as page 1 and document incrementing `pageNum` to enumerate all rows before treating the result as the complete known-sitemap set.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: Properties with more than 25 sitemap rows will only return the first page from this exact URL, so an audit can miss sitemaps and crawl statuses. Label this as page 1 and document incrementing pageNum to enumerate all rows before treating the result as the complete known-sitemap set.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At agent-workspace/domain-skills/bing-webmaster-tools/auditing.md, line 48:

<comment>Properties with more than 25 sitemap rows will only return the first page from this exact URL, so an audit can miss sitemaps and crawl statuses. Label this as page 1 and document incrementing `pageNum` to enumerate all rows before treating the result as the complete known-sitemap set.</comment>

<file context>
@@ -44,6 +44,10 @@ Verified endpoints (July 2026):
 - `/webmasters/api/sitescan/ignoreurlparams?siteurl=<encoded-property>` — configured URL parameter exclusions.
 - `/webmasters/api/submiturls/listcount` — URL submission quota/count metadata loaded by the SPA.
+- `/webmasters/api/sitemaps/overview?siteurl=<encoded-property>` — sitemap totals.
+- `/webmasters/api/sitemaps/list?siteurl=<encoded-property>&pageSize=25&sortBy=UrlCount&sortingOrder=Desc&pageNum=1` — known sitemaps and current crawl status.
+- `/webmasters/api/globalelements/settings` — account-level communication preferences.
+- `/webmasters/api/globalelements/messages` — notification-center messages and their site association.
</file context>

Suggested change

	- `/webmasters/api/sitemaps/list?siteurl=<encoded-property>&pageSize=25&sortBy=UrlCount&sortingOrder=Desc&pageNum=1` — known sitemaps and current crawl status.
	- `/webmasters/api/sitemaps/list?siteurl=<encoded-property>&pageSize=25&sortBy=UrlCount&sortingOrder=Desc&pageNum=1` — first page of known sitemaps and current crawl status; increment `pageNum` to enumerate all rows.