AmplifierSkills and tools for thoughtful work

Skill

Transfer

Bring the behavior to the app you use.

A skill for moving a bounded capability between applications. Understand the donor, check what the host already does and rebuild the missing behavior through the host’s own architecture.

Use TransferWatch the 70-second filmWalk through an example
What you getFictional illustration
Fictional transfer: pause a job
Donor contract: running → paused → resumed
Runtime prerequisite: explicit pause/resume operation
Client A: wire existing control
Client B: add control through native UI seam
Verification: observe state transitions in each host
State: gap checked; implementation not yet verified

Fictional worked example. It illustrates the intended output; it is not a measured result or a real customer story.

Transfer the useful part

Describe the behavior and failure paths, then drop features the host already has or does not need.

Keep the host coherent

Re-express the capability through native interfaces instead of grafting donor source into a different system.

Verify against the donor

Use donor-derived acceptance checks and actual host surfaces to challenge the builder’s completion claim.

The film

Two buttons. Zero pauses.

In 70 seconds, Tilly the long job cannot stop, and copying another app's pause button changes nothing, because there is no pause underneath. Transfer watches what the button does, checks what your apps already have, builds the shared pause first, then lets each app add it in its own style. Until the donor's test runs in each real app, the card says not verified. Captions are on the player; a transcript is below.

Download the film 15-second cut Captions
Read the transcript

Meet Tilly. She’s your long job, and she can’t stop.

Next door, another app can pause its jobs. You want that.

So you copy its button into both your apps.

Tilly presses it. Nothing. Underneath, there is no pause to call.

Transfer watches what the button does. Running, paused, resumed. The donor code stays put.

It checks what your apps already have. The real gap is underneath.

So the shared pause lands first. Then each app adds it in its own style.

The test comes from the donor, and runs in each real app. Until then, it says not verified.

On screen: Move the behavior, not the code.

Transfer. Bring the behavior to the app you use.

The apps, the job and the run are a fictional example. The film shows how the skill behaves; it does not report results.

See the work take shape.

Fictional worked example. It illustrates the intended output; it is not a measured result or a real customer story.

Compare donor and host

Observe the behavior, inspect both architectures and record the genuine gap.

Fictional example

A client feature with a server prerequisite

The brief A fictional donor lets users pause a job; two target clients lack it and their shared runtime has no pause operation.

Before

Copy donor code into both clients and mark two features complete.

After applying the method

Describe pause/resume behavior, add the runtime protocol first, then implement each client in its own seam and test actual state transitions.

The capability crosses hosts through an explicit contract; client UI cannot manufacture backend behavior.

A clear job.
A useful stopping point.

Use for a bounded capability transfer across architectures or languages, while keeping host boundaries intact.

Use it when

  • A feature in another app would be useful in yours.
  • The same capability must reach several different clients.
  • A UI feature depends on a missing shared protocol operation.

Choose another route when

  • Copying or vendoring donor implementation as a shortcut.
  • Rebuilding an entire application; use Migrate for that scope.

Gap check

A donor seems useful but host overlap is unclear.

Observed donor contract and an explicit keep/drop rationale per host.

Re-express

A missing capability and host seam are known.

A native host slice with tests, real-surface probe, and CI parity.

Verify

The builder reports a transfer complete.

A donor-derived check, bounded reopen, and retained evidence or blocker.

Read the canonical method

Transfer

Bring a proven capability to the host you use.

Gap-check before building

Declare donor(s), host(s), bounded capability/scope, excluded work, and acceptance surface. Read the host's current code and operate it where useful. Determine which behavior already exists and what is genuinely missing in each host; document keep/drop reasons. The original principles and runbook preserve the multi-host HGT engine's stricter queue policy; state any intentional instance deviation rather than silently changing its graph.

Extract the observable contract

Observe the donor's actual user-facing behavior and read its code to understand boundaries. Record trigger, inputs, state transitions, outputs, errors, recovery, cancellation, persistence, and dependencies. Do not import, vendor, or copy donor source. Preserve attribution for ideas. Source access and a working donor demo do not mean the host implementation already works.

Plan through host seams

Choose each host's existing layer and interface. Keep a pure protocol client a client. A shared backend/protocol prerequisite lands before dependent clients. The retained ledger supports a, ab, and split; use distinct ordered rows for backend and client slices. Avoid duplicate work when the capability already exists. Independent disjoint work may run in parallel; competing edits and state dependencies need ordering.

Build one vertical slice

Author an acceptance probe from the donor contract before host implementation. Re-express the feature in host idioms, with unit checks, the host's normal CI gate, and a real-surface probe. Terminal features require a real terminal; API/desktop features require the corresponding observable surface. Execute and preserve evidence. A passing unit fixture or an LLM statement alone is insufficient.

Use isolated branches and existing granted authority. The historical graph can push/open PRs, but installing this skill never authorizes publication. Bound attempts (the engine uses at most three), then acknowledge a blocker with reason and a reproducible handoff. Keep requested, implemented, independently verified, acknowledged, and released distinct.

Verify against the donor

A verifier derives checks from the donor knowing only the capability ID/scope; hide builder artifacts and expected answers when feasible. Record what blindness and independence actually held. Findings may go to the builder; builder claims must not define the verification oracle. Reopen within a declared bound; preserve failed checks and remaining gaps. A ratchet metric tests ledger state transitions, not donor-host behavioral equivalence by itself.

Return

Give the donor contract, per-host gap and seam decisions, changed interfaces, exact unit/real-surface/CI results, independent verification evidence, blockers, and rollback. Do not call a transfer proven merely because the queue has no new rows.

Limits and prerequisites
  • The donor is read-only; transfer observable behavior by re-expression, not source grafting.
  • Existing host conventions and authority boundaries win over donor implementation choices.
  • Optional HGT graphs, ledgers, Forge, and Amplifier are execution aids; declared fitness is not benefit evidence.

Your first useful run.

Bring one donor capability and the host where you want it to work.

The download contains the complete skill folder. Extract it into the skills directory supported by your agent, keeping its references and license together. Or use the source installer below. Python 3.11+ is required for that installer.

Download the portable skillSource on GitHub

Start from the public source

git clone https://github.com/michaeljabbour/amplifier-skill-transfer.git
cd amplifier-skill-transfer
python3 scripts/capability.py doctor
python3 scripts/capability.py install --dest ~/.agents/skills
Native tools and optional execution
amplifier bundle add ./bundle.md

These commands are for the optional native surface. Follow its installation guide and prerequisites; portable method installation is separate.

Keep the complete skill folder together, including its references and license. The host applies the method in your context; the skill does not start a background service.

  • Requires Git and Python 3.11+ for the repository installer. The portable method itself can be read by a compatible agent without a service or provider account.
  • The destination is a skills-parent folder. Use the discovery path supported by your agent; ~/.agents/skills is an example, not a universal host setting.
  • Keep the complete installed folder, references and license together. Identical reinstall is safe; conflicts are refused. A deliberate --replace keeps a dated backup.

Try this with your agent

Use Transfer to compare pause/resume behavior in this fictional donor with two host clients. Keep donor source read-only. Identify current host overlap and shared runtime prerequisites, then propose one donor-derived acceptance probe per slice.

Use after installing in a host that loads skill folders. Supply your own task files and review the result.

Keep the guide nearby

Read the guide · License · Changes · Release metadata · Install guide · Migration · Validation · Native guide · consolidation

Know what you can rely on.

Retained graph syntax and ledger regression fixtures pass, and the portable install is checked. A ledger state is not donor-host equivalence; a real transfer still needs its source-derived and actual-surface evidence.

Read the checks and their scope
  • Ledger ratchet detector — passed

    Builder/verifier state regressions rejected and synthetic fixture curve read. No new donor-host transfer or user benefit claimed.

  • Executable graph syntax — passed

    Both retained graphs parse. No graph/orchestration changes or paid pipeline execution.

  • Portable packaging and install — passed

    All operations passed. No runtime activation or effectiveness measured.

  • Skill discovery metadata — passed

    Skill is valid. This is a structural check, not a behavioral benchmark.

Retained graph syntax and ledger regression fixtures pass, and the portable install is checked. A ledger state is not donor-host equivalence; a real transfer still needs its source-derived and actual-surface evidence.

Fictional examples explain the capability. Tests check the stated behavior. Outside-user outcomes need their own evidence.