skiphow-plan ยท diff

git:20260912.674eb65 to git:20260923.062fa5a

4 added, 2 removed. Audit A to A.

---
name: skiphow-plan
description: Prepare an idea or substantial change for implementation with research, a reviewed specification, vertical slices, and an execution prompt. Explicit invocation requests durable planning records; ordinary read-only planning stays read-only. Stop before implementation.
---
# SkipHow plan
Prepare work that another agent can execute without rediscovering settled decisions. Before consequential work, have the [SkipHow CTO kernel](../skiphow/SKILL.md) in context. Read it if absent. 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.
Use [product](../skiphow/references/product.md) to recover the intended outcome, current behavior, constraints, exclusions, and acceptance conditions. Investigate questions before taking genuinely unresolved product choices to the owner. Keep dependent behavior undecided until its answer arrives, and prepare independent work meanwhile.
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. Research current primary sources where they settle a material uncertainty. Choose engineering mechanisms yourself and record enough rationale for another agent to preserve the decision.
- Apply [delegation](../skiphow/references/delegation.md) to substantial independent research and to slicing. Distinguish a tracker grouping, a verifiable end-to-end product slice, and a delegate assignment where they differ. The next ready assignments should be executable from the plan, with boundaries grounded in the inspected workload, necessary context, expected output, verification, and integration. A broad work package alone does not establish a bounded assignment. Include acceptance criteria, relevant evidence, exclusions, and real dependencies. Show which independent preparation or assignments can proceed in parallel and where shared writes or integration constrain them. Keep open product decisions explicit. Keep later boundaries provisional when earlier results determine them, and keep small cohesive work direct. Cover integration, migration, rollback, and operation where the proposed behavior needs them. One pass is a sizing goal, not a promise; adjust boundaries when evidence warrants it.
+ Apply [delegation](../skiphow/references/delegation.md) to substantial independent research and to slicing. The plan's tasks must be dispatchable without further planning, so every task it records for execution is one slice delivering one outcome someone can verify on its own, cut through the layers where the work has them, that a single implementation agent can carry from its record to a verified, reviewable change. A grouping record may collect tasks but is never itself dispatched. Before finalizing, split a task that holds several outcomes or several agents' work, or that leaves its own split for later. Work with no honest vertical slice, such as a wide mechanical change, slices into batches each verifiable on its own. Where ordinary delegation stops at the next verifiable outcome, this workflow sizes every task the accepted scope needs from the inspected workload: the context it needs, the output it produces, its verification, and its integration. Where an earlier result could change a later task, name that result and what it would change so the lead rechecks the task at dispatch. A task's size is a judgment from evidence, not a promise; the executing lead splits one that proves larger.
- Have an independent agent review the proposed work against the request and source evidence using [verification](../skiphow/references/verification.md). Check missing outcomes, conflicting decisions, assignment feasibility, real dependencies, and verifiable acceptance conditions, including whether the planned review and integration workload is itself bounded. Resolve supported findings before finalizing the records. If independent review is unavailable, finish the preparation and report review as unverified.
+ Write each task for a capable agent that has the repository and its record but not this conversation: the outcome and what would show it true, links to the accepted specification and decisions it must preserve, relevant evidence, what it takes from earlier tasks and leaves to later ones, exclusions, and what it returns. Leave files, names, and steps to the implementer unless an accepted decision fixes them. Show real dependencies, which tasks can proceed in parallel, and where shared writes or integration constrain them. Keep open product decisions explicit, and keep small cohesive work one task. Cover integration, migration, rollback, and operation where the proposed behavior needs them.
+
+ Have an independent agent review the specification and every task as it will be published against the request and source evidence using [verification](../skiphow/references/verification.md). Check missing outcomes, conflicting decisions, and verifiable acceptance conditions; for each task, whether it holds one outcome that one agent could finish from its record alone; and across tasks, invented or missing dependencies, overlapping work, parts of the result no task covers, prescribed implementation, and whether the planned review and integration workload is itself bounded. Resolve supported findings before finalizing the records. If independent review is unavailable, finish the preparation and report review as unverified.
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 and unresolved limits, and a short execution prompt naming the accepted records, intended destination, scope, and existing authorization boundaries. The prompt should start execution without repeating the CTO policy or granting new protected actions. Stop before implementation.