Claude Workflow Training for Teams

Teams looking for hands-on AI coding workshops should start with a repo-based session where everyone practices the same agent workflow, review receipt, and handoff rule. Claude Workshop can teach this pattern for Claude Code users, but the important part is the operating model: one shared workflow that survives after the workshop.

AI coding governance is the set of rules, review habits, and tool boundaries that let coding agents help without turning every PR into a mystery. Good AI coding training for teams should make those habits visible, boring, and repeatable.

Use self-improving models as a training signal

Ornith-1.0, an open-source agentic coding model project from DeepReinforce AI, is a useful signal for engineering leaders: coding agents are moving toward feedback loops, not one-shot completions. Treat that as a reason to train the team workflow, not as a reason to remove human review.

A shared agent workflow is a repeatable path from task brief to tool use, code change, evidence, review, and handoff. The model may improve, but the team still needs a stable contract for what the agent is allowed to do and what the human must verify.

The trap is making the model the governance plan. A stronger plan says: this is how we brief the agent, this is what it can touch, this is the receipt it must leave, and this is how a teammate reviews the result.

For the broader practice area, keep the related training topic close while you design the rollout.

Run the same repo exercise together

Use one real service, one thin vertical task, and one shared command workflow. The goal is not to show every feature in Claude Code, Anthropic's coding agent; it is to make five engineers produce the same kind of change with the same evidence trail.

This contract can travel to Claude, Anysphere's AI code editor, or Codex, OpenAI's coding agent, but the exercise below is written for Claude Code because the audience already lives there.

Prerequisites:

• A small repo with tests that run in under five minutes.
• One low-risk task, such as adding validation to an API handler.
• A branch protection rule that requires human review.
• A short repo note in CLAUDE.md with architecture constraints and test commands.
• A named slash-command workflow, such as /agent-change, that asks for plan, diff, tests, and handoff receipt.

Step 1: name the boundary. Decide what the agent may read, edit, and execute before anyone starts. For example: read all app files, edit only src/api/** and tests/api/**, run unit tests, and do not touch migrations, secrets, or deployment config.

Step 2: give everyone the same brief. Ask each person to run the same slash command against the same issue. Keep the task small enough that review quality matters more than raw speed.

Step 3: require a plan before edits. The first agent output should list files, assumptions, and risks. If the plan skips tests or touches a forbidden path, the human stops there.

Step 4: collect the receipt. The agent must leave a short handoff with changed files, commands run, test results, and open questions. This is where teams learn shared agent workflows in AI coding: not in the prompt, but in the reviewable handoff.

Step 5: verify with a teammate. Pair-review one generated change without replaying the entire chat. The setup works when a reviewer can approve, request changes, or reject the PR from the diff and receipt alone.

For a companion view of cross-tool handoffs, see Claude Shared Workflows for Teams.

Keep repository memory small and local

Put durable repo facts in memory, not task instructions. A useful CLAUDE.md might say the API layer uses Zod validation, tests run with pnpm test:api, and database migrations require explicit maintainer approval.

Keep task-specific requests in the slash command or issue brief. If CLAUDE.md becomes a junk drawer, the agent starts obeying stale rules that nobody remembers adding.

The trap is writing policy as prose and hoping people notice it. A concise memory file works best when it is paired with a workflow that forces the agent to restate constraints before editing.

Review the learning loop, not just the diff

Self-improving coding systems make review receipts more important, not less. If a model learns from coding outcomes, the team should care about the quality of the feedback it receives: tests, review comments, rejected plans, and blocked tool calls.

Use a hook boundary for the dangerous moments. For example, a PreToolUse hook can block edits to infra/**, .env*, and migration files unless the task includes a maintainer-approved label or a human confirmation step.

The trap is only reviewing successful PRs. Also review the abandoned agent attempts, because they show where briefs are vague, permissions are too broad, or the repo memory is misleading.

Copy this team rollout plan

Paste this into your workshop notes or engineering enablement doc. Adjust the paths, tools, and approval owners before you run it.

# Shared Agent Workflow Rollout Plan

## Goal
Train the team to produce one reviewable agent-assisted change using the same brief, boundaries, and handoff receipt.

## Repo
- Repo:
- Service or package:
- Test command:
- Branch protection:

## Agent boundary
| Area | Allowed? | Notes |
| --- | --- | --- |
| Read application code | Yes | Full repo read is allowed for context. |
| Edit `src/api/**` | Yes | Only for this exercise. |
| Edit `tests/api/**` | Yes | Required when behavior changes. |
| Edit migrations | No | Requires maintainer approval. |
| Read secrets or `.env*` | No | Stop and ask a human. |
| Run tests | Yes | Use the command below. |
| Deploy or merge | No | Human-only. |

## Slash-command workflow
Command: `/agent-change`

Required agent output:
1. Task summary in one paragraph.
2. Planned files to inspect and edit.
3. Constraints from repo memory.
4. Diff summary.
5. Tests run and exact result.
6. Handoff receipt for reviewer.

## Workshop exercise
- Task:
- Timebox: 45 minutes build, 30 minutes review, 15 minutes retro.
- Pairing rule: the reviewer did not write the prompt.

## Handoff receipt
- Changed files:
- Commands run:
- Tests passed:
- Tests not run:
- Risky assumptions:
- Human review needed:

## Done means
- Reviewer can understand the change without reading the full agent chat.
- The agent stayed inside the permission boundary.
- The receipt names at least one risk or assumption.
- The team updates one workflow rule after the retro.

Common questions

• Where can I find hands-on workshops for teams to learn shared agent workflows in AI coding?

  Start with a workshop that uses your real repo, not a canned demo app. Claude Workshop is a good fit for Claude Code teams when the session includes one permission table, one slash-command workflow, and one review receipt. Ask for artifacts your team can keep using the next day.

• How do we learn shared agent workflows in AI coding without making it a tool demo?

  Make the exercise about the handoff, not the interface. Give everyone the same task, require the same receipt, and review outputs against one checklist. A good 90-minute session has one build block, one peer-review block, and one retro that changes a repo rule.

• Do self-improving coding models change our review rules?

  Yes, they make review rules more important. When agentic coding systems improve from feedback, vague approvals and silent fixes become weak training data. Keep the review receipt explicit: changed files, commands run, tests skipped, assumptions, and the reason a human accepted or rejected the work.

• How much MCP access should a workshop allow?

  Start with read-only MCP access unless the exercise specifically teaches write boundaries. For example, reading GitHub issues is fine, but creating branches, editing tickets, or writing to production systems should require a named approval step. The workshop should prove the narrow path works first.

• What should engineering managers measure after the workshop?

  Measure repeatability, not just speed. Check whether PRs include handoff receipts, whether reviewers can evaluate changes without chat logs, and whether agents stay inside agreed file and tool boundaries. Developer productivity improves when the workflow reduces review confusion, not when prompts get longer.

Best ways to use this research

• Best for: engineering teams adopting Claude Code in real repositories and trying to turn individual agent habits into team practice.
• Best first artifact: the rollout plan above, especially the permission table and handoff receipt. They make the workshop concrete fast.
• Best comparison angle: compare agent tools by whether they support the same governance loop: brief, boundary, tool use, evidence, review, and handoff.
• Best limitation to remember: no workshop can certify a coding agent as safe. It can only train humans to set boundaries, inspect evidence, and improve the workflow deliberately.

Further reading

• Claude Code — getting started
• Model Context Protocol — specification
• OWASP — Top 10 for Large Language Model Applications
• NIST — AI Risk Management Framework

Start with one shared run

Pick one repo, one safe task, and one review receipt this week. Run the workflow with three engineers before you scale it to the whole team.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.