Prompt patterns

Two surfaces in Cobblr take a plain-language request: Cobb and the AI builder. A little care in how you phrase things gets a better result from both. Scan routing takes no prompt at all, but it is steered by how you name and shape your trackers, so that is here too.

Asking Cobb to do something

Cobb reads your workspace before acting, so it does not need you to spell out ids. Name the thing and what you want.

• "Add a part called M3x10 socket screw, quantity 200, in Bin 4."
• "Set the reorder point on PLA black to 3."
• "Mark the enclosure build done."
• "What is low on stock right now?"

Vaguer requests still work, they just cost a round trip while Cobb asks which record you meant. If several records match "black filament", Cobb lists them and asks. Naming the exact one skips that.

Open Cobb from a screen's Ask Cobb button and you can point at what you are looking at without naming it, since Cobb reads the page you are on. "Put these away" or "what is low here" resolve against that screen.

Point instead of describing

The shortest prompt is often the one that names nothing. Tick the rows, or highlight the text, or press the Cobb button on the record, and then say what to do with "these". Cobb gets the records themselves rather than a search:

• Tick eight parts, then "order more of these".
• Tick a rack's shelves, then "delete duplicates". Without the tick that means every duplicate in the workspace.
• Press the Cobb button on one machine, then "when was this last serviced?".

Ticking beats naming for anything you can already see, because a name has to be resolved and can match two records. See Pointing Cobb at something.

Ask for the whole set at once

"Each rack should have Shelf 1 through 5" is one request, not sixty. Ask for the set rather than looping yourself: it lands in seconds, arrives as one line with one Undo, and counts what was already there rather than duplicating it. Up to 200 records in a request.

Holding off on writes

When you want Cobb to hold off on writing, say so, or use the Changes chip in the chat header.

• Changes: ask (the default): nothing runs without a confirm.
• Changes: auto: edits apply as you go.
• Changes: off: it stops writing at all.
• Actions always ask whatever the setting. Every change stays undoable.

Describing a bundle to the builder

The builder does best when your description names three things: what you track, the fields you care about, and any automation. Put them in one description rather than a title.

Thin, and the builder has to guess:

Track my paint.

Fuller, and it has enough to shape real fields and a wire:

Track my spray paint cans: brand, color, finish (matte, satin, gloss), and how many cans are left. When a color drops to one can, add it to my shopping list.

• Your wording also sets the scope. For a tweak, the Build page derives which of your trackers the change touches from the words and field names you use, so naming the thing ("parts", "yarn") lands it in the right place. A Change link shows the full picker if it guessed wrong.
• You do not have to get it right the first time. Apply what it builds, then adjust the fields directly, or describe a new tracker and keep the parts that fit.

Shaping trackers so scans route

Scan routing reads a tracker's own identity, so the tracker's design is what steers it, with or without AI connected:

• Name an instance for the thing it holds. A "Yarn" tracker pulls in a scanned skein, and a "Car Parts" tracker pulls in a brake pad. A generic name routes worse.
• Give fields real choice lists. A weight field with the choices Lace, Worsted, Bulky lets a capture that says "worsted" fill it. The choices are the vocabulary the matcher extracts against.
• Add scan keywords for ambiguous cases. When two trackers could plausibly hold an item, a keyword on the right one ("skein", "ball-band") sharpens the match.
• Correct a scan that routed wrong and it teaches the workspace, so the next similar item lands better.