zuar-portal-mcp: Command for Claude Code

Set this project up to work against a Zuar Portal. One-time, per folder.

1. Check current state. Call check_connection — it reports the portal, the binding state, and whether the credentials actually work. If it comes back connected, report which portal it points at and its binding (host + identity only — never print secrets), then confirm with the user whether to keep it or reconfigure. If binding is already bound and a .zuar-portal/brief.md exists, there is nothing to do — say so and stop. If it reports connected:false, its fix says whether this is an unconfigured folder (→ set it up below) or working credentials gone bad (→ reconfigure).

2. If not configured (or the user wants to reconfigure): launch the portal-onboarding agent (via the Task tool) to:

   • collect the portal credentials and write them with configure_project to ./.zuar-portal/config.json,
   • then run the alignment Q&A — learn the user, their business, their portal, and their data — and write ./.zuar-portal/brief.md (the brief every other agent reads).

   configure_project's guided elicitation flow (the interactive flag: true = require prompts, false = headless, omit = auto) collects, in order:

   • the portal credentials (URL, API key, user ID) and a name for the portal ("Acme Production") — the name is what later wrong-portal warnings say, so it's worth setting;
   • GitHub version control (optional) — every content change mirrored to a repo you can roll back;
   • Claude for Chrome — recorded as browser.claudeInChrome. With it, the build pipeline can see a rendered block (screenshot, console) for visual debugging and a final visual sign-off, not just review code. Mention the payoff, and the one caveat: visual checks need the user signed into the portal in Chrome (the MCP's API key doesn't authenticate the browser session). It degrades gracefully when the extension isn't present;
   • the design intake — brand accent, which theme modes to support, layout density. These are rendered into ./.zuar-portal/design.md, which every block built in this folder then inherits.

   It writes four things: the gitignored config + credentials, ./.zuar-portal/design.md, and a managed block in the repo-root CLAUDE.md naming the bound portal. It also pins the folder to the portal's live identity.

3. Confirm the binding. After onboarding returns, verify the connection is live (identity/version) and report success: which portal this folder is now bound to, that it is bound (pinned) rather than merely declared, and that the brief was written. Do not echo passwords, tokens, or any secret value at any point.

Why the binding matters. One install serves many portals, so this folder is pinned to the one it was onboarded against and re-checks the portal's identity before every write. If a write is ever refused as a wrong-portal mismatch, that is the guardrail working — never resolve it by pointing the credentials somewhere else. Re-run configure_project with overwrite=true to rebind deliberately.

No arguments. After this, /portal-build, /portal-theme, /portal-bulk, and /portal-audit are ready to use.