Module 09 · Lesson 05

Claude Code Power Setup

Reading time: 25 minutes Track: Advanced Claude Setup · Universal Prerequisites: Module 09 · Lesson 04

What Claude Code actually is

Claude Code is Anthropic's agentic coding environment — a CLI that lets Claude read and write files, execute commands, manage git, and perform multi-step tasks autonomously in your development environment.

For non-engineering biotech teams, the relevance is this: Claude Code is increasingly how technical teams build and maintain AI-powered workflows. Understanding its architecture helps you specify requirements for your IT or software teams and participate in AI infrastructure decisions.

For engineering teams, this lesson is a practical setup guide.

The architecture has five layers. Get all five right and Claude Code behaves consistently, safely, and in ways your team can audit and enforce.

01 · Layer 1: CLAUDE.md — what Claude should know

CLAUDE.md is the primary memory file for Claude Code. It's a markdown file that Claude reads at session start. Its purpose is not to describe Claude's personality — it's to encode how your environment works.

Think of it as the onboarding document you'd write for a senior contractor joining your team for the day: what does this codebase do, what are the conventions, what tools do we use, what must never happen.

CLAUDE.md file hierarchy:

~/.claude/CLAUDE.md          ← global (applies to all projects)
.claude/CLAUDE.md            ← project (committed to repo, shared with team)
.claude/CLAUDE.local.md      ← project-local (gitignored, personal overrides)

What belongs in CLAUDE.md:

• Project architecture and directory structure
• Technology stack and key dependency versions
• Coding conventions (naming, file organization, test patterns)
• Data handling rules (e.g., "never write patient data to local files")
• Tool preferences ("use npm, not yarn")
• Context about what's currently being built
• Links to referenced files with detailed specs

What doesn't belong in CLAUDE.md:

• Personality instructions ("Be helpful and professional")
• Restrictions that should be enforced via hooks (hooks are deterministic; CLAUDE.md is a suggestion Claude can ignore)
• Everything — keep the main file under 500 tokens and offload details to referenced files

Example biotech CLAUDE.md:

# Project: ClinicalOps Assistant

## Purpose
Automates monitoring report drafting and deviation tracking for clinical operations.

## Architecture
- Next.js frontend + Node.js API + Supabase
- Data: no patient data stored locally — all PHI goes through de-identification API first
- Auth: Clerk

## Conventions
- TypeScript strict mode
- All new API routes get a test in /tests/api/
- Database queries go through /lib/db/ never directly in components

## Data rules
- Never write any string that matches PHI patterns to local filesystem
- Trial IDs are internal only — do not include in error messages or logs

## Current sprint
Building deviation tracking workflow — see /docs/deviation-spec.md

02 · Layer 2: Settings hierarchy — what Claude is allowed to do

Settings control permissions, not knowledge. The hierarchy (highest precedence wins):

1. Managed settings (admin-enforced, organization-wide)
2. User settings (~/.claude/settings.json — personal, all projects)
3. Project settings (.claude/settings.json — committed to repo)
4. Project local (.claude/settings.local.json — personal, this project only)

This hierarchy matters for enterprise deployment. Managed settings enforce policies across all developers that cannot be overridden by user or project settings. Use managed settings for:

• Blocking credentials file access
• Preventing destructive commands in production environments
• Requiring approval for all git push operations

Project settings let teams commit shared permissions and hook configurations to the repo, so all developers get the same Claude Code behavior without individual setup.

03 · Layer 3: MCP Servers — external tools

MCP (Model Context Protocol) is the open standard for Claude Code to communicate with external tools and services. Think of it as a plugin system: add a JSON config, get new tools.

Example MCP server configuration in .claude/settings.json:

{
  "mcpServers": {
    "clinical-db": {
      "command": "node",
      "args": ["/path/to/clinical-db-mcp-server.js"],
      "env": {"DB_URL": "${CLINICAL_DB_URL}"}
    },
    "regulatory-search": {
      "type": "http",
      "url": "https://regulatory-search-mcp.internal.company.com/sse"
    }
  }
}

Security warning — this is not optional: MCP servers run with the same trust as the Claude Code session. A malicious MCP server — including a compromised or poorly-vetted one — can direct Claude to exfiltrate files, make unauthorized API calls, or execute harmful operations. Only connect MCP servers from sources you control or have fully audited.

For enterprise teams: maintain an approved MCP server registry and use managed settings to restrict which servers can be added.

Biotech application: Useful internal MCP servers to build: a de-identification API server (calls your PHI-stripping service before any data leaves the secure environment), a regulatory document search server (indexes internal guidance docs), a trial status server (queries your CTMS for current trial state).

04 · Layer 4: Agent Skills — reusable workflows

Agent Skills are modular capabilities packaged as SKILL.md files. They're not prompts — they're complete workflow guides with optional attached scripts and reference materials.

How Skills load (progressive disclosure):

Minimal SKILL.md structure:

---
name: deviation-draft
description: Draft a protocol deviation report from structured input. Use when the user asks to create, draft, or write a deviation report or CAPA.
---

# Protocol Deviation Report Drafting

## When to use this skill
Use when user provides: deviation type, subject ID (de-identified), root cause, and CAPA actions.

## Process
1. Extract the four required inputs from user message
2. If any input is missing, ask for it before proceeding
3. Draft using the template in /skills/deviation-draft/template.md
4. Apply the QC checklist in /skills/deviation-draft/qc-checklist.md before returning

## Output format
Standard deviation report format per SOP-CLN-042.

For teams: Build a shared skill library for your most common document types — deviation reports, monitoring visit summaries, protocol amendment summaries. Version them in a central repo and distribute via Claude Code plugins.

05 · Layer 5: Hooks — deterministic automation

Hooks are the most powerful and most underused Claude Code feature. They're the difference between "Claude might follow this rule" and "this rule runs every time, no exceptions."

Hooks are shell commands, HTTP endpoints, or LLM evaluations that execute automatically at specific lifecycle events.

Key hook events for enterprise use:

Example: block destructive bash commands

In .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "if": "Bash(rm *)",
            "command": ".claude/hooks/block-destructive.sh"
          }
        ]
      }
    ]
  }
}

block-destructive.sh:

#!/bin/bash
COMMAND=$(jq -r '.tool_input.command' < /dev/stdin)
if echo "$COMMAND" | grep -qE 'rm -rf|DROP TABLE|truncate'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive operation blocked by team policy. Use --dry-run first or request manual review."
    }
  }'
else
  exit 0
fi

Example: auto-lint after file edits

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "eslint --fix",
            "args": ["${tool_input.file_path}"],
            "timeout": 30
          }
        ]
      }
    ]
  }
}

Example: load project context at session start

#!/bin/bash
# SessionStart hook — inject current git state and recent issues
BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "unknown")
RECENT=$(git log --oneline -5 2>/dev/null || echo "no git history")

jq -n --arg branch "$BRANCH" --arg recent "$RECENT" '{
  hookSpecificOutput: {
    hookEventName: "SessionStart",
    additionalContext: "Current branch: \($branch)

Recent commits:
\($recent)"
  }
}'

Biotech application for hooks: Use PreToolUse to block any bash command containing PHI patterns (name-like strings, date-of-birth formats, SSN patterns). Use PostToolUse on Write/Edit to call a PHI-detection API on newly created files. These hooks run every time — unlike CLAUDE.md instructions, they cannot be forgotten.

06 · Enterprise enforcement with managed settings

For organizations that need compliance without relying on individual developer discipline:

{
  "allowManagedHooksOnly": true,
  "enabledPlugins": ["company-approved-plugin"]
}

When allowManagedHooksOnly is true:

• User and project hooks are blocked
• Only hooks from managed settings and force-enabled plugins run
• Developers cannot override security policies

This is the correct architecture for organizations in regulated industries where audit trail and access control requirements must be enforced programmatically, not by convention.

07 · Knowledge check

Q1. Your team wants to enforce that Claude Code never writes files to the /patient-data/ directory, regardless of what individual developers configure. Which layer handles this?

a) CLAUDE.md — add an instruction stating the prohibition b) Project settings (.claude/settings.json) — commit a PreToolUse hook to the repo c) Managed settings with a PreToolUse hook and allowManagedHooksOnly: true — enforced at org level d) MCP server permissions — restrict file system access via the server config

Q2. What is the primary difference between CLAUDE.md instructions and hooks, in terms of reliability?

a) CLAUDE.md is faster to configure; hooks require shell scripting b) CLAUDE.md instructions are processed more reliably than hooks for safety-critical rules c) CLAUDE.md is probabilistic — Claude may not follow it; hooks are deterministic — they run every time d) Hooks only work for Bash tool calls; CLAUDE.md applies to all tools

Q3. A developer adds an MCP server from an open-source repository to the team Claude Code setup without security review. What is the primary risk?

a) Performance degradation — unvetted MCP servers slow down Claude Code sessions b) Compatibility issues — the MCP server may not work with the current Claude version c) The MCP server can direct Claude to execute operations that exfiltrate data or compromise systems d) Cost overruns — unvetted MCP servers may make excessive API calls

Answers: Q1: c · Q2: c · Q3: c

End of Lesson 05.