Skill: Debug Rule

Diagnose why a rule or approximation behaves unexpectedly on a model — samples that won't pass after repeated attempts, a missed flow, or a spurious finding on a real scan — by tracing where taint is dropped, and decide who owns the fix: the rule, a missing library model, or the engine

Inputs

From the caller; if omitted, fall back to the default. Ask only when a required input is missing and has no sensible default

• Rules <full-ids> — the security rule to trace AND every library rule it refs (source/sink), each as <ruleSetRelativePath>.yaml:<shortId>; fact-reachability runs only the rules you list and silently disconnects the join if a ref is missing. For an approximation, trace the rule whose sample routes taint through the approximated method
• Project model <model-dir> — the model where the behavior shows up. Default: .opentaint/test-compiled/<name> for a test project, or .opentaint/project for a main scan
• Ruleset <rules-dir> — Default: builtin plus .opentaint/rules
• Output directory <results-dir> — where the debug SARIF lands. Default: .opentaint/test-results/<name> for a test model, or .opentaint/results for a main scan
• Dropped external methods <dropped-file> — the list from the run that showed the problem. Default: dropped-external-methods.yaml next to that run's SARIF
• Approximation directories <config-dir> / <approx-dir> (optional) — apply when the behavior depends on them, so the debug run matches the run that showed the problem. Default: .opentaint/pass-through, .opentaint/dataflow

Workflow

1. Precondition — library model complete