Your agent has
some reading to do.

01 / YOU CAN SKIP THE FLASH CARDS

Know your application.
Let the agent learn the APIs.

You should be able to ask for a searchable list, open an editor, or change what happens after saving without memorizing the framework first. Your agent can read the contracts and choose the implementation.

You direct.

Describe the behavior. Try the result. Decide what needs to change. Read the relevant code when you want a closer look.

Your agent implements.

Find the matching documentation. Choose the responsible Application or View. Make the change, then check that it behaves as requested.

Marionette gives that work a recognizable shape. A Region owns the View in one part of a screen. A CollectionView manages repeated items. An Application gives a feature a start and a stop. The agent has a vocabulary for building it; you have a way to follow what it built.

The agent will still have ideas. Some of them will even be good. Clear responsibilities give you somewhere to point when the next instruction is “change this part.”

02 / CHOOSE IT FOR THE WORK

For applications with
moving parts.

A list that stays put while its detail panel changes. An editor with local state. A feature that loads data before opening and cleans up when it closes. These are the kinds of relationships Marionette makes explicit.

That structure is useful when an agent will keep adding and revising features—and someone needs to understand where each change belongs.

A mostly static page or a small isolated interaction may need very little of it. If your product depends on a particular component library, server-rendering setup, or framework-specific integration, have the agent verify that fit before choosing Marionette.

For an existing application, begin with the problem you want to solve. Keeping the current stack, introducing one isolated feature, and migrating are different decisions. A new version is not a reason to rewrite a working application.

03 / WHAT’S IN THE BOX

A familiar name.
A different set of choices.

Marionette 5 no longer requires Backbone, jQuery, or Underscore in core. Plain objects, static arrays, and native DOM operations are available from the start.

Interface structure

Applications, Views, Regions, CollectionViews, and Behaviors organize the feature and its lifetime. See how they fit.

Rendering & DOM

Template functions work with the default renderer. Optional adapters connect Lit HTML, Morphdom, or jQuery; a renderer API supports other template systems. Check the available adapters.

Data & state

Optional @mnjs/data provides observable Models and Collections. Adapters also connect Backbone sources and XState actors. Choose the data setup.

Your application

You supply API access and persistence, choose components and routing, and connect the tools your product needs. Check each required integration; an extension point still needs an implementation.

If you know an earlier Marionette, send your agent to the v5 migration guide. It has a few habits to unlearn.

04 / THE VERSION MATTERS

Match the version.
Build on its contracts.

This site’s documentation and demos use Marionette 5.0.0. Pin matching package versions and use their documentation when choosing APIs and integrations.

Before committing a product, check the integrations and support you will depend on. Agent-readable guidance helps with implementation; maintainer availability and the people who will own the application still belong in the decision.

05 / PULL SOMETHING

Try the moving parts.

Choose an item in the homepage application. Its detail View is replaced and the previous one is destroyed. The screen and list keep their identities. Follow that small change before asking your agent for a bigger one.

The demos put lists, cleanup, and unfinished work on display, with their running source alongside. Radio Ghostbusters is about cleanup. The ghosts are there to help.

For a more ordinary feature, give your agent the Records example: loading, selection, retry, and keeping the interface in place. Then bring a request of your own to Backstage.

For a complete application, read the RealWorld case study: three development stages, the resulting Conduit frontend, and measured comparisons with selected implementations.

For an established product, read the RoundingWell migration study: preserving care-team workflows, clarifying ownership, and measuring worklist costs.

06 / THE SECOND REQUEST IS THE INTERESTING ONE

Build a feature.
Then change your mind.

1. Ask for something useful.

   Choose one feature with an interaction and a data or state change. Give your agent the agent entrypoint and your requirements.

2. Ask for a revision.

   Change the selection behavior, add a filter, or adjust what happens after saving. Ask the agent to explain which part owns the change.

3. Try both paths.

   Check the new behavior and the behavior you expected to keep. Close and reopen the feature. Follow the changed code far enough to decide whether you can keep directing it.

You do not need to recite the API. You need an application you can work on with your agent—and a second change that still makes sense.