sakura-replicate

name	sakura-replicate
description	Define and enforce observable replication parity for cloning, reimplementation, compatibility, migration, or replacement work. Use when an existing product or system is the behavioral target; do not use for ordinary greenfield development or visual inspiration without a parity requirement.

Sakura Replicate

Role

Convert a replication request into a capability inventory, automatically derived parity levels, explicit conformance contracts, level-appropriate tests, and an honest gap verdict.

Use When

• The user asks to clone, recreate, reimplement, replace, migrate from, or remain compatible with an existing product or system.
• The request uses terms such as exact parity, one-to-one behavior, protocol compatibility, drop-in replacement, or runtime compatibility.
• A reference implementation contains behavior, contracts, or lifecycle mechanisms that may be missed by a page-oriented feature list.

Do Not Use When

• The work is greenfield and no existing behavior is a parity target.
• The reference is only visual inspiration and the user does not require behavioral consistency.
• The task is ordinary maintenance inside one implementation with no compatibility boundary.

Inputs

• The user's requested target and explicit scope.
• Verified current-project behavior and architecture.
• Observable target capabilities, state changes, contracts, lifecycle signals, failures, persistence, and restart semantics found during research.
• Existing product acceptance and non-goals.

Outputs

• A target classification and capability inventory.
• docs/replication/ scope, level decisions, contracts, matrix, validation, and gaps.
• One machine-checkable replication contract bound to task state for every task that enters this skill.
• A handoff to planning, verification, or review with mandatory gaps clearly identified.

Workflow

1. Classify the target as UI clone, feature clone, behavior clone, protocol-compatible clone, or runtime-compatible clone.
2. Inventory capabilities rather than pages. Include discovery, state, data flow, integration, failure, persistence, lifecycle, and recovery behavior when present.
3. Record each capability's target minimum and observed architecture signals, then derive L1, L2, L3, or L4. Never lower a level to match the current implementation.
4. Write one replication contract per capability and map every required level to structured evidence containing a procedure, expected result, actual result, passing status, and optional artifact.
5. Run the deterministic evaluator for machine-checkable contracts and correct under-classification before planning.
6. During verification, run conformance tests appropriate to every required level and record mandatory gaps.
7. During review, reject Done when a required level, contract, lifecycle, failure path, persistence rule, or mandatory gap remains unsatisfied.

Read parity-levels.md when classifying signals. Read contract-format.md when creating or evaluating contracts. Read conformance-validation.md when planning tests or deciding Done.

Quality Gate

• An exact-parity request is never treated as UI-only; it starts at L2 and escalates for observed protocol or runtime signals.
• Exact parity starts at L2 even when the visible request mentions only interface similarity.
• Every capability has a target minimum, declared level, automatically detected level, required level, status, structured evidence, and gap state.
• The project classification is satisfied by the highest required included capability without escalating unrelated capabilities.
• Dynamic modules, manifests, runtime registration, activation, deactivation, cleanup, failure isolation, or restart semantics force L4 for the affected capability.
• APIs, CLIs, file formats, message channels, or permission protocols force at least L3.
• A visual approximation is labeled approximation and cannot satisfy a higher required level.
• External implementation artifacts are not copied or closely translated by default.

Failure and Fallback

• Mark unknown architecture signals as unresolved and keep the affected capability incomplete.
• Use approximation when only a surface simulation is possible; do not report Done.
• Record an environment limitation separately from an implementation gap.
• Ask the user only when scope or compatibility direction materially changes the required outcome.

Upstream and Downstream

• Upstream: sakura-spec and sakura-research for a replication task.
• Downstream: sakura-plan, then sakura-verify and sakura-review for conformance evidence and the final verdict.

Handoff

Include target classification, capability count, automatic escalations, mandatory levels, unresolved signals, mandatory gaps, contract path, validation path, and the next skill. Do not include external code fragments or research transcripts.