From Findings to a Trust Decision

SkillSpector’s report is where diverse evidence becomes an operational choice, but the score is not the choice by itself. This chapter explains how confidence, severity, repetition, executable context, baselines, completeness, and integration boundaries shape that choice. The aim is practical: readers should be able to read a SkillSpector result, decide whether to allow, warn, or block, and preserve the evidence and limitations that make the decision defensible.

A scanner is useful only if its output survives contact with a real workflow. A developer may need a quick terminal result, a CI system may need SARIF and exit codes, and an agent may need a structured safe_to_install response. Those consumers ask for different shapes, but they should be applying the same underlying judgment. SkillSpector keeps the common logic in the report stage while leaving the final strictness of the gate to the integrating operator.

The Score Compresses Evidence; It Does Not Replace It

SkillSpector computes a risk score from findings rather than simply counting matches. Each finding has a severity and a confidence. The base contribution is 50 points for CRITICAL, 25 for HIGH, 10 for MEDIUM, and 5 for LOW, scaled by the finding’s confidence after it is clamped to the 0–1 range. That scaling recognizes a basic difference between a strong, concrete proof and a tentative heuristic signal.

The score also uses diminishing returns within each rule. The first occurrence of a rule receives its full weight, the second receives half, and the third receives a quarter; further repetitions do not continue inflating the score. This keeps a file with hundreds of similar matches from saturating the score simply because a pattern repeats. It does not remove the repeated findings from the report. The evidence remains available for review, while the summary avoids treating repetition as unlimited additional risk.

Executable context adds another distinction. When a finding comes from an executable script file, SkillSpector can apply a 1.3 multiplier. Findings in documentation-like files are not multiplied merely because they contain security-related words. The reason is not that documentation is always safe. It is that a code path with execution capability generally deserves a different posture from a sentence describing that capability. The multiplication is a policy default, not a measured probability that the script is malicious.

A simple example shows why the inputs matter. A HIGH finding with 0.8 confidence contributes 20 points before file weighting. If the evidence is in an executable file, the contribution becomes 26 points after the 1.3 multiplier. A second occurrence of the same rule would begin at half the rule weight, subject to its own confidence. The arithmetic gives the operator a consistent posture signal, but it says nothing about whether the underlying behavior is necessary for the skill’s purpose. That question still belongs to evidence and review.

The report maps the final score into broad bands: LOW from 0 to 20, MEDIUM from 21 to 50, HIGH from 51 to 80, and CRITICAL from 81 to 100. The corresponding default recommendations are SAFE, CAUTION, DONOTINSTALL, and DONOTINSTALL. These are convenient defaults for a shared contract.