Delivery Slice Planner

Delivery Slice Planning

Convert designs and larger change ideas into ordered work structures that a team can safely implement, review, verify, and release.

The purpose of this skill is not to "split tasks into smaller pieces." It is to preserve the intent of the change while cutting it into units where risk appears early, humans can review the work, tests can verify the intended behavior, and the team can roll back when needed.

Core Stance

• Preserve the design intent while converting it into implementable units.
• Do not hide dangerous uncertainty until the end.
• Do not pack multiple kinds of decisions into one PR.
• Do not treat tests as an afterthought; map them to the assurance each slice needs.
• Do not assume a single release after everything is complete; reason about intermediate states, production rollout, rollback, and observability.
• Do not hand decisions off to the tech lead without preparation; organize options, risks, recommendations, and the judgments that need confirmation.

When To Use

Use this skill for:

• Creating delivery slices from basic designs or design notes.
• Turning a large change into a sequence of reviewable PRs.
• Deciding how to separate refactoring, behavior changes, data migration, and UI changes.
• Planning implementation order for API or data changes while preserving backward compatibility.
• Planning work that involves feature flags, staged rollout, rollback, and monitoring checks.
• Organizing topics to confirm with a tech lead before implementation.
• Reworking an AI-generated implementation plan into something realistic for Scrum delivery.

Do not use this skill for:

• Small bug fixes or straightforward implementation.
• Pure design review.
• Pure refactoring diagnosis.
• Code review.
• Validating the product requirements themselves.
• Estimation-only discussions.

For out-of-scope requests, do not force the output into this skill's format. If requirements, design, responsibility boundaries, refactoring direction, or business decisions are too unsettled to form a delivery plan, briefly extract only the decisions or questions that must be settled first.

Workflow

1. Check the inputs and existing constraints. 2. Frame the delivery target. 3. Separate delivery slices, PRs, deployments, and feature enablement. 4. Choose a slicing strategy. 5. Create delivery slices and a PR sequence. 6. Map review focus and test focus to each slice. 7. Check release order, compatibility, rollback, and observability. 8. Separate tech-lead confirmation points from unresolved issues. 9. Integrate everything into one executable delivery plan.

1. Check Inputs And Existing Constraints

First decide whether the user's design notes are sufficient. If relevant information is available, read the minimum needed scope before producing a plan.

• Basic design, detailed design, ADRs, tickets, user stories, acceptance criteria
• Existing code, existing tests, existing PRs, related configuration and jobs
• API specs, DB schemas, events, DTOs, external interfaces, authorization rules
• Release procedures, feature-flag operations, rollback procedures, monitoring, logs, support procedures
• Constraints already agreed with the tech lead or team

Do not start with exhaustive research. To identify the impact surface, prioritize related contracts, callers, existing tests, and release procedures. If full research is needed, continue with a provisional plan and leave it in Unresolved Issues.

If information is unavailable, say so. When planning without reading existing constraints, mark plan confidence as High / Medium / Low and leave the needed checks in Unresolved Issues.

Confidence guide:

• High: Key contracts, existing impact, tests, and release constraints have been checked within the minimum needed scope.
• Medium: Important assumptions remain, but the overall plan and high-risk areas can be judged.
• Low: The plan is based mainly on design notes or requests, with existing impact, contracts, and release constraints mostly unchecked.

2. Frame The Delivery Target

Briefly organize:

• The value or business meaning to achieve
• Impact on existing users, existing APIs, existing data, and existing operations
• What would hurt most if the change failed
• Kinds of changes involved: behavior change, structural change, data migration, contract change, UI change, operational change
• Whether the change must finish within one sprint or can be released in stages
• Areas likely to require tech-lead judgment

Do not stop immediately when information is missing. State safe assumptions explicitly. Only raise confirmation items for things that are dangerous to decide unilaterally, such as compatibility, data integrity, authorization, or changes that cannot be safely rolled back.

3. Separate Delivery Slices, PRs, Deployments, And Feature Enablement

Do not mix these units:

• Delivery slice: A meaningful unit for the team to implement and verify.
• PR: A review unit where reviewers can understand intent and diff.
• Deployment: A unit that applies code or configuration to an environment.
• Feature enablement: A unit that creates user impact through a feature flag, configuration, authorization, exposed entry point, or similar mechanism.
• Production operation: A work unit managed separately from PRs, such as backfills, manual execution, operations approval, execution records, and monitoring checks.

One delivery slice may become multiple PRs, and multiple PRs may be deployed together. Code may be deployed while the feature remains disabled. Backfills and migrations must be treated not only as PRs, but also as production operation procedures, execution approvals, execution records, and monitoring checks. For high-risk changes, make these relationships explicit in the plan.

4. Choose A Slicing Strategy

Choose one primary strategy first. Do not spread the plan across too many strategies in parallel. Safety-related strategies may be listed as supporting strategies.

• Value vertical slicing: Slice by units that can validate user value or business value, even if small.
• Risk-first slicing: Expose uncertainty, external integrations, performance, authorization, data integrity, and similar risks early.
• Compatibility layer first: Build dual support or translation layers first so existing users are not broken.
• Migration first: Firm up schema, data, contract, or event migration feasibility early.
• Structure first: Add only the minimum responsibility separation or test scaffolding needed before behavior changes.
• Observability first: Add logs, metrics, monitoring, or investigation paths before relying on the change's safety.

When strategy choice is unclear, prefer the one that exposes the risk that would be most expensive if discovered late.

If external integrations, authorization, performance, data integrity, migration, backward compatibility, or multi-team coordination are involved, read references/risk-first-slicing.md.

5. Create Delivery Slices And A PR Sequence

Each slice must include at least:

• Purpose: What this slice advances.
• Included changes: What belongs in this PR or task.
• Excluded changes: What is intentionally kept out.
• Dependencies: Earlier slices required and handoffs to later slices.
• Review focus: What reviewers should judge.
• Test focus: What this slice assures.
• Done condition: What makes this slice complete. Include whether main, the integration branch, or the release target remains deployable, and whether the result can safely remain in production until follow-up work happens.
• Release notes: Notes about production rollout, feature flags, compatibility, rollback, and observability.

Being "small" is not enough. Each slice must be reviewable, verifiable, and leave a meaningful state for the next piece of work.

If PR splitting, oversized PR avoidance, separating refactoring from behavior changes, contract changes, or migration changes are involved, read references/reviewable-pr-design.md.

6. Map Tests And Verification

For each slice, state which assurance is carried at which layer.

• Unit tests: Cheaply assure rules, branches, transformations, and state transitions.
• Integration tests: Assure persistence, APIs, external integrations, and major boundaries.
• E2E tests: Assure representative user paths and regression risks from the user perspective.
• Manual checks: Handle UI, operational procedures, complex exceptions, and first-release checks.
• Production observability: Handle logs, metrics, alerts, and diagnosability for support.

Do not push everything into E2E tests. Choose the cheapest reliable layer that can provide the needed assurance.

7. Check Release Safety

Check whether intermediate states may exist in production.

• Can old code and new code coexist?
• Can old data and new data coexist?
• Will old API consumers, new API consumers, batches, admin screens, and external integrations keep working?
• Are feature flags, configuration values, or staged rollout needed?
• During rollback, will data, contracts, or user operation history break?
• After release, can success and abnormal states be observed?

If DB schemas, data migration, API contracts, external integrations, authorization, batches, UI enablement, feature flags, configuration switches, staged rollout, or rollback are involved, read references/release-safe-sequencing.md.

When reading reference files, do not mechanically copy all their content into the output. Read the relevant references and adopt only the viewpoints that affect this plan.

8. Separate Escalation Targets

Separate these in the output:

• Implementation decisions safe to proceed with
• Work-splitting decisions to align with the team
• Design decisions to confirm with the tech lead
• Business or release decisions to confirm with the PO, customer, or operations

Do not end tech-lead confirmations as bare questions. When possible, include options, risks, a recommendation, and a decision deadline.

Output Format

Normally use this format:

# Delivery Plan

## Delivery Target

- Plan confidence:

## Slicing Strategy

- Primary strategy:
- Supporting strategies:

## Proposed Slices

| Slice | Deliverable/PR | Deploy/Enablement | Purpose | Included changes | Excluded changes | Dependencies | Review focus | Verification | Done condition | Release notes |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |

## Review Plan

## Test Plan By Slice

## Release And Rollback Notes

## Tech Lead Confirmation Points

## Unresolved Issues

For smaller discussions, compress the output to only Delivery Target, Slicing Strategy, Proposed Slices, and Tech Lead Confirmation Points. Do not omit Dependencies, Review focus, or Done condition.

For lightweight output, a table is not required. Write each slice as roughly four bullet lines including what to do, dependencies, review focus, and verification/done condition.

If a concrete output example is needed, or if you need to confirm the expected output quality for this skill, read references/output-example.md.

Self-Check

Before the final output, check that:

• The purpose of the change has not been lost in the work breakdown.
• Risks that would hurt if discovered late are exposed by early slices.
• One PR does not overmix mechanical changes, structural changes, behavior changes, migration, and release work.
• Delivery slices, PRs, deployments, and feature enablement are not confused.
• Each slice has review focus, verification method, and done condition.
• Intermediate release states, compatibility, rollback, and observability are considered.
• Judgments to raise to the tech lead are separated from judgments I can proceed with.
• Missing information is not treated as fact.

delivery-slice-planner

このスキルは何か

大きな実装案や設計案を、安全に進めやすい delivery slice（安全に進める作業単位）、PR、リリース順に整理するためのスキルです。

作った意図

大きな変更は、実装内容そのものよりも、どう分けて進めるかで失敗しやすいことがあります。1 本の巨大 PR にまとめるとレビューしづらくなり、逆に細かく切りすぎると意図が分からなくなります。このスキルは、設計意図を壊さずに、レビュー可能性とリリース安全性を両立した分け方を作るために用意しています。

特に、互換性、ロールバック、段階リリース、移行作業のような実務上の怖さを、後ろではなく前に出して計画したい意図があります。

どういう人・場面に向いているか

• 実装前に PR の切り方やリリース順を整理したい人
• 設計はあるが、どこから着手すれば安全か迷っている人
• AI が出した大きな実装案を、そのままではなく現実的な進め方に直したい人

使いどころの例

• API 変更、DB 変更、画面変更が絡む機能追加を何段階で出すべきか考えたい
• 互換性を保ちながら移行する必要がある変更の順序を決めたい
• レビューしやすい PR 単位と、本番で有効化する単位を分けて計画したい

依頼イメージ

入力例: 「この機能追加案を、互換性を崩さず出せる PR の順番とリリース順に分けて。DB 変更と API 変更がある」

返ってくるもの: 「どの順で実装・レビュー・リリースするか」「各 PR で何を入れて何を入れないか」「途中段階での安全性」をまとめた進め方の案

関連するスキル

• software-design-review-router: 進め方ではなく設計の妥当性を先に見たいときに向いています
• quality-requirements-elicitation-coach: そもそもの前提や品質条件が薄いときに先に使うと相性がよいです

Output Example

Example: API Change With A DB Column Addition

Assumptions:

• Add display_name to an existing API.
• Existing clients must not be broken.
• Add a new column to the DB.
• UI exposure will happen later.

# Delivery Plan

## Delivery Target

Add a display name to the existing API so a later UI can use it. Preserve backward compatibility for existing clients, and roll out the DB change and API exposure in stages.

- Plan confidence: Medium. The list of existing clients and the allowed production backfill duration are still unconfirmed, but the DB/API/UI splitting direction can be judged.

## Slicing Strategy

- Primary strategy: Compatibility layer first
- Supporting strategies: Risk-first, observability first

## Proposed Slices

| Slice | Deliverable/PR | Deploy/Enablement | Purpose | Included changes | Excluded changes | Dependencies | Review focus | Verification | Done condition | Release notes |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 1. Backward-compatible DB addition | PR1 | Deployable/no feature impact | Prepare a place to store the new value where old and new code can coexist | Nullable column addition, migration, schema tests | API response changes, UI changes, old-path deletion | None | Whether old code works with the new schema | Migration dry run, existing regression tests | Integration branch or release target remains deployable, and old code can ignore the new column | Old code must keep working even if the DB is not rolled back |
| 2. Dual-support writes | PR2 | Deployable/no enablement | Write the new value without affecting existing users | Save logic, unit tests, logs | API exposure, UI exposure | PR1 | Handling of unset values and impact on existing update flows | Unit tests, integration tests | Existing screens/APIs keep working while old and new data coexist | Confirm logs for write failures |
| 3. API response addition | PR3 | Deployable/old-client compatible | Expose the new field in a backward-compatible way | Response field addition, contract tests | Making the field required, deleting old fields | PR2 | Whether this is an additive change that does not break existing clients | Contract tests, representative client checks | Representative old-client paths succeed | Observe usage through logs |
| 4. Backfill | PR4 + production operation procedure + execution approval + execution record | Run job in stages | Make existing data usable by the new field | Backfill job, rerun design, count logs, operation procedure | UI exposure, old-path deletion | PR2 | Idempotency, rerun after failure, load, operation approval | Staging run, staged production run, count reconciliation | Execution result is recorded, and failed items can be rerun | Rollback is absorbed on the read side rather than by deleting data |
| 5. UI enablement | PR5 | Staged enablement with a feature flag | Show display names to users | UI display, display conditions, representative E2E path | Old-field deletion | PR3, backfill execution record | Unset-value display, authorization, display conditions | E2E, manual check | Impact can be stopped by disabling the flag, and representative paths succeed when enabled | Check logs after limited enablement |

## Review Plan

- PR1: Review DB backward compatibility closely.
- PR2: Review write rules and unset-value handling closely.
- PR3: Review the API contract and existing-client compatibility closely.
- PR4 and production operation procedure: Review idempotency, rerun behavior, load, execution approval, and execution records closely.
- PR5: Review display conditions, authorization, and user impact closely.

## Test Plan By Slice

- PR1: Migration dry run and existing regression tests.
- PR2: Unit tests for save rules and DB integration tests.
- PR3: API contract tests and representative existing-client checks.
- PR4 and production operation procedure: Staged execution, rerun checks, count-log checks, and execution-record checks.
- PR5: Representative E2E path, manual checks, and feature-flag switching checks.

## Release And Rollback Notes

- Make the DB addition backward-compatible.
- Do not break existing responses when adding the API field.
- Enable the UI in stages with a feature flag.
- Run the backfill in stages only after preparing the production operation procedure, execution approval, execution record, and monitoring checks.
- After backfill, absorb rollback by disabling read/display behavior rather than reverting data.
- Plan old-path deletion separately after usage is confirmed.

## Tech Lead Confirmation Points

- Is it acceptable to treat the API field addition as backward-compatible?
- For backfill failures, is it acceptable to recover by rerun rather than reverting data?
- Is it acceptable to keep old-path deletion out of this scope?

## Unresolved Issues

- Existing client list.
- Allowed production backfill duration.
- Target user scope for UI enablement.

Release-Safe Sequencing

Purpose

Design change order from production rollout, compatibility, observability, and rollback safety rather than implementation completion order.

Release safety is not an after-the-fact check. It affects how slices should be cut.

When To Use

• DB schemas, data migration, API contracts, external integrations, authorization, batches, or UI enablement are involved.
• Old code and new code will run at the same time for some period.
• Staged rollout, feature flags, configuration switches, or rollback are needed.
• Post-release observability is needed to judge success, abnormal states, or support inquiries.

States To Check

• Old state: The system works with the pre-change code, data, and contracts.
• Dual-support state: Both old and new behavior work.
• New state: The system works with new code, data, and contracts.
• In-migration state: Some parts are migrated or enabled while others are not.
• Rollback state: Consistency remains intact after rollback.

Common Sequences

DB Changes

1. Add backward-compatible columns or tables. 2. Add dual old/new reads and writes. 3. Migrate or backfill data. 4. Switch reads to the new path. 5. After stabilization, delete old columns, old paths, or old processing.

API Changes

1. Prepare APIs or responses that support both old and new contracts. 2. Move clients or consumers in stages. 3. Observe usage. 4. Decide the stop date for the old contract. 5. Delete the old contract.

Feature Flags

1. Make code deployable to production while disabled. 2. Enable for internal users or limited conditions. 3. Observe logs, metrics, and support impact. 4. Expand in stages. 5. After stabilization, clean up the flag and old path.

Authorization Changes

1. Confirm the interpretation of existing permissions and audit logs. 2. Add the new decision logic disabled or impact-limited. 3. Observe affected users and operations. 4. Enable the change. 5. Prepare handling procedures for exceptions or incorrect decisions.

Rollback Checks

• Is reverting code enough?
• Does data also need to be reverted?
• Would reverting data break user operation history or external integration results?
• Can old code read new data without breaking?
• Can events or notifications sent to external systems be reversed?
• Can the operation be rerun after rollback?

Observability Checks

• What indicates success?
• What indicates abnormal behavior?
• How is the impact scope narrowed?
• When a support inquiry arrives, which IDs, logs, screens, or data can be used for investigation?
• Is an alert needed, or are manual checks sufficient?

Bad Release Order

• Schema changes, code changes, data migration, UI enablement, and old-path deletion ship together.
• A migration that cannot be safely rolled back is deployed to production before verification.
• The plan treats the existence of a feature flag as sufficient for safety.
• There are no logs or metrics, so success and failure cannot be distinguished.
• Old clients, batches, admin screens, and external integrations have not been checked.

Output Integration

Include the following in Release And Rollback Notes:

• Recommended release order
• Whether feature flags or configuration switches are needed
• Old/new coexistence period
• Production operations that require procedures, execution approval, execution records, or monitoring checks
• Rollback possibility and constraints
• Post-release confirmation method
• Timing for old-path deletion

Reviewable PR Design

Purpose

Design a PR sequence that lets reviewers follow intent and risk.

The purpose of PR splitting is not only to make diffs small. Each PR should make clear what reviewers are being asked to judge, while avoiding excessive mixing of mechanical changes, structural changes, behavior changes, migration, and release work.

Types Of Changes To Separate

• Mechanical changes: Renaming, formatting, import cleanup, type-name changes, simple moves.
• Structural changes: Responsibility separation, abstraction, module moves, dependency direction changes.
• Behavior changes: Changes to specifications, branches, validation, authorization, or state transitions.
• Contract changes: Changes to APIs, DTOs, events, DB schemas, or external interfaces.
• Migration changes: Data migration, compatibility handling, dual old/new support, cleanup.
• Verification changes: Test additions, test cleanup, monitoring, logs, confirmation procedures.
• UI changes: Screens, copy, user flows, display conditions.

Basic Principles

• Do not mix mechanical changes and behavior changes in the same PR.
• When possible, ship structural changes first while preserving behavior.
• For contract changes, write compatibility and user impact in the PR description.
• For migration PRs, state the old state, new state, intermediate state, and rollback path.
• Treat UI changes as rule changes when display conditions or operability conditions change.
• Even for test-only PRs, confirm that the specification intent has not changed.

Common PR Sequence Patterns

Structure-First Pattern

1. Add tests or characterization tests that protect existing behavior. 2. Separate responsibilities without changing behavior. 3. Add the new behavior. 4. Remove unnecessary old paths.

Compatibility-First Pattern

1. Create an entry point that supports both old and new behavior. 2. Add new writes or calls. 3. Migrate readers or consumers in stages. 4. Stop and delete the old path.

Risk-First Pattern

1. Use a minimal verification PR to check external integration, performance, authorization, migration, or similar risk. 2. Firm up the structure based on the verification result. 3. Add the behavior change. 4. Add release preparation and observability.

UI-Later Pattern

1. Prepare APIs, state, authorization, and data first. 2. Integrate the UI behind a feature flag or hidden state. 3. Enable the user flow. 4. Confirm monitoring and support investigation paths.

Bad PR Splitting

• PR 1 is a huge "preparation" PR and nobody can tell what should be reviewed.
• PR 1 introduces abstraction, PR 2 changes behavior, and PR 3 is assumed to fix bugs.
• Data migration, API changes, UI enablement, and old-path deletion are in the same PR.
• Tests are grouped into the final PR.
• The only reviewer instruction is "please review everything."

Per-PR Description Template

## Purpose

## Included Changes

## Excluded Changes

## What To Review

## Verification

## Done Condition

## Release And Compatibility Notes

Review Questions

• What is this PR asking reviewers to judge?
• Can reviewers follow specification changes separately from structural changes?
• Can this PR be tested or manually checked on its own?
• Is this a state that may exist in production until the next PR arrives?
• Are there any issues with rollback or coexistence with old paths?

Risk-First Slicing

Purpose

Expose uncertainty that would be expensive if discovered late through early slices.

Risk-first slicing does not mean "build all the dangerous parts first." It means creating small, testable pieces that quickly produce evidence for design, implementation, and operational decisions.

When To Use

• External integrations, authorization, performance, data integrity, migration, or backward compatibility are uncertain.
• The design looks plausible, but feasibility cannot be known until implementation is attempted.
• If discovered late, the issue could disrupt PR splitting or the release plan.
• Evidence is needed early for tech-lead judgment.

Risk Types

• Contract risk: APIs, DTOs, events, DB schemas, or external interfaces may break existing consumers.
• Data risk: Migration, consistency, duplication, missing data, reruns, or rollback may be difficult.
• Authorization risk: It is unclear who can see, operate, or audit what.
• State risk: Statuses, modes, transitions, and failure handling are complex.
• Performance risk: Volume, frequency, synchronous processing, N+1 behavior, external calls, or batch duration are uncertain.
• Operational risk: Investigation, recovery, reruns, or support handling may be difficult during incidents.
• Organizational risk: Multiple teams, the tech lead, operations, or customer confirmation are involved.

Procedure

1. List the risks included in the change. 2. Estimate how painful each risk would be if discovered late. 3. Look for the smallest way to verify each risk. 4. Do not overmix risk-exposure slices with value-delivery slices or structural-change slices. 5. State how the verification result changes the later slices.

Good Risk-First Slices

• Easy to discard if they fail.
• Do not break production users.
• Produce evidence that can guide later decisions.
• Make clear what the tech lead or reviewers should confirm.
• Avoid excessive generalization even if the work can remain as part of the final implementation.

Bad Risk-First Slices

• They become "build the whole foundation first."
• They are large preparation work with no value and no verification.
• They do not affect later design decisions.
• They ship schema or contract changes that cannot be safely rolled back before verification.
• They pretend to address risk while avoiding the most uncertain part.

Review Questions

• What would be the most painful thing to discover late?
• What is the smallest thing that can expose it?
• Which later decision changes based on this slice's result?
• Is this verification meaningful under conditions close to production data, production load, or production authorization?
• If it fails, can the team discard, roll back, or redo it?

Output Integration

In Slicing Strategy, write the main risks and the order in which they will be exposed.

In Proposed Slices, include the following for risk-first slices:

• Risk to expose
• Verification method
• Verification done condition
• Whether the intermediate state after verification may exist in production
• Follow-up plan if successful
• Revision direction if unsuccessful
• Judgment to confirm with the tech lead