How the agents work together

Every task is handled by three agents. Each one does one job, and each hand-off shows up in the task thread.

Reading their facesCopy Anchor Link

Each agent shows what it's doing. Pip looks up while thinking and leans in with raised brows while waiting on your answers; Nib taps away while building; Moss squints and scans while testing. A worried face with a sweat drop means the task needs your help, a sleeping agent means the task is paused (for example when you're out of credits), dizzy spirals mean a step failed on our side, and a jump with sparkles means your change just went live. They move at their own pace, so two agents on a screen never move in sync. With reduced motion turned on in your system settings, they hold still and only their expression changes.

The flow of a taskCopy Anchor Link

1. Drafting. Pip reads the relevant files and your store memory, then asks a round of clarifying questions (usually three to six) before writing the plan: where it goes, how it looks and behaves, the wording. When you answer, he carries on from where he stopped, with everything he read still in mind. The questions come one at a time. Pick one or more options, write your own answer, or skip a question and let Pip decide, then submit them together. Clarifying questions cost nothing.
2. Building. After you press Build it, Nib starts right away while Shopify duplicates your live theme, and his work lands on that copy. He starts from exactly what Pip read while planning (read again from the copy, so it's never out of date), so he doesn't explore the theme a second time. Before he hands over, he runs Shopify's Theme Check on the copy and checks for bugs QA used to catch, such as a translation escaped twice or a new setting without a value. Every round Nib works on (the build, then any fix or adjustment) adds its own file cards to the thread, showing only what that round changed. Click a card to see that round's diff; All changes shows the whole copy against your live theme.
3. Testing. Moss writes the test from Nib's exact changes and runs the QA checks on your real storefront. Flukes are retested on their own. If something really fails, Moss explains why and asks you whether Nib should fix it or it should go to you for approval.
4. Waiting for your approval. You review the before and after, the QA report and, if you want, the code diff.
5. Live. Kobold publishes the copy and Moss re-runs the smoke tests on your live store.

When a check keeps failing, the task moves to Needs your help with what went wrong and a few ways forward. Nothing is published.

Changing something after it's liveCopy Anchor Link

Write in the same thread to change something that's already live ("make the button a bit smaller"), or press Try again with a fix after a rollback. Kobold starts a new round on a fresh copy and builds on what the task already shipped, so you don't have to describe the first change again. Pip and Nib see the earlier plan, Nib's notes and the exact changes that went live.

Before Pip plans, Kobold checks that your theme still has that change:

• It does: Nib builds on top of it ("Nib is building on top of what's live").
• You rolled it back: Nib brings it back on the fresh copy, then makes your change.
• It was replaced or edited since (another theme was published, or someone edited those files in the Shopify admin): Pip asks what to build on. You can bring back what Kobold shipped, or start from the theme as it is now and keep those edits. If only some files changed, Pip lists them. If you skip the question, Kobold brings the change back when the theme lost all of it, and keeps the edits when only some files changed.

If the theme loses the change after Pip planned but before you press Build it, Nib brings it back on the copy and says so in the thread. A task keeps the theme it started from (see Work from theme), so rounds after the first can't switch it. Stores that push changes as a CLI change package aren't checked, because Kobold can't see what was pushed.

Test data for QACopy Anchor Link

Some changes can only be tested with your store's own data. For a discount code field, Moss needs a code that works, one that should be rejected and, when it matters, one that exists but doesn't apply (a minimum spend, say). Pip asks for these in his question round and puts them on the plan, and suggests saving reusable ones to store memory under Testing, so he doesn't ask again. If Moss still finds something missing when he writes the test, he asks you, and QA waits for your answer. Kobold can't create discounts or products, so give ones that already exist.