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

.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