agentleFS
glebisglebis/claude-skills/recording/SKILL.md

recording

Skill410 starsChanged 5 months agoMITView on GitHub

Demo/recording mode that redacts personally identifiable and sensitive information from Claude Code's outputs. Use when the user invokes /recording or says they are about to record, screen-share, or demo their Claude Code session and want PII scrubbed in real time.

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 7 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When in doubt, redact. The cost of over-redaction in a demo is near zero.

    line 32
  2. Very specific:

    Use obviously dummy values, not plausible fakes that could be mistaken for real ones.

    line 36
  3. Distinctive:

    Keep replacements consistent within a session: the same real name maps to the same fake name every time, so the demo stays coherent.

    line 37
  4. Distinctive:

    When summarizing tool results back to the user, apply redaction to the summary.

    line 51
  5. Distinctive:

    When quoting file contents inline (e.g.

    line 52
  6. Distinctive:

    Avoid reading sensitive files into the visible transcript unnecessarily — prefer to act on them silently and report a redacted summary.

    line 53
  7. Very specific:

    If recording mode is OFF, /recording turns it ON.

    line 59
  8. Very specific:

    If recording mode is ON, /recording turns it OFF.

    line 60
  9. Distinctive:

    Before emitting any message while recording mode is active, scan the draft for:

    line 66
  10. Distinctive:

    If any hit, redact and re-check.

    line 72

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Recording Mode

Activate this mode when the user runs /recording or otherwise signals a demo/screen-share. Stay in this mode for the rest of the session unless the user says "stop recording", "/recording off", or equivalent.

Core rule

While recording mode is active, every user-visible output (chat text, code, file contents shown inline, tool result summaries, commit messages, file names invented for examples) MUST have sensitive content replaced with obviously fake placeholder data before it leaves the assistant.

This applies to text the model generates. It does NOT retroactively edit files on disk — only what the audience sees on screen. If asked to write redacted content to a file, do so explicitly; otherwise leave files alone.

What to redact

Replace these categories:

  • Names (people, partners, family, colleagues, clients) → Alex Doe, Jamie Roe, Sam Park
  • Handles / emails / phones / URLs with identifiers → @demo_user, user@example.com, +49 000 000 0000
  • Org / company / brand names (when private) → Acme Co, Globex
  • Locations — anything more specific than continent. City, neighborhood, street, venue, coordinates, IP-derived location → Some City, Main Street, Venue A. Even "Berlin" gets replaced if it could identify the user.
  • Dates — any real calendar date (birthdays, appointments, sessions, deadlines, deploy dates, transaction dates, file timestamps shown inline) → shift to placeholder dates like 2025-01-01, 2025-01-02. Keep relative ordering and weekday if it matters to the demo. Today's actual date should be replaced too if it appears in output.
  • Financial values (revenue, prices, salaries, invoice amounts) → round dummy numbers like €1,234 or $X,XXX
  • Medical info (diagnoses, medications, doses, symptoms, lab values) → [medication], [condition], [symptom]
  • Emotional / therapy / coaching content (feelings, session notes, DIMs/SIMs, relationship details) → [personal reflection]
  • Business info (deal terms, client lists, internal strategy, unreleased projects) → [business detail]
  • Credentials (tokens, keys, passwords, session IDs, file paths containing usernames) → sk-XXXX, /Users/demo/...
  • Genetic / health data specific to the user → [genetic marker]

When in doubt, redact. The cost of over-redaction in a demo is near zero; the cost of leaking is high.

Style of replacement

  • Use obviously dummy values, not plausible fakes that could be mistaken for real ones. Alex Doe not Andrey Volkov. Acme Co not Northwind Studio.
  • Keep replacements consistent within a session: the same real name maps to the same fake name every time, so the demo stays coherent. Maintain this mapping mentally for the duration of recording mode.
  • Preserve structure and length roughly so the demo still reads naturally (e.g. a real email becomes a fake email, not [REDACTED]).
  • Preserve technical accuracy of non-sensitive parts: code logic, library names, public APIs, framework terminology stay exact.

What NOT to redact

  • Public technical content: language keywords, public package names, public docs URLs, generic file names (README.md, package.json).
  • The user's own typed input — do not rewrite what they said, only what the assistant outputs.
  • Vault structure conventions and folder names that are already public knowledge from CLAUDE.md.

Tool calls

Tool calls themselves run normally — redaction is about what the assistant says. But:

  • When summarizing tool results back to the user, apply redaction to the summary.
  • When quoting file contents inline (e.g. showing a snippet of a daily note), redact the snippet.
  • Avoid reading sensitive files into the visible transcript unnecessarily — prefer to act on them silently and report a redacted summary.

Toggle behavior

/recording is a toggle. Calling it flips the current state:

  • If recording mode is OFF, /recording turns it ON. Reply with one short redacted line confirming it's on.
  • If recording mode is ON, /recording turns it OFF. Reply with one short line confirming it's off, then resume normal output.

Track the current state across the session. Natural-language equivalents also toggle: "I'm about to record" / "starting a demo" turn it on; "stop recording" / "demo done" / "you can stop redacting" turn it off. When in doubt about intent, infer from current state — if already recording and the user says "recording", they mean stop.

Self-check before sending

Before emitting any message while recording mode is active, scan the draft for:

  1. Any proper noun that isn't a public technical term.
  2. Any number that looks like money, age, dose, or measurement tied to the user.
  3. Any path containing glebkalinin, Brains/brain, real folder names from People/, Daily/, etc.
  4. Any emotional or medical vocabulary tied to a first-person subject.

If any hit, redact and re-check. Only then send.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.