plan-implementation-slices

name	plan-implementation-slices
description	Split an approved design into small, traceable implementation slices. Use when Codex needs reviewable, testable, dependency-aware coding increments with stable slice IDs, done criteria, touched modules, and validation scope before implementation starts. Do not use for coding, bug fixing, or architecture redesign.

Plan Implementation Slices

Goal

Convert approved architecture and contracts into a sequence of small, implementable diffs that can be built and reviewed with low risk.

Read Shared Contract Reference before producing the artifact.

Trigger boundary

• Use after contracts and architecture are approved and before implementation starts.
• Do not use for writing code, reviewing code, or redesigning upstream artifacts.

Required input

• Required: approved contracts with metadata showing approval_status: approved and stable CONTRACT-* identifiers
• Required: approved architecture with metadata showing approval_status: approved and stable MODULE-* or PORT-* identifiers
• Required: prioritized use cases with stable UC-* identifiers
• Optional: existing codebase context, team constraints, release ordering

Refusal and blocked policy

• Plan slices, not the whole delivery program.
• Keep each slice small enough for one coherent diff and one review.
• Use enabling slices only when they unlock the next valuable slice.
• Return BLOCKED when contracts, architecture, or prioritized use cases are missing or lack stable IDs.
• Return BLOCKED when the request is actually to implement code instead of planning slices.

Workflow

1. Identify the minimal sequence that can deliver the approved use cases.
2. Split the work into thin vertical or architecture-enabling slices.
3. Assign a stable SLICE-* identifier to each slice.
4. Define in-scope work, out-of-scope work, and prerequisites for each slice.
5. Call out likely modules, contracts, invariants, and tests touched by each slice.
6. Order slices to minimize merge risk and rework.

Output contract

Write slice-plan.md or return equivalent Markdown using this structure:

# Slice Plan

## Artifact Metadata
- artifact_id:
- artifact_type: slice-plan
- artifact_status: draft | current | superseded
- approval_status: pending_review | approved | changes_required | rejected
- approved_by_gate_profile: none | slice-quality | cross-artifact-consistency
- gate_report_ref: none | <ref>
- upstream_artifact_refs:

## Ordering Principles
- ...

## Slice Summary
| slice_id | goal | prerequisite_ids | target_use_case_ids | target_contract_ids | review_risk |
| --- | --- | --- | --- | --- | --- |

## Slice: SLICE-01 <name>
- goal:
- user_or_system_outcome:
- prerequisites:
- target_use_case_ids:
- target_contract_ids:
- target_invariant_ids:
- in_scope:
- out_of_scope:
- modules_or_files_likely_touched:
- tests_to_add_or_update:
- validation_scope:
- done_criteria:
- approval_checklist:
- review_risk_reason:
- risks_or_notes:

## Deferred Work
- ...

Quality bar

• Make every slice independently reviewable.
• Avoid slices that span many unrelated modules without a clear throughline.
• Attach done criteria and test expectations to every slice.
• Preserve traceability back to use cases, contracts, and invariants.
• Prefer one coherent diff over batching multiple user outcomes into a single slice.
• Initialize artifact metadata with approval_status: pending_review until a gate or approver marks it otherwise.