AmplifierSkills and tools for thoughtful work

Skill

Build with Amplifier

Add the capability. Keep the architecture clear.

A working guide for people extending Amplifier. Find the right home for a feature, build one useful slice, and check that it behaves correctly inside the host you actually use.

Use Build with AmplifierWatch the 70-second filmWalk through an example
What you getFictional illustration
Fictional slice: import progress
UI owns: display and user cancellation
Core owns: tool execution
Contract: current host event schema, inspected revision recorded
Checks: success, error, cancel, listener cleanup
Open evidence: real-host run pending

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

Choose the right seam

Separate application interaction, reusable bundle wiring, callable tools, hooks and providers before adding code.

Keep the useful context

Six substantial reference topics cover Core, Foundation, module authoring, application integration, routing and work across repositories.

Hand over a working slice

Make inputs, errors, cancellation and cleanup explicit, with commands someone else can repeat.

The film

Find the seam. Then build the slice.

In 70 seconds, Tock the metronome copies the conductor into the lobby to show progress, so two loops keep time and Cancel stops only the copy. Build with Amplifier finds the right seam in the host you installed, hangs a hook so the lobby only listens, and proves the slice: success, bad input, cancel and cleanup. Captions are on the player; a transcript is below.

Download the film 15-second cut Captions
Read the transcript

Inside your app, one conductor runs the work.

You want a progress panel in the lobby. Tock volunteers.

The quick fix copies the conductor out front.

Two loops now keep time. Cancel stops only the copy.

Build with Amplifier finds the right seam first, in the host you actually installed.

The lobby owns the display and the cancel button. Core keeps the conductor.

So you hang a hook by the podium. The lobby listens, and the work stays in the hall.

Then you prove the slice: success, bad input, cancel, and cleanup.

Old examples are history. You check them against what you installed.

On screen: Find the seam. Then build the slice.

Build with Amplifier. Add the capability. Keep the architecture clear.

The app and its music importer 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.

Inspect the host

Read its manifests, installed contracts and a neighboring implementation. Record what version the advice applies to.

Fictional example

A progress panel that does not own the loop

The brief A fictional terminal app needs visible streaming progress.

Before

Copy the orchestrator into the UI and add a custom session store.

After applying the method

Read the installed hook/event contract; subscribe in the client, retain Core execution custody, and test cleanup on cancellation.

Composition and lifecycle ownership keep UI interaction separate from the execution engine.

A clear job.
A useful stopping point.

Use when adding an Amplifier capability, composing a client, or debugging the boundary between Foundation and Core.

Use it when

  • You need to add a tool, hook, provider or bundle.
  • A client feature is starting to duplicate the execution engine.
  • A change spans Core, Foundation and an application.

Choose another route when

  • A replacement Amplifier runtime or a new provider configuration.
  • Blindly copying historical API signatures into a different installed version.

Place

A request could become configuration, bundle, tool, hook, provider, or app code.

A seam decision with inspected contracts and a smallest working slice.

Build

The host and extension seam are known.

A native implementation with cleanup, failure behavior, and contract checks.

Delegate

The user explicitly asks to run work through Amplifier.

A bounded runtime request and an attributed result; never implicit delegation.

Read the canonical method

Build with Amplifier

Build the extension in the right place, against the current contracts.

Start with the seam

Inspect the actual host's manifests, source, extension protocol, and tests. Record versions or commit IDs. Ask what must change: app interaction, reusable composition, a callable operation, event observation/control, model access, context policy, or execution policy. Prefer the existing seam that owns that responsibility. A bundle wires capabilities; it does not replace Core. Foundation resolves/composes/prepares bundles; the host's Core protocol owns execution. Check this against the installed source, not a remembered catalog.

Place → build → prove

  • State the user's observable outcome and one failure case. Locate the host's current contract and a neighboring implementation. Explain why config alone is sufficient or why code is needed.
  • Write a boundary table: inputs, output/result schema, failure semantics, lifecycle/cleanup, permissions, and owner. Keep credentials in the host's existing provider configuration.
  • Build one vertical slice in an isolated branch. Compose only needed modules; preserve the host's provider/session configuration. Avoid wrapping Foundation APIs solely to rename them.
  • Test mount/registration, a successful call, invalid input, cancellation, and cleanup using the host's actual test doubles or runtime. A fake-provider result proves integration plumbing only.
  • Run the host's normal checks. If live execution is warranted and already authorized, use one bounded test with explicit input/output limits. Record the exact command, source versions, result, and what remains untested.
  • Hand over a native install command and rollback. Do not claim persistence because a session ID was saved: distinguish metadata, current session state, and durable resumption.

Choose the reference deliberately

Current contract caveats distinguish preserved source examples from verified installed APIs. The six substantial topics from the current public suite remain available behind this one entry:

| Need | Preserved topic |

|---|---|

| Classify repo, layer, intent and delegation | Ecosystem router |

| Kernel, module types, hooks and session concepts | Core concepts |

| Author a module or compose a capability | Module and bundle development |

| Navigate Foundation patterns and examples | Foundation reference |

| Embed runtime behind an application boundary | Application integration |

| Order changes and validate across repos | Cross-repo workflows |

CLI and Foundation patterns retain the original substantial authoring guide and its architecture, hooks, build, and troubleshooting references. Those examples are historical patterns, not verified current SDK signatures. Runtime delegation preserves the separate explicit-intent workflow. Optional helper scripts are installed in scripts/; use sh scripts/list_agents.sh --help or sh scripts/session_context.sh --help from the installed skill folder. Cached agent/session listings are dated evidence and can be stale. Do not print private transcripts or credentials.

For delegation, first inspect amplifier --help and provider/bundle state. Run only the task the user asked to delegate; report start/completion/error evidence separately. There is no requirement to delegate a local edit simply because this skill is installed.

Completion

Return the seam decision, changed paths, inspected contracts, exact checks, live-versus-fake evidence, remaining blockers, and local install/rollback. Never count a copied API example or packaging check as a working extension.

Limits and prerequisites
  • The portable method needs no Amplifier install. Executing examples or delegation needs a configured runtime.
  • Historical API and model examples are reference material; inspect installed versions before copying a signature.
  • Memory is an optional extension, never a prerequisite.

Your first useful run.

Bring one feature request and the repository where it should 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-build-amplifier.git
cd amplifier-skill-build-amplifier
python3 scripts/capability.py doctor
python3 scripts/capability.py install --dest ~/.agents/skills
Native tools and optional execution
amplifier --help
amplifier bundle list

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 Build with Amplifier to inspect this repository. I want a progress panel for a long-running tool. Decide where the feature belongs, identify the actual event contract, and propose one slice with cancellation and cleanup checks.

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 · UPSTREAM SUITE · upstream suite manifest · upstream merge

Know what you can rely on.

The six-topic reference mirror, isolated helper regressions and complete portable installation are checked. These checks establish retained content and software behavior; a new extension still needs validation in its actual host.

Read the checks and their scope
  • Current public six-topic reconciliation — passed

    Normal merge retains public4beb46c and previous/secondary ancestry. All six full source topics match generated source/output hashes;8 list-agent shell checks,11 session shell checks and2 discovery tests pass.31 portable files install byte-identically and reinstall idempotently. No provider/runtime activation or efficacy claim.

  • Isolated discovery regressions — passed

    2 tests; opaque cache-folder bundle filtering and invalid limit handling; stub runtime and dedicated AMPLIFIER_HOME. No personal state or provider used.

  • 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.

The six-topic reference mirror, isolated helper regressions and complete portable installation are checked. These checks establish retained content and software behavior; a new extension still needs validation in its actual host.

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