agentleFS
seqraseqra/opentaint/skills/triage-dependencies/SKILL.md

triage-dependencies

Skill172 starsChanged 2 months agoApache-2.0View on GitHub

Mark which of a project's dependency libraries could introduce taint sources. Use to start source discovery

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read the project's dependency libraries and flag the ones that can introduce a taint source — a place untrusted data enters

    line 12
  2. Very specific:

    Read .opentaint/project/project.yaml — the dependencies list under each per-language projects entry is every third-party dependency the …

    line 24
  3. Very specific:

    Write in .opentaint/tracking/coverage.yaml (per Tracking) a flat list of the flagged libraries' packages

    line 32

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

Skill: Triage Dependencies

Read the project's dependency libraries and flag the ones that can introduce a taint source — a place untrusted data enters

Inputs

Provided by the caller, fall back to the default value when omitted. Ask back only when a required input is missing and has no sensible default

  • project-root (optional) — root of the target project. Opentaint keeps all analysis artifacts under the fixed <project-root>/.opentaint/ directory, so every .opentaint/... path below resolves there. Default: current directory

Workflow

1. List the dependencies

Read .opentaint/project/project.yaml — the dependencies list under each per-language projects entry is every third-party dependency the model resolved. Resolve each to the library it is. Most of a large project's dependencies are transitive infrastructure

2. Mark each library

For each library decide: could it introduce an attacker-controlled source — a method returning untrusted data (HTTP/RPC request data, message-broker payloads, deserialized untrusted input and so on)? Judge by the library's identity itself, read sources to get overviews, docs

3. Write the flag list

Write in .opentaint/tracking/coverage.yaml (per Tracking) a flat list of the flagged libraries' packages

When coverage.yaml already exists from a prior run, reconcile rather than overwrite: keep every listed package and add any dependency newly added to the model that could introduce a source. A flagged package whose usage shifted (new call sites, a version bump) needs no re-open — source discovery automatically plans any used member not yet verdicted. When unsure whether a package belongs, list it: an over-flag only costs one discovery pass, a missed library loses its sources on every later stage

4. Verify before returning

Re-check the full dependency list against your flags: confirm every dependency was judged, then re-read the ones you did NOT flag and make sure none of them can actually introduce a source. A library left out here loses its sources on every later stage and the run can't recover it. Add any package you missed to the list. This is a re-read of what you already wrote — simple grep or re-read is fine, no need to use some scripts.

Output

Short and concise report of what was done

Artifacts:

  • .opentaint/tracking/coverage.yaml — the flagged packages list

Summary:

  • one line per flagged package: the package and why it was flagged

Tracking

.opentaint/tracking/coverage.yaml — a flat list of the dependency packages flagged to drill for taint sources. Keep it clear from comments

packages:
  - <dependency-package-a>
  - <dependency-package-b>

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.