Checks

fix-prompt

fix-prompt renders the findings of a verify run into a deterministic instruction block you can hand back to the agent.

What it does

Run paranoid fix-prompt the same way you run verify, and instead of a report it prints one deterministic, copy-paste-ready instruction block: a contract up front (fix the code, do not change the tests or suppress a finding), one numbered instruction per open finding, worst severity first, and a closing line asking for proof that the whole build, lint, and test suite still passes.

$ paranoid fix-prompt --claims summary.md
Fix the code. Do not change the tests, do not weaken any assertion, and
do not suppress or delete findings to make this pass.

1. [CRITICAL] TI001 internal/calc/calc_test.go
   Restore the deleted test file at internal/calc/calc_test.go; do not
   delete a test to make the suite pass. Evidence: test file with 1
   test functions deleted.

2. [MEDIUM] EH001 internal/app/save.go:4
   Restore proper error checking around the call in
   internal/app/save.go (around line 4) instead of discarding the
   result. Evidence: _ = f.Close().

When every instruction above is done, prove it: rerun this project's
full build, lint, and test suite (the equivalent of `make check`) and
show that it passes.

Hand that block straight back to the agent (a chat message, a follow-up prompt, a CI comment) and re-run verify once it replies.

Where each instruction comes from

Every rule in the registry carries a Fix template: a plain-English, imperative instruction with placeholders for the finding's file, line, evidence, message, and suggestion. The template language is a restricted subset of Go's text/template: only two helper functions exist, shared by every rule, and no rule can add its own.

Function	What it does
atLine	Turns a possibly-zero line number into a sentence fragment ("line 12", or "an unspecified line" when the line is 0 or unknown)
evidenceOrNote	Falls back to "no evidence recorded" when the finding's evidence text is empty

A registry test fails the build if any rule is missing a Fix template, and every template must render without error even on a zero-value finding. When a rule's detection logic changes, its Fix template is updated in the same pull request; this is part of the rule-authoring checklist in docs/rules.md.

Findings are already filtered

Findings already suppressed by a baseline never show up here, since fix-prompt only ever sees the findings verify would have scored. See Baseline & suppressions.
Skipped checks are listed at the end as "could not verify" notes, not silently dropped.
Instructions are ordered by severity, then rule ID, then file: the same input always produces the same block, in the same order.

Two ways to run it

By default, fix-prompt [path] runs the verify pipeline itself, accepting the same --base, --head, --claims, --session, --sandbox, and baseline flags as verify.

Pass --report <file> to render from an already-generated --format json verify report instead of re-running the pipeline. --report cannot be combined with any pipeline flag (base, head, claims, session, sandbox, baseline); either point fix-prompt at a report or let it verify the range itself, never both.

paranoid verify --format json --output report.json
paranoid fix-prompt --report report.json

Flags

Flag	Default	Meaning
--report string	none	Read findings from an already-generated JSON verify report instead of running the pipeline
--format string	text	Output format: text or json
--output string	stdout	Write the instruction block to a file instead

Plus every pipeline flag verify has: --base, --head, --offline, --sandbox, --sandbox-image, --sandbox-timeout, --compare-base, --claims, --session (and its hidden --claude-session alias), --baseline, and --no-baseline. See verify & flags for what each one means.

JSON output

--format json follows its own versioned schema, independent of the verify report's schema. See Report & schema for the exact shape: {schema_version, instructions: [{rule_id, severity, file, line, instruction}], notes}.

Exit code

fix-prompt produces no score or verdict of its own; it only reorders and re-renders findings a verify run already produced. It exits 0 once it renders successfully, no matter how many instructions it printed, so --fail-under and --strict do not apply to it. It exits 3 only when it could not produce an instruction block at all: bad flags, a git failure, or an unreadable or wrong-schema --report file.