Implementation Slice Template with Parallel Work

When to use this template

This is an extended version of the Implementation Slice Template with extra fields for parallel implementation. Use it when multiple engineers, teams, or AI agents may work on different parts of the system at the same time. See the Parallel Work guide for the supporting concepts.

What this template adds

On top of the standard slice fields, this template requires every slice to declare its lane, contracts, dependencies, parallelism, and integration points so parallel work does not collide:

• Implementation Lane — which stream of work this slice belongs to
• Module or Component — the specific boundary being changed
• Shared Contracts — interfaces this slice depends on or provides
• Dependencies — what must exist before this slice can start
• Can Run In Parallel With — slices that are safe to run alongside this one
• Blocks — slices that cannot start until this one is done
• Integration Points — where this slice must meet other slices
• Integration Checks — verification that integration actually works

Template

implementation-slice-parallel.md

# Implementation Slice

## Slice ID

`IMP-000`

## Name

Short name for the implementation slice.

## Status

Draft | Ready | In Progress | Review | Accepted | Rejected

## Purpose

Explain why this slice exists. Describe the outcome this slice must produce.

## Implementation Lane

Define the lane this slice belongs to.

Examples:

- Web application
- Backend API
- Document storage
- Text processing worker
- Search index
- Language model adapter

## Module or Component

Define the module, component, service, package, or subsystem this slice changes.

## Linked Intent

### Users

List the users affected by this slice.

### Behaviours

List the behaviours this slice implements or changes.

### Features

List the features this slice contributes to.

### Success Criteria

List the success criteria this slice supports.

## Linked Shape

### Constraints

List the constraints that apply.

### System Context

List external systems, actors, or boundaries involved.

### Solution Strategy

Reference the selected technical approach.

### Building Blocks

List the components, services, modules, or packages involved.

### Data and Interfaces

List database tables, APIs, events, files, messages, or contracts involved.

### Runtime Behaviour

Describe the runtime flow this slice affects.

### Deployment and Operations

List deployment, configuration, logging, monitoring, or operational concerns.

## Shared Contracts

List contracts this slice depends on or provides.

Examples:

- API request format
- API response format
- database schema
- event schema
- file format
- interface definition
- component props
- message contract

## Dependencies

List slices, modules, contracts, or decisions that must exist before this slice starts.

## Can Run In Parallel With

List slices or lanes that can be implemented at the same time.

## Blocks

List slices or lanes blocked by this slice.

## Integration Points

Define where this slice must integrate with other slices.

## Applicable Rules

### Cross-Cutting Rules

Authentication, authorization, validation, errors, logging, security, privacy, performance, or coding standards.

### Decisions

Reference relevant decision records.

### Delivery Rules

List the delivery rules this slice must follow.

## Scope

Define exactly what this slice includes.

## Out of Scope

Define exactly what this slice does not include.

## Implementation Tasks

List the expected tasks.

## Expected Files or Areas to Change

List the files, folders, modules, or services expected to change.

## Files or Areas Not to Change

List files, folders, modules, or services that must not be changed.

## Verification

### Automated Tests

List required automated tests.

### Manual Checks

List required manual verification.

### Integration Checks

List checks required to prove this slice integrates with related slices.

### Acceptance Criteria

List the conditions that must be true for this slice to be accepted.

### Definition of Done

Define when this slice is complete.

## AI Instructions

Define how AI may assist with this slice.

Example:

- AI may implement only this slice.
- AI may edit only the files listed in expected areas unless it explains why another file must change.
- AI must not implement out-of-scope items.
- AI must not change shared contracts without explicit approval.
- AI must not modify another implementation lane without explicit approval.
- AI must stop if required information is missing.
- AI must return a summary of changes.
- AI must list files changed.
- AI must list tests added or changed.
- AI must list assumptions made.
- AI must list unresolved questions.
- AI must list verification performed.

## Review Notes

Use this section during review.

Include:

- what changed
- what was accepted
- what was rejected
- follow-up work
- risks found
- integration issues
- documentation updates required

Minimum parallel-work fields

If you are adding parallel-work fields to an existing slice rather than starting fresh, these are the ones every slice must include:

implementation-slice-parallel.min.md

## Implementation Lane

## Module or Component

## Shared Contracts

## Dependencies

## Can Run In Parallel With

## Blocks

## Integration Points

Core rule

When parallel work is safe

Parallel implementation is only safe when module boundaries, contracts, dependencies, and verification are explicit.

If these are not defined, the slice is not ready for parallel implementation.