← ClaudeAtlas

polite-mcp-conventionslisted

Use when working in one of the *-polite-mcp personal automation repos (olx-polite-mcp, emag-polite-mcp, altex-polite-mcp, freshful-polite-mcp, temu-polite-mcp) or product-research-pipeline — implementing a new tool, running a live spike/CDP exploration against a real logged-in site, deciding whether an action needs confirmation before running it, or asking the user for several small per-item decisions (quantities, yes/no per item) during a reorder/shopping flow. Covers: confirming before the first live mutating action against a real personal account, batching interactive AskUserQuestion decisions instead of asking for a typed list, and writing spike/research findings into PLAN.md before or alongside implementing.
TheodoreAD/agent-skills · ★ 0 · AI & Automation · score 72
Install: claude install-skill TheodoreAD/agent-skills
# Polite-MCP family: agent collaboration conventions Behavioral conventions for this author's own shopping/classifieds automation family — `olx-polite-mcp` and its siblings, which exist on this author's machine and nowhere else — distinct from `mcp-server-shipping` (dev-loop/distribution mechanics for the same repos) and from whatever always-loaded instructions file the machine carries, which holds the truly universal conventions. These are specific to the domain: automation against a user's own live, logged-in personal accounts. Installed elsewhere, the conventions still read; the repo names are the author's. ## Confirm before the first live mutating action Before performing the _first_ real mutating browser action against the user's live, personal, logged-in account in a session (e.g. a real add-to-cart click, not a dry read), stop and ask via `AskUserQuestion` rather than just doing it — even when the action is narrowly scoped, low-cost, and reversible. Frame it as a one-off scoped test (what will run, and that it'll be undone/reverted afterward if applicable), not a generic permission request. Once approved and the shape/behavior is confirmed, subsequent same-kind actions in the same session don't need re-confirming. **Why:** this family already treats checkout/personal-account actions as a materially higher-stakes category than plain reads — every repo's own boundary docs say so (e.g. "checkout is never automated," no-CAPTCHA-solving). A first live mutation test agai