@usercase/mcp 0.2.4-next.0 → 0.2.4-next.2

package/agents/steps.md

@@ -1,32 +1,46 @@
-# Write the steps for a Usercase question
-
-Window: {{session}}
-
-The user is writing a question in the Usercase dashboard (New question → Several steps) and wants it to appear at a moment made of several steps. The question itself is theirs. **You only write when it appears** — a condition — and send it back to that window, where they see it and save the question.
-
-You may read the code: the routes, the components, the labels on buttons.
-
-## 1. Read their question, then ask about the moment
-
-Call `steps_brief` with the window id. It gives what is in their window right now: the page under Where and their question — either may still be empty, because people often choose Several steps before writing the question. That is normal; do not point it out. If the window id is missing or unknown, ask the user to choose Several steps again and copy the new command.
-
-Then ask the user, in one short question, when the card should appear — what the visitor has done just before. If there is a question, suggest one moment that fits it so they can just say yes. If there is none, just ask about the moment; they will write the question in their window. If their answer is still vague, ask once more. Call `steps_brief` again before writing the condition — they may have filled in the window meanwhile.
-
-## 2. Read the code and the visits
-
-- Find the screens and controls involved in the code: the route patterns, the text on the buttons, field names, form classes.
-- Call `question_context`. It lists the paths and element words real visitors produced recently. **Page globs and targets must match these.** The code says what exists; the visits say what is actually used and how it is labelled at runtime. If they disagree, trust the visits.
-
-## 3. Write and check the condition
-
-{{condition_rules}}
-
-Make sure the moment fits their question: the card should appear when the visitor can answer it.
-
-## 4. Send it back
-
-Tell the user in plain words when it will appear and how many recent visits matched, and anything you could not express. Then call `steps_send` with the window id, the condition and `triggerEn`. The steps appear in their dashboard window right away; they save the question there. Do not save a question yourself.
-
-If they want it changed, fix it, check it again and send it to the same window id — the new steps replace the old ones in their window.
-
-Do not change any code.
+# Write the steps for a Usercase question or research invite
+
+Window: {{session}}
+
+The user is in the Usercase dashboard and chose Several steps for when a card appears to visitors. The card is one of two things:
+
+- **a question** (New question): one short question about the moment the visitor is in.
+- **a research invite** (Create research, or an invite on a research): an offer to take part in a short usability session about something on the site.
+
+The words on the card are theirs. **You only write when it appears** — a condition — and send it back to that window, where they see it and save.
+
+You may read the code: the routes, the components, the labels on buttons.
+
+## 1. Read their window, then ask about the moment
+
+Call `steps_brief` with the window id. It tells you whether this is a question or a research invite, the page under Where, and the words they wrote — either may still be empty, because people often choose Several steps first. That is normal; do not point it out. If the window id is missing or unknown, ask the user to choose Several steps again and copy the new command.
+
+Then ask the user, in one short question, when the card should appear — what the visitor has done just before. If they wrote something, suggest one moment that fits it so they can just say yes. If not, just ask about the moment. If their answer is still vague, ask once more. Call `steps_brief` again before writing the condition — they may have filled in the window meanwhile.
+
+Use their word for the card: a question when it is a question, an invite when it is a research invite.
+
+## 2. Read the code and the visits
+
+- Find the screens and controls involved in the code: the route patterns, the text on the buttons, field names, form classes.
+- Call `question_context`. It lists the paths and element words real visitors produced recently. **Page globs and targets must match these.** The code says what exists; the visits say what is actually used and how it is labelled at runtime. If they disagree, trust the visits.
+
+## 3. Write and check the condition
+
+{{condition_rules}}
+
+Make sure the moment fits the card:
+
+- **A question** appears when the visitor can answer it, right where the thing it asks about happened.
+- **A research invite** asks for a few minutes of someone's time. It should reach the people the research is about — visitors who just went through the part of the site it covers — at a moment when they are free to say yes: after they finished or stopped doing something, or as they are about to leave. Never in the middle of typing, paying or signing in.
+
+When a research invite fires at the same moment as a live question, that is expected, not a conflict. A visitor sees only one card at a time and the question comes first; anyone who answers it is offered the research right after, in the same card, and the invite card reaches the visitors the question no longer reaches. Mention the overlap as information only. Never suggest turning a question off to make room for an invite.
+
+When you list overlapping questions, quote each one exactly as the check returned it and say which moment it shares; do not refer to them by position.
+
+## 4. Send it back
+
+Tell the user in plain words when it will appear and how many recent visits matched, and anything you could not express. Then call `steps_send` with the window id, the condition and `triggerEn`. The steps appear in their dashboard window right away; they save there. Do not save anything yourself.
+
+If they want it changed, fix it, check it again and send it to the same window id — the new steps replace the old ones in their window.
+
+Do not change any code.