draft-plan-4bff26 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited draft-plan-4bff26 (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.
Produce an implementation plan at .turbo/plans/<slug>.md. Capture the task, survey patterns, escalate decisions, discuss, and draft.
Use update_plan to track each step, restating any remaining steps of a parent workflow alongside them:
$survey-patterns skillAbsorb the user's request without interrupting. Restate the goal in one or two sentences and confirm.
Generate a slug for the plan file from the task title:
Example: "Add a caching layer to the image pipeline" → add-a-caching-layer-to-the-image-pipeline.
If .turbo/plans/<slug>.md already exists, append -2, -3, etc. until the path is free. Do not overwrite.
The user may pass an explicit slug or output path in their request (e.g., "draft plan as auth-rewrite"). If so, honor it. If .turbo/plans/<slug>.md exists in that case, use request_user_input to ask whether to overwrite, append a numeric suffix, or pick a different slug.
A path to a file that already exists is background input rather than an output destination. Treat it as the output path only when the request says so explicitly.
State the chosen slug and the resulting plan path before continuing.
If a path to a background document is passed as input (a design doc, an issue, a written proposal), treat it as the source of truth for product decisions and discussion areas. Read it, then:
A question is resolved only when the document makes a definitive statement that answers it. Mentions without a chosen direction, open questions, and deferred decisions do not count as resolved; escalate those normally. Neither does a constraint on the solution that the document carries from someone other than the user: it stays open for Step 4, however definitively the document states it.
Step 2 (pattern survey) and Step 3 (consult skills and docs) still run in full. The document describes what; $draft-plan still surveys how.
$survey-patterns SkillRun the $survey-patterns skill with the confirmed task description. Keep the returned findings in conversation context for use in Steps 5 and 6.
Ground library and framework choices in current reality before escalating decisions.
Keep findings at the decision level: what a library can do, which approach is idiomatic, which version to target. Do not embed specific API signatures or code snippets into the plan. Those belong at execution time, where the same skills are re-loaded.
Identify product or design decisions the user's request did not resolve. Escalate these via request_user_input before drafting steps.
Escalate when:
Do not escalate technical decisions the agent can make autonomously: which data structure, which existing pattern to follow, internal implementation approach. The boundary is product intent.
Confirm external constraints before escalating. When an option depends on a third-party API, service, or platform behaving a particular way, drop it unless that behavior is confirmed by current documentation.
Look up a named precedent before escalating. When the request or a background document names a precedent the design is meant to follow, such as an existing product, a protocol, or a standard, look up how it behaves on the points the design touches, and frame options against what the lookup found. Mark as unverified only a claim about it that the lookup could not settle.
Observe existing surfaces before escalating. When an option concerns how an existing surface looks, observe it as it currently renders, by running the app from the current code, or from a screenshot requested from the user, and drop any option its rendered state rules out.
Read the code an option's benefit lands in before escalating. When an option is justified by what it lets code outside the change do, such as the caller of an interface or the consumer of an output, or by what it does for data already stored, read that code, or every path that has written that data, and follow the benefit through what you read. Confirm the code or data needs what the option provides and does not already get it another way. Drop a benefit the reading does not bear out. Apply the UX lens before escalating. When a decision concerns what the software does for the person using it, a default or a control included, run the $user-experience skill on it first, and state each option as the behavior that person gets and the goal it serves. Leave the mechanism behind each behavior to the plan.
Output what is at stake as text first, even when the reading it came from is fresh in this conversation. When the decision turns on a failure or misuse scenario, that means the invariant the change would protect and what makes that scenario reachable given the existing guards. Then use request_user_input to present the decision as a concise trade-off with options. Keep each option's description to the decision being asked and its trade-off. When an option would also commit to a design choice the question does not ask about, ask that choice on its own or leave it to the plan. Mark the strongest option "(Recommended)" and place it first. Treat the work of departing from the codebase's existing structure as a cost to state beside the option that incurs it, with no bearing on which option is strongest. Draft plan steps that depend on these decisions only after the user responds.
Offer a Get a second opinion option whenever the decision is costly to reverse (it establishes a pattern others will follow, defines an interface, commits to a data shape, or imports a pattern the codebase has not used), and whenever no option earns "(Recommended)" with conviction. It runs the $consult-claude skill for what each option commits to, what reversing it costs, and what the prevailing convention is. Hold the concrete options to two so the question stays within the three-option limit. Then resolve the decision with that answer in hand, re-asking when the choice stays the user's.
Interview the user relentlessly about every aspect of the implementation shape until you reach shared understanding. Use request_user_input, one question at a time. Use the pattern survey findings to frame choices. Cover whichever of these matter for the task. Do not present a rigid checklist.
Settle the first two rows before the rest, so implementation choices land against concrete outcomes and bounds instead of being taken in the abstract. When the user jumps to implementation shape early, engage briefly then circle back.
| Area | What to explore |
|---|---|
| Outcomes | What must be true when this is done? The observable behaviors that decide whether it worked, and the acceptance criteria that pin each one. |
| Bounds | How many users and operators, now and realistically? Concurrent writers? Which rigor tier is proportionate — personal tool, small team, or business-critical — and what failure tolerance does that imply? |
| Constraints | Which non-functional requirements apply: performance, security, accessibility, i18n, compliance? Which tech-stack, hosting, or integration choices does the work commit to? |
| Prototype unknowns | What does the surface look like, and does the interaction pattern make sense in the hand? Separate these from ordinary design questions by whether an answer in prose would still leave the user guessing. |
| Reuse vs new | Which survey findings should the new work build on? Which should it deliberately not follow, and why? |
| File placement | Where do new files live? Which existing files are modified? |
| Data flow | How does data move through the change? Any new boundaries or contracts? |
| Edge cases | Partial failure, empty states, backward compatibility, concurrency |
| Tests | Which existing test patterns apply? Where do new tests live? |
| Scope cut | Anything to explicitly defer? Keep in scope any items the change would otherwise leave as the last holdouts of the behavior it replaces, however small their payoff. |
$consult-claude skill for the soundest answer on technical merit alone, independent of the task's original scope; on a question of product intent, run it for what each answer commits to and what reversing it costs. Then resolve the question with that answer in hand, re-asking when the choice stays the user's.$prototype skill on that unknown, then asks the question again with the prototype in hand. A confirmation of outcomes is such a question when the outcomes describe what a control or gesture does in use.$user-experience skill on it before framing options, and state each option as the behavior that person gets and the goal it serves.Synthesize the task description, pattern survey findings, consulted skill and doc context, resolved product decisions, and deep-dive discussion outcomes into a complete plan document.
When a decision in Step 4 or Step 5 deferred work to the improvements backlog, run the $note-improvement skill for it before writing the plan. State the deferral in the plan's Context as out of scope and, when the skill wrote a backlog entry, as already noted.
Create .turbo/plans/ if it does not exist. Write the plan to .turbo/plans/<slug>.md using the slug picked in Step 1 (or the override path from Step 1) using this structure:
---
status: draft
---
# Plan: <Task Title>
## Context
<Why this change is being made — the problem or need it addresses, what prompted it, the intended outcome. One or two paragraphs.>
<The deployment's bounds: user and operator count, concurrency, the rigor tier, and the failure tolerance it implies. One or two sentences.>
## Acceptance Criteria
What must be true when this is done:
- When <trigger or condition>, the system shall <expected behavior>.
- As a <persona>, I want <capability> so that <outcome>.
- Acceptance: <criterion>
## Pattern Survey
<Insert the structured findings from `$survey-patterns`: Analogous Features, Reusable Utilities, Convention Anchors, Proposed Alignment. Use the same format the survey returned.>
## Implementation Steps
1. **<Step 1 title>**
- <Concrete action with `file_path` references and named functions or symbols>
- <Another action>
2. **<Step 2 title>**
- ...
3. ...
## Verification
How to verify the change works end-to-end after implementation:
- <Specific test command, manual smoke check, or MCP tool invocation>
- <Expected observable result for each verification step>
- <Edge cases to spot-check>
## Context Files
Files to read in full before starting implementation:
- `<path/to/file1>` — <why it matters>
- `<path/to/file2>` — <why it matters>
- ...file_path references and named functions or symbols. Confirm each symbol a step names resolves to a real declaration — same spelling and casing, in a file you opened, carrying the signature, fields, option keys, or event name the step relies on — searching the codebase, or the dependency's shipped interface when the symbol belongs to one. Verify that shape rather than recording it. When the change introduces the symbol instead, mark it new and name where it is defined and what uses it. When a step deletes, renames, or changes the signature of a symbol, list every file that references it, including references on code paths the change otherwise leaves alone or that never execute in practice. When a step turns on behavior that has not been observed, either how a platform, tool, or dependency behaves at runtime or what a plan-specified algorithm produces on its inputs, observe it with a cheap experiment that leaves the working tree unchanged before writing the step, confirm that each setting the experiment varies took effect, and state what it showed. For a plan-specified algorithm, write it as a throwaway script and assert the step's postconditions over randomized and degenerate inputs, keeping in the sample the inputs on which a postcondition is hard or impossible to meet. 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 the algorithm replaces existing behavior, run the same assertions against that behavior, and restate a postcondition the current code already violates as no worse than today unless the step sets out to fix it. State the sample size, the failures, and the cases left unresolved. 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, and state what it showed. Mark a behavior that could not be observed as unobserved. When the change introduces per-entity state with an asynchronous lifecycle, state which path creates it, which single path commits its terminal outcome, and which path removes it once that outcome is committed. Confirm every state short of that outcome has a path that reaches it, then check every step that touches that state against those owners. When a step reorders operations that run in sequence today, runs them concurrently, or moves one across the boundary between the change and its caller, read the code that uses their results or effects and state the ordering that code relies on and how the step keeps it. Reference existing functions and utilities from the Pattern Survey instead of reinventing them. Each step describes a discrete unit of work that can be tracked independently during execution.$finalize invocation, test commands, or commit instructions in the plan content — those are execution-wrapper concerns. Keep commit, push, and PR instructions out of every section, Verification included. A Verification item may observe the result of a push without instructing one. One plan file covers one implementation run. When later work must wait on an external gate the implementation cannot pass itself, such as a verified deploy of the earlier work, write that later work as a separate plan file with the same structure, rather than marking a stopping point inside one plan. Derive its slug from the later work with Step 1's rules and state its path before writing it. When the later work changes a different repository than this one, write its plan file to .turbo/plans/ in that repository: check Step 1's free-path rule against that directory, write the plan's paths relative to that repository's root, and use the file's absolute path wherever this rule names the later plan's path. Write the later plan against the repository as the earlier plan leaves it: leave out what the earlier plan already removes, account for every caller and every role or access holder it introduces, and wherever the later plan relies on what the earlier plan adds or removes, name the earlier plan's path and the step's title. State the gate in the later plan's Context section as every condition the later work depends on, such as data the earlier work must serve once it is live, unlanded work the later plan's changes affect, and the gate holding in each environment a routine release carries the later plan's change to. When a condition is measured, such as a quiet period, measure it where the later work's own targets are consumed. Name the later plan's path in the earlier plan's Context section. Plan size never justifies a second file.Present a brief summary of the drafted plan: the essence of what it builds and the key decisions behind it, short enough to read at a glance so the user does not have to read the full plan file. When the plan delivers value to a user, developer, or operator, also present a short list of stories capturing what that person gains, in the form "As a <persona>, I want <capability> so that <outcome>". Skip the stories only when no beneficiary or outcome can be named, such as a purely mechanical refactor. Fit both to the plan rather than a fixed template. When Step 6 also wrote a gated plan, summarize each file, and name which one to implement first and the gate the later one waits on.
Close with how to reply: approve the plan as final, or describe what to change. When an unknown that only a built artifact settles is still open, also offer prototyping it first, and recommend that over approving, since a surface or interaction pattern that is still unproven cannot be judged from the plan text.
Then end the turn.
A goal continuation turn that carries no reply from the user is not an approval: end it without calling any tool and without advancing.
$prototype skill, then apply what it settled to the plan file. Then re-present Step 7's summary, close with its reply guidance, and end the turn again.Then call update_plan to mark this step completed and continue with the next step of the active workflow.
.turbo/, and any prototype the discussion or the user's reply to the summary called for are the only outputs. Do not write code, scaffolding, or other project files.$review-plan or any review skills here.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.