Purpose: get a new engineer fully set up with Claude the way Xzopia uses it — the chat/connector layer, a local Claude Code environment on your own machine, and the branch → PR → review git workflow. This page assumes no prior Claude experience at all. Work top to bottom.
Confidential — Xzopia Limited (NI620366)
House rules still apply (see the Engineer Hub): secrets only in Vaultwarden, repo is source of truth, don't hand-edit wiki pages. This page adds the Claude-specific setup on top of those.
There are four different things all called "Claude." They are not interchangeable — get these straight first or the rest is confusing.
| Thing | What it is | Where | You use it for |
|---|---|---|---|
| claude.ai (chat) | The normal chat website/app. One conversation at a time, no memory of other chats by default. | claude.ai in a browser or the desktop/mobile app | Quick questions, drafting, running MCP connectors (see Part B). |
| A Claude Project | A saved workspace inside claude.ai that bundles custom instructions + files + MCP connectors so every chat in it starts with the same context and tools. | claude.ai → Projects | Your day-to-day Xzopia work chats — this is where your connectors live. |
| Claude Code | Claude running as a command-line tool in a terminal on your own machine. It can read/edit files, run commands, and commit to git. | Your WSL terminal (Part C) | Working on the xzopia-deploy repo — scripts, docs, infra automation. |
| Claude Cowork | Claude that can run scheduled/background tasks and drive a desktop. Simon uses it for the quarterly DR-drill reminder. | Claude desktop app | You won't need this during onboarding — just know it's a separate thing. |
The one-line mental model: chat is a conversation, a Project is a chat with your tools pre-loaded, Claude Code is Claude in your terminal working on the repo, Cowork is Claude on a timer. Simon works mostly in chat+Project (for connectors) and Claude Code (for the repo). You'll do the same.
Account: you get a personal Claude Pro account (paid by Xzopia, individually — not a Team/Enterprise seat). Sign in with stephen@xzopia.com. Pro is required for Projects + connectors + Claude Code.
What an MCP connector is: a controlled bridge that lets your Claude talk to one of our tools (TacticalRMM, ITFlow, SentinelOne, …). See the MCP training page for the concept. Here we just get them connected.
A connector working needs two separate things, and both must be in place:
In claude.ai → Settings → Connectors → Add custom connector, add each of the following. Simon will confirm any OAuth/token step per connector (secrets come from Vaultwarden, never pasted into chat).
Server-4-hosted (base URL https://mcp.xzopiasecure.com/<service>/mcp):
| Connector | URL |
|---|---|
| NinjaOne | https://mcp.xzopiasecure.com/ninjaone/mcp |
| Giacom | https://mcp.xzopiasecure.com/giacom/mcp |
| Wiki.js | https://mcp.xzopiasecure.com/wikijs/mcp |
| SentinelOne (S1-EDR) | https://mcp.xzopiasecure.com/sentinelone/mcp |
| TacticalRMM | https://mcp.xzopiasecure.com/tacticalrmm/mcp |
| ITFlow | https://mcp.xzopiasecure.com/itflow/mcp |
| BookStack | https://mcp.xzopiasecure.com/bookstack/mcp |
| Twenty CRM | https://mcp.xzopiasecure.com/twentycrm/mcp |
| M365 Admin | https://mcp.xzopiasecure.com/m365admin/mcp |
Externally-hosted (native connector, not on Server 4):
| Connector | URL |
|---|---|
| CIPP (M365 partner mgmt) | https://cippbun2i.azurewebsites.net/api/ExecMcp |
You get every fleet connector EXCEPT Xero (Xero = finance/accounting — deliberately out of scope for engineering). CIPP and M365 Admin ARE included and are intentional — they're the highest-privilege connectors on the list, and you're trusted with them given your role and existing CIPP-SAM/GDAP involvement. The authoritative current connector list lives in
config/servers.json(repo) and the MCP training page; if a connector is added/renamed, that's the source of truth, not this table.
Once added, put the connectors in a Claude Project (claude.ai → Projects → New) so every work chat starts with them loaded. Add the boot instruction Simon gives you (read session-protocol id=80 + your handoff page — see Part E).
This sets up Claude Code in a Linux (WSL) environment on your Windows machine. It's a separate physical machine from Simon's, so there are no naming/path clashes — use the same conventions below.
In an admin PowerShell:
wsl --install -d Ubuntu-24.04
Reboot if prompted, then launch Ubuntu from the Start menu and set a UNIX username/password when asked. Everything below runs inside that Ubuntu shell.
sudo apt update && sudo apt -y upgrade
sudo apt -y install git curl build-essential
# Node.js 20 (for Claude Code + the repo tooling)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - && sudo apt -y install nodejs
Get your ~/.ssh/xzopia_server1 key from Simon (via Vaultwarden — never pasted in chat), place it at ~/.ssh/, and chmod 600 ~/.ssh/xzopia_server1. Set up your GitHub auth (gh auth login, or an SSH deploy key Simon adds to the repo) so you can clone + push branches.
git clone git@github.com:Silentrunnerx/xzopia-deploy.git ~/xzopia-deploy
cd ~/xzopia-deploy
git config core.hooksPath .githooks # activate the repo's git hooks
npm install # repo tooling
npm install -g @anthropic-ai/claude-code
⚠️ Known gotcha — the
ignore-scriptspostinstall failure. If Claude Code reports "claude native binary not installed" (orENOEXECafter an auto-update), it's the globalignore-scripts=truenpm hardening blocking the native-binary postinstall. This is already documented — do not re-derive it. Follow the fix in the DR runbook, Scenario A step 5 (docs/runbooks/disaster-recovery.md): repair without touching the guard vianode "$(npm root -g)/@anthropic-ai/claude-code/install.cjs", and NEVER runnpm config set ignore-scripts falseglobally. It recurs after CC auto-updates, so keep that one-liner handy.
Launch it from the repo: cd ~/xzopia-deploy && claude. Sign in with your Pro account.
Install the same skill set Simon runs, so your Claude Code behaves the same way. These are the standing methodology + operational skills:
/tdd · /karpathy-guidelines · /spec-first · /writing-plans · /executing-plans · /dispatching-parallel-agents · /verification-before-completion · /security-review · /pre-flight-check · /audit-server · /backup-server · /security-pentest · /deploy-pipeline
The operational skills (/pre-flight-check, /audit-server, /backup-server, /security-pentest, /deploy-pipeline) live in the repo under .claude/skills/ — they come with the clone. The methodology skills are installed per their upstream sources; ask Simon for the current install list if any aren't already present under .claude/.
.claude/settings.jsonCopy Simon's auto-approve / permissions configuration so common read-only commands don't prompt every time. The repo's .claude/settings.json is the shared baseline — use it as-is; put any machine-local tweaks in .claude/settings.local.json (git-ignored), not in the shared file.
Keep experimentation out of the clone. Make a sibling scratch dir for throwaway work, notes, and test scripts:
mkdir -p ~/xzopia-scratch
Use ~/xzopia-scratch/ for anything not destined for the repo. This is standard practice — it keeps git status clean and stops experimental files getting committed by accident. Nothing production-facing lives there.
You do NOT push directly to main. Your Claude Code works on a feature branch, opens a GitHub pull request, and Simon reviews and merges.
git checkout -b feat/<short-description>
# … make changes, commit …
git push -u origin feat/<short-description>
gh pr create --fill # opens a PR for Simon to review
Why (state this plainly — it is not a trust judgment): you're already trusted with near-full access across the fleet. The branch requirement is precautionary during onboarding, for two concrete reasons: (1) your Claude Code instance is brand new and hasn't built up the calibration Simon's has over weeks of use; and (2) it mirrors the exact stage → review → promote pattern we already use for the wiki, applied to git. Git handles two committers far more gracefully than the wiki did (it flags conflicts instead of silently overwriting), so this is lower-risk than the wiki case — the branch rule is caution, not because git is dangerous with two people.
This is explicitly revisitable. Once you've got a track record (Simon's call on timing — roughly a month, or a dozen-ish clean PRs), moving to direct push is reasonable to reconsider.
See also CLAUDE.md ("Documentation Workflow — agent roles") which now describes this two-Claude-Code model.
Your coordination page and the two-Claude collaboration rules live in your handoff page — see Stephen — Session Handoff. Read that page's header in full before your first working session. In short: you read id=15 in full (no restrictions), you stage anything worth surfacing in your own page's "FOR SIMON TO PROMOTE" section (async — Simon folds it into id=15), and for genuinely joint work you nominate one writer out loud to avoid collisions.
stephen@xzopia.com)xzopia-deploy cloned; core.hooksPath set; npm install doneignore-scripts repair one-liner).claude/settings.json in place; ~/xzopia-scratch/ createdgh pr create → Simon reviews/merges (no direct push to main)Xzopia Limited (NI620366) | promote via Claude Code; do not hand-edit in the wiki.