Plate

Use before any prose artifact goes public - a blog post, social post, README section, PR or issue body, commit message, release notes - to scrub identity and infrastructure leaks and apply writing conventions. Also use when the user asks to "scrub this", "is this safe to post", or "clean this up before it goes out". For repo and git-history leak scans use publish-readiness instead.

Plating is the last look before the dish leaves the kitchen: nothing goes out with a thumbprint on the rim. This skill is that final pass over a single piece of outward-facing writing. It catches the things that leak the author's machine, identity, or internal world, and enforces the writing conventions, before the words are published where they cannot be unpublished.

This is per-artifact prose hygiene. It is the companion to publish-readiness, which gates a whole repo and its git history; reach for that one for source trees and commit history, this one for the thing you are about to paste into a post, PR, or commit.

What to scan for

Run every check against the artifact text. Report each hit with its location and a concrete replacement.

1. Infrastructure and identity leaks

• Internal hostnames and machine names. Personal box names, lab hostnames, anything that is not a public, intentional reference. Replace with a generic placeholder or the public project name. A cold agent will not know the user's machine names: ask for them, or flag any internal-looking host (*.local, mDNS names, lab-style or pet-name hosts, non-public domains) for confirmation rather than letting it pass.
• Private IPs. RFC 1918 ranges (10., 172.16-31., 192.168.). Replace with documentation ranges: RFC 5737 (192.0.2.x, 198.51.100.x, 203.0.113.x) or RFC 2544 (198.18.x). A scanner that blocks all private ranges will also flag a "fake" 192.168.x placeholder, that is correct, use the doc ranges.
• LAN service URLs, local ports, internal endpoints. localhost:<port>, http://192.168..., internal dashboards. Replace with example.com or a neutral description.
• Absolute home paths. /home/<user>/..., /Users/<name>/... leak a username. Generalize to ~/ or a relative path.
• Personal email addresses that are not the author's public identity.

2. Authorship disclosure

• No statement that an AI, assistant, or model wrote or co-wrote the user's content, unless the user explicitly wants it. This is broader than commit trailers. Match phrasings like "written with help from", "with help from ", "generated by", "co-written by an AI", "drafted by", as well as named-model mentions in an authorship context. Default action: propose deleting the line, confirm with the user.
• No Co-Authored-By / Generated with / Assisted by trailers in public commits, PR bodies, or release notes.

3. Writing conventions

• Honor the project's or user's house style. The canonical example: no em dashes. Replace — with a comma, period, colon, or rewrite the sentence; never leave a literal em dash in scrubbed output.
• Watch for self-targeting irony: prose that explains a scanner rule by quoting the exact trigger string trips the scanner. Write around it (say "a private IP" instead of typing one), or use a doc-range placeholder.

How to run it

The draft is usually pasted text, not a file. Write it to a temp file (or scan it inline) first, then sweep:

bash

# Mechanical leak sweep. This is a FLOOR, not the whole check.
grep -nE '(\b10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)|localhost:[0-9]+|/home/[a-z]|/Users/[A-Za-z]|—|Co-Authored-By|Generated with' artifact.md

The regex only catches the mechanical hits. The two highest-stakes leak types do not match it: internal hostnames (you must add the project's and author's machine names, or eyeball section 1) and authorship-disclosure lines (eyeball section 2). An agent that treats the grep as the check will miss both. Read the prose by eye for those. A policy-driven scanner beats ad hoc grep for repeat use; content-guard enforces a leak policy and can run as a pre-push hook.

Preview, then apply

1. Scan and present every hit as a table: what was found, where, and the proposed replacement.
2. Wait for the user to confirm. Do not silently rewrite their voice; a hostname is an obvious fix, a sentence rewrite to dodge an em dash is a stylistic call they may want to make.
3. On confirmation, apply the replacements and show the diff.

Rules

• The author's public git/social identity is allowed; their private one is not. Know the difference before flagging an email or handle.
• A placeholder must stay technically valid. Swapping a real IP for 999.999.x to "be safe" produces broken docs; use the reserved doc ranges.
• Flag, do not auto-delete, anything ambiguous. A code sample that legitimately shows localhost:3000 in a tutorial may be intentional; ask.
• This pass is necessary, not sufficient, for a repo. Publishing a whole project still goes through publish-readiness for the tree and the git history.

Common mistakes

• Scrubbing the visible draft but missing the same leak in the commit message or PR body that ships with it.
• Replacing a private IP with a made-up invalid one instead of a reserved documentation range.
• Rewriting the user's voice without showing the change first.
• Treating a clean prose scan as clearance to publish the repo. Different gate.
• Leaving an em dash in because it "reads fine", when the house style forbids it.