Team Leader Setup

This page comes after Project Setup, not before it.

The team lead’s job is not to build a policy engine on day one. The job is to choose defaults the team can actually live with, then raise the bar gradually.

What team leaders are actually deciding

• which account and workspace path the team should use
• what “good daily workflow” means in this repo
• what belongs in CLAUDE.md
• which permissions and shared settings reduce noise without hiding risk
• which skills, hooks, plugins, and agents are mature enough to standardize

Rollout order that keeps the team calm

1. Standardize the minimum baseline

Get these in place first:

• the team account expectation
• a short CLAUDE.md
• shared verification commands
• a modest .claude/settings.json

Do not start by teaching every hook event or plugin namespace. Also do not make --dangerously-skip-permissions the team default. If confirmations are noisy, fix the shared permission baseline instead.

2. Teach the daily workflow before enforcing it

Ask every developer to walk through:

• Core Session Commands
• Your First Feature
• Daily Workflow

This is where trust gets built. If the team does not understand the individual workflow yet, repo-wide automation will feel arbitrary.

3. Standardize one shared skill before multiple hooks

Skills usually make a better early standard than hooks because they teach a pattern without blocking the session.

Start with one shared skill only if it captures a workflow the team already repeats successfully.

4. Add one hook only when there is a clear reason

The first hook should be easy to explain in one sentence.

Good examples:

• “We block obviously dangerous shell commands.”
• “We automatically format files after edits.”

Bad examples:

• “We copied a long hook matrix from a guide and hope it helps.”

5. Review plugins and shared MCP deliberately

Use:

/plugin

Recommended team flow:

1. review what is already installed
2. confirm which plugins the repo genuinely benefits from
3. standardize only the ones that reduce real friction

If the team needs MCP servers, use the same standard: keep early experiments personal, then commit project-scoped .mcp.json entries only when the integration is clearly shared infrastructure.

That keeps plugin and MCP rollout aligned with actual work instead of curiosity-driven sprawl.

6. Save CI/CD and advanced enforcement for later

Headless workflows, deferred approvals, stronger hooks, and scale-oriented automation belong later in the rollout.

They matter, but only after the team baseline is dependable.

What to tell developers on day one

Keep the message simple:

1. Use the team account for repo work.
2. Learn the daily workflow before trying to customize everything.
3. Use the tutorials first.
4. Treat project configuration as something you grow into, not a test you have to pass on day one.

A small-team rollout example

Imagine a five-person team onboarding this week:

Week 1

• everyone completes First-Time Setup
• everyone works through Core Session Commands and Your First Feature
• you commit the minimum CLAUDE.md and shared settings baseline

Week 2

• the team uses Daily Workflow on real tasks
• you notice the recurring patterns worth turning into one shared skill
• you add one small hook only if it removes repeated pain

Later

• you standardize plugins through /plugin
• you add stronger hooks, agents, or CI/CD automation only when the need is obvious

Team-lead checklist

• Tell developers to use the team account.
• Keep CLAUDE.md short and specific.
• Standardize the daily workflow before advanced automation.
• Add one shared skill before multiple hooks.
• Use /plugin to review installed plugins instead of assuming everyone needs the same set immediately.
• Introduce stronger guardrails only after the team already understands the behavior they enforce.
• Point advanced users to Hooks & Events, Scaling Workflows, and CI/CD Integration when the team is ready.