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
In this repository15 other files it gives its agents.
- analyze-external-methodsSkill
- analyze-findingsSkill
- appsec-agentSkill
- assemble-lib-rulesSkill
- build-projectSkill
- create-dataflow-modelSkill
- create-pass-through-modelSkill
- create-ruleSkill
- create-test-projectSkill
- debug-ruleSkill
- discover-attack-surfaceSkill
- generate-pocSkill
- orchestrate-stageSkill
- run-scanSkill
- triage-dependenciesSkill
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
- Very specific: line 39
Write .opentaint/issues/<slug>.md — the self-contained deliverable, <slug> a short kebab-case symptom name.
- Very specific: line 45
Run logs — the run's log files, by path: for analysis, any debug log or fact-reachability SARIF the caller cited, if present.
- Distinctive: line 54
Keep it tight: the header plus about one screen of body.
≈ “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.
Files
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
analysisissue — 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
resourceissue — 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 directorydiagnosis(required foranalysis) — the caller's brief engine-level cause: roughly where taint appears to die and why. A short hand-off, not a proven traceartifact(required foranalysis) — 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 reproducesetup(required forresource) — 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 —
analysisorresource - Setup — the exact command that reproduces it: the
opentaint test rule …/test model runforanalysis, or the failedopentaint scanforresource, each with its model, rulesets, and model dirs (plus final memory and timeout/backstop outcome forresource) - Run logs — the run's log files, by path: for
analysis, any debug log or fact-reachability SARIF the caller cited, if present; forresource, 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; forresource, the project model, rulesets, and model dirs in play (with their rough size) - TL;DR — 2–3 sentences: the symptom, and for
analysiswhere taint appears to die and what the engine should do instead
Below the header, free-form — whatever makes the case, at least:
analysis— theartifactunder 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 ananalysisissue, where taint appears to die
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
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.

