Skill: Create Rule

OpenTaint is a whole-program, interprocedural, field-sensitive alias analysis engine. It already propagates through visible application code, calls, aliases, and individual fields; custom rules and approximations model only the assigned source, sink, or opaque-method boundary. Compile-time constants and literals carry no taint, so a source or carrier whose output is only a constant introduces nothing.

A unit names the source or sink members to detect. Identify an existing built-in or project library rule when it already implements the boundary, otherwise author a custom rule, then verify the unit against its test project. Every selected or created source rule must carry the unit's untrusted-data-source tag, and every selected or created sink rule must carry its unit group's *-sink tag. Production joins use those tags and are assembled later only when a new sink tag needs one.

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
• language (required) — target language for this project and language-specific instructions
• side (required) — sources or sinks; the unit's side. It selects the unit file, the sample style, and the test sub-project
• unit (required) — the <package-kebab> identifying the unit. Its spec and tracking are in .opentaint/tracking/rules/<side>/<unit>.yaml; its test project is .opentaint/test-projects/<unit>/<side> and its compiled model .opentaint/test-compiled/<unit>/<side>
• fix-target (optional) — a created rule <path>#<id> the main scan flagged, plus the false positive or false negative to correct. When set, narrow or broaden that one rule instead of authoring from the unit

Workflow

1. Check existing coverage