skiphow-fast-fixes ยท diff
git:20260916.4c6ef00 to git:20260929.a0e1778
17 added, 7 removed. Audit A to A.
---
name: skiphow-fast-fixes
- description: Iterate on a local screen or other visible result with the owner before delivery. Use for small copy, layout, and frontend changes shown on a running dev preview, with feedback checkpoints and deferred delivery tests. A request to ship uses the delivery workflow.
+ description: Coordinate a live stream of local fixes and feedback before delivery, across interfaces, services, scripts, configuration, and artifacts. Use for bounded changes that may arrive while others run, with proportional delegation, focused checks, and recoverable shown results. A request to ship uses the delivery workflow.
---
# SkipHow fast-fixes
- Give the owner a working preview to inspect and revise. Before consequential work, have the [SkipHow CTO kernel](../skiphow/SKILL.md) in context. Read it if absent. The lead remains the CTO; this session's completion boundary is each reviewed and shown iteration.
+ Give the owner checked local results to inspect and revise while continuing independent accepted work. Before consequential work, have the [SkipHow CTO kernel](../skiphow/SKILL.md) in context. Read it if absent. The lead remains the accountable CTO; showing one result completes that iteration, not the rest of the session's work.
- Prepare an isolated branch and worktree from the project's current development base. Discover the base, dev startup command, and existing preview conventions rather than assuming branch names or commands. Preserve unrelated changes. Reuse this session's owned workspace on subsequent turns. Keep its preview and worktree available while the iteration session continues, and preserve the minimal outcome-to-workspace association for recovery under [tracked work](../skiphow/references/tracked-work.md).
+ ## Coordinate incoming work
- Make the requested bounded change. Use [verification](../skiphow/references/verification.md) for review, rendered inspection, and permitted focused checks. Show the actual running preview at a usable address or through the host's preview tool, with a concise account of the change, then stop for feedback. If the preview cannot run, report the blocker and do not represent an unshown result as shown.
+ Use [delegation](../skiphow/references/delegation.md) to handle arriving requests, changed assignments, dependencies, isolation, and returns. Keep simple work direct and group related tiny fixes. Delegate independent investigation, implementation, or review when it reduces expected completion cost or useful latency within the owner's constraints. Keep the lead available to reconcile messages and results instead of tying it up in lengthy implementation that a delegate could usefully carry. A message is not automatically a separate task or agent.
- Defer Playwright/e2e test runs, full backend gates, and pytest until delivery. Browser interaction and screenshots for inspecting the preview remain appropriate. Inspect the effects of project commands and commit hooks so they do not run deferred suites indirectly. If the permitted commit path requires a deferred check, report the conflict and preserve the work; do not bypass the hook or silently run the suite. Name verification gaps when a requested change cannot be checked sufficiently within this boundary.
+ Resolve engineering choices yourself. Use [product](../skiphow/references/product.md) for genuinely open product choices and plan only as much as the affected outcome needs. Continue independent work while an answer is pending. Keep all accepted work accounted for through [tracked work](../skiphow/references/tracked-work.md), without a separate ticket for every small edit.
- When feedback or the next task arrives, commit the previous shown iteration as a checkpoint before making further edits, even when the feedback requests a revision. An explicit instruction to discard or exclude a change takes precedence. Commit only this session's owned changes. Feedback and acceptance keep the session in iteration mode and do not trigger push, shared integration, or delivery tests.
+ ## Preserve and show local results
- On a delivery request such as deploy-ready or clean, use [deploy-ready](../skiphow-deploy-ready/SKILL.md) to carry the accumulated changes through deferred checks and authorized delivery. Deployment to production still needs its applicable explicit grant. On pause or resume, preserve and reconcile the shown state, pending feedback, owned preview resources, and remaining verification as [tracked work](../skiphow/references/tracked-work.md) describes.
+ Discover the project's working base, isolation, preservation, and inspection conventions. Reuse this session's owned workspace; in a Git project, use an isolated branch and worktree where needed to preserve other work. A project without Git or a browser result needs neither initialized version control nor a server for this workflow. Verify writer isolation and coordinate shared runtime resources under delegation; without safe isolation keep the lead as the only writer. Without delegates, work directly where the required review remains possible and report unavailable independent review.
+
+ Use [integration](../skiphow/references/integration.md) to combine accepted results locally and [verification](../skiphow/references/verification.md) to check and review the combined state. Show coherent results as they become ready, naming what changed and its evidence. For an interface, inspect the rendered result and show the actual preview through a usable address or host tool; for other work, demonstrate the relevant behavior or inspect the resulting artifact. Report an unavailable inspection as a gap rather than claiming it happened. Continue other accepted work after showing a result; wait when none can safely advance or the owner asks to pause or wait.
+
+ Before an edit or integration supersedes a shown state, preserve that state as a local checkpoint, even when feedback asks to revise it. In Git, commit only owned changes through the permitted commit path; elsewhere use the project's or host's safe recoverable mechanism. A message alone needs no checkpoint, and isolated work need not wait for one. If preservation is blocked, keep the shown state intact and continue only work independent of that transition. An explicit instruction to discard or exclude a change takes precedence. Keep owned resources needed for continued inspection available and retain the minimal recovery association under tracked work.
+
+ ## Verification and delivery boundary
+
+ Choose focused checks for the changed behavior by their evidence, cost, and effects, not by tool name. A targeted unit, API, CLI, or browser test can be appropriate. Defer full delivery gates until delivery while honoring mandatory project checks and explicit owner restrictions. Inspect commands and hooks before running them; if a required path conflicts with those restrictions, preserve the work and report the conflict without bypassing the hook or running the forbidden check. Name any remaining verification gap.
+
+ Feedback and acceptance keep this session in iteration mode and do not trigger push, shared integration, or delivery gates. On a delivery request such as deploy-ready or clean, use [deploy-ready](../skiphow-deploy-ready/SKILL.md) to reconcile the delivery set, including in-flight work, and carry it through deferred checks and authorized delivery. Production still needs its applicable explicit grant. On pause or resume, preserve and reconcile accepted work, the shown state, pending feedback, resources, and remaining verification through tracked work. Handle new messages when the host delivers them; do not claim background execution or automatic resumption that the host does not provide.