Hi, I'm Christian.

Engineer at Nomain.

We turn complex mainframe systems into clear, accessible knowledge — so engineers, analysts and business stakeholders can all understand legacy code, onboard faster, and plan modernization with confidence.

What this talk is

How our team actually works with Claude — day to day.

Not a framework. Not best practices. Just the workflow we converged on since we switched to Claude in December — what we share, where we put it, and how a ticket flows from Linear all the way to production telemetry.

The problem we kept hitting

Everyone's running agents. Same codebase. Different decisions.

We switched to Claude in December. Every engineer is now running their own Claude — often several in parallel, across worktrees and background tasks. Without something shared, those agents make different decisions on the same problem: different naming, different test patterns, different log levels, different security assumptions.

So the real question stopped being how do I prompt better. It became what do all our agents need to know, and where does it live? Everything below is what we've built up since.

One thing that helps a lot

We work in a monorepo.

Backend services, web apps, the VS Code extension, infrastructure, docs, eval datasets — all in one repo. So whichever feature an engineer is touching, their Claude has the full picture available in one place.

It also gives us a single, obvious home for the shared substrate: CLAUDE.md at the root, skills and agents under .claude/ — read by every session, from every corner of the codebase.

The principle behind it all

We adapt Claude to our ways of working — not the other way around.

Our conventions exist because they're right for the problem — conv commits, xUnit v3, our audit-logging boundary, our Linear taxonomy, our LADR format. Every skill, CLAUDE.md entry and hook exists to teach the model how we work, so it contributes without dragging the codebase toward its training defaults.

The flip side would be picking tools because Claude prefers them, or quietly relaxing our standards because the model keeps drifting from them. We try hard not to.

The substrate · what we share

Our rule: if a teammate would benefit, it goes in the repo.

Our dev workflow

From ticket creation to production.

Each step is a skill — a markdown file with a procedure, invoked by name. The procedure itself is what we review and iterate on, not the prompts people happen to type.

/manage-issue

One entry skill. Companion skills for what you're touching.

One command to ship. CI does the first review.

The skill pattern, applied to ops.

Each one is just a procedure one of us did manually, written down so nobody has to remember it again.

Skills, CLAUDE.md, agents — every convention you encode compounds across the team.

Things we've learned along the way

• Keep skills simple and code-invariant The less a skill hard-codes — specific files, module names, exact paths — the longer it stays useful. We try to encode the procedure, not the implementation details that move when we refactor.
• Mix in hooks where determinism matters A skill is still a prompt — the model has to read and follow it. For steps that must happen the same way every time (linting, version bumps, validation), a Claude Code hook is more reliable than asking the model nicely. We do this in a few skills; we should do it in more.
• Invest in a skill if it's worth it Some skills are quick wins. Others — like our MR reviewer — take several iterations to get right: what to report, at what confidence, how the findings show up in GitLab. We've learned to pick the few skills that genuinely deserve that effort, and not over-invest in the rest.