Skiphow Longrun

---
name: skiphow-longrun
description: Deliver an accepted epic, milestone, or issue set through delegated implementation and independent review loops. Use for sustained execution and resumes of tracked work, with CTO sequencing, integration, and process diagnosis. If context was compacted while this workflow governed, reopen this file and the SkipHow CTO skill before the next consequential action.
---

# SkipHow longrun

Deliver every authorized outcome in the requested work set to its agreed destination. Before consequential work, and again after any context compaction, read the [SkipHow CTO kernel](../skiphow/SKILL.md) unless its full text is already in context; a summary is not its text. The lead remains the accountable CTO throughout execution.

Use [tracked work](../skiphow/references/tracked-work.md) to reconcile current records, accepted decisions, live branches, ownership, and prior delivery before starting or resuming. Retire superseded instructions in execution records no live session is writing. Leave a live session's lane to it and continue independent authorized work around it and around owner decisions.

Use [delegation](../skiphow/references/delegation.md) to size and sequence verifiable slices. Delegate implementation and independent review to fresh agents for each slice. The shared review loop below governs continuation and replacement through corrections. Keep scope, product decisions, synthesis, integration, and the completion claim with the CTO.

Reassess routing or split the assignment when a miss, growing scope, or context pressure makes its current shape unreliable. Parallelize ready independent work within verified isolation and integration capacity. Without verified writer isolation, explain the limitation and keep the lead as the only writer while delegates investigate and independently review. When delegates are unavailable, carry safe implementation directly, leaving required independent review explicitly blocked. If independent review itself is unavailable, report that slice's review blocker rather than claiming the loop complete.

Use [verification's shared review loop](../skiphow/references/verification.md#reviewing-a-change) to confirm findings, repair defects, and independently review corrections before accepting a slice into the lead's working state. Use [integration](../skiphow/references/integration.md) to combine accepted results, verify them together, and choose delivery units. A slice's handoff to the lead and the owner's delivery can have different destinations. Close each record only when its own promised outcome holds under [tracked work](../skiphow/references/tracked-work.md#closing-what-the-tracker-carries); accepting a handoff does not close an outcome still awaiting delivery. An implementation report or a review verdict alone does not establish delivery.

Use [diagnosis](../skiphow/references/diagnosis.md) when a test, delegate, tool, or integration behaves anomalously, progress loses its signal, or the same failure returns. Use [operations](../skiphow/references/operations.md) when the cause belongs to the delivery system. Diagnose the responsible layer, change direction when evidence warrants it, and keep independent outcome-producing work moving.

Checkpoint through the existing tracking and continuation conventions at meaningful boundaries. Continue beyond slice handoffs until every authorized outcome is verified at its agreed destination or has a concrete recorded blocker. Report delivered outcomes and evidence, accepted results still awaiting delivery, remaining review or owner actions, and owned resources that could not be retired. Production and public releases retain the kernel's explicit-grant boundary.