Skill: Integration Slice Orchestration

Purpose

Ensure that feature implementation proceeds in vertical integration slices that keep frontend, backend, and contracts aligned, verifiable, and low-risk.

This skill prevents:

• •“all backend first” or “UI-only” drift
• •late integration surprises
• •long-lived branches with unverified assumptions

Trigger

Use this skill whenever ANY of the following occur:

• •implementation begins for a feature that touches both frontend and backend
• •a contract has transitioned to Frozen
• •parallel FE and BE work is planned
• •a feature risks being implemented in large, unverified chunks

Authoritative references

This skill treats the following as authoritative:

• •docs/team/WORKFLOW.md → phase ordering and gates
• •docs/team/HANDOFF.md → runtime coordination and ownership
• •feature design artifact (docs/features/<feature-slug>/02-design.md) → frozen contracts

Inputs

• •frozen integration contracts
• •feature requirements and acceptance criteria
• •current HANDOFF state
• •implementation constraints (if any)

Outputs

This skill MUST produce all of the following:

1. •

   Slice plan

   • •recorded in docs/features/<feature-slug>/03-implementation-notes.md
   • •defines a small number of vertical slices (prefer 1–3 initially)
   • •each slice includes:
     • •contract surface in scope
     • •backend responsibility
     • •frontend responsibility
     • •verification signal
2. •

   HANDOFF updates

   • •sequence of ownership transitions
   • •locked areas per slice
   • •explicit “ready for next slice” signals

What constitutes a valid integration slice

A valid slice MUST:

• •touch both backend and frontend (or explicitly state why not)
• •rely only on frozen contract surfaces
• •be independently verifiable
• •reduce uncertainty after completion

Examples of valid slices:

• •“Create + fetch entity with minimal UI rendering”
• •“Authenticated read-only list with pagination”
• •“Submit form → validate → persist → confirm”

Examples of invalid slices:

• •“Implement all models”
• •“Build entire UI”
• •“Wire everything together at the end”

Orchestration rules (strict)

• •Prefer one slice at a time unless there is a strong reason to parallelize.
• •Do NOT expand slice scope mid-implementation.
• •Do NOT begin a slice until the previous slice is verifiable.
• •Contract changes during slicing require re-entry into contract negotiation.
• •Each slice completion MUST be visible in HANDOFF.

Explicit non-responsibilities

This skill MUST NOT:

• •write code
• •decide product scope or value
• •redesign contracts
• •optimize performance
• •replace verification or QA

It sequences work; it does not perform it.

Interaction with other skills

This skill works in coordination with:

• •

  contract-handshake-and-freeze → ensures slices rely on frozen contracts

• •

  handoff-coordination → manages ownership and locks per slice

• •

  workflow-enforcement → ensures slicing respects phase gates

• •

  verification-gate → validates each slice before advancing

• •

  bug-management → logs defects discovered during slicing

Failure handling

If slicing reveals:

• •missing contract details
• •unclear acceptance criteria
• •excessive scope for a single slice

Then:

1. •Pause the slice
2. •Record the issue in HANDOFF
3. •Escalate to the Lead
4. •Re-enter the appropriate earlier phase if needed

Proceeding with unclear slices is prohibited.

Acceptance criteria

This skill is successful when:

• •integration happens early and often
• •FE and BE remain aligned throughout implementation
• •verification occurs per slice, not at the end
• •integration-related defects decrease over time
• •feature risk is reduced incrementally

Design principle

This skill exists to make integration incremental and unsurprising.

If integration is delayed, painful, or risky, slicing was insufficient or ignored.