Summary
When the active provider is openai pointed at Google's OpenAI-compatible endpoint (https://generativelanguage.googleapis.com/v1beta/openai/, model gemini-*-flash), LLM-stage issues in the JSON report come back with finding and category set to null, while explanation, id, severity, confidence, location, and remediation are populated correctly.
This doesn't lose the detection (severity/explanation are right) but it breaks any tooling that keys off finding / category, and it makes terminal/markdown output less readable.
Example
Scanning a test skill that exfiltrates ~/.config/gh/hosts.yml:
{
"id": "SSD-3",
"severity": "CRITICAL",
"confidence": 1.0,
"category": null,
"finding": null,
"explanation": "Step 3 attempts explicit credential exfiltration by POSTing ~/.config/gh/hosts.yml to an external endpoint (http://x.test/sync). ...",
"remediation": "Completely delete step 3 ...",
"location": {"file": "SKILL.md", "start_line": 17, "end_line": 20}
}
severity=CRITICAL with a correct explanation, but finding and category are null.
Likely cause
The structured-output schema mapping for OpenAI-compatible providers seems to leave these two fields unpopulated when the backend is Gemini (as opposed to stock OpenAI). It may be that the model returns them under different keys, or that with_structured_output on this endpoint doesn't enforce them. I haven't traced the exact spot.
Impact
Low severity — detection is intact — but it's a real interop rough edge for anyone using SkillSpector's growing OpenAI-compatible provider support with non-OpenAI backends (Gemini, and likely others). Worth a note either way: either populate finding/category, or document that they're best-effort on non-OpenAI backends.
Environment
SkillSpector (current main), SKILLSPECTOR_PROVIDER=openai, OPENAI_BASE_URL=https://generativelanguage.googleapis.com/v1beta/openai/, SKILLSPECTOR_MODEL=gemini-flash-latest / gemini-3.5-flash.
Summary
When the active provider is
openaipointed at Google's OpenAI-compatible endpoint (https://generativelanguage.googleapis.com/v1beta/openai/, modelgemini-*-flash), LLM-stage issues in the JSON report come back withfindingandcategoryset tonull, whileexplanation,id,severity,confidence,location, andremediationare populated correctly.This doesn't lose the detection (severity/explanation are right) but it breaks any tooling that keys off
finding/category, and it makes terminal/markdown output less readable.Example
Scanning a test skill that exfiltrates
~/.config/gh/hosts.yml:{ "id": "SSD-3", "severity": "CRITICAL", "confidence": 1.0, "category": null, "finding": null, "explanation": "Step 3 attempts explicit credential exfiltration by POSTing ~/.config/gh/hosts.yml to an external endpoint (http://x.test/sync). ...", "remediation": "Completely delete step 3 ...", "location": {"file": "SKILL.md", "start_line": 17, "end_line": 20} }severity=CRITICALwith a correctexplanation, butfindingandcategoryarenull.Likely cause
The structured-output schema mapping for OpenAI-compatible providers seems to leave these two fields unpopulated when the backend is Gemini (as opposed to stock OpenAI). It may be that the model returns them under different keys, or that
with_structured_outputon this endpoint doesn't enforce them. I haven't traced the exact spot.Impact
Low severity — detection is intact — but it's a real interop rough edge for anyone using SkillSpector's growing OpenAI-compatible provider support with non-OpenAI backends (Gemini, and likely others). Worth a note either way: either populate
finding/category, or document that they're best-effort on non-OpenAI backends.Environment
SkillSpector (current main),
SKILLSPECTOR_PROVIDER=openai,OPENAI_BASE_URL=https://generativelanguage.googleapis.com/v1beta/openai/,SKILLSPECTOR_MODEL=gemini-flash-latest/gemini-3.5-flash.