implement-1a7456 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited implement-1a7456 (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.
Standard implementation flow: load style rules, make the change, run post-implementation QA.
At the start, use update_plan to track each step, restating any remaining steps of a parent workflow alongside them:
$code-style skill$smoke-test skill for UI/UX changes$preview skill for UI/UX changesWorkflow state lives at .turbo/workflows/<slug>.md — slug from the governing plan when one is in context, otherwise the current branch name with non-alphanumerics replaced by hyphens. It pairs one-to-one with the thread's goal. When this run's create_goal attempt succeeds, write the file fresh: Status: active plus this invocation's update_plan list as a checkbox list. When an unfinished goal already exists, mirror into the workflow file its objective names; when it names none, continue without workflow state. Mirror every update_plan call into the file; it holds the pipeline's remaining steps and their statuses. When this run created the goal, run the terminal step in order: mark the final entry completed and mirror it, set Status: closed, mark the goal complete with update_goal, then emit any halt message.
Then attempt create_goal with the objective: "Make this change: <one-line task summary>. Carry it through Step 7, which runs $finalize unless a quick close or stopping is chosen. Workflow state: .turbo/workflows/<slug>.md; mirror every update_plan call into it. Loop state lives under .turbo/loops/. After any context compaction, re-read the workflow file and any active ledger, and continue from the first unfinished entry. Mark this goal complete when Step 7 has finished." If an unfinished goal already exists, an outer workflow owns it; continue without creating one.
$code-style SkillRun the $code-style skill to load existence, reuse, mirror, and symmetry rules before editing.
Scan the work for types that match available skills, matching against the richest context available: a plan's Implementation Steps if a plan is in conversation context, otherwise the user request, a prior skill's task description, or an improvement entry. For each unambiguous match, run the skill by reading and following the installed skill instructions. For example, if the work includes "add a Drizzle migration" and a skill exists whose triggers reference Drizzle migrations, load it. If a work type has no matching skill trigger, do not load a generic skill.
If unsure, do not load.
Apply the change described by the current context — the user request, a prior skill's task description, or an improvement entry. Keep the edit scoped to what the context describes.
When the fix changes how a value is constructed, grep for every other site that constructs it and fix the ones carrying the same defect; treat these siblings as part of the same change. If the scope balloons beyond what the context specified, stop and confirm scope before continuing.
Before this step starts or uses a process that runs until it is stopped, such as a server or a watcher, run the $test-run-rules skill. Its rules verify without modifying code, so act on a failed check as this step directs.
If a Verification section is in conversation context (e.g., from a plan file), execute the commands, smoke checks, or MCP tool invocations it specifies. If a check fails, run the $investigate skill. If a check is blocked by a dependency, unclear requirement, or environmental issue, use request_user_input to surface the blocker and let the user choose how to proceed. If no Verification section is in context, go straight to the configuration check below.
When the Verification section lists both checks that can force code edits, such as a formatter or a linter, and a slow run, such as an integration suite, finish the edit-forcing checks and the edits they force before starting the slow run. When an edit lands after a slow run started, re-run it; when re-running is not practical in this session, state which part of the verification the final code did not get.
When the change adds or documents a configuration override — an environment variable, build flag, or any setting a reader is told to set — prove that a supported path delivers it: set the value, run the build or process meant to consume it, and confirm the output changed. When no supported path delivers it, fix the path or drop the documentation before this step completes. Restore the setting afterwards, and rebuild or discard any output produced with the non-default value. Passing checks are no evidence here, since a default that matches the value already in use keeps a broken override invisible to every run that never asks for a different one.
$smoke-test Skill for UI/UX ChangesIf the change touches a user-facing surface (UI components, styles, templates, markup, user-facing routes or screens), run the $smoke-test skill. When that is unclear, use request_user_input to ask whether the change is user-facing rather than skipping silently. Skip this step for changes with no user-facing surface (backend-only, CLI, library, build or config).
$smoke-test verifies without modifying code, so act on what it reports here: fix each failure and re-run it. When the same failure survives a fix attempt, run the $investigate skill; if investigation finds no root cause, stop and report with its findings. When a blocker cannot be cleared in this session (a path needing real credentials, an external service, or state unavailable here), carry it into Step 6 rather than treating it as a failure. When a fix made here edited code, re-run the Step 4 checks it could affect once no failure remains; when re-running is not practical in this session, state which part of the verification the final code did not get.
$preview Skill for UI/UX ChangesIf Step 5 determined the change is user-facing, run the $preview skill so the user can try it firsthand before QA. Skip this step otherwise. Pass along any blocker Step 5 could not clear, so the hand-over names the cases still left to the user.
When a plan file governs the work, hold this step until every Implementation Step has been applied, and continue to the next Implementation Step at every earlier boundary. Then run the $finalize skill.
When no plan file governs the work, use request_user_input to offer three options:
$finalize skill$quick-finalize skillIf this run created a goal, follow the closing update_plan call below by mirroring it into the workflow file, setting Status: closed, and marking the goal complete with update_goal, in that order. Then call update_plan to mark this step completed and continue with the next step of the active workflow.
git commit, git push, and PR creation to Step 7..turbo/ content (filenames, acceptance criteria, step numbers, headings) in code or comments. .turbo/ is gitignored, so these references would be opaque to anyone reading without local copies.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.