AmplifierSkills and tools for thoughtful work

Skill

Build with Torque

Add a domain without tangling the application.

An authoring skill for Torque developers. Give a bundle a clear responsibility, connect it through declared interfaces and events, and plan data changes before they reach an existing store.

Use Build with TorqueWatch the 70-second filmWalk through an example
What you getFictional illustration
Fictional bundle: maintenance tasks
Owns: task records and task state
Depends on: declared asset query interface
Consumes: asset.updated with declared payload
Optional dependency absent: task history still readable
Acceptance: event replay is idempotent; migration can roll back

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

Keep domains independent

Own tables inside a bundle and call other domains through declared coordinator interfaces.

Make integration inspectable

Align manifest queries, routes, handlers, events and UI exports with the installed host contracts.

Treat data changes deliberately

Include migration, restart and rollback in the slice instead of assuming hot reload proves readiness.

The film

Own your tables. Declare the rest.

In 70 seconds, Pockets the raccoon night porter borrows a master key to fetch another floor’s news, and the tasks floor goes dark when the assets floor renames a column. Build with Torque keeps each domain on its own keycard floor: you ask a neighbour through the coordinator on a declared line, react to past-tense events, plan what still works when a neighbour is gone, and try data changes on a mock-up floor with a way back. Captions are on the player; a transcript is below.

Download the film 15-second cut Captions
Read the transcript

Your Torque app is one hotel. Each domain has its own keycard floor.

Tasks needs boiler news, so Pockets borrows a master key.

Assets renames a column. Tasks goes dark.

Build with Torque keeps each domain on its own floor.

To ask a neighbour, you call the coordinator on a line you declared.

A boiler changes, and assets posts a past-tense fact. Tasks reacts.

Out comes the plan: what tasks owns, what it needs, what works when a neighbour is gone.

Data changes go to a mock-up floor first, with a way back.

Its checks test the guide, not your running hotel.

On screen: Own your tables. Declare the rest.

Build with Torque. Add a domain without tangling the application.

The hotel and its building-maintenance app 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.

Place the responsibility

Inspect the current mount plan and neighboring bundles; decide whether configuration or a new domain is needed.

Fictional example

A task bundle without a cross-domain table join

The brief A fictional maintenance app needs task cards that react to asset changes.

Before

Import the asset bundle directly and query its tables from the task domain.

After applying the method

Keep task storage scoped; declare the asset dependency and public query contract, subscribe to a past-tense asset event, and test missing optional dependencies.

The useful boundary is the declared behavior and contract; a shared process does not justify shared private state.

A clear job.
A useful stopping point.

Use when designing a Torque domain, authoring a bundle manifest and logic, wiring events/interfaces, or validating integration and schema changes.

Use it when

  • A new domain must join an existing Torque app.
  • Two bundles are reaching into each other’s private tables.
  • A manifest or schema change needs a migration and rollback plan.

Choose another route when

  • The Torque framework, its services or a replacement data layer.
  • A promise that historical package versions or private Git URLs are publicly available.

Place

A domain boundary or dependency is unclear.

A bundle responsibility map with declared interfaces, events, and optional dependencies.

Author

The domain contract and host are known.

A manifest/logic/UI slice that fits the scoped data and coordinator contracts.

Integrate

A bundle must join a running app or evolve its data.

A mount plan, integration checks, migration/rollback evidence, and explicit unknowns.

Read the canonical method

Build with Torque

Build a domain that still fits the rest of the application.

Read the host before proposing a bundle

Inspect its mount plan, installed package versions, neighboring domain manifests, runtime contract tests, and existing registry. State the domain outcome and what is explicitly outside it. Decide whether configuration of an existing bundle is enough or a new domain responsibility is warranted. A shared process does not make private tables or source imports public interfaces.

Choose the mode

  • Place: trace domain ownership, data, events, and public query contracts. Use the registry to understand the package roles, then verify actual availability and versions. Keep the kernel, schema, data layer, event bus, server, shell, CLI, and extensions in their native modules. A new skill is an authoring front door, not a replacement platform.
  • Author: use the substantial Bundle Authoring Guide for manifest, logic class, route/interface implementation, scoped data, events, UI exports, tests, and integration. Read only the sections needed for the task. Use AI setup context for orientation; historical install and demo values there are examples, not deployment instructions.
  • Integrate: declare a mount plan, dependencies, configuration, native gates, schema/data migration, and rollback. Verify on an isolated copy before any existing data changes.

Preserve the non-obvious contracts

A bundle owns its tables; avoid cross-bundle source imports. Cross-domain calls go through the coordinator and declared dependencies. Public interfaces take named-argument objects; the manifest's query names and the class's implemented interfaces must agree in both directions. Route declarations need corresponding handlers. Authentication, validation, and application authorization are distinct checks; a declaration alone is not proof they ran.

Events describe past-tense facts using the domain/entity namespace, with a declared payload. Subscriptions should match published events and preserve idempotency/recovery assumptions. An optional dependency can be absent: define the degraded behavior and test it. Keep UI component export keys aligned with manifest routes, and use the current shell contract rather than copying another app's internals.

Intents explicitly declare context, allowed tools, goal, success criteria, and required confirmation. Runtime enforcement must be verified against the installed engine; a prompt promise is not a permission boundary. Use the application's existing authorization and provider setup. Do not install an AI runtime merely to author a non-AI domain.

Prove the slice, then hand it over

Run the native manifest/contract validator and tests available in the host. Check a successful interface call, invalid input, unauthorized request, missing dependency, event reaction, state persistence, and failure recovery where applicable. A mocked unit test is not proof that HTTP, UI, or a real database migration works. For schema changes, retain data snapshot and rollback; a table rebuild rewrites data even when called a type change. Hot reload does not establish a production restart or migration.

Return changed bundle/mount-plan paths, ownership and contract decisions, exact native commands/results, actual runtime scope, migration status, and unresolved evidence. The reference mirrors are generated from the canonical docs with a hash check; edit the docs, not the generated copies. Documentation-content checks establish coverage and packaging, not framework behavior or user benefit.

Limits and prerequisites
  • Installing the authoring method installs no Torque runtime or npm package.
  • Torque framework modules keep their own code ownership, package identities, and lifecycle; they are not all being renamed or retired.
  • Registry versions and historical examples are source snapshots. Inspect the installed package contracts before applying them.

Your first useful run.

Bring the host mount plan and one domain you want to add.

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-torque.git
cd amplifier-skill-build-torque
python3 scripts/capability.py doctor
python3 scripts/capability.py install --dest ~/.agents/skills
Native tools and optional execution
torque --help
torque validate
torque doctor

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 Torque to design a maintenance-task bundle. It should react to asset changes without reading another bundle’s private tables. Inspect this host first, then propose its manifest, public interfaces, events and migration 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

Know what you can rely on.

Canonical reference hashes and 106 documentation checks passed. They establish reference coverage, not a deployed framework. Native package availability and app behavior need checking against your installed Torque environment.

Read the checks and their scope
  • Canonical reference mirror gate — passed

    AI setup, Bundle Authoring, and Registry mirrors match canonical sources plus their recorded source/output hashes.

  • Retained documentation checks — passed

    47 Node tests and 59 Python tests pass. These verify documentation coverage only; no Torque framework/runtime or app deployment result is claimed.

  • Portable build and clean install — passed

    Canonical ZIP bytes, local links, complete method/license, clean install and idempotent reinstall pass. No runtime starts.

Canonical reference hashes and 106 documentation checks passed. They establish reference coverage, not a deployed framework. Native package availability and app behavior need checking against your installed Torque environment.

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