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

Day 1 — From Personal Proficiency to Shared Context

While team members have individually developed their own workflows with Claude Code, Day 1 focuses on translating this individual fluency into shared, team-wide practices.

Morning: Current State Assessment (45 min)

• A concise framing session, rather than a lecture, to assess the team's current position and identify the divergence between high-level adopters and lighter users.

• Conceptual reference to the AI maturity model, highlighting that frequent daily use does not equate to deep utilization; this gap is the primary target of the two-day programme.

• A structured group discussion to uncover the specific techniques high-adopter team members use that are not yet visible to the rest of the group.

Effective Context Engineering (half day)

This section directly addresses the 'strong individually, but not shared' gap identified in the scoping phase.

• Transitioning from simple prompting to context engineering: understanding why identical prompts yield different results based on the model's visible context.

• Treating CLAUDE.md as living team documentation — establishing conventions for content, review processes, and versioning alongside the codebase.

• Encoding project rules, architectural constraints, and team conventions as persistent context, eliminating the need for re-explanation in each session.

• Creating reusable commands and in-context examples to teach Claude Code patterns once, rather than repeating them in every conversation.

• Utilizing Best-of-N as a strategic technique: determining when generating multiple candidate solutions justifies the token cost and how to evaluate them efficiently.

• Lab: Pairs or trios construct a CLAUDE.md file and command set as a team artefact, applied to a real or representative slice of the TS/Node codebase.

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

This addresses the common pattern where individuals download skills, modify them privately, but fail to push changes back due to a lack of process.

• Comparing the benefits of a shared skills approach versus ad hoc personal prompts.

• Structured discussion on why 'pull-and-fork-without-contributing' occurs — exploring friction, ownership ambiguity, and undefined review standards. The team's specific blockers are best understood by the team itself.

• Designing a lightweight contribution loop: defining where modified skills go, who reviews them, and what 'good enough to merge' entails. This focuses on process design, as the tooling exists but the process does not.

• Automating documentation and repeatable workflows using Claude Code commands.

• Lab: Take a privately modified skill (or a prepared example) and process it through the contribution loop — writing the PR, drafting review comments, and agreeing on the merge criteria.

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

A practical, non-theoretical look at a topic specifically requested in scoping.

• Identifying true token drivers: context bloat, repeated re-explanations, and reading excessively large files.

• Adopting low-cost habits: maintaining a lean CLAUDE.md, scoping commands tightly, and recognizing when starting a fresh session is more cost-effective than extending a long one.

Day 2 — Team-Based, Async, and Trusted

Individual workflows evolve into team workflows. Trust and guardrails are intentionally designed rather than discovered through incidents.

Asynchronous and Parallel Team Workflows (half day)

The content most directly requested in the scoping phase.

• Using Git worktrees and branches to run parallel Claude Code sessions without collisions.

• Coordinating subagents across distinct features — clarifying ownership and defining hand-off procedures for integration.

• Defining the prerequisites for 'async' to be a safe pattern rather than a risky one: clear context, guardrails, and well-scoped tasks.

• Establishing team norms: determining when parallel/async work is appropriate versus when a human must remain actively in control.

• Lab: A two-person simulation where one individual initiates an async task on a branch or worktree while the other continues separate work; both then reconvene to integrate. The exercise is designed to surface coordination challenges, not just demonstrate mechanics.

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

Addressing candid concerns from scoping: reluctance to let Claude commit, wariness about external tool connections, stripped-back personal accounts, and the cost of 'babysitting Claude'. This is tackled directly in a dedicated block.

• Precisely naming the underlying fears: 'Claude will make a mistake' versus 'I won't know if it happens' versus 'I won't be able to undo it.' These require different guardrails; conflating them leads to both over-restriction and false confidence.

• Evaluating what permission models, approval gates, and reviewable diffs actually provide — and identifying where 'click yes without checking' behavior creeps in despite these controls.

• MCP and tool connections: A clear assessment of what connecting Claude to external tools exposes versus what it does not, using a framework to evaluate connections based on trust requirements rather than blanket allow/deny policies.

• Designing team guardrails as a deliberate artefact: defining what requires human sign-off, what is auto-approved, and what is logged for post-hoc review.

• Group exercise: The team surfaces their own fears and objections live, then categorizes them into 'solved by guardrail,' 'solved by process,' and 'requires building trust over time' — yielding a more honest and durable outcome than a standard checklist.

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

Rather than a deep dive, this offers a structured comparison to help the team make a considered choice instead of relying on individual preference.

• TDD-with-AI: Using tests as a contract to keep Claude Code honest, and understanding where this breaks down if the model writes both the test and the implementation without an 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 simultaneously.' The goal is not a final decision in the room, but a clear understanding of the costs and benefits of each approach.

Where Humans Add Value (45 min)

Recognizing that the 'AI is not here to take your jobs' narrative should come from leadership. This session is scoped narrowly and deliberately.

• A structured exercise: Reviewing a recent, real piece of work to honestly mark which parts required human judgement — requirements trade-offs, stakeholder context, business alignment — versus mechanical execution.

• Building a shared, concrete vocabulary for 'where I add value' that persists beyond the training room, avoiding a mere reassurance speech from an external trainer.

• Closing the session by explicitly handing the conversation back to leadership, positioning it as the start of an ongoing dialogue rather than an endpoint.

Capstone: Team Claude Code Charter

Reshaped from a 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.

• Brief group presentations — not for polish, but to help each cohort understand where views converge and diverge.

• The session closes by assigning a charter owner in the room, ensuring the document has a steward beyond the end of the training.