refine-plan-b1187f — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited refine-plan-b1187f (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Loop the review pipeline over a plan until no new findings are accepted. Writes back to the plan file in place.
At the start of every invocation (including re-runs from Step 5), use update_plan to track each step, restating any remaining steps of a parent workflow alongside them:
$review-plan skill$evaluate-findings skill$apply-findings skill$refine-plan skill if changed.turbo/plans/<slug>.md.turbo/plans/*.md. If exactly one file exists, use it.turbo/plan.md if .turbo/plans/ does not exist$turboplan and stopIf multiple candidates exist and the choice is non-obvious, use request_user_input.
State the resolved path before continuing.
Unless an explicit path or slug was passed, or .turbo/loops/<slug>.md exists with Status: active, confirm the resolved plan still describes work that remains to be done. The signal is a frontmatter status: of done.
When the signal fires, output it as text. Then use request_user_input to offer:
.turbo/plans/, then confirm that plan against this same signalOn Leave the plan alone, call update_plan to drop the remaining refine steps, restating any remaining steps of a parent workflow, then continue with the next step of the active workflow.
Loop state lives at .turbo/loops/<slug>.md — slug from the resolved plan; for a legacy single-file fallback, use the file's basename. At the start of every invocation, read the ledger if it exists.
Status: line is closed): write a fresh ledger with Status: active, then attempt create_goal with the objective: "Run the $refine-plan loop on <plan path> until converged: a run with no changes, a prose-only round, or remaining findings that do not justify another re-run. Loop state: .turbo/loops/<slug>.md; re-read it after any context compaction and do not re-adjudicate findings it records as rejected. Mark this goal complete when the loop converges." If an unfinished goal already exists, an outer workflow owns it; continue without creating one.Status: active): this invocation is the iteration after the last one the ledger records, whether a Step 5 re-run or a resumption after an interruption. Continue from the recorded state. If no unfinished goal exists, attempt create_goal with the same objective as a fresh loop.Status: closed; if this loop created the goal, mark it complete with update_goal. An inherited goal stays active for the outer workflow. A halt on an unresolved failure leaves Status: active and the goal untouched, so the next invocation resumes the recorded state.$review-plan SkillRun the $review-plan skill on the resolved plan.
Always run this step even if the plan looks polished.
$evaluate-findings SkillRun the $evaluate-findings skill on the review findings from Step 2.
$apply-findings SkillRun the $apply-findings skill on the evaluated results.
$refine-plan Skill if ChangedCheck whether the plan file was edited during Step 4. Any edit counts.
Iteration 1 is the initial run; iteration 2 is the first auto-re-run; and so on. The loop is not capped; it terminates on its own: when a run makes no changes, when a round makes only prose-only edits, or when you judge a further re-run pointless.
If changes were made, classify what Step 4 edited:
$refine-plan again by reading and following the installed skill instructions, passing the resolved path. If the round contains both structural and prose-only edits, treat it as structural and re-run automatically.If changes were made but you judge a re-run unnecessary, output a summary of what changed and your reasoning for stopping, then stop instead of re-running.
Judge convergence by the trend across iterations: when rounds have stopped surfacing defects (contradictions, infeasible steps, missing requirements) and keep surfacing improvements of kinds earlier rounds already applied, a further re-run is pointless even though the edits were structural. A round that surfaces no defects is the termination signal; never add a confirmation round, an extra reviewer, or review steps beyond this skill's own.
Judge the kind of surviving defect as well as the trend. Once earlier rounds have drained the design- and requirement-level defects and a round's findings are dominated by claims that a named identifier does not exist or does not match its declaration, the plan has passed the point where reviewing it as text pays, even when the count is rising and every finding is genuine. Implementation surfaces that class immediately; a further re-run is pointless. Expect any round that adds mechanism to seed defects at the seams it creates.
When a round's findings turn on behavior nobody has observed, either how a platform, framework, or dependency behaves, or what a plan-specified algorithm produces on its inputs, prefer a cheap instrumented experiment to another review round. Run it in a temp directory outside the repo, confirm that each setting it varies took effect, and record what it shows in the plan before judging whether another round is warranted. For a plan-specified algorithm, write it as a script there, assert the plan's stated postconditions over randomized and degenerate inputs, and rewrite its rule only from what that run shows. Keep in the sample the inputs on which a postcondition is hard or impossible to meet, and judge each of their outcomes against that postcondition. Pair a postcondition that holds only once a state is reached, such as "once nothing is pending", with one asserting that the state is reached whenever it should be. Check each postcondition at the moment it must hold, such as when the operation it describes completes. When only a person's real input can show the behavior, such as keyboard focus or a gesture, use request_user_input to ask the user for a short hands-on check in place of the experiment, and record what they report the same way. Mark a behavior that could not be observed as unobserved.
When the same class of defect recurs across iterations, stop patching the individual instance and instead write the root-cause invariant into the plan itself, enumerating the worked failures it must prevent. Count a defect that swings to the opposite failure after its fix, such as a check found too strict in one round and too lax in the next, as the same class recurring. In the same pass, re-read the whole plan against the new invariant and fix every instance it catches, including text written before the invariant existed. Treat recurrence on a new axis of the same invariant as a signal that the invariant is incomplete: widen it to cover the new axis rather than assuming the latest fix failed. When the recurring defect turns on behavior nobody has observed, run that experiment, or ask for that hands-on check, before writing the invariant: an invariant derived from reasoning can be wrong in exactly the way the mechanism it replaces was wrong, and every later round is measured against it.
When successive rounds move away from each alternative in turn on a different ground and the loop arrives back at a design an earlier round left behind, treat that as evidence the first finding's severity was misjudged against the alternatives' failure modes. Re-examine that finding rather than inventing another mechanism: when the earlier design survives the comparison, adopt it and record that finding as Skip, citing the alternatives' failure modes; when the user chose the direction that displaced it, surface it as Escalate, naming the original decision and this evidence beside it.
When a round has adopted a scope narrowing to limit blast radius, check that the narrowing is derivable. The narrow case is implementable only when the fact distinguishing it from the broad case is available to the implementation at the point the rule runs, whether from persisted state, the request, configuration, or data already at hand; when nothing supplies that fact, the two cases are indistinguishable at runtime and the rule silently strands whatever it excludes. Widen back to the broad case rather than carrying a rule nothing can evaluate, unless the user chose the narrowing: then surface it as Escalate, naming the original decision and this evidence beside it.
The re-invocation is a full, fresh run of this skill. Every step (1-5) executes with its own task tracking and skill invocations. When the classification above sends the run into another iteration, supply that iteration with every rejected and escalated verdict the ledger records, across this run and earlier iterations, as the already-adjudicated list for $review-plan, one line each: the finding, its verdict, and the recorded reason. Source it from the ledger rather than from in-context state, which compaction drops. A finding that re-proposes a design an earlier round left behind stays in scope regardless of the list: the alternatives having since failed on their own grounds is evidence the earlier reason did not account for, and it is the signal the rule above depends on.
Then call update_plan to mark this step completed and continue with the next step of the active workflow.
Added or removed steps, new or removed design decisions, rewired dependencies between steps, changed acceptance criteria, changed the deployment's stated bounds, changed testing strategy.
$evaluate-findings is a judgment gate that must run before $apply-findings touches the plan. Each step must invoke its designated skill by reading and following the installed skill instructions..turbo/, the plan file is the only file that should change.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.