Claude Code for Engineering Teams — Two-Day Customised Training Training Course

Day 1 — From Personal Proficiency to Shared Context

The team has each built their own way of working with Claude Code. Day 1 turns individual fluency into team-shareable practice.

Morning: Where we actually are (45 min)

• Quick framing, not a lecture: where is the team today, and where do strong individual adopters diverge from lighter users.

• Reference to the AI maturity model conceptually — the core point being that daily use does not equal depth of use, and that gap is what the two days target.

• Structured group discussion: what are the strong adopters doing that the rest of the team doesn't see yet?

Context Engineering, Properly (half day)

This directly addresses the 'good individually, not yet shared' gap named in scoping.

• From prompting to context engineering: why the same prompt produces different results depending on what the model can see.

• CLAUDE.md as living team documentation — conventions for what goes in it, how it is reviewed and versioned alongside the codebase.

• Project rules, architecture constraints, and team conventions encoded as context rather than re-explained session by session.

• Reusable commands and in-context examples — teaching Claude Code patterns once rather than re-teaching them each conversation.

• Best-of-N as a deliberate technique: when generating multiple candidate solutions is worth the token cost, and how to evaluate them efficiently.

• Lab: pairs or trios build a CLAUDE.md and command set as a team artefact against a real or representative slice of the TS/Node codebase.

Skills, Marketplace, and the Contribution Gap (half day)

Directly addresses the pattern named in scoping: people pull a skill down, modify it privately, and never push it back because there is no process.

• What a shared skills approach buys a team versus ad hoc personal prompts.

• Structured discussion: why pull-and-fork-without-contributing-back happens — friction, ownership ambiguity, no agreed review bar. The team will know their specific blockers better than a trainer will.

• Designing a lightweight contribution loop: where a modified skill goes, who reviews it, what 'good enough to merge' looks like. Process design, not a tooling demo — the tooling exists, the process does not.

• Automating documentation and repeatable workflows via Claude Code commands.

• Lab: take a skill someone has privately modified (or a prepared example) and run it through the contribution loop — write the PR, write the review comment, agree the merge bar.

Day 1 close: Token Optimisation (30–45 min)

Requested by name in scoping. Practical, not theoretical.

• What actually burns tokens: context bloat, repeated re-explaining, over-large file reads.

• Low-cost habits: keeping CLAUDE.md lean, scoping commands tightly, knowing when a fresh session is cheaper than a long one.

Day 2 — Team-Based, Async, and Trusted

Individual workflows become team workflows. Trust and guardrails are designed deliberately rather than discovered through incidents.

Async and Parallel Team Workflows (half day)

The most directly requested content in scoping.

• Git worktrees and branches as the mechanism for running parallel Claude Code sessions without collision.

• Coordinating subagents across separate features — who owns what, how work is handed back for integration.

• What 'async' actually requires before it is a safe pattern rather than a risky one: context, guardrails, clearly scoped tasks.

• Designing a team norm: when parallel/async is appropriate versus when a human needs to stay at the wheel throughout.

• Lab: two-person simulation — one person kicks off an async task on a branch or worktree while the other continues separate work, then both reconvene to integrate. Structured to surface coordination problems, not just demonstrate mechanics.

Guardrails, Trust, and 'Babysitting Claude' (half day — dedicated block)

The scoping notes are candid: reluctance to let Claude commit, wariness about connecting it to external tools, personal accounts already stripped back, and 'babysitting Claude' named as a present cost. This gets a dedicated block and is tackled directly.

• Naming the actual fear with precision: 'Claude will do something wrong' versus 'I won't know it happened' versus 'I won't be able to undo it.' These require different guardrails, and conflating them produces both over-restriction and false confidence.

• What permission models, approval gates, and reviewable diffs actually buy — and where 'click yes without really checking' creeps in even when they exist.

• MCP and tool connections: a clear-eyed look at what connecting Claude to external tools exposes, what it does not, and a framework for evaluating connections based on what would need to be true to trust them — rather than a blanket allow or deny.

• Designing team guardrails as a deliberate artefact: what requires human sign-off, what is auto-approved, what is logged and reviewed after the fact.

• Group exercise: the team surfaces their own fears and objections live, then sorts them into 'solved by a guardrail,' 'solved by a process,' and 'needs trust built over time' — a more honest and durable outcome than a checklist handed to them.

Choosing a Team Methodology: SpecKit and TDD with AI (45–60 min)

Not a deep dive into either — a structured comparison to help the team make a considered choice rather than leaving it to individual preference.

• TDD-with-AI: using tests as the contract that keeps Claude Code honest, and where this breaks down when the model writes both the test and the implementation with no independent check.

• SpecKit-style spec-first work: front-loading context engineering rather than relying on iterative conversation.

• Framed as 'pick one, trial it, do not adopt both at once.' The room does not need to leave with a final decision, but should leave with a clear sense of what each costs and what each buys.

Where Humans Add Value (45 min)

Scoping is explicit that the 'AI is not here to take your jobs' framing needs to come from leadership, not the trainer. This session is scoped narrowly and deliberately.

• A structured exercise: walk through a recent, real piece of work and mark honestly which parts were judgement calls only a human could make — requirements trade-offs, stakeholder context, 'is this actually what the business needs' — versus which parts were mechanical execution.

• The aim is to build a shared, concrete vocabulary for 'where I add value' that survives the training room. Not a reassurance speech from an external trainer, which is unlikely to land as credible.

• The session closes by explicitly handing the thread back to leadership: this is flagged in the room as the start of a conversation, not the end of one.

Capstone: Team Claude Code Charter

Reshaped from the original course's personal-process capstone into a team-owned artefact.

• Small groups draft a one-page team charter covering: shared CLAUDE.md conventions, skills contribution process, async and parallel norms, guardrail tiers, and the chosen methodology trial.

• Groups present back briefly — not for polish, but so each cohort develops a sense of where they are converging and where views diverge.

• The session closes by naming a charter owner in the room. Without that, the document goes nowhere after the day ends.