Skip to content
cccskills
FreePublished on GitHub

deliver-slice

Implement and finalize one ready rolling-wave slice in one invocation while preserving the lifecycle boundary between implementation and independent review. Use when the user wants a slice delivered end to end without manually invoking implement-slice and finalize-slice, wants main-local implementation by default with workers only when delegation pays, followed by mandatory fresh-context finalization, or says deliver, implement and finalize, or take the slice through review.

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md4.5 KB
  • agents/openai.yaml293 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

Deliver Slice

Core Invariants

  • Preserve phase ownership and statuses: implement-slice ends at ready for review; finalize-slice moves it to and leaves it in review.
  • Never mark the slice done; complete-slice remains user-owned.
  • Follow implement-slice execution routing: main-local for small or cohesive work; Terra workers only for genuine parallelism, large mechanical/discovery work, or specialist value.
  • Use a fresh-context agent for finalization so implementation assumptions are not treated as review evidence.
  • Stop when implementation remains in progress, user input is required, or finalization finds a genuine external blocker.

Workflow

  1. Resolve one slice using implement-slice rules.

    • Accept only a ready slice for a new delivery.
    • If the named slice is already ready for review or in review, skip implementation and continue with finalization.
    • If it is in progress, resume through implement-slice; finalize only after it reaches ready for review.
  2. Read both phase skills completely.

    • Read ../implement-slice/SKILL.md and every reference it requires for this slice.
    • Read ../finalize-slice/SKILL.md and every reference it requires for this slice.
    • Treat both phase contracts as authoritative. This skill only orchestrates them.
  3. Execute implementation.

    • Follow implement-slice without weakening its execution-routing, human handoff, scope, note, or status rules.
    • When workers are used, wait for them, integrate their disjoint changes, and close them.
    • After implementation completes, run one batched root checkpoint: confirm local or worker completion gates, implementation notes, slice/roadmap status, target base, and current HEAD. Inspect only missing, conflicting, or integration-sensitive evidence; do not run a second broad implementation review.
    • If implementation does not reach ready for review, stop. Report remaining work; do not start finalization.
  4. Preserve the review checkpoint.

    • Confirm slice and roadmap statuses are ready for review.
    • Capture implementation notes before finalization starts.
    • Create a minimal immutable handoff with project path, slice path, target branch, current HEAD, implementation-note location, and prior verification commands plus exact results.
    • Do not precompute changed paths, diff stat, worktree status, or untracked paths solely for the handoff. Mutable review-surface discovery belongs to the fresh finalizer and should happen once.
    • Keep the handoff factual. Do not pass implementation conclusions, recommendations, or suspected findings as facts.
  5. Execute finalization in fresh context.

    • Spawn one fresh subagent with fork_turns: "none" and the parent model inherited.
    • Give it repository instructions, the immutable handoff, and: Use $finalize-slice to finalize this slice completely.
    • Dispatch it immediately after the batched root checkpoint and minimal handoff are complete.
    • Tell it that other agents may have edited the worktree, not to revert unrelated changes, and to preserve user changes.
    • Treat the fresh finalizer as the primary independent reviewer. Default to zero additional reviewers.
    • Let it add one or two focused reviewers only for concrete unresolved uncertainty, specialist risk, high semantic complexity, or explicit adversarial review. File count and mechanical relocation size alone do not justify another reviewer.
    • Require it to report status, resolved findings, accepted gaps, changed files, and any material decision needing user input.
    • Close the finalizer after its result is captured.
  6. Finish.

    • Confirm final slice and roadmap status from artifacts instead of trusting the subagent report alone.
    • Leave clean delivery in review.
    • Leave user completion and learning capture to complete-slice.

Completion

Report implementation files, resolved finalization findings, accepted gaps or risks, and resulting status. If finalization needed no fixes, preserve its exact No findings. result inside the delivery summary.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Review local git changes before opening a PR or merging. First review all local tracked and untracked files; if none exist, review the current branch against a requested base branch or the Git Town parent branch. Use zero to three review subagents only when risk, diff size, language specificity, or uncertainty justifies the token cost, then report high-confidence bugs, regressions, risky assumptions, and missing tests. Use when the user asks for code review, local review, branch sanity check, pre-PR review, or review of work-in-progress changes.

The English summary is being prepared. Showing the original description.

rijkvanzanten/rolling-wave-engineering13Updated Aug 18, 2026

Review changed code for YAGNI, removable over-complexity, reuse, code quality, and efficiency, then apply worthwhile simplifications. Use when the user asks to simplify, clean up, tighten, de-hack recent changes, identify logic that can be dropped, or review whether added safeguards and edge-case handling are actually needed.

The English summary is being prepared. Showing the original description.

rijkvanzanten/rolling-wave-engineering13Updated Aug 18, 2026

Mark a rolling-wave slice done on explicit user authority, regardless of its current lifecycle status or missing implementation, finalization, review, verification, or child-project state. Use when the user says a slice is done, complete, finished, accepted, or should be marked done; capture available material learnings, update project state, and output roadmap progress without requiring earlier workflow steps.

The English summary is being prepared. Showing the original description.

rijkvanzanten/rolling-wave-engineering13Updated Aug 18, 2026

debug

Free

Systematically find root causes and fix bugs. Use when debugging errors, investigating test failures, reproducing bugs from issue trackers (GitHub, Linear, Jira), or when stuck on a problem after failed fix attempts. Also use when the user says 'debug this', 'why is this failing', 'fix this bug', 'trace this error', or pastes stack traces, error messages, or issue references.

The English summary is being prepared. Showing the original description.

rijkvanzanten/rolling-wave-engineering13Updated Aug 18, 2026

Produce a short executive summary for the current rolling-wave project. Use when the user wants a concise status update, investor/team-friendly summary, leadership summary, project progress snapshot, or TL;DR of completed slices, the current slice plan, and upcoming slices.

The English summary is being prepared. Showing the original description.

rijkvanzanten/rolling-wave-engineering13Updated Aug 18, 2026

Finalize an implemented rolling-wave slice for user review. Use when the user wants Codex to review the current branch state against a ready-for-review or in-review slice contract, confirm and fix required findings, repeat review and verification until no required findings remain, ask before accepting findings that materially change project shape or contradict project assumptions, record review state, and leave the clean slice in review for complete-slice.

The English summary is being prepared. Showing the original description.

rijkvanzanten/rolling-wave-engineering13Updated Aug 18, 2026

See all skills by rijkvanzanten

Report a problem with this skill