Working with Claude Code

This page covers the third stage of the pipeline: implementation itself, once a change (with or without a handoff package behind it) reaches Claude Code.

The plugin set

Five plugins are installed and enabled at user level, so they apply in every repository and every session. They come from two marketplaces: Anthropic's claude-plugins-official, and thedotmack for claude-mem.

Plugin	Version	What it contributes
claude-mem	13.12.1	Cross-session memory: observations captured as work proceeds, searchable later. Also supplies the planning and execution skills below
superpowers	6.4.1	The brainstorm → plan → execute structure for multi-step work, and a TDD skills library
github	fa59bc903774	The official GitHub MCP server: issues, pull requests, reviews, repository search
semgrep	2.3.0	Scans generated code for security findings — SAST, secrets, and supply-chain
typescript-lsp	1.0.0	TypeScript/JavaScript language server: go-to-definition, find references, error checking

Versions in that table are a snapshot, not a contract

The table shows the re-read of 27 September 2026, recorded last below. It was first read from ~/.claude/plugins/installed_plugins.json on 12 September 2026, and already moved twice while this page was being written. claude-mem's marketplace was configured with autoUpdate: true when this page was first written, so its version advanced on its own — it went 13.12.1 → 13.24.0 without anyone asking. It no longer is: see the 27 September re-read. The github plugin is worse: it carries a commit ref rather than a version, and that ref moved twice in a single day (ed404106fcd8 → 1dd995193ba2 → 85cce0381e78). Treat the set of plugins as the durable claim and the version column as the dated observation it is.

Re-read on 11 September 2026, and three of six had moved again: claude-mem 13.24.0 → 13.24.20, semgrep 2.1.5 → 2.2.0, and github 85cce0381e78 → f2cc019c16eb. The set and every scope were unchanged.

Re-read again on 12 September 2026: claude-mem 13.24.20 → 13.24.23 and github f2cc019c16eb → 3deb821cb71c. Six plugins, all enabled, every scope unchanged — four re-reads, and the set had not moved once.

Re-read on 19 September 2026, and the set moved for the first time. understand-anything is gone, and so is its marketplace from known_marketplaces.json, leaving five plugins, all enabled, all at user scope. semgrep moved 2.2.0 → 2.3.0 and github 3deb821cb71c → c447c3207a42. claude-mem now reads 13.12.1 — lower than the 13.24.23 recorded a week earlier. That is what the file says; why is not established here. It is the clearest case yet for treating the version column as an observation.

Re-read on 27 September 2026. Five plugins, all enabled, all at user scope, from the same two marketplaces. superpowers moved 6.3.0 → 6.4.1 and github c447c3207a42 → fa59bc903774; claude-mem still reads 13.12.1, and the file now gives the likely reason it stopped moving: the thedotmack marketplace reads autoUpdate: false. That entry, and claude-mem's own installedAt and lastUpdated, are all dated 23 July 2026, so whatever produced the 13.24.x readings in between has left no trace in either file.

Enabled is not the same as reachable

Both MCP-backed plugins can be enabled and still fail to connect in a given session — github on a malformed authorization header, semgrep on a cached connection failure. The session reports this at startup; treat a plugin's presence in this table as configured, not as available right now. The gh CLI is the fallback for anything the github plugin would have done.

This is not a one-off: the github plugin failed to connect again on 4 September 2026, with the same malformed-authorization-header error, and the v2026.09.0 documentation sync used gh api throughout instead. It failed the same way on 11 September 2026, and that day's sync did the same. A capability you can only reach half the time is one you should have a fallback for. It failed the same way again on 27 September 2026.

Two notes on that table, because both are easy to get wrong:

• superpowers used to be project-scoped. It was installed only for ronl-business-api and was promoted to user level on 2026-08-28, on the same reasoning that moved the working rules to ~/.claude/CLAUDE.md — it describes how you work, not what the repository is. See Skills & Boundaries.
• typescript-lsp needs typescript-language-server on the PATH, and it resolves typescript from the workspace — not globally. Install the server with npm install -g typescript-language-server. Do not add typescript to that command: npm now resolves it to 7.x, the native rewrite, which ships tsc only — no tsserver.js, no typescript.js, and no tsserver bin. The language server cannot use it, and the failure surfaces as Could not find a valid TypeScript installation. The working arrangement is the server installed globally, plus a typescript package carrying lib/tsserver.js in the repository you have open — the workspace root is the session's working directory, not wherever the file lives. Measured on 28 August 2026: ronl-business-api and linked-data-explorer both had 5.9.3, ttl-editor 4.9.5 via react-scripts. Re-read on 27 September 2026 from the lockfiles: the first two still resolve 5.9.3, and ttl-editor — now built with Vite, with no react-scripts — resolves 6.0.3, transitively, with no typescript in its own package.json. The Norm Editor has no typescript dependency, and this documentation repository is Python/MkDocs, so the plugin does nothing in either. On the maintainer's workstation, as of 27 September 2026, typescript-language-server is not on the PATH at all — so the plugin is enabled and does nothing anywhere until the server is installed as described above.

semgrep deserves a specific mention: it is the assistant-side counterpart to the supply-chain gate in CI. One scans what is being written, the other gates what the pipeline executes — and neither substitutes for the other.

It also has a working-tree side effect worth knowing about, because it is the only plugin here that writes into the repository: it drops a machine-local .semgrep/ cache in the project root, which shows up as untracked noise in every git status until it is ignored. All four repositories this documentation covers now ignore it — the Linked Data Explorer and the RONL Business API from 3 September 2026, the CPSV Editor from 4 September (v2026.09.0), and this documentation repository from 24 September. A repository adopting the plugin will want to do the same. Machine-local plugin state belongs in .gitignore, not in a commit.

Session memory

claude-mem runs by default and captures session memory as work proceeds. Its viewer runs at http://localhost:37780. The port is configurable via CLAUDE_MEM_WORKER_PORT in ~/.claude-mem/settings.json — if you have changed it locally, use your own value instead.

Inline versus superpowers

Small, well-understood changes proceed inline. Multi-step work goes through the superpowers plugin instead, which structures it as brainstorming a design, writing a plan, and executing it with review between tasks.

The choice is made by the size and uncertainty of the work, not by preference. A change whose steps and outcome are already clear does not need a plan written for it; a change where either is still unclear benefits from superpowers slowing it down.

Subagent-driven development

Once a plan exists, it is executed one task at a time, and each task goes to a fresh subagent rather than continuing in the session that wrote the plan. The subagent receives a brief containing only what its own task needs — the files, the exact values, the constraints that bind it — and none of the conversation history behind it.

After each task, a separate reviewer reads the resulting diff and checks two things: that the task did what the plan specified, and that the result is good work on its own terms. The implementer's own self-review does not replace this. When the reviewer finds something, a fix round follows and the review is repeated, scoped to the fix. When every task is done, one broader review reads the whole branch at once, which is the only stage that can catch the things no single task could see — a page contradicting another page, a reader's route through the result, a claim that drifted.

Progress is recorded in a ledger file, not only in the conversation, because conversation memory does not survive being compacted. The ledger names every commit and every decision taken along the way, so work can resume accurately after a break.

Two properties make this worth the overhead:

• Context isolation. An implementer that never sees the preceding twenty tasks cannot be distracted or misled by them, and the reviewing agent has no stake in the implementation it is judging.
• The brief is not the authority. Where a brief and the source disagree, the source wins and the implementer is expected to say so. During the work that produced this subsection, five separate briefs turned out to be wrong and were correctly overridden from what was actually on disk. That is the intended behaviour, not insubordination.

Red/green test-driven development

Implementation, inline or via superpowers, follows red/green TDD. The cycle:

1. Write the failing test first.
2. Run it and watch it fail, for the reason you expect.
3. Write the minimum code that makes it pass.
4. Run it again.
5. Refactor with the test as the safety net.

Step 2 is the one most often skipped, and the only one that actually proves anything. A test that has never been seen to fail proves nothing: it may be asserting something already true, or nothing at all. If a test passes before the implementation exists, it is testing something other than what it claims — and the fix is to correct the test, not to celebrate an early pass.

The superpowers plugin structures work this way by default, so a contributor using it follows the cycle whether or not they think of it as TDD. Where it does not apply, say so plainly rather than forcing it: a documentation change has no failing test to write, and pretending otherwise is cargo cult.

What this means for a contributor

Within all of this, the assistant works inside recorded boundaries — rules about what it will do unprompted and what it always asks first. Skills & Boundaries, the next page in this subsection, covers those boundaries in detail.