Name the Human
If this is wrong, whose name is on it?
One page, one row per thing that runs without you, ending in a name or a blank you can see.
The scripts, schema and privacy statement on GitHub Download the skill, v0.1.0
Run it as a script
The method ships as a small read-only tool, and the two buttons above are the whole distribution. Plain Node 22, no dependencies to install, MIT licensed, and every line is readable in an afternoon. If you use Claude Code or Codex, the download is an agent skill your harness can load directly; if you do not, it is five scripts you can run by hand. There is also a copy-paste prompt further down for any model at all, which needs nothing installed.
The privacy posture matters more than usual here, because the thing reads dotfiles. It reads only. It writes exactly one file, the output path you name. It makes no network calls of any kind, in any script. It records the names of secrets it sees, such as EVAL_API_KEY, and never their values, and the test suite checks that a fixture value cannot reach the output. It refuses to run without directories you name out loud, because there is no safe default for a tool like this. Every file it opened is listed in its own output, so you can check exactly what it touched.
The repository carries the schema, the privacy statement in full, and a table of every path the harvest reads and why.
The question
Most of us are running things we never individually approved. A scheduled workflow someone added two years ago. A cron that posts to a channel. A hook that fires on every commit. An agent with an API key. Each one was a reasonable idea at the time, and together they are a set of decisions nobody is making any more.
The question this asks is not "is it secure" or "is it compliant". It is narrower and harder to wriggle out of: if this thing is wrong, whose name is on it? Not a team. Not a role. Not whoever is on call. A person.
A surface counts if something acts on its output without a human deciding first. A linter does not count, because a person reads the result and decides. A scheduled job whose output goes straight into a channel someone acts on does count.
What you end up with
One page. Nine columns, one row per surface. The left of the table is filled by a machine: what the thing is, what it does unattended, who finds out if it goes wrong and how long that takes, how far the damage reaches.
The right of the table is five columns a machine may never fill: who is accountable, who the fallback is, whether that person can stop it alone, when a human last checked, and the verdict. Those are yours. The tool emits null and moves on.
That emptiness is the deliverable. A register where every owner field is populated with a squad name tells you nothing. A page where four rows say nothing at all in the accountable column tells you exactly where to spend Thursday.
It ends in a count: how many you reviewed, how many you named, how many you turned off. The last number is the one worth reporting.
Run it with any model
No installation, no account, nothing to sign up for. Paste this into whatever chat window you already trust. It works in two modes: if the model can read your files it scans the directories you name, and if it cannot it interviews you instead. Same output either way.
Help me build an accountability inventory of the automated things I run. This is not a security audit and not a compliance exercise. I am answering one question per surface: if this thing is wrong, whose name is on it? A surface counts if something acts on its output without a human deciding first. A linter does not count. A scheduled job whose output someone reads and acts on does count. When in doubt, include it and let me cut it. MODE If you can read my files, work in SCAN mode over the directories I name, and only those. Do not walk my home directory or the current directory unless I name it. Find candidates by looking for: scheduled workflows and cron entries, Vercel crons, launch agents, harness hook files, registered MCP servers, webhooks and callbacks, anything holding an API key, and any script invoked on a timer or by another system. Read any CODEOWNERS file you find and record what it claims, as evidence only. List every file you opened, list what you excluded and why, and list anything you noticed but were not given as a proposal for me to add next time. If you cannot read files, work in INTERVIEW mode. Ask me what runs without me touching it. Ask at most three questions at a time and keep going until I say stop. FOR EACH SURFACE, GIVE ME - id: stable across runs, built from where it lives and what triggers it - surface: what it is, in the words I would use to a colleague - location: path, URL, or platform - schedule: the trigger as written - existing_owner_signal: what the repo or platform already claims about ownership. A CODEOWNERS entry, a catalog owner field, a registry record. Report it verbatim as evidence. It is not an answer to the accountable question and you must not promote it into one - secret_names_referenced: the NAMES of any env var or secret the source references. Never a value - unattended_action: what it does when nobody is watching. "Drafts" and "sends" are different surfaces; do not merge them - detection.who_finds_out: who notices if the output is wrong. A person, a system, "nobody", or "not-determinable-from-source" when the source shows no detection path either way. The last one is a correct answer, not a failure, and it is different from "nobody" - detection.lag: immediately, next-run, a-quarter, never, or not-determinable-from-source - blast_radius: internal-draft, internal-decision, or external - moves_personal_data: true or false, independent of blast radius - stop_authority.how: the actual mechanism to stop it, or "unknown" - basis: under every one of the judged fields above, a short quote of the line you judged it from RULES YOU DO NOT BREAK 1. Leave accountable and fallback as null. Always. You may not name a person, suggest a person, or infer one from commit history, file ownership, CODEOWNERS, or anything else. Those fields are mine to fill and the point of this exercise is that I can see where they are empty. 2. Leave last_human_check, stop_authority.can_stop_alone and stop_authority.ever_tested as null. Same reason. 3. Do not invent surfaces. Only what you actually found or what I told you. 4. If I answer with a team, a role, or "whoever is on call", tell me that is a blank and move on. Do not record it. 5. Do not set any verdict. Leave every one as "unresolved". 6. Do not soften anything. If detection is "nobody" and "never", write that down plainly. 7. Do not guess. When the source does not show a detection path, write "not-determinable-from-source". OUTPUT Valid JSON matching the schema name-the-human/v0.3 at https://raw.githubusercontent.com/snapsynapse/skill-name-the-human/v0.1.0/name-the-human/references/schema.json, with a manifest of what you scanned, excluded and proposed, and a totals object where reviewed is the count and the other three are zero and reviewed respectively: named 0, killed 0, unnamed_still_running equal to reviewed. Then render it as a markdown table, one row per surface, nine columns: surface, unattended action, who finds out and how long, reach, accountable, fallback, can they stop it alone, last human check, verdict. Leave the last five columns for me. Finish with the shortest list you can of the surfaces I should look at first, ordered by blast radius and then by detection lag, and say why each one is on that list. I do not need to give you any credentials, customer names, or secrets to do this, and you should not ask for any.
The part that is not optional
Fill the five human columns yourself, alone, in one sitting. Do not delegate it, do not let a model draft it for you, and do not accept a team name in the accountable column. The moment a machine fills that field, the only load-bearing claim on the page is gone and you are back to a register that looks complete and means nothing.
Then act on the count. A surface with no name, no detection and wide reach is not a documentation problem. It is a thing to turn off.