This invite link looks incomplete
We couldn't find an invite code in this link. Ask your host to resend it — the full link ends with /join#c=….
Join a task
You've been invited to pair on a sys-buddy task. Pick a name, then pair to get your setup — the invite is single-use, so we'll only redeem it when you're ready.
Run it in the folder you'll open your agent in, then restart your session.
claude mcp list — run it from that same folder; it should list
sys-buddy. Nothing there means the add landed in a different
directory, not that it failed.
0 — open your project in Claude first. With no project open there is no project root to write to, and the entry lands in a home-directory config.
1 — paste this into the chat
2 — start a NEW conversation. Not a restart; a new conversation is enough.
3 — verify
rules, readiness_check, send_message, …
0 — open your project in Cursor first. On the Home tab, with no project open, the file lands in Cursor's global config rather than your project.
1 — paste this into Cursor's chat
2 — reload. Cursor's own advice: “Reload the Cursor window or restart MCP servers in Settings → MCP.”
3 — verify
<your-project>/.cursor/mcp.json. If your agent says it wrote
~/.cursor/mcp.json, it had no project open and wrote Cursor's
global config instead — that works, but it registers this task for
every project you open.Run it in the folder you'll open Gemini in — it writes to that project.
gemini mcp list; you want a green ✓ and
“Connected”.
gemini mcp
list prints (sse) next to the entry even though this is HTTP.
Ignore the label — it's cosmetic, and the connection is fine.sys-buddy is a standard MCP server over HTTP. Any MCP client can connect with two things.
Most clients take a config file shaped like this:
· top-level key
mcpServers · servers · context_servers· URL field
url · serverUrl · httpUrl· VS Code requires
"type": "http"; most infer itrules, readiness_check, send_message,
report_status…If it lists them you are connected — nothing else to do. If not, the config is in the wrong place, or the field names don't match your client.
Got it working? Tell us which client and we'll add it to the list.
Set up Playwright recommended for UI testing
Lets your agent drive a real browser, so it can prove the UI works against the API instead of asserting it. Optional — not required to pair, and you can add it later.
Prerequisite: Node.js installed (it provides npx).
- Put this at your project root as
.mcp.json. Read from the folder you work in, so it cannot land somewhere your session doesn't look — and you can commit it, so your whole team gets the identical setup:
.mcp.json
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp@0.0.77"]
}
}
}
No terminal needed — Claude can write the file itself. The first time it loads you'll be asked to approve the server; that prompt is normal, not a failure.
Prefer the CLI? claude mcp add --scope user playwright npx '@playwright/mcp@0.0.77' — but see the warning below about where --scope user actually writes.
- Restart your Claude session. MCP servers only load at start-up — without a restart the tools simply won't be there, which is the usual reason this looks broken.
- Verify from inside the session, not a separate terminal: ask your agent “what Playwright tools do you have?”, or type
! claude mcp listin the session so it runs in the session's own environment.
--scope user writes to $CLAUDE_CONFIG_DIR/.claude.json, or
~/.claude.json when that variable is unset. If it is set for your Claude
sessions but not for the terminal you typed the command in, those are two different
files and the add landed in the one nothing reads.
Compare echo $CLAUDE_CONFIG_DIR in both. If they differ, re-run the add
from inside the session — or use the .mcp.json above, which sidesteps it
entirely.
This is also why
claude mcp list in a separate terminal proves nothing:
it reads the same file the add wrote, so it agrees with itself whether or not your
session can see the server.
What to expect. The first run downloads the package, so it's slow once and needs a network connection. It then opens its own browser window on a throwaway profile — not your everyday browser, so none of your saved sessions, extensions, or history are visible to it. That isolation is deliberate: runs stay reproducible, and the agent never operates inside a signed-in browser.
The version is pinned on purpose. Tool and flag names shift between releases, and you want your setup to behave the same as your buddy's when you compare results.
If you also run a browser extension-based tool, that's a different thing driving your real browser. Having both is the usual reason someone wonders why a signed-in session "disappeared" between runs — pick one.
What we’re askingdetails
This prompt teaches your agent how to use sys-buddy. It does not tell it what to build — you do that, in your own words.
- Grants
- Sends
- Never
- Seen by
Don’t take our word for it — paste the prompt into a different Claude (not the one you’ll use for this task) and ask what it does.