21 Claude Code Interview Questions: MCP, Skills & SDK (2026)

Claude Code combines a conversational interface with an agent loop that can inspect a repository, edit files, execute commands, and call external tools. Those capabilities make permissions, isolation, context management, verification, and human review as important as prompting. This guide covers 21 questions against the September 2026 documentation.

Table of Contents

1. Agentic Coding Fundamentals Questions
2. MCP Server Questions
3. Skills and Commands Questions
4. Agents and Subagents Questions
5. Hooks and Lifecycle Questions
6. Security and Permissions Questions
7. Claude Agent SDK Questions
8. Git Workflow Questions
9. Plugins and Skills Questions
10. Practical Scenario Questions
11. Quick Reference

Agentic Coding Fundamentals Questions

These questions test your understanding of what makes Claude Code different from traditional AI coding tools.

What is Claude Code and how does it differ from GitHub Copilot?

Claude Code is an agentic coding tool that can iterate through model responses and tool calls to complete a task. It can inspect repositories, edit files, run commands, use MCP tools, and maintain sessions, subject to the active permission mode, policies, sandbox, credentials, and user approvals.

It is inaccurate in 2026 to contrast Claude Code with GitHub Copilot as “agent versus autocomplete.” Copilot provides inline suggestions, IDE agent mode, and a cloud agent that researches repositories, edits a branch, runs checks, and can open pull requests. Product capabilities also change quickly.

Compare concrete operating models instead: local terminal versus hosted environment, supported repository hosts, available models, MCP and plugin integration, persistent instructions, permission enforcement, isolation, enterprise controls, cost, audit evidence, and the pull-request review path. A strong interview answer evaluates these requirements rather than declaring a universal winner.

# Example agentic workflow
1. User defines the goal, scope, constraints, and acceptance checks.
2. Agent inspects relevant code and proposes or selects an approach.
3. Permission controls approve, deny, or ask about tool calls.
4. Agent edits a bounded set of files and runs targeted checks.
5. User reviews the diff, test evidence, and unresolved risks.
6. A commit or pull request is created only when explicitly requested and authorized.

The key distinction is not “who types.” It is how much work is delegated, what evidence the agent can gather, which actions it may take, and where a human or policy gate remains.

What is CLAUDE.md and how should it be structured?

CLAUDE.md supplies persistent instructions and project context. Team guidance can live at ./CLAUDE.md or ./.claude/CLAUDE.md; user guidance lives at ~/.claude/CLAUDE.md, while CLAUDE.local.md is appropriate for uncommitted personal project notes. Claude also discovers nested files on demand when it accesses files in those subtrees.

Keep instructions concise, specific, consistent, and verifiable: commands that actually run, architectural boundaries, ownership rules, and validation requirements. The internal system prompt is not published. CLAUDE.md content is context that shapes behavior, not a hard enforcement mechanism; use settings, managed policy, sandboxing, permissions, and hooks for controls that must be enforced.

## Project Overview
Multi-tenant SaaS platform using Clean Architecture.
Backend: Node.js/Express with TypeScript. Database: PostgreSQL with Prisma.
Frontend: React with Vite.
 
## Development Commands
 
### Local Development
npm run dev  # Starts both frontend and backend
 
### Testing
npm test                    # Run all tests
npm test -- auth.test.ts    # Specific test file
 
### Build
npm run build  # Production build with type checking
 
## Architecture Decisions
- Use named exports, never default exports
- All API endpoints follow REST conventions
- Business logic lives in /src/domain, never in controllers
- Tests go in __tests__ directories adjacent to source files
 
## Code Conventions
- Prefer composition over inheritance
- Use early returns to reduce nesting
- No console.log in production code—use the logger

A project CLAUDE.md is normally reviewed and committed with the repository; user and local variants are not. Never place credentials in instructions or import secret-bearing files. Environment variables and .env files still require access controls because tools and subprocesses may read them.

MCP Server Questions

The Model Context Protocol is where Claude Code becomes genuinely extensible. These questions test understanding of external tool integration.

What is MCP and what transport types does Claude Code support?

MCP (Model Context Protocol) lets Claude Code discover and call tools or read resources exposed by external servers. The protocol standardizes communication; it does not make a server, its output, or the credentials supplied to it trustworthy.

MCP servers bridge Claude Code and external resources. Connecting one advertises capabilities; whether a tool call runs depends on tool permissions and policy. Even a read-only-looking tool can disclose sensitive data or return prompt-injection content, while a local server process itself may have broader host access than its MCP schema suggests.

Stdio is for a local child process communicating through standard input and output. That process runs with the user's operating-system privileges and environment unless separately sandboxed, so package provenance and argument review matter.

Streamable HTTP is the current transport for remote servers and supports OAuth authentication where the server implements it. Claude Code still supports legacy SSE, but the documentation marks SSE as deprecated and recommends HTTP where available.

WebSocket is not one of the documented Claude Code MCP transports. Do not infer transport support from a generic real-time requirement.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/directory"]
    }
  }
}

How do you configure authenticated MCP servers securely?

Prefer OAuth for remote HTTP servers where available. For configuration that must reference a local environment value, Claude Code supports ${VARIABLE_NAME} and ${VARIABLE_NAME:-default} expansion in .mcp.json. Keeping the value out of Git is necessary but insufficient: scope the credential, trust the server process, restrict available MCP servers by command or URL in managed policy, and allow only the tools the task needs.

For the current official GitHub MCP server binary with a narrowly scoped personal access token:

{
  "mcpServers": {
    "github": {
      "command": "github-mcp-server",
      "args": ["stdio"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"
      }
    }
  }
}

For HTTP-based servers requiring Bearer token authentication:

{
  "mcpServers": {
    "api-server": {
      "type": "http",
      "url": "https://api.example.com/mcp",
      "headers": {
        "Authorization": "Bearer ${API_TOKEN}",
        "X-API-Key": "${API_KEY}"
      }
    }
  }
}

Project-scoped servers are shared through .mcp.json and require user approval before use. A server name alone is not a security identity because users can rename servers; organization policy should match a remote URL or the exact stdio command and arguments. A local stdio server can read credentials passed in env, while a remote HTTP server receives configured headers, so use separate least-privilege credentials and rotate or revoke them when trust changes.

Skills and Commands Questions

Skills are the current extension mechanism for reusable instructions and invocable workflows. Legacy command files remain compatible.

How do you create custom slash commands in Claude Code?

Custom commands have been merged into skills. For new work, create .claude/skills/commit/SKILL.md at project scope or ~/.claude/skills/commit/SKILL.md at user scope; the directory name becomes /commit. Existing flat files under .claude/commands/ and ~/.claude/commands/ still work.

---
description: Stage changes and create a commit with conventional format
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git status *) Bash(git commit *) Bash(git diff *)
argument-hint: [type] [message]
---
 
Current repository status:
!`git status --short`
 
Recent commits for style reference:
!`git log -5 --oneline`
 
Staged changes:
!`git diff --staged`
 
Create a commit following these rules:
1. Type must be one of: feat, fix, docs, style, refactor, test, chore
2. Message should be imperative ("Add feature" not "Added feature")
3. Keep the subject line under 72 characters
4. Do not push or alter unrelated changes
 
Arguments supplied by the user: $ARGUMENTS

disable-model-invocation: true makes this a user-triggered workflow, appropriate for a side effect such as a commit. allowed-tools pre-approves matching tools while the skill is active; it does not remove other tools. Deny rules or an appropriately restrictive permission mode provide enforcement. The !`command` syntax runs a command before sending the expanded skill, so its output and cost must be bounded and treated as untrusted context.

What is the difference between @file and !command syntax?

These two syntaxes serve different purposes. @file includes the contents of a file directly in the prompt—@src/config.js would inject the JavaScript source code. !`command` executes a shell command and includes its output—!`git status` would run git status and inject the result.

Use @file for a deliberate file import and !`command` for dynamic context such as current Git state. Both can disclose data or inject misleading instructions, so review project skills before granting workspace trust and keep command output narrowly scoped.

Agents and Subagents Questions

Understanding the agent system is essential for productive Claude Code usage. These questions test knowledge of task delegation.

What is the difference between Claude Code skills and subagents?

Skills are reusable Markdown instructions with optional scripts, references, assets, frontmatter, and invocation controls. By default, the user can invoke a skill with /name and Claude can load it when its description matches; disable-model-invocation or user-invocable changes that behavior.

Subagents receive a delegated task in a separate context window with their own system prompt, tool surface, model choice, and inherited or configured permissions. They are useful when search output or a specialist workflow would pollute the main context. Separate context is not separate infrastructure: unless worktree isolation or another boundary is configured, concurrent agents may still touch the same files and services.

A skill can also declare context: fork to run through a subagent. Conversely, a custom subagent can preload selected skills. Choose from context ownership and enforcement needs, not from a slogan that every long task deserves parallelism.

What is the Explore subagent and when does it activate?

Explore is a built-in, read-only subagent optimized for fast codebase search and analysis. The documentation describes its model class as Haiku rather than promising a fixed dated model version. Claude may delegate suitable exploration to it and can specify quick, medium, or very thorough search depth.

For questions such as “how does our authentication middleware work?” or “find all deprecated API calls,” Explore can discover files and return a focused summary without filling the main context with every read. Its built-in policy denies write and edit tools; do not memorize an incidental list of shell utilities as the API contract.

This preserves main-context capacity and routes read-only discovery to a lower-latency model. The returned summary is still model output: verify important claims against the files before changing code.

How do background agents enable parallel work?

Claude Code now exposes several different concurrency models: subagents that report into one session, background sessions in Agent view, agent teams, and isolated worktree sessions. Select the model based on coordination and filesystem isolation rather than treating all of them as equivalent “background agents.”

Imagine you're implementing a feature that requires understanding a third-party API's authentication flow:

1. Spawn a research agent to explore the API documentation
2. Give it a bounded deliverable and no overlapping file ownership
3. Continue only on work that does not depend on its unresolved findings
4. Reconcile and verify its result before using it

Use /agents to inspect subagents in the current session and /tasks for background work in that session. The claude agents command opens Agent view for separate background sessions; /bg detaches the current conversation. Concurrent editing needs explicit file ownership or worktree isolation because shared working directories can conflict.

Hooks and Lifecycle Questions

Hooks are Claude Code's extension points for injecting custom behavior. Security-conscious organizations care deeply about this system.

What lifecycle events are available in Claude Code hooks?

Claude Code exposes many lifecycle events, including SessionStart, UserPromptSubmit, PreToolUse, PermissionRequest, PostToolUse, PostToolUseFailure, SubagentStart, SubagentStop, PreCompact, Stop, and SessionEnd. The current reference is the source of truth. Handlers can be commands, HTTP endpoints, prompts, agents, or MCP tools, with event-specific support.

Here is an illustrative PreToolUse hook that blocks a matching Write or Edit call before the tool runs:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/prevent-secrets.sh"
          }
        ]
      }
    ]
  }
}

The hook script scans for patterns like AWS keys, GitHub tokens, or private key headers:

#!/bin/bash
INPUT=$(cat)
FILE_CONTENT=$(printf '%s' "$INPUT" | jq -r \
  '.tool_input.content // .tool_input.new_string // empty')
 
# Secret patterns
if echo "$FILE_CONTENT" | grep -qE 'AKIA[0-9A-Z]{16}|ghp_[0-9a-zA-Z]{36}|-----BEGIN.*PRIVATE KEY-----'; then
    echo "Blocked: potential secret detected; run the repository scanner" >&2
    exit 2
fi
 
exit 0

Command hooks receive event JSON on stdin, not positional argument $2. For a blockable PreToolUse event, exit code 2 blocks and stderr becomes feedback; other non-zero codes are hook errors and generally do not block. The regex above is illustrative and will have false positives and negatives—use a maintained secret scanner and repository-side checks as independent controls.

How does CLAUDE_ENV_FILE enable dynamic configuration?

During SessionStart, CLAUDE_ENV_FILE points to a file where a command hook can append shell export statements for subsequent Bash commands. It is not a general-purpose secret store, and the hook should quote values rather than interpolate untrusted project content as shell syntax.

A common use case is session initialization that detects project type and configures appropriate variables:

#!/bin/bash
# .claude/hooks/session-start.sh
 
if [ -z "$CLAUDE_ENV_FILE" ]; then
    exit 0
fi
 
# Detect project type
if [ -f "${CLAUDE_PROJECT_DIR}/package.json" ]; then
    printf '%s\n' 'export NODE_PROJECT=true' >> "$CLAUDE_ENV_FILE"
fi
 
if [ -f "${CLAUDE_PROJECT_DIR}/pyproject.toml" ]; then
    printf '%s\n' 'export PYTHON_PROJECT=true' >> "$CLAUDE_ENV_FILE"
fi

This exports two facts to later Bash commands. If Claude itself needs explanatory context, return additionalContext from the hook or place stable project facts in CLAUDE.md; environment variables alone do not guarantee the model will infer the intended workflow.

Security and Permissions Questions

Security questions are increasingly common as companies deploy AI tools with real system access. These questions test awareness of implications.

How should you apply the principle of least privilege in plugin development?

Treat a plugin as executable supply-chain input: it can package skills, agents, hooks, MCP/LSP servers, binaries, and other behavior. Inspect its source and publisher, pin or govern distribution, minimize credentials available to its processes, and test it in a sandboxed, non-production environment before enabling it broadly.

{
  "permissions": {
    "allow": [
      "Grep",
      "Read(./src/**)",
      "mcp__github__get_issue"
    ],
    "ask": ["Bash(git push *)"],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Permission rules belong in Claude Code settings rather than inside an MCP server definition. Rules evaluate deny, then ask, then allow. An allow rule pre-approves a call; it does not remove every unlisted tool, so use deny rules, managed settings, sandbox controls, or a locked-down SDK permissionMode: "dontAsk" configuration when you need an actual boundary. For MCP governance, match trusted servers by URL or exact stdio command—not only by a user-chosen server name.

How do you prevent path traversal attacks in Claude Code plugins?

Rejecting the literal text .. or checking a raw string prefix is not enough. Normalize path syntax, resolve existing paths and allowed roots through the filesystem, use path.relative for containment, and account for symlinks, junctions, case rules, non-existing write targets, and time-of-check/time-of-use races. Enforce the boundary with operating-system permissions or a sandbox as well as application validation.

const path = require('path');
const fs = require('fs');
 
const ALLOWED_ROOTS = [
  '/home/user/projects/my-repo',
  '/home/user/documents/safe-data'
].map(root => fs.realpathSync(root));
 
function isPathAllowed(requestedPath) {
  // This example is for an existing read target.
  const candidate = fs.realpathSync(requestedPath);
 
  return ALLOWED_ROOTS.some(root => {
    const relative = path.relative(root, candidate);
    return relative === '' ||
      (relative !== '..' &&
       !relative.startsWith(`..${path.sep}`) &&
       !path.isAbsolute(relative));
  });
}

For new files, validate the real parent directory and then open with platform-appropriate anti-symlink controls where available. A check followed by a separate open can still race. Also remember that installed marketplace plugins are copied to a cache and cannot rely on paths traversing outside the plugin root; use CLAUDE_PLUGIN_ROOT for bundled files and CLAUDE_PLUGIN_DATA for persistent plugin state.

Claude Agent SDK Questions

For developers building AI-powered applications, these questions test whether you can move from using Claude Code to building with it.

What are the two official Claude Agent SDKs?

The Agent SDK is officially available for Python (claude-agent-sdk) and TypeScript (@anthropic-ai/claude-agent-sdk). Both embed the Claude Code agent loop and expose tools, sessions, permissions, hooks, MCP, and subagents. Use the Client SDK instead if you want direct Messages API access and will implement the tool loop yourself.

Python:

import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions
 
async def main():
    options = ClaudeAgentOptions(
        allowed_tools=["Read", "Glob", "Grep"],
        permission_mode="dontAsk",
    )
    async for message in query(
        prompt="Analyze this codebase and report risks without editing files",
        options=options,
    ):
        print(message)
 
asyncio.run(main())

TypeScript:

import { query } from '@anthropic-ai/claude-agent-sdk';
 
for await (const message of query({
  prompt: 'Analyze this codebase and report risks without editing files',
  options: {
    allowedTools: ['Read', 'Glob', 'Grep'],
    permissionMode: 'dontAsk'
  }
})) {
  console.log(message);
}

query() is convenient for a one-off exchange and returns an async stream of messages. Use ClaudeSDKClient for a connected, multi-turn conversation or when you need interrupts. allowedTools pre-approves tools; paired with dontAsk above, unlisted calls are denied instead of prompting in a headless process. Always handle result and error message types, cancellation, budgets, timeouts, session storage, and partial side effects.

How should API keys be stored securely for the SDK?

For local development, inject ANTHROPIC_API_KEY through the process environment; a gitignored .env file is a convenience, not a production secret manager. In CI or production, use the platform's secret store or workload identity path supported by the target provider, scope access to the service, rotate credentials, and prevent logs or agent-readable files from exposing them.

# .env (NEVER COMMITTED)
ANTHROPIC_API_KEY=replace-locally
 
# .env.example (COMMITTED)
ANTHROPIC_API_KEY=your-api-key-here

# .gitignore
.env
.env.local
*.local.json

Add .env and variants to .gitignore, but also deny agent reads of those paths in .claude/settings.json, scan commits, and revoke a value immediately if it reaches Git history. The SDK reads supported authentication from its environment; do not invent constructor parameters that are absent from the current API.

Git Workflow Questions

Claude Code's git integration is one of its most practical features for daily development. These questions test understanding of automated workflows.

How does Claude Code automate commit and PR creation?

When asked and permitted, Claude Code can inspect status and diffs, stage a selected set of paths, draft a commit message in repository style, run checks, and use a hosting CLI such as gh to open a pull request. These are tool calls, not an unconditional built-in transaction: the exact commands, approvals, credentials, branch rules, and available CLIs determine what happens.

Before committing, it should inspect the complete diff and recent history without staging unrelated user changes:

git log -20 --pretty=format:'%s'

History can reveal conventions such as prefixes, scope, mood, and capitalization. The user should still review the staged diff and message, and a commit must not imply that tests passed unless they actually ran successfully.

Attribution behavior is configurable and can change; it is not a semantic requirement of Git. Follow the repository's authorship policy and never rewrite, push, force-push, or open a pull request merely because the working tree appears ready.

Plugins and Skills Questions

The plugin and skills architecture is where Claude Code becomes genuinely extensible. These questions test understanding of the extension model.

What is the Skills system and how does it differ from slash commands?

Skills are reusable instructions or workflows packaged around a SKILL.md file with optional scripts, references, assets, and configuration. Custom commands have been merged into skills: both a legacy .claude/commands/review.md file and .claude/skills/review/SKILL.md can expose /review, but the directory form supports more capabilities and is recommended for new work.

By default, both the user and Claude may invoke a skill. Claude sees model-invocable skill names and descriptions, while the body loads when invoked. Use disable-model-invocation: true for side effects such as deploy or send-message; use user-invocable: false for model-only knowledge. allowed-tools pre-approves rather than restricts tools, and context: fork runs the skill in a subagent.

A skill structure:

my-skill/
├── SKILL.md          # Required: Core instructions with YAML frontmatter
├── scripts/          # Optional: Helper scripts
├── references/       # Optional: Detailed documentation
└── assets/           # Optional: Templates, data files

What is CLAUDE_PLUGIN_ROOT and why is it important?

CLAUDE_PLUGIN_ROOT resolves bundled files relative to the installed plugin version. It matters because marketplace plugins are copied into a per-version cache instead of running from their source checkout.

Use it in hook and MCP configuration rather than assuming a developer checkout or current working directory. Use ${CLAUDE_PLUGIN_DATA} for persistent state that must survive plugin updates and ${CLAUDE_PROJECT_DIR} for the active project root.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PLUGIN_ROOT}/scripts/format-code.sh"
          }
        ]
      }
    ]
  }
}

Installed plugins cannot depend on ../ paths outside their packaged root because those files are not copied into the cache. Environment variables solve path resolution, not trust: users and administrators should still review plugin components, executable code, credentials, and update policy.

Practical Scenario Questions

These questions test ability to apply knowledge to realistic situations.

How would you create a test-build-release workflow?

Create a user-only skill with explicit preconditions, verification, artifact identity, and approval before externally visible or hard-to-reverse actions:

---
description: Execute complete release workflow
disable-model-invocation: true
allowed-tools: Bash(npm test) Bash(npm run build) Bash(git status *) Bash(git diff *)
argument-hint: [major|minor|patch]
---
 
# Release Workflow
 
Execute these steps in strict sequence. Stop immediately if any step fails.
 
## Pre-flight Checks
1. Verify the release branch matches repository policy
2. Verify working directory is clean
3. Fetch and verify the expected upstream state without overwriting local work
4. Read the release policy, changelog, and version source
 
## Test Suite
1. Execute `npm test`
2. If ANY tests fail, STOP and report
 
## Build
1. Run `npm run build`
2. Verify build artifacts, record their digests, and retain test evidence
 
## Version and Release
1. Present the proposed version, changelog, tag, artifacts, and exact commands
2. Obtain explicit approval before changing the version, pushing, or creating a release
3. Run each approved step once and verify the remote result before retrying
 
If any step fails, report the error and DO NOT continue.

The key principles are explicit ordering, idempotent checks, a clean ownership boundary, fail-fast validation, immutable artifacts, and a human gate for publication. allowed-tools is pre-approval, not a capability allowlist, so keep mutating remote commands out of it unless organizational policy deliberately permits them.

How would you debug a failing MCP server connection?

Follow a systematic approach:

1. Run claude mcp list, inspect the server with claude mcp get <name>, and use /mcp for connection and OAuth status
2. Validate JSON, scope precedence (local, project, user, plugin, connector), command arguments, URL, and environment expansion
3. For stdio, run the server independently and keep protocol stdout free of logs; send diagnostics to stderr
4. Enable bounded server-specific logging without printing credentials:

{
  "mcpServers": {
    "my-server": {
      "command": "node",
      "args": ["dist/index.js", "--debug"],
      "env": {
        "DEBUG": "*",
        "LOG_LEVEL": "debug"
      }
    }
  }
}

5. Inspect Claude Code debug output and server stderr, then confirm protocol and tool negotiation
6. For HTTP, check TLS, proxy/DNS, status codes, OAuth discovery/callback configuration, and server logs without copying bearer tokens into shell history

Common causes include an unset variable without a default, wrong option order in claude mcp add, an untrusted project server awaiting approval, stdout contamination in stdio, a deprecated SSE endpoint, OAuth callback mismatch, or a server that advertises tools but exposes none. Increase timeouts only after identifying actual startup latency; a larger timeout does not fix protocol or authentication errors.

How would you implement standardized code reviews with Claude Code?

Create a review skill that codifies evidence requirements and separates blocking findings from suggestions. The checklist should be adapted to the repository rather than treated as proof that a review is complete:

---
description: Review code with team standards
disable-model-invocation: true
allowed-tools: Bash(git diff *) Bash(git status *) Read Grep
---
 
# Team Code Review Checklist
 
## Architecture
- [ ] Follows layered architecture
- [ ] Proper separation of concerns
 
## Code Quality
- [ ] Functions are single-purpose
- [ ] No magic numbers
 
## Security
- [ ] No hardcoded secrets
- [ ] Input validation present
 
Provide: required changes (blocking) and suggestions (non-blocking)

For automated pull-request review, use the maintained Claude Code Action with minimum GitHub and Claude tool permissions. The following is a readable sketch; pin every action to a reviewed full commit SHA in production:

name: Automated Code Review
on:
  pull_request:
    types: [opened, synchronize]
 
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v7
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Review only the pull-request diff. Report evidence-backed findings
            and post review feedback; do not modify files or push commits.

Treat pull-request content as untrusted input. Avoid executing contributed code with secrets, restrict App installation permissions as well as GITHUB_TOKEN, account for fork-secret behavior, cap time and cost, and require human review. An LLM review supplements deterministic tests, linters, scanners, ownership rules, and branch protection; it does not replace them.

Quick Reference

Frequently Asked Questions

What is Claude Code and how does it differ from GitHub Copilot?

Claude Code is an agentic coding tool that can inspect repositories, edit files, run commands, and use external tools under configured permissions. GitHub Copilot also has IDE and cloud agents, so the useful comparison is the execution surface, repository host, models, extension system, isolation, governance, and review workflow—not agent versus autocomplete.

What is CLAUDE.md and where should it be placed?

CLAUDE.md supplies persistent instructions and context. Team guidance belongs in ./CLAUDE.md or ./.claude/CLAUDE.md, personal guidance in ~/.claude/CLAUDE.md or CLAUDE.local.md, and nested files load when Claude accesses their subtree. Keep instructions concise and verifiable; CLAUDE.md influences behavior but is not a security enforcement layer.

What is MCP (Model Context Protocol) in Claude Code?

MCP is a protocol through which Claude Code can use external tools and data. Local servers normally use stdio and remote servers use streamable HTTP with OAuth where supported. Legacy SSE remains available but is deprecated; WebSocket is not a documented Claude Code MCP transport. Every server and tool remains a trust and permission boundary.

What is the difference between Claude Code skills and subagents?

A skill is reusable Markdown guidance or a workflow loaded into the current context by the user or model, with optional supporting files and invocation controls. A subagent runs a delegated task in its own context with a system prompt, tools, model, and permissions. A skill can also use context: fork to execute through a subagent.

What are hooks in Claude Code?

Hooks run configured commands, HTTP handlers, prompts, agents, or MCP tools at lifecycle events such as SessionStart, PreToolUse, PermissionRequest, PostToolUse, Stop, and SubagentStop. Command hooks receive JSON on stdin. Only supported pre-action events can block, and exit code 2 has event-specific behavior, so hooks need strict input handling, timeouts, and least privilege.

What are the official Claude Code SDKs?

The Claude Agent SDK is officially available for Python as claude-agent-sdk and TypeScript as @anthropic-ai/claude-agent-sdk. Both expose the Claude Code agent loop, tools, sessions, permissions, hooks, MCP, and subagents, but their APIs and message types are language-specific and should be checked against the current reference.

Sources

• How Claude Code works
• How Claude remembers your project
• Connect Claude Code to tools via MCP
• Official GitHub MCP Server for Claude Code
• Extend Claude with skills
• Create custom subagents
• Run agents in parallel
• Hooks reference
• Claude Code settings
• Configure permissions
• Plugins reference
• Claude Agent SDK overview
• Python Agent SDK reference
• TypeScript Agent SDK reference
• Claude Code Action
• About GitHub Copilot cloud agent

Related Articles

• System Design Interview Guide - Scalability, reliability, and distributed systems
• TypeScript Type vs Interface - When to use type aliases vs interfaces