@usercase/mcp 0.2.2-next.0 → 0.2.2-next.1

package/agents/focus.md

@@ -2,11 +2,12 @@
 
 The user wants this run to be about one part of the site — "{{focus}}" (it may name more than one feature). Everything below still applies, with these changes:
 
-**Step 2 — pin down what the focus means.** After you build the feature map, find which features, pages and routes "{{focus}}" covers. Before casting anyone, tell the user in one or two lines what you understood (e.g. "the calendar = /calendar and the event detail popup") and wait for them to confirm. If you cannot find it on the map, or it could mean several things, ask — do not guess from the word alone.
+**Step 2 — pin down what the focus means, and ask.** After you build the feature map, find which features, pages and routes "{{focus}}" covers, and what people do there (e.g. for a chat: read it, join the room, send a message). Then **ask the user, as its own question and before the sign-in and writes questions**: what you understood the focus to cover (e.g. "the calendar = /calendar and the event detail popup"), and which of those actions they want people to really try. Wait for the answer. Asking about sign-in or writes does not count as this question. If you cannot find it on the map, or it could mean several things, say so in the same question — do not guess from the word alone.
 
 Then check what the focus needs before anyone is cast:
 - If it is only reachable when signed in, demo account sign-in is required, not optional — say so, and if signed-in visits turn out to be impossible, tell the user the focus cannot really be reached and ask whether to go on.
 - If it is mostly writing to the site (comments, posting, saving, sign-up) and writes are not sent, tell the user when you ask about writes: with "not sent", visitors reach it but it is never really tried.
+- If it needs something done on the account first (joining a room, following, saving, an order), you do not know whether the demo accounts have done it. Ask the user in the sign-in question, or cast people who do it for the first time on this visit.
 
 **Step 3 — cast for the focus instead of spreading over the whole map.** Every person comes with a reason that makes the focus a natural part of their visit, and their `feature` is the focused feature they are about (if the focus names several, spread people over them). Everything else in the casting rules stays: varied people, their own words, a main reason that can lead on — never "test the calendar".
 
@@ -14,6 +15,8 @@ Split how they arrive, about half and half:
 - **Straight in:** they land on a page of the focus itself (a bookmark, a shared link, a search result that opened it). This shows how the feature works for someone already there.
 - **Find it:** they land on the front page or a related page — wherever their arrival really takes them — and the focus is something they would need to get to. This shows whether people can find it.
 
+If the focus is only reachable when signed in, everyone is a member — this replaces "keep some as newcomers". Add newcomers only if the user asks for them (to see the sign-in wall). And cast the members to fit what the account has really done: if the user did not say a demo account already joined the room or saved the item, do not write people who are "already in the room" or "checking their saved list" — write people who join, save or start there on this visit.
+
 Do not add people who have nothing to do with the focus. In later rounds, cast new people for the same focus.
 
 **Step 4 — unchanged.** The visitors are never told about the focus.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@usercase/mcp",
-  "version": "0.2.2-next.0",
+  "version": "0.2.2-next.1",
   "description": "Virtual users that browse your website and tell you what they thought — an MCP server for Claude Code",
   "license": "UNLICENSED",
   "homepage": "https://usercase.io",