Skiphow Plan

---
name: skiphow-plan
description: Prepare the whole requested scope for implementation with research, a completed product interview, a reviewed specification, bounded tasks, and an execution prompt suited to its size. Explicit invocation requests durable planning records; ordinary read-only planning stays read-only. Stop before implementation. If context was compacted while this workflow governed, reopen this file and the SkipHow CTO skill before the next consequential action.
---

# SkipHow plan

Prepare the whole requested scope so another agent can execute it without rediscovering settled decisions. 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. It remains responsible for technical judgment and owner questions.

Explicit invocation of this skill requests a specification and planning records in the project's authorized tracker. Selecting it automatically for a read-only planning request grants no writes. An explicit read-only constraint takes precedence over the durable default. Keep implementation, commits, and delivery outside this workflow. Completion means the requested scope is prepared, not merely that its current questions and drafts are recorded.

Interview answers and grants for planned actions belong in the execution records; they do not by themselves switch this session to execution. An explicit request to execute after planning authorizes that transition once preparation is ready, within host restrictions and existing grants, without another confirmation. Otherwise return the plan and launch prompt, then stop.

Use [product](../skiphow/references/product.md) to recover the intended outcome, current behavior, constraints, exclusions, and acceptance conditions. Investigate before taking genuinely unresolved product choices to the owner. Carry the interview through the questions their answers reveal until no known product choice remains open in the accepted execution scope. Preserve settled answers and distinguish them from recommendations and assumptions. Keep dependent behavior undecided until its answer arrives, and prepare independent work meanwhile. A pending answer keeps the interview open. When no useful independent preparation remains, wait through available host controls or return a waiting-for-answer status with the question and resume condition. Resume the interview on the answer, including choices it newly exposes. Elapsed time, a saved draft, or a ready independent task does not complete preparation. Later discoveries can still require a decision during execution.

Use [technical design](../skiphow/references/technical-design.md) for consequential choices and build-versus-reuse analysis. Establish what the repository already provides before proposing new logic or dependencies. Use current primary sources to settle material uncertainty. Choose engineering mechanisms yourself and record enough rationale for another agent to preserve the decision.

For user-facing work, carry the relevant journey scenarios, design direction, and identified reuse constraints into the specification and tasks that depend on them. Separate accepted product decisions from proposals and engineering judgments. Preserve enough source context for an implementer to understand what must hold and why. Record the resulting decisions and acceptance conditions independently of the specialist capability that helped establish them; an executing agent reassesses the capabilities available on its host while preserving the accepted outcome.

Apply [delegation](../skiphow/references/delegation.md) to substantial independent research and to slicing. Every task recorded for execution delivers one independently verifiable outcome, cut through the layers where the work has them, that one implementation agent can carry from its record to a verified, reviewable candidate. One assignment allows normal tool calls and review corrections. A grouping record collects tasks and is never dispatched. Size every task in the accepted scope now; split one that needs several agents or defers its own split. Keep implementation and its necessary checks together when separate parts have no independently verifiable outcome. Small cohesive work stays one task. Compatible migrations and mechanical work use independently verifiable units; a large uniform automated change may stay one task when the meaningful change is bounded and completeness can be checked. A task's size is a judgment from evidence, not a promise; the executing lead reslices one that proves larger.

A shared outcome alone does not establish one-agent feasibility. Assess required context, materially different changes, manual implementation, verification, review, and integration together while drafting. Where workload is uncertain, use existing measurements, comparable completed work, or representative source and check inspection; a full inventory is not required. Split where reliability and total cost improve, accounting for repeated context, coordination, and integration; file, line, or acceptance counts are no universal limit.

Where the accepted work lacks a proven path through its components, choose a thin first slice with real behavior. Establish only the structure and component connections that slice needs, verify the working path, then expand it through the remaining bounded slices. Reuse an established path in a mature project. The first working behavior preserves required safety, integrity, and compatibility. Name what its result unblocks and which later assumptions the lead must recheck at dispatch. Prepare independent work meanwhile and the whole task set without a universal foundation stage.

Write execution tasks using [tracked work's shared task contract](../skiphow/references/tracked-work.md#writing-one-that-survives-the-wait), the same contract used for deferred findings. Show actual blocking results, available parallel work, and shared writes, runtime resources, or integration capacity that constrain dispatch. Consuming the same settled API creates no dependency by itself. Name earlier results that could change later tasks and what to recheck at dispatch. Keep open product decisions explicit and cover integration, migration, rollback, and operation where needed.

Independently review the specification and every task against the request and source evidence using [verification's shared review loop](../skiphow/references/verification.md#reviewing-a-change). Check missing outcomes, conflicting decisions, verifiable acceptance, and owner authority for consequential choices. Review whole-scope readiness, affected existing behavior, and dependent state. Technical slicing cannot select a smaller execution scope. A size finding names the concrete load and a smaller independently verifiable cut that preserves all acceptance and dependencies. Across tasks check invented or missing dependencies, overlaps, uncovered outcomes, unnecessary prescription while retaining justified contracts and reuse constraints, and bounded review and integration workload. Check the journey's application context. The published candidate needs review coverage, including material corrections under that shared loop. Unavailable or unfinished independent review stays unverified and limits readiness of the affected scope.

Use [tracked work](../skiphow/references/tracked-work.md) to reconcile existing records and save the plan when authorized. Use GitHub Issues within the established audience unless the project uses another authorized tracker. Write engineering artifacts in English. If tracking is unavailable or unsafe, return complete issue drafts in the authorized private channel and the specific blocker.

Return the specification and issue links or drafts, material decisions, review evidence, unresolved limits, and whole-scope readiness. Account for any implementation candidate already created; a planning handoff does not erase that work. Return an execution launch when that scope is ready, or for a ready subset the owner explicitly selected. Keep an unresolved interview open rather than offering a partial launch in its place. Choose ordinary SkipHow for small cohesive work and longrun for substantial work needing coordinated implementation and independent review loops. Preserve an execution workflow the owner already selected. Use the target host's explicit invocation syntax and this launch shape, replacing the skill with the selected one.

```text
$skiphow-longrun
Deliver the accepted implementation scope in <plan-reference> to <agreed-destination>.
```

Replace placeholders with concrete accepted records and the agreed destination. Add only otherwise-missing project location, owner-selected subset, or necessary run constraints, preserving their authorization provenance. Requirements and dependencies stay in the task records; execution policy stays in SkipHow. Grant no new protected actions. Keep unfinished preparation, inaccessible sources, and known human prerequisites explicit as blockers to the affected scope; a saved plan proves neither readiness nor permission. Stop before implementation.