Rolling this out to a client team: two weeks

Written for a team of about four developers and one IT contact. Dates are relative. Nothing here is a promise of a result; the measures in the last section exist so the team can see for itself.

Before day 1 (with the client, 1 hour)

Agree the goal in one sentence, for example "use Claude Code safely on the internal tools repos".
Name one IT contact (permissions, network, accounts) and one team lead who owns .claude/ changes.
Pick the pilot repo: small, active, with a test suite that runs in under two minutes.
Confirm how the client licenses Claude (team seats or API billing) and where data may go. I do not use client credentials; the client owns the accounts.

Week 1: pilot with two people

Day 1. Install and read. Add the kit to the pilot repo on a branch: CLAUDE.md, .claude/, .mcp.json. Edit CLAUDE.md with the team lead so it matches how they actually work. Run the hook tests (npm test in the kit) and show the output.

Day 2. Permissions review with IT (90 minutes). Walk settings.json line by line. For each allow, deny and hook, IT answers: keep, tighten, or loosen. Decide where the audit log lives (local only, or shipped to the client's log tool). Decide the MCP policy: read-only servers only in week one, each named and reviewed. Output: a signed-off settings file and a list of open questions.

Days 3-5. Pilot. Two developers use it on real tickets. I sit in for the first session of each. Each evening they add to a shared "friction log": blocked when they shouldn't be, allowed when they shouldn't be, prompts that went badly. I fix the hooks and CLAUDE.md daily, as small commits.

Day 5. Retro (45 minutes). Review the friction log and the audit log together. Anything blocked wrongly gets fixed. Anything allowed wrongly gets a deny rule and a new test case.

Week 2: the whole team

Day 6. Expand. Merge the kit to the main branch. Everyone runs the setup from ONBOARDING.md; I fix what breaks.

Day 7. Coaching session 1 (60 minutes): asking well. Live on a real ticket: specific prompts, plan mode, checking a diff, when to /clear.

Day 8-9. Team skills. Capture the two or three tasks the team repeats most (new endpoint, release notes, security checklist) as skills. Write each from a real past pull request.

Day 10. Coaching session 2 (60 minutes): review and limits. The reviewer subagent, reading blocked-call messages, where the model is weak (long refactors, anything needing production access), and what stays a human decision.

Day 11-12. Hand-over. Walk the team lead through changing a hook, adding a deny rule with its test, and adding a skill. They make one change themselves while I watch.

Day 14. Review with the client (30 minutes). Show the numbers below, the friction log, and a short list of what I would change next.

What to measure

Collected from the audit log, git history and a 5-question survey. Report counts and the rule used, not verdicts.

Adoption: developers who ran at least one session in each week; sessions per developer.
Guard activity: number of blocked calls per rule id, and how many were later judged wrong by the team. Wrong blocks get a fix and a test.
Stop-hook results: how often tests ran after edits, how often they failed, how many attempts until they passed.
Review load: changes reviewed by the code-reviewer subagent before a pull request, and findings a human reviewer later raised that it missed.
Time on the repetitive tasks: cycle time for the tasks that became skills, before and after, from ticket timestamps.
Survey (day 14): what saved time, what annoyed them, what they would not trust it with.

Risks I plan for

Over-trust. The guard catches common mistakes; it is not a sandbox. The real boundaries are the OS account, network policy and the permission rules. I say so in the first meeting.
Rule creep. Every new allow gets a reason in the pull request. Every new deny gets a test case.
Prompt drift. CLAUDE.md is reviewed monthly; stale instructions are worse than none.
Secrets in prompts. Covered in coaching, not just by hooks.