Claude Code Skills·Hooks·MCP Practical Guide: How the Entire Team Can Produce Senior-Level Results with Just 4 Configuration Files

Let's ask 10 team members who share the same Claude Code to "add a new method to the NestJS service layer." The code you receive will vary widely. Some will bring code that includes DTOs and exception handling in compliance with team conventions, while others will bring code where business logic is mixed into the controller. The cost of this disparity is tangible. The same feedback is repeated in every code review, the rework cycle lengthens, and technical debt quietly accumulates—a debt that no one has ever explicitly decided to address.

The cause of the gap is not model capability, but differences in environment design. Claude Code provides four layers: CLAUDE.md, Skills, Hooks, and MCP. By combining these layers correctly, you can turn the judgment criteria that senior developers used to convey only during code reviews into the defaults for the entire team—even for newly joined juniors and codebases they are seeing for the first time.

If you finish reading this article, you will be able to obtain a set of configuration files (CLAUDE.md, .claude/settings.json, Skills file) that can be committed to Git. Prerequisites: This is intended for developers who have the Claude Code CLI installed and know how to use the prompt for basic purposes.

Problems solved by each of the 4 layers

Overview of the Entire Structure at a Glance

The four layers each solve a different problem. Let's start by grasping the overall map.

CLAUDE.md — The Team's Coding Constitution

CLAUDE.md is a document that is automatically read when a Claude Code session starts. If a senior developer writes down what they know to "obviously do"—which patterns to avoid and why a particular structure is used—Claude Code responds to all team members in the same context.

By utilizing a hierarchical structure, you can separate enterprise rules, project-specific rules, and subpackage-specific rules.

~/.claude/CLAUDE.md          # 개인 전역 규칙 (커밋 스타일, 선호 언어 등)
.claude/CLAUDE.md            # 프로젝트 규칙 (아키텍처, 금지 패턴)
packages/frontend/CLAUDE.md  # 서브패키지 규칙 (모노레포 대응)

Priority Rule: Project-level .claude/CLAUDE.md has higher priority than global ~/.claude/CLAUDE.md, and subpackage CLAUDE.md is applied additionally at that path. In the event of a conflict, the more specific (sub-path) file takes precedence.

Below is an example of an actual CLAUDE.md from a NestJS project.

# 프로젝트 규칙
 
## 아키텍처
- 비즈니스 로직은 반드시 Service에, Controller는 얇게 유지한다
- DTO로 입력 검증, custom exception filter 사용
- `any` 타입 사용 금지 — 불가피할 경우 `unknown`과 타입 가드를 사용
 
## 금지 패턴
- `console.log` 대신 NestJS Logger 사용
- 직접 `throw new Error()` 금지 — 반드시 커스텀 예외 클래스 사용
 
## 빌드 명령
- Build: `pnpm build`
- Test: `pnpm test`
- Lint: `pnpm lint`

Skills — /커맨드 Standard procedure executed as a single unit

Skills (custom slash commands) are Markdown files stored in the .claude/commands/ directory. When a teammate types /커맨드명, the contents of the file are loaded and executed as Claude's instructions.

Important: Skills do not execute automatically. They are triggered only when the user explicitly enters a slash command, such as /pr-review. The "when to execute" descriptions within the file are human-readable instructions and are not rules for the system to parse and execute automatically.

If you save a file to .claude/commands/pr-review.md, the entire team can run the same PR review procedure once in /pr-review.

Hooks — Force execution that bypasses Claude's judgment

Hooks are fundamentally different from CLAUDE.md. Even if you write "Do not modify .env file" in CLAUDE.md, Claude merely decides to follow it. On the other hand, if configured as a Hook, it is always executed or blocked regardless of Claude's intentions.

Hooks bind shell commands to Claude Code's lifecycle events.

Action on Hook Failure: If the Hook command returns a non-zero exit code, the execution of the corresponding tool in PreToolUse is immediately stopped, and an error message is printed in PostToolUse. If a lint error occurs, Claude Code stops and does not continue editing.

Prompt Instructions vs. Hooks: Prompt instructions are "guidelines," while Hooks are "enforcement." Hooks are necessary to seriously apply team standards.

MCP — Standard Interface for External System Integration

Model Context Protocol (MCP) is a standard protocol for AI-tool integration released as open source by Anthropic in November 2024. It became a de-facto standard after OpenAI officially adopted it in March 2025. Currently, thousands of MCP servers have been built by the community.

With MCP, Claude Code can directly manipulate external systems such as GitHub, Jira, Slack, and databases using tools. Integration logic that previously had to be written separately for each tool converges into a single standardized interface.

3 Application Scenarios in Code

Example 1: Enforcing Quality Gates with Hooks

When .claude/settings.json is committed to Git, all team members will execute the same Hook. Below is a configuration that applies both simultaneously. It runs automatic lint and type checking after file editing, and blocks attempts to directly modify the main branch.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "pnpm lint --fix && pnpm tsc --noEmit"
          }
        ]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "scripts/check-branch-protection.sh"
          }
        ]
      }
    ]
  }
}

matcher field: This is a regex pattern. "Write|Edit" means that the Hook is triggered when Claude Code uses the Write or Edit tool. Using ".*" applies it to all tools.

The core logic of check-branch-protection.sh is as follows.

#!/bin/bash
# scripts/check-branch-protection.sh
# main 브랜치에서 직접 commit/push 명령을 차단한다
 
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null)
COMMAND_ARGS="${CLAUDE_TOOL_INPUT:-}"
 
if [[ "$CURRENT_BRANCH" == "main" || "$CURRENT_BRANCH" == "master" ]]; then
  if echo "$COMMAND_ARGS" | grep -qE '\bgit\s+(commit|push)\b'; then
    echo "ERROR: main 브랜치에 직접 커밋/푸시할 수 없습니다. feature 브랜치를 사용하세요." >&2
    exit 1
  fi
fi
 
exit 0

The moment this script returns exit 1, the PreToolUse Hook halts Bash execution, and Claude Code does not execute the command. This structurally makes it impossible for a team member to accidentally push directly to main.

Example 2: Standardizing the PR Review Process with Skills

If the PR review process of senior developers is packaged as a skill, junior developers can also perform reviews of the same quality.

---
name: pr-review
description: Pull Request를 팀 표준에 따라 리뷰한다
---
 
# PR 리뷰 절차
 
이 커맨드는 현재 브랜치의 변경 사항을 팀 표준에 따라 검토한다.
 
1. `git diff main` 으로 변경 파일 목록을 파악하고 컨텍스트를 이해한다
2. 팀 아키텍처 규칙(CLAUDE.md) 위반 여부를 확인한다
   - 비즈니스 로직이 컨트롤러에 있지 않은지
   - `any` 타입이 사용되지 않았는지
3. 보안 취약점(OWASP Top 10 기준) 스캔
4. 테스트 커버리지 확인 — 새로운 공개 메서드에 테스트가 있는지
5. 한국어로 리뷰 코멘트를 작성한다. 각 코멘트는 [심각도: 높음/중간/낮음] 레이블을 포함한다

If you save this file to .claude/commands/pr-review.md, the team's standard review process runs identically every time simply by entering /pr-review. Committing this file to Git is the same as a team-wide deployment.

Example 3: Jira-Code-GitHub as a Single Flow with MCP

When you configure the MCP server, Claude Code directly manipulates external systems. With a single command like "Implement JIRA-1234," the entire process is handled: reading the Jira ticket, implementing the code, updating the Jira status, and generating a GitHub PR.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "jira": {
      "command": "npx",
      "args": ["mcp-atlassian"],
      "env": {
        "ATLASSIAN_URL": "${JIRA_URL}",
        "ATLASSIAN_API_TOKEN": "${JIRA_TOKEN}"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-postgres"],
      "env": {
        "POSTGRES_CONNECTION_STRING": "${DATABASE_URL}"
      }
    }
  }
}

The list of MCP servers frequently used by the team is as follows.

MCP Security Caution: MCP servers can have extensive access to external systems. Explicitly minimize the access scope of each server before deploying to the entire team. The recommended pattern is to grant read-only permissions to the GitHub MCP server for code reviews and separate write permissions for PR creation.

Pros and Cons Analysis

Advantages

Disadvantages and Precautions

The Most Common Mistakes in Practice

1. Do not write CLAUDE.md once and never update it. As the project evolves, if CLAUDE.md becomes out of touch with reality, it will provide incorrect context that is worse than having no context at all. Schedule quarterly reviews on the team calendar.
2. Put too many checks in the Hook. Running the entire test suite for every edit drastically slows down development speed. Place only quick lint and type checks in PostToolUse, and put heavy tests in the PreCommit Hook.
3. Set MCP server permissions to the administrator level for convenience. The moment extensive permissions are granted, the MCP server becomes an attack surface. Explicitly define the access scope for each server before deploying to the entire team.

In Conclusion

Ultimately, configuring CLAUDE.md, Skills, Hooks, and MCP is the act of versioning the team's collective knowledge into code. If a senior developer's judgment criteria are conveyed only through Slack messages or code review comments, that knowledge evaporates. If stored in the .claude/ directory, it does not disappear even if team members change or the project doubles in size.

3 Steps to Start Right Now:

1. Create the .claude/CLAUDE.md file. If you are unsure what to write, find the comments that have been repeated in code reviews over the past month. If the same feedback has been repeated three or more times, that is the first rule that must go into CLAUDE.md.
2. Write a file under .claude/commands/ for one of the most repetitive tasks performed by the team, and share it with team members in /커맨드명. Anything is fine, such as PR reviews, sprint retrospective summaries, or migration script generation.
3. Add the PostToolUse Hook to .claude/settings.json to configure pnpm lint to run automatically after editing the file, and commit this file to Git. The moment these three files are added to the repository, all new team members joining the team will have the same AI development environment with just a single git clone. Onboarding is complete if you add a single line to the README stating, "When using Claude Code, .claude/ directory settings are automatically applied."

Next Post: Claude Code How to Automate Complex Multistep Tasks with Subagents and the Orchestrator Pattern

Reference Materials

• Hooks reference — Claude Code Official Documentation
• Automate workflows with hooks — Claude Code Official Guide
• Connect Claude Code to tools via MCP — Claude Code 공식 문서
• Slash commands — Claude Code Official Documentation
• Introducing the Model Context Protocol — Anthropic
• What is the Model Context Protocol (MCP)? — modelcontextprotocol.io
• Understanding Claude Code's Full Stack: MCP, Skills, Subagents, and Hooks Explained — alexop.dev
• Claude Code Skills vs MCP Servers — DEV Community
• Claude Code to AI OS Blueprint: Skills, Hooks, Agents & MCP Setup in 2026 — Medium
• Claude Code Hooks: A Practical Guide to Workflow Automation — DataCamp
• Claude Code Team Best Practices — SmartScope
• Claude Code Enterprise Setup: Scale AI Development for Teams — HashBuilds
• awesome-claude-code — GitHub
• Top 12 MCP Servers: A Complete Guide for 2026 — Skyvia