Claude Code is the most used assistant here, so it has the deepest links into Fulltrace. Every session starts with the rules for how to work and an index of what it has learned about the project, and two hooks keep both in sync automatically. Its setup has three parts: how to behave, what to know, and which commands to run. Permissions allow almost everything and stop hard on a short list. Routine chores run through low-cost tools, which keeps the bill down.
Claude Code's setup has three parts: how to behave, what to know, and what to do. Keeping them apart makes each one easy to look after.
A written contract for how the assistant communicates: its style, language rules (no em dashes, no AI openers), what the person already knows, and formatting. It loads in every session, from ~/.claude/CLAUDE.md.
Who the person is, what they are working on, and what is already settled. The shared memory (global.md, conventions.md, projects/*.md) sits on disk for every project and is read when a command or a note points to it. Each project also has its own memory under ~/.claude/projects/[slug]/memory/, which the assistant writes as it learns. Its index loads at the start of every session.
Shortcuts for repeated jobs, available in any project as /jn-* commands: building and deploying extensions, updating changelogs and docs, and syncing memory and config. Routine work runs the same way every time. In Claude Code each command is marked so the assistant cannot start it by its own choice.
Two things load at the start of every session. The rest sits on disk and is read when it is needed.
Two things load at the start: the contract at ~/.claude/CLAUDE.md and the current project's memory index. The shared memory under ~/.claude/memory/ and the shared commands under ~/.claude/skills/ sit on disk for every project. A memory file is read when a command or a note points to it, and a command loads when it is typed.
A project's own .claude/project.md says which project this is, and the commands read it. The project's memory lives in a folder named after its path, so D:\Development\AI becomes d--Development-AI. The same project on another drive would get a different name, so aliases point both at one folder.
The repo holds the master copy. sync.ps1 copies it into place and clears out stale files, and two hooks in settings.json run the sync automatically.
Copies CLAUDE.md, the shared memory, the shared commands and settings.json into ~/.claude/, and clears stale files from earlier runs. It is safe to run again and again, and it is the only command that writes to the live setup.
The one exception to one-way sync, because the assistant writes memory as it learns. Each file is compared with the version from the last sync. A side that has not changed is left alone, a change on one side is copied across, and a conflict keeps the live copy and archives the other. File dates are never trusted. Before a note is copied into the repo it is checked against six common key patterns, and a match is refused.
A Stop hook runs push-runtime each time Claude finishes a response, so changes made during a session are captured without a manual sync.
A second hook fires the moment Claude writes or edits a file the sync looks after under ~/.claude/, such as a memory note or a command, and runs the sync straight away.
| Command | What it does |
|---|---|
| push-runtime | Deploys the master config to ~/.claude/, filling in every {{TOKEN}} placeholder (machine paths, the lightweight model id, the server token) as it goes, so the same repo deploys to any machine or drive. Clears stale files first. Config only flows one way; project memory is the one lane that flows both ways. |
| pull-extracted | Copies files from ~/.claude/memory/_extracted/ into memory/_extracted/ for review. It does not commit them. |
| clean-runtime | Removes every managed file from ~/.claude/, then runs push-runtime again. Used to clear out orphans after a restructure. |
| check-sync | Reports where the repo copy and ~/.claude/ have drifted apart. It changes nothing. The test battery runs it for all three assistants. |
Mechanical steps should not be billed like thinking. A command does the thinking once, hands the mechanical steps to tools, and logs them against a lightweight model, so the cost of a deploy reflects its one decision.
/jn-read-context reads a portfolio:// file straight from the server in the main session. The server already holds the file, so nothing new has to start.
/jn-ext-deploy calls the server's own compile, package and install tools instead of running shell commands. The command itself is logged as Sonnet, and each mechanical step is logged as the lightweight model, so the analytics charge compile and package at Haiku rates.
By default a helper runs as a real sub-agent: a separate context with its own tool limits, and only the result comes back. That suits any job that is better off without the main session's history.
A helper that needs to ask questions cannot run as a sub-agent, because a sub-agent has no way to stop mid-run and wait for an answer. Studio reads an agent marked interactive: true and runs it inside the main conversation instead. The portfolio interview first ran that way, before it moved into Studio's setup screen.
The permissions started strict and were opened up. When every routine command asks first, people learn to click approve without reading. So settings.json accepts edits by default with a broad allow list, and keeps its prompts for the few things that must stop.
Routine tools run without asking, ending in broad patterns such as Bash(*), PowerShell(*), Edit(*) and Write(*). The narrower entries above them record the common paths.
Two things stop and ask. Granting or revoking Fulltrace's authority to apply a change (approval-cli grant and revoke), because that is the gate on every write to project code. And force-pushing, because it rewrites history that other machines depend on.
Refused outright, with no prompt: wiping a drive or the home folder, reading secret files, and since 12 August the common download commands (curl, wget, Invoke-WebRequest, Invoke-RestMethod and their short forms).
The repo holds the master copies, under clients/claude/ and clients/shared/. sync.ps1 copies each file below to its live place under ~/.claude/.
| Repo path | Deployed to | Purpose |
|---|---|---|
| clients/claude/CLAUDE.md | ~/.claude/CLAUDE.md | Behavioural contract |
| clients/shared/memory/global.md | ~/.claude/memory/global.md | Identity and stack |
| clients/shared/memory/conventions.md | ~/.claude/memory/conventions.md | Technical conventions (Salesforce, git, code standards) |
| clients/shared/memory/projects/*.md | ~/.claude/memory/projects/*.md | Per-project context files |
| clients/shared/skills/<name>/SKILL.md | ~/.claude/skills/<name>/SKILL.md | 17 shared slash commands |
| clients/claude/settings.json | ~/.claude/settings.json | Hooks and permission allowlists |
All 17 come from clients/shared/skills/ and are copied to all three assistants. In Claude Code they run as slash commands, and a hook logs each run to the server. Each one is marked so the assistant cannot start it by its own choice. A run begins with a typed command, and a chaining command such as /jn-website-commit then works through the steps of the others.