agentleFS
ychampionychampion/ystack/skills/secure-diff/SKILL.md

secure-diff

Skill4 starsChanged 2 days agoMITView on GitHub

Security self-check of your own diff before you hand it over: scan for secrets, then walk every new input path for injection, missing authorization, unsafe file and network access, and risky defaults, and prove each suspect with a quick probe. Use before committing or pushing agent-written code, for "security check my changes", "is this diff safe", "check for secrets", or any change touching auth, user input, files, shell commands, SQL, HTML output, URLs or config.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before the first push of agent-written code.

    line 20
  2. Very specific:

    Use a real scanner if installed (gitleaks, trufflehog).

    line 32
  3. Distinctive:

    Every place the diff accepts data it didn't create: request params, headers, bodies, CLI args, env, files, uploads, webhooks, messages, …

    line 38
  4. Distinctive:

    Never paste a found secret into the report.

    line 80

≈ “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

Secure diff

Agents add input paths fast and forget who can reach them. This is a short pass over your own change, done by the author, before anyone else reviews it. It complements a full review; it doesn't replace one.

When it applies

  • Any diff that takes outside input, touches auth or permissions, runs commands, builds queries or HTML, reads or writes files by name, fetches URLs, or changes config and defaults.
  • Before the first push of agent-written code.

Procedure

1. Secrets

Scan the diff and any new files, including test fixtures, logs and notebooks:

git diff <base> | grep -nEi '(api[_-]?key|secret|token|passw|bearer|private key|-----BEGIN)'

Use a real scanner if installed (gitleaks, trufflehog). Any real value found: remove it, use an env var or the project's secret store, and tell the user the value must be rotated if it was ever committed or pushed.

2. List the new inputs

Every place the diff accepts data it didn't create: request params, headers, bodies, CLI args, env, files, uploads, webhooks, messages, model output. One line each, with file:line.

3. Walk each input to where it is used

SinkCheck
SQL / queriesparameters, never string concatenation
Shell / process spawnargument arrays, no shell string built from input
HTML / templatesescaped by default; no raw-HTML escape hatch on input
File pathsresolved and confined to an allowed directory; no .. escape
URLs fetched by the serverallowlist hosts; block internal addresses
Deserialization / evalno eval, unsafe YAML or pickle on outside data
Redirectsonly to known targets
Logsno secrets or personal data written

4. Authorization

For each new route, action or tool: who may call it, and where is that checked? Check that one user can't read or change another user's object by changing an id. A check in the UI only is not a check.

5. Defaults and failure

New config defaults closed (off, deny, private), not open. Errors fail closed and don't leak stack traces, paths or secrets to the caller. New dependencies are real, maintained packages.

6. Probe what you suspect

For each suspect, run something: a request with ../../etc/passwd, ' OR 1=1 --, <script>, another user's id, an internal URL. Record the command and the result. A probe that gets through is a finding.

Report

Secrets: none found | <removed: where; rotation needed: yes/no>
Inputs: <n>   Findings:
| # | file:line | Issue | Probe | Result | Fixed |
Not covered: <anything you couldn't check>

Rules

  • Never paste a found secret into the report; give its location only.
  • A suspect is settled by a probe or a quoted guard, not by "looks fine".
  • For high-stakes changes (auth, payments, sandboxing), also get an independent review.

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.