Building Team Communication with Claude Code (Claude CLI)

Claude Code (Claude CLI) is not just a personal productivity tool—it can become a shared language for your team. By sharing settings and rules and integrating with Slack and Linear, you can build a framework for communication and knowledge sharing. Based on a review of English-language blogs, we organize these practices here.

This article summarizes, in English, the key points from official documentation and technical blogs in the English-speaking world, as reviewed by our company. The source for each technique is listed in the "References" section at the end of the article. Please always check the original sources for details.

1. CLAUDE.md is the "team contract"

One point all sources agree on is to commit the CLAUDE.md at the repository root and grow it as a team via git. The official docs state clearly: "Check CLAUDE.md into git so your team can contribute. The file accumulates value over time." Describe team standards such as code style, build/test commands, PR conventions, and branch naming. Keep personal notes separate in a gitignored CLAUDE.local.md (Source 3).

In real-product examples, teams define response modes (plan-first vs. implement-immediately), build/test commands, and PR templates in CLAUDE.md, and keep it within roughly 2,500 tokens (to avoid degradation from bloat) (Source 6).

2. Share the entire .claude/ directory

What turns one person's workflow into a team standard is version-controlling everything under .claude/.

• Custom slash commands (.claude/commands/) — just drop in a Markdown file and everyone can use it as /project:command-name. You can also pass arguments via $ARGUMENTS (Source 4)
• Skills (.claude/skills/) — share your team's API conventions and standard workflows
• Subagents (.claude/agents/) — e.g., an agent for security reviews
• Hooks (.claude/settings.json) — deterministically enforce formatting and prohibited operations

Vincent Bruijn cites examples such as /project:update-readme and notes that these "encapsulate domain knowledge and best practices, making teams more efficient and consistent" (Source 4).

3. Automate PRs and reviews with GitHub Actions

The main battleground for a team's asynchronous communication is GitHub. With Claude Code's GitHub Actions integration, you can simply mention @claude in a PR or Issue to request code analysis, feature implementation, bug fixes, and PR creation.

@claude implement the feature based on the description in this Issue
@claude fix the TypeError in the user dashboard

Even in CI, Claude respects the guidelines in CLAUDE.md and existing code patterns, so team standards are reflected in automated reviews as well. With the code-review plugin, you can automatically run a review each time a PR is opened. There are also examples of running periodic reports on a cron schedule, such as "summarize yesterday's commits and open Issues" (Source 2). Inside Anthropic as well, the product design team automates PR comments with GitHub Actions (Source 1).

4. Connect team tools with MCP servers

Using MCP (Model Context Protocol) servers, you can connect team tools such as Slack, Linear, Jira, and internal databases to Claude Code. You just register the server URL with claude mcp add and complete OAuth authentication.

Samuel Lawrentz reports combining the Slack and Linear MCPs to have Claude summarize discussions scattered across multiple channels, separate individual tasks from team deliverables, and automatically create and assign Linear tickets based on ownership areas—achieving this "with just three conversational prompts and no custom scripts." It's a great example of Claude bridging "where decisions are made" and "where work is recorded" (Source 5).

5. Onboarding and "accumulating knowledge"

Claude Code accelerates onboarding for new members. Anthropic's official docs say, "This usage pattern is an effective onboarding workflow that reduces ramp-up time and lightens the load on other engineers." New hires can ask Claude the same questions they would ask a senior colleague (Source 3).

In internal examples, when a new data scientist hands the entire codebase to Claude, it reportedly "reads CLAUDE.md, identifies dependencies, and explains how the data pipeline fits together." In production cases, there are reports that "a new hire delivered customer value on their second day." By leaving post-incident analyses and operational procedures as Markdown runbooks, knowledge accumulates for both future engineers and future agents (Sources 1 and 6).

Summary: the six elements to share

• CLAUDE.md (commit to git, keep it concise) — the team contract
• Custom commands / skills / subagents / hooks — share the entire .claude/
• GitHub Actions — @claude mentions and automated reviews
• MCP servers — bridge discussion and work, e.g., Slack and Linear
• Writer/Reviewer — mutual review with fresh context
• Runbooks / post-incident analyses — accumulating team knowledge