메뉴
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 직업 분류 기준
Model 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
| 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 filed