Skip to main content
Remediation is a separate, explicit step. Nothing is edited during an assessment — the Agent Skill’s rule is that source changes happen only after the user chooses to apply a fix.

​
1. Get the prompt

This prints a remediation prompt built from the finding — the root cause, the smallest durable fix, the framework safeguard to prefer, and the verification that should fail before the change and pass after it — and records the finding as fix_suggested. The HTML report has the same thing behind Copy prompt to fix. Paste it into your coding agent, or work from it yourself.

​
2. Apply the change

Change the source, run the project’s own targeted tests, then re-run the specific security verification the finding named. Prefer the framework’s own safeguard over a hand-rolled check, and prefer the smallest change that removes the root cause over a broad rewrite.

​
3. Record what actually happened

Then, only after running the verification:
The finding’s status becomes fixed_verified.
Options on fix record: Exactly one of the four actions is required.
Never mark a finding verified unless the targeted security verification actually passed. A finding reaches fixed_verified only through a recorded passing verification — there is no other path, and that is the whole value of the field.

​
The history is append-only

Every step lands in fixHistory on the finding, with the instant, the action, whether verification passed, the changed files, and any note. The original evidence is preserved either way, so a reader can see what was claimed, what was changed, and whether it worked. Inspect it directly:

​
Try it against the fixture

The repository ships a reversible patch for the bundled vulnerable application, so you can see the whole loop without editing your own code.
1

Apply the patch

Then restart the fixture so the change takes effect.
2

Verify the behaviour actually changed

Before the fix the cross-account read returns 200. After it, 404.
3

Record it

Try --verification-failed first and inspect .myrqen/sessions/*/session.json: the status stays fix_applied, and the history keeps every step.
4

Put the fixture back

Restart the fixture again. Leaving the patch applied will make pnpm benchmark report a missed finding.

​
Retesting the whole application

A fix changes the application, so the honest way to confirm the wider picture is a new session:
A new session gets a new local report id and its own report files, so the before and after are both on disk and comparable.