refactor(#237): add silent-failure severity escalation guidance

internal/scaffold/fullsend-repo/skills/code-review/SKILL.md

@@ -82,6 +82,11 @@ dimension carry over to another — each requires its own scrutiny.
   (e.g., what happens if a critical sub-component fails — does the
   caller degrade gracefully or silently proceed?). Trace the full path
   from where the mechanism is set to where it is read.
+- **Silent-failure severity escalation:** When a code path silently
+  produces wrong results or skips critical work without any error signal,
+  rate the finding **medium or higher** — regardless of how unlikely the
+  triggering condition seems. Severity reflects the failure mode (silent,
+  total, no error signal), not the probability of triggering.
 - Test adequacy: are the right behaviors tested?
 - Do the tests actually constrain the code's behavior, or do they
   merely assert it runs?

internal/scaffold/fullsend-repo/skills/pr-review/sub-agents/challenger.md

@@ -32,7 +32,13 @@ For each finding:
    - "Missing test" when the test exists in a different file
 2. **Assess severity calibration.** Is the severity proportionate to
    the actual risk? Downgrade findings whose severity is inflated
-   relative to the codebase context.
+   relative to the codebase context. **Exception — silent-failure
+   findings:** Do not downgrade findings where the failure mode is
+   silent (code appears to succeed but produces wrong results with no
+   error signal). The severity of silent failures reflects the failure
+   mode, not the probability of triggering. Probability-based reasoning
+   ("X is likely Y, so low impact") is not grounds for downgrading a
+   silent-failure finding.
 3. **Identify duplicates.** Findings from different dimensions that
    describe the same underlying issue should be merged. Keep the
    higher severity and the more specific remediation.

internal/scaffold/fullsend-repo/skills/pr-review/sub-agents/correctness.md

@@ -33,6 +33,24 @@ or inter-component contract in the diff:
   unavailable, does the caller handle it or silently proceed as if it
   succeeded?
 
+### Silent-failure severity escalation
+
+When a code path silently produces wrong results, returns stale or
+incorrect data, or skips critical work **without any error signal** to
+the caller, rate the finding **medium or higher** — regardless of how
+unlikely the triggering condition appears under current usage.
+
+Severity reflects the **failure mode** (silent, total, no error signal),
+not the **probability of triggering**. A bug that silently corrupts data
+for all affected users is more severe than a bug that crashes loudly for
+some, regardless of which is more likely today.
+
+Anti-pattern — probability-based severity discounting: "Low impact since
+X is likely Y" is not a valid severity justification when the failure
+mode is silent and total. The defensive-coding principle applies: code
+must handle all valid inputs correctly, not just the currently expected
+ones.
+
 **Consumer completeness:** If the diff adds new values to an enum,
 dispatch table, JSON schema enum, or case/switch structure, identify all
 code paths that consume or branch on that type (including scripts,