القائمة
Write an OpenTaint engine-issue report from a confirmed diagnosis, optionally opening a GitHub issue. Use when engine-side issue got confirmed and requires report
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | report-analyzer-issue |
| description | Write an OpenTaint engine-issue report from a confirmed diagnosis, optionally opening a GitHub issue. Use when engine-side issue got confirmed and requires report |
| license | Apache-2.0 |
| metadata | {"author":"opentaint","version":"0.2"} |
Turn a confirmed engine-level diagnosis into a self-contained .opentaint/issues/<slug>.md report, and optionally a GitHub issue. It only writes the report from the diagnosis, the test project, and the rule or approximation it concerns — it runs no analysis of its own
From the caller; if omitted, fall back to the default. Ask only when a required input is missing and has no sensible default
<diagnosis> — debug-rule's engine-level conclusion: where taint dies (file:line + instruction), the fact-reachability trace up to the last reachable fact, and observed vs expected verdict<test-project> / <test-compiled> — the project the artifact was tested on and debug-rule traced, already built by create-test-project. Default: .opentaint/test-projects/<name> / .opentaint/test-compiled/<name><artifact> — the rule or approximation the issue concerns: a rule's full id and ruleset, or the approximation's target method(s)<issue-file> — where to write the report. Default: .opentaint/issues/<slug>.md; <slug> is a short kebab-case symptom name (a filename — no spaces or hashes)<open-issue> (optional) — whether to also file at github.com/seqra/opentaint; the main agent decides and passes this. Default: noFile a report only for an engine issue debug-rule already confirmed. The diagnosis must establish all three; if any is missing, return to the caller and ask for debugging first — don't verify or run anything yourself:
dropped-external-methods.yamlWrite <issue-file> — this file is the deliverable; never return the diagnosis as chat text only. Assemble from the inputs:
<test-project> path, the test command (test rule run / test approximation run), and the failing test-result.json snippet (e.g. a positive sample stuck at falseNegative)<artifact>: a rule's full id and ruleset, or the approximation's target method(s)Sink.java:42; observed nonefile:line and the instruction, quoted up to the last reachable factKeep it to about one screen plus the test project
When <open-issue> is set, file the same content to the fixed repo:
gh issue create --repo seqra/opentaint \
--title "<slug>: <one-line symptom>" \
--body-file <issue-file>
<issue-file> (always), and the issue URL if one was filedModel a library method's taint propagation as a passThrough approximation config. Use for a dropped external method whose propagation is simple copying
Author and verify an OpenTaint detection rule for a vulnerability class on JVM code. Use whenever a rule needs to be created for an uncovered vulnerability, or an existing rule needs a false-positive or false-negative fix
Create an OpenTaint test project with annotated positive/negative samples for verifying a rule or approximation. Use when a rule or approximation needs a test project to check against
Debug a rule or approximation that behaves unexpectedly by tracing where taint is dropped. Use when its samples won't pass after repeated attempts, or it passes tests but is wrong on a real scan
Mark which of a project's dependency libraries could introduce taint sources or sinks. Use to start attack-surface discovery
Run an end-to-end application-security analysis on a JVM project with OpenTaint — build, scan, model missing library methods, triage, and confirm vulnerabilities. Use when the user asks to find vulnerabilities, run SAST, or scan a Java/Kotlin app for security issues