sync-protocol

name

sync-protocol

description

Reconcile an existing operational contract against accepted docs/concept/ and implementation reality after toolchain, validation, harness, command, runtime, or other project-specific behaviour changes. Use when the user says sync protocol, implementation may have drifted from AGENTS.md or DESIGN.md, or closeout requires a no-op protocol audit. Do not use for initial planning, roadmap creation, or BUILD_STATE.md generation.

Sync Protocol

Maintain an existing operational contract after /plan-implementation creates it. Reconcile drift; do not invent execution strategy.

What it owns

• AGENTS.md: only the Project Specifics region between its markers.
• DESIGN.md: only when the file already exists, preserving human additions.

It audits ROADMAP.md and BUILD_STATE.md for contradictions but never creates, re-sequences, or edits them. Planning changes return to /plan-implementation; current-state maintenance belongs to the execution agent and /consolidate-state.

When it runs

• Before closeout when implementation changes toolchain, validation gates, harness configuration, command surfaces, generated artefacts, runtime assumptions, or stack-specific behaviour.
• Before commit when Project Specifics or an existing DESIGN.md may be stale.
• As a no-op audit when unsure.

Read the concept index status before sync and proceed only when it is Operationally planned and BUILD_STATE.md exists. If the status is Shaping or Re-shaping, stop and resume /shape-concept. If the status is Ready for operational planning, Ready for operational re-planning, or Operationally planned without BUILD_STATE.md, stop and invoke /plan-implementation. For any other or missing status, stop and report the invalid stage state rather than guessing.

Procedure

1. Read every file in docs/concept/, the current Project Specifics, existing DESIGN.md when present, BUILD_STATE.md, optional ROADMAP.md, and the implementation evidence relevant to the change.
2. Compare accepted intent with actual behaviour. Derive only changes supported by both. Never invent a command; blank-and-flag beats a wrong guess.
3. Reconcile:
   • descriptor and locked boundaries;
   • exact toolchain commands that implementation actually supports;
   • ordered validation gates;
   • stack-specific operational rules; and
   • existing design tokens or rationale when implementation or accepted design intent changed.
4. Preserve human additions unless they contradict accepted intent or verified reality. Surface contradictions instead of silently choosing.
5. If reconciliation requires new architecture, phases, slices, roadmap order, or product behaviour, stop and recommend /plan-implementation or /shape-concept at the appropriate boundary.
6. Note repeatable project-specific behaviour that may deserve a locally authored skill. Never search for, install, or copy remote skills during sync.
7. Present the proposed diff and get approval before writing. When no changes are needed, state the no-op audit explicitly so the handoff records that sync ran.

Rules

• Never edit the universal baseline above the Project Specifics marker.
• Never create or edit BUILD_STATE.md or ROADMAP.md.
• Never create DESIGN.md; absence means planning did not require one.
• Never broaden a closeout audit into technical or product planning.
• After applying, continue from the current BUILD_STATE.md; no separate prompt file is required.