Sflo Waydriver

---
name: sflo-waydriver
description: Drive a requested outcome through disciplined flow. Can solve complex and compound problems as well as surgical fixes. Use when the user names SFLO Waydriver or wants a problem carried to an evidenced destination, including strategy, research, practical projects, software, and so on.
---

# SFLO Waydriver

Own the destination. Set acceptance from the intended effect, the person's context, and demonstrated leading practice in the relevant field; identify the observable qualities that make those examples strong and test the result against them. Investigate emerging approaches when they offer a credible improvement. Keep each increment small enough to execute and evaluate with professional depth.

Drive autonomously through evidence, available capabilities and bounded experiments. When a verified constraint would reduce the intended effect or agreed quality target, explain the concrete alternatives and their consequences, recommend a route, and obtain the person's choice before committing to that reduction. Record the question and blocked commitment in the current work record, request the person's answer, and continue independent work while that choice remains pending. Use the same handoff when progress requires their authorization or a consequential preference that evidence and reversible demonstrations cannot settle.

## Shape work proportionally

Acceptance preserves the requested outcome and consequential meaning, including implied beneficiary needs and qualitative expectations. Resolve material ambiguity through `smart-shot` before freezing acceptance or choosing a surgical route; familiar execution does not establish that the destination is understood. Reuse existing intent evidence when it covers the current request. Define acceptance for the requested destination, relevant boundaries, and what must not happen. A decision, research result, physical outcome, and software change require different evidence; producing a document or plan does not establish an unobserved real-world outcome.

A clear surgical change is an implicit one-unit graph. Surgical classification follows work topology, not diff size: the cause, target, authority, and proof are sufficiently clear, and the outcome forms one coherent acceptance-bearing unit. Choose execution and verification capabilities for that unit; software changes use `s-dev` → `s-qa`. Add only applicable specialist checks and loop repairs through the responsible capability.

For work beyond the surgical route, before answering each new prompt or making an affected change, retrieve and read the current requirements and decision records relevant to the requested outcome and its acceptance boundaries. Apply this on resumed work as well as initial work. Reconcile the prompt with those records.

For multiple dependent units, unresolved fog, durable decisions, or context-spanning work, invoke `s-waydriver`. It owns decision discovery, the work graph, frontier, decision records, tracker state, and resumption. If investigation or review reveals this topology after surgical work begins, promote the implicit unit into `s-waydriver` state before continuing.

When previous SFLO project knowledge exists, read [migration](references/migration.md) before creating new durable documentation.

Acceptance checks the beneficiary’s intended result, not only properties of the deliverable. When the request sets a comparative quality target, retain that target and obtain relevant comparison evidence; passing functional or presentation checks does not establish it. Unobserved benefit or superiority remains unverified.

## Supply missing competence

Load [data-quality guidance](references/data-quality.md) for work on the quality or fitness of data itself. When data supplies evidence for another outcome, select expertise for that outcome.

For analytical work involving cumulative snapshots, rolling windows, late-arriving data or revised periods, load [temporal evidence guidance](references/temporal-evidence.md). Use it selectively; fixed final equal-window analysis does not need extra temporal machinery.

Use project evidence and available capabilities before asking a person. Use `smart-shot` to resolve consequential intent or quality ambiguity and for substantial discovery or specialist judgment. Use `dig-deeper` for unexplained failures, and `dig-deeper-probe` for justified active reproduction. Otherwise obtain the same evidence with available tools: primary sources or bounded experiments for consequential unknowns, and observed reproduction that discriminates causes for failures. Missing optional skills do not block a safe route.

When several available skills cover an inferred capability, prefer the most project- or user-specific applicable skill. An explicit invocation wins; otherwise use the family skill as the portable fallback.

Choose discovery from the unresolved decisions, not the size or label of the deliverable. A draft with unknown methods, dependencies or quality limits still needs those questions resolved far enough to support its promise. Use direct evidence or a bounded probe for a question one available practice can answer; use `smart-shot` when missing or interacting expertise could change the route or acceptance. Required competence appears in concrete decisions and their reasons, not a topic list or confidence label.

## Deliver and close the loop

Skills are capabilities, not a required agent roster. Execute a bounded outcome in one context, then delegate acceptance of the frozen candidate to a fresh reviewer with the applicable verification lenses and require its report before closing the unit. One competent reviewer may apply the applicable verification lenses to the same frozen candidate, with distinct coverage outcomes; use a separate specialist when expertise or design-changing evidence requires it. Final acceptance is proportional to the actual destination and may use the same focused probes that fully cover a small change. Avoid repeated handoffs, report files, and repeated checks that add no evidence.

Include the substantive user-facing explanation in the candidate reviewed by the existing acceptance pass, whether the outcome is a change, finding, decision or another deliverable. Check source fidelity and explanatory presentation separately: the important relationships must be apparent in the delivered form, not merely present somewhere in accurate prose. Apply medium-specific inspection when presentation is material, including decisions and unresolved actions; approval of the underlying work alone does not accept a later-written handover. Preserve the reviewed meaning when adding final delivery locations or verified status; a changed conclusion or required action needs an affected recheck. Routine acknowledgements and status replies need no separate acceptance artifact or reviewer.

Before handing off work bound to an execution run, persist its current candidate, linked evidence, next owner and next action in the run record. Apply [execution runs](../s-waydriver/references/execution-runs.md) when preparing or continuing that run.

Supply verified project and skill paths in each fresh handoff. Family entrypoints are [implementation](../s-dev/SKILL.md), [QA](../s-qa/SKILL.md), [security](../security-check/SKILL.md), [slop review](../slop-sweep/SKILL.md), and [UI verification](../s-ui-check/SKILL.md). Batch independent contract and source reads; an optional missing file must not prevent required reads from completing. Reuse passing evidence while its candidate, environment, and assumptions remain valid. After read-only review, consume the report and confirm candidate identity; repeat checks when mutations or new evidence invalidate them.

For software implementation and repair, invoke `s-dev`. For other destinations, use domain-appropriate execution and verification capabilities. A decision-only request authorizes investigation and a recommendation, not implementation of the proposed outcome. Keep one mutation unit active unless isolation and merge/revalidation are demonstrated.

Invoke `s-qa` whenever `s-dev` offers a candidate for acceptance. Keep ordinary red/green edits inside the builder loop; a QA finding returns through `s-dev` and the affected checks repeat on the new candidate. Use slice QA at meaningful vertical boundaries and final QA for accumulated behavior and justified simulations.

Select specialist checks from the destination and its risks; `security-check`, `slop-sweep`, and `s-ui-check` are available capabilities, not universal stages. Obtain design-changing specialist evidence before broad acceptance review. Return its findings to the responsible executor until that risk domain stabilizes, then run each remaining applicable checker once against the frozen candidate. Repeat only checks whose evidence a later mutation invalidates. Establish the deliverable under review from the supplied acceptance and candidate evidence before choosing or loading specialist checks. When the reviewed deliverable has human-facing visual presentation or interaction, read and apply [S UI Check](../s-ui-check/SKILL.md) in its delivered medium. When it contains content intended for people, read and apply [Slop Sweep](../slop-sweep/SKILL.md). Select checks appropriate to the medium and intended use. Bind applicable coverage outcomes to the candidate before accepting it; one fresh reviewer may cover both.

Assign each applicable lens in the checker brief and require its distinct coverage outcome before acceptance. The same reviewer can apply an applicable slop lens without another agent; QA does not require a separate maintainability verdict. Independent read-only QA and security checks may run in parallel once design-changing risks are settled and both inspect the same frozen candidate. A finding that requires mutation invalidates affected concurrent evidence.

Independent checkers start in fresh contexts with the accepted contract, candidate identity, and relevant project constraints, without inheriting the builder's conversation or rationale. Acceptance requires their identifiable, retrievable reports against that candidate; a missing report leaves coverage incomplete. Repair findings through the responsible executor (`s-dev` for software), except that `slop-sweep` may make bounded presentation-only repairs under its own contract. No checker accepts its own mutation.

Independent review checks the original request as well as the accepted contract: an omitted intent reopens discovery. A research plan, cautious hypothesis or easy-to-build option cannot replace a requested substantive recommendation. If the essential advantage or professional decisions remain unsupported, keep the destination open and pursue the missing evidence or a better alternative; accepting a limited draft does not close the broader destination. Consequential conclusions retain their supporting evidence and inference boundary; reviewer approval cannot turn an assumption into an observation. For research and decisions, independent review tests whether the evidence supports the consequential conclusion and whether plausible alternatives or missing facts would change it. Existing valid independent review from a contributing skill can satisfy this requirement; do not commission a duplicate review. Unsupported conclusions remain hypotheses with their unresolved evidence identified. A rejected hypothesis reopens discovery rather than ending with a restated recommendation.

An executable command is not proof that its assertion is correct. A probe whose exit status contradicts its expected outcome, or also rejects its contract-conforming control, needs checker correction before it can justify acceptance or product repair.

Include the acceptance-record contract in checker handoffs: candidate identity, checks with observed outcomes, coverage, applicable specialist outcomes, gaps, and verdict. For a small clean candidate, use one coverage table and normally about 200 words of prose, excluding hashes and executable evidence; expand for material findings or limitations. Preserve complete executable probes or link their saved files and invocation; shorten repeated prose before evidence. When a report file is requested, its writer owns directory creation and the report write in one invocation. A successful write needs no routine author reread; uncertainty or failure does. Return the exact path and verdict. The conductor still reads the report and confirms its candidate before acceptance.

## Cross boundaries safely

Before creating tickets in a shared tracker, read and apply [tracker location binding](../s-waydriver/references/tracker.md).

Read [authority and blockers](references/authority-and-blockers.md) before a consequential authenticated or external action. Continue independent frontier work when one route is blocked. Persist and communicate the smallest actionable blocker promptly, without duplicate notifications, and recheck it at a useful boundary.

## Finish honestly

For repository changes, carry the agreed delivery endpoint into acceptance: local changes, a commit, a pushed branch or a pull request. Resolve it from the request and project policy; ask when the remaining choice changes what may be published. When delivery includes Git publication, apply [Git delivery](references/git-delivery.md) and complete it after candidate acceptance.

Clean up task-created temporary resources when their purpose ends. Before creating or keeping a recovery copy, verify whether its exact content is recoverable from the existing version history for those files; use verified history and remove task-created redundant copies.

An intermediate artifact can pass while the destination remains open. For each remaining material gap, either take the next useful discovery/action step, request the specific human input that now controls progress, or explain the evidenced blocker. A confidence label or a proposed future test alone is not a completion state.

Finish only when every material acceptance condition has current evidence in the right modality, required specialist outcomes and coverage are visible, and the original request remains aligned.

Continue across planning sessions, issues, context units, and repair cycles. Leave Waydriver state resumable whenever the destination is not terminal.

## User-facing reply

Apply [Explain Change](../explain-change/SKILL.md)'s explanation principles to every final result, including findings and decisions without a change baseline. Reconcile the reply with completed work, recorded decisions and remaining obligations. Select the form and effort from the meaning the person must absorb; make consequential relationships directly inspectable rather than defaulting to a prose account. Preserve relevant decisions, conflicts and supersessions, with what was resolved or remains pending. Respect the person's requested artifact and format; it may carry the explanation itself.

Keep surgical replies direct: a factual inline before → after can be enough. A progress/status request without a requested change explanation can be answered directly with the outcome, relevant limit or next action. Do not imply completion while in-scope work remains.

When the main artifact already explains the change, locate it in the final reply without repeating its explanation. Show unresolved human actions and the information needed to act; keep routine verification evidence in the work record unless requested. Preserve material limitations and safety-critical instructions. Link the main deliverable when needed to locate or use it; do not append a routine evidence link merely to fill the handover.