chore(skills): make public-repo scrubbing explicit in ship and babysit (#6819)

The repo is public and both skills publish permanently. `/ship` already listed
what to omit, but the rule only fired inside that skill — a PR opened directly
with `gh pr create` skipped it entirely, which is how a customer name, a
knowledge base id, and verbatim sheet and column names reached a public PR
description.

Ship's list now covers every artifact rather than just the title and body,
names verbatim customer content as its own category, draws the line on
aggregate counts (fine detached from a tenant, not fine attributed to one),
and carries a pre-publish grep so the check is mechanical instead of
remembered.

Babysit had no such guidance at all despite posting replies continuously, and
triage is precisely where prod evidence gets pasted in. It now has a short
section plus a hard rule, pointing at ship's list rather than restating it.

.agents/skills/babysit/SKILL.md

@@ -134,9 +134,21 @@ round. Always check both conditions freshly after every push.
 When the loop ends, summarize: how many rounds it took, what was actually fixed (one line each),
 what was pushed back on as a false positive and why, and the final Greptile score / thread count.
 
+## Public-repo hygiene
+
+Every reply, comment and commit you post here is public and permanent, and review bots quote
+your replies back so a leak propagates. Before each post, strip anything that ties the change to
+a tenant: customer/company names, workspace/user/org/KB/connector IDs, emails, tenant hostnames,
+verbatim document/sheet/folder names, log lines, and per-tenant DB output. Cite the mechanism and
+aggregate numbers instead — see `/ship`'s "What to Omit" for the full list and the pre-publish
+grep. Triaging a finding often means pasting evidence you gathered from prod; that is exactly the
+moment this gets violated. Check before posting, not after: editing a comment does not unsend its
+notification email.
+
 ## Hard rules
 
 - Never post the two re-review mentions as a single combined comment.
+- Never paste prod evidence into a reply without scrubbing it first (see above).
 - Never resolve a thread without replying to it first.
 - Never fix a finding with a hacky workaround — if the clean fix isn't obvious, find the sibling
   pattern elsewhere in the codebase solving the same class of problem and match it.

.agents/skills/ship/SKILL.md

@@ -102,13 +102,20 @@ chore(scope): description for maintenance
 
 ## What to Omit
 
-The repo is public. Keep the title and description to the code change and its reasoning — never:
+The repo is public. **Everything you publish — title, description, commit messages, and every later comment — must stand on its own without the incident that produced it.** Never include:
 
-- Customer, company, or user names; workspace/user/org IDs; email addresses
+- Customer, company, or user names; workspace/user/org/KB/connector IDs; email addresses
 - Prod or staging operational data: log lines, DB rows, metrics, timestamps, incident details, canary/alert output
-- Infrastructure specifics: hostnames, ARNs, internal URLs, env var values, secret names
+- Infrastructure specifics: hostnames (incl. tenant subdomains), ARNs, internal URLs, env var values, secret names
+- Verbatim customer content: file names, document titles, sheet/column names, folder paths
 
-Describe the bug by its mechanism, not by how you found it. "Expired OAuth credentials fail to refresh in the worker" — not "the Sheets canary failed at 16:31Z for workspace abc-123".
+Describe the bug by its mechanism, not by how you found it. "Expired OAuth credentials fail to refresh in the worker" — not "the Sheets canary failed at 16:31Z for workspace abc-123". Aggregate counts are fine once detached from the tenant ("1,379 PDFs failed"); the same number attributed to a named customer is not. Replace real examples with placeholders (`<real sheet name>`) rather than cutting them — the illustration is usually the useful part.
+
+**Scrub before publishing, not after** — a leak is public the instant it posts, and editing later does not unsend the notification email. This applies to every PR you open, including ones created directly with `gh pr create` rather than through this skill. Grep the title, body, and `git log origin/staging..HEAD` before publishing:
+
+```bash
+grep -niE 'customer-or-company-name|@[a-z0-9.-]+\.(com|io|ai)|[0-9a-f]{8}-[0-9a-f]{4}-|\.sharepoint\.com|arn:aws|https?://[a-z0-9.-]*\.internal'
+```
 
 ## PR Description Format