agentleFS
seqraseqra/opentaint/skills/report-analyzer-issue/SKILL.md

report-analyzer-issue

Skill172 starsChanged 2 months agoApache-2.0View on GitHub

Write a self-contained OpenTaint engine-issue report from an analysis diagnosis or a full-scan failure. Use when an engine-side issue needs a report

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. Very specific:

    Write .opentaint/issues/<slug>.md — the self-contained deliverable, <slug> a short kebab-case symptom name.

    line 39
  2. Very specific:

    Run logs — the run's log files, by path: for analysis, any debug log or fact-reachability SARIF the caller cited, if present.

    line 45
  3. Distinctive:

    Keep it tight: the header plus about one screen of body.

    line 54

≈ “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: Report Analyzer Issue

Turn a suspected engine-level problem into a self-contained .opentaint/issues/<slug>.md report. It runs no analysis of its own — it only writes the report from what the caller supplies. Two kinds:

  • an analysis issue — a suspected engine-level taint-propagation problem the caller couldn't resolve with a rule or a model (the analyzer's result looks wrong)
  • a resource issue — a full-project scan that produced no SARIF after its allowed retry, memory bound, or timeout backstop; no taint diagnosis, just the setup that triggered it so the engine team can reproduce

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
  • diagnosis (required for analysis) — the caller's brief engine-level cause: roughly where taint appears to die and why. A short hand-off, not a proven trace
  • artifact (required for analysis) — the rule or model the issue concerns: a rule's full id and ruleset, or the model's target method(s)
  • name (optional, analysis) — the test-project name the artifact was traced on; its tree is .opentaint/test-projects/<name> and model .opentaint/test-compiled/<name>, cited so the engine team can reproduce
  • setup (required for resource) — what was running when the scan failed without SARIF: the ruleset(s), model dirs, project model, final memory bound, timeout/backstop outcome, scan log, and commit hash (git rev-parse HEAD)

Workflow

1. Gate

The inputs pick the kind: a diagnosis (+ artifact) is an analysis issue, a setup is a resource issue.

For an analysis issue, write from the caller's brief cause as supplied — don't verify, reproduce, or run anything yourself. This is a first-pass approximate hand-off to the engine team, not a proven diagnosis; whatever the caller gives is enough to write the report.

For a resource issue, the gate is simpler: the caller confirms the full-project scan completed its allowed retry/backstop without producing valid SARIF. No taint diagnosis is required — write the report from the setup.

2. Write the report

Write .opentaint/issues/<slug>.md — the self-contained deliverable, <slug> a short kebab-case symptom name. Open with a fixed header so the engine team can triage at a glance, then free-form detail below it.

Header (both kinds):

  • Type — analysis or resource
  • Setup — the exact command that reproduces it: the opentaint test rule … / test model run for analysis, or the failed opentaint scan for resource, each with its model, rulesets, and model dirs (plus final memory and timeout/backstop outcome for resource)
  • Run logs — the run's log files, by path: for analysis, any debug log or fact-reachability SARIF the caller cited, if present; for resource, the scan's output log
  • Minimal repro — the smallest set of files/folders that demonstrates it: for analysis, the test project .opentaint/test-projects/<name> if one was named; for resource, the project model, rulesets, and model dirs in play (with their rough size)
  • TL;DR — 2–3 sentences: the symptom, and for analysis where taint appears to die and what the engine should do instead

Below the header, free-form — whatever makes the case, at least:

  • analysis — the artifact under test (rule id + ruleset, or model target method(s)); the caller's brief cause; observed vs expected and any fact-reachability trace, if the caller supplied them; a 1–3 sentence hypothesis of what the engine does wrong (a hypothesis, not a fix)
  • resource — the model's rough size (classes/modules if known) and the commit hash (git rev-parse HEAD) it was built from

Keep it tight: the header plus about one screen of body.

Output

Artifacts

  • .opentaint/issues/<slug>.md — the self-contained issue report (the deliverable)

Summary

  • the kind (analysis / resource) and the one-line symptom; for an analysis issue, where taint appears to die

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.