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

Day 1 — From Personal Proficiency to Shared Context

While team members have likely developed individual workflows with Claude Code, Day 1 aims to convert this individual fluency into a shared, team-wide practice.

Morning: Assessing Current State (45 min)

• Brief framing rather than a lecture: identifying where the team currently stands and noting the divergence between heavy individual adopters and lighter users.

• Conceptual reference to the AI maturity model—highlighting that daily usage does not equate to depth of usage, a gap this two-day programme addresses.

• Structured group discussion to uncover what high-performing adopters are doing that remains invisible to the rest of the team.

Context Engineering, Done Right (half day)

This segment directly addresses the gap between individual effectiveness and shared team knowledge.

• Moving 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—defining conventions for content, review, and version control alongside the codebase.

• Encoding project rules, architectural constraints, and team conventions as context to avoid re-explaining them in every session.

• Creating reusable commands and in-context examples—teaching Claude Code patterns once rather than repeating instructions in every conversation.

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

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

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

This section addresses the common issue where individuals download skills, modify them privately, and never contribute back due to a lack of process.

• The value a shared skills approach brings to a team compared to ad hoc personal prompts.

• Structured discussion on why “pull-and-fork” without contribution occurs—friction, ownership ambiguity, and lack of agreed review standards. The team is best positioned to identify their specific blockers.

• Designing a lightweight contribution loop: defining where modified skills go, who reviews them, and what “good enough to merge” looks like. This is process design, not a tooling demo—the tools exist, but the process is often missing.

• Automating documentation and repeatable workflows using Claude Code commands.

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

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

Specifically requested in scoping, this session is practical rather than theoretical.

• Identifying what actually consumes tokens: context bloat, repeated re-explanation, and overly large file reads.

• Adopting low-cost habits: keeping CLAUDE.md lean, tightly scoping commands, and knowing when a fresh session is more efficient than a long one.

Day 2 — Team-Based, Async, and Trusted

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

Async and Parallel Team Workflows (half day)

The most explicitly requested content in the scoping phase.

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

• Coordinating subagents across separate features—defining ownership and how work is handed back for integration.

• Understanding what “async” truly requires to be a safe pattern rather than a risky one: proper context, guardrails, and clearly scoped tasks.

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

• Lab: a two-person simulation where one person initiates an async task on a branch or worktree while the other continues separate work; both then reconvene to integrate. Structured to surface coordination challenges rather than just demonstrate mechanics.

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

Scoping notes highlight candid concerns: reluctance to let Claude commit, wariness about external tool connections, stripped-back personal accounts, and the cost of “babysitting Claude.” This dedicated block addresses these directly.

• Precisely naming the fear: “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; conflating them leads to over-restriction or false confidence.

• What permission models, approval gates, and reviewable diffs actually provide—and where the habit of “clicking yes without checking” can creep in even when these exist.

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

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

• Group exercise: the team surfaces their own fears and objections live, then categorizes them into “solved by a guardrail,” “solved by a process,” and “needs trust built over time”—yielding a more honest and durable outcome than a generic checklist.

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

Not a deep dive into either, but a structured comparison to help the team make a considered choice rather than relying on individual preference.

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

• 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 doesn’t need a final decision but should leave with a clear understanding of the costs and benefits of each approach.

Where Humans Add Value (45 min)

Scoping explicitly states that the framing of “AI is not here to take your jobs” must 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 honestly mark which parts required human judgement—requirements trade-offs, stakeholder context, business need validation—versus mechanical execution.

• The aim is to build a shared, concrete vocabulary for “where I add value” that persists beyond the training room. This is not a reassurance speech from an external trainer, which may lack credibility.

• The session closes by explicitly handing the thread back to leadership: 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 briefly—not for polish, but so each cohort develops a sense of where views are converging and where they diverge.

• The session closes by naming a charter owner in the room. Without this, the document is unlikely to be implemented after the training ends.