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

Day 1 — From Individual Expertise to Shared Context

Team members have likely developed their own distinct approaches to using Claude Code. Day 1 aims to convert individual proficiency into practices that can be shared across the team.

Morning: Assessing Current State (45 min)

• A concise overview rather than a lecture: evaluating the team's current position and identifying divergences between advanced individual adopters and casual users.

• Conceptual reference to AI maturity models — highlighting that daily usage does not equate to deep usage, a gap these two days aim to bridge.

• Structured group discussion: Identifying actions taken by strong adopters that remain unseen by the rest of the team.

Context Engineering, Effectively (half day)

This section directly addresses the gap between individual competence and shared knowledge identified during scoping.

• 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, and versioning alongside the codebase.

• Encoding project rules, architectural constraints, and team standards as context to avoid re-explanation in every session.

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

• 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 create a CLAUDE.md and command set as a team asset using a real or representative portion of the TS/Node codebase.

Skills, Marketplace, and Contribution Challenges (half day)

This addresses the common pattern where individuals download and modify skills privately without contributing back due to lack of process.

• The benefits of a shared skills approach for teams compared to ad hoc personal prompts.

• Structured discussion: Analyzing why 'pull-and-fork-without-contributing-back' occurs — due to friction, ownership ambiguity, or lack of review standards. The team's insight into their specific blockers will be valuable.

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

• Automating documentation and repeatable workflows through Claude Code commands.

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

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

Specifically requested during scoping. This section is practical rather than theoretical.

• Identifying token drains: context bloat, repeated explanations, and excessive file reads.

• Cost-effective habits: Keeping CLAUDE.md concise, scoping commands tightly, and recognizing when a new session is more efficient than extending a long one.

Day 2 — Team-Centric, Asynchronous, and Trustworthy

Individual workflows are elevated to team workflows. Trust and guardrails are intentionally designed rather than learned through incidents.

Asynchronous and Parallel Team Workflows (half day)

The most directly requested content from the scoping phase.

• Using Git worktrees and branches to enable parallel Claude Code sessions without conflicts.

• Coordinating subagents across separate features — defining ownership and handoff processes for integration.

• Requirements for 'asynchronous' work to be safe rather than risky: proper context, guardrails, and clearly scoped tasks.

• Establishing team norms: Determining when parallel/async work is appropriate versus when human oversight is required throughout.

• Lab: A two-person simulation where one initiates an async task on a branch/worktree while the other continues separate work, followed by reconvening to integrate. This is structured to expose coordination challenges, not just demonstrate mechanics.

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

Scoping notes highlighted concerns: reluctance to let Claude commit, caution with external tools, restricted personal accounts, and the cost of 'monitoring Claude.' This block tackles these issues directly.

• Precisely naming the fears: 'Claude will err' vs. 'I won't notice the error' vs. 'I can't undo the error.' Each requires different guardrails; conflating them leads to either over-restriction or false confidence.

• The value of permission models, approval gates, and reviewable diffs — and identifying where 'clicking yes without checking' can creep in even when these exist.

• MCP and tool integrations: An objective assessment of what connecting Claude to external tools exposes versus what it does not, using a trust-based framework for evaluation rather than blanket allow/deny decisions.

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

• Group exercise: The team identifies their own fears and objections live, categorizing them into 'resolved by guardrails,' 'resolved by process,' and 'requiring trust-building over time' — yielding a more honest and durable outcome than a provided checklist.

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

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

• TDD-with-AI: Using tests as a contract to keep Claude Code accountable, and identifying breakdown points when the model writes both tests and implementation without independent verification.

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

• Guidance to 'pick one, trial it, and avoid adopting both simultaneously.' The group need not leave with a final decision but should understand the costs and benefits of each.

Where Humans Add Value (45 min)

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

• Structured exercise: Reviewing a recent real work item to identify which parts required human judgment (requirements trade-offs, stakeholder context, business needs) versus mechanical execution.

• Building a shared, concrete vocabulary for 'where I add value' that remains relevant beyond the training. This avoids an external reassurance speech, which may lack credibility.

• Closing by explicitly returning the topic to leadership: Framing this as the start of a conversation, not the end.

Capstone: Team Claude Code Charter

Modified from the original personal-process capstone to become a team-owned asset.

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

• Brief group presentations — not for polish, but to help the cohort recognize areas of convergence and divergence in views.

• Closing by appointing a charter owner in the room. Without this, the document will likely be disregarded after the training.