# https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know Project Manual
Generated at: 2026-07-15 01:05:02 UTC
## Table of Contents
- [Overview and Claude Code Setup](#page-1)
- [Skills and Slash Commands](#page-2)
- [Hooks System and Lifecycle Events](#page-3)
- [Subagents and Agent Teams](#page-4)
- [Specialized Agent Library](#page-5)
- [MCP Servers and External Integrations](#page-6)
- [Configuration, Models, and Reference](#page-7)
## Overview and Claude Code Setup
### Related Pages
Related topics: [Skills and Slash Commands](#page-2), [Configuration, Models, and Reference](#page-7)
Related Source Files
The following source files were used to generate this page:
- [README.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/README.md)
- [CONTRIBUTING.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/CONTRIBUTING.md)
- [LICENSE](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/LICENSE)
- [CHANGELOG.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/CHANGELOG.md)
- [docs/setup.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/docs/setup.md)
- [docs/overview.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/docs/overview.md)
- [Images/claude-jumping.svg](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/Images/claude-jumping.svg)
# Overview and Claude Code Setup
## Purpose and Scope of the Repository
The repository `wesammustafa/Claude-Code-Everything-You-Need-to-Know` functions as a community-curated knowledge base and onboarding guide for Anthropic's **Claude Code** — an agentic command-line developer tool that brings Claude directly into a terminal workflow. Its stated goal is to consolidate installation steps, configuration patterns, best practices, and troubleshooting tips into a single navigable document so that engineers can move from "zero" to productive Claude Code usage quickly. Source: [README.md:1-40]().
The project targets developers who already work inside a shell and want to delegate coding tasks (refactors, file edits, multi-step commands, repo exploration) to a model-driven agent without leaving the terminal. It explicitly frames itself as a "living" guide, inviting pull requests and corrections through its contributor workflow. Source: [CONTRIBUTING.md:1-25]().
## High-Level Architecture of the Knowledge Base
The repository is intentionally lightweight: a top-level `README.md` acts as the table of contents and entry point, while a `docs/` directory contains deep-dive pages, and an `Images/` folder holds illustrative assets such as `claude-jumping.svg`, which is used as the project's logo. A `CHANGELOG.md` tracks meaningful updates, and `LICENSE` defines reuse terms. Source: [README.md:42-70](), [CHANGELOG.md:1-15]().
| File / Path | Role |
|---|---|
| `README.md` | Landing page, summary, and navigation |
| `docs/overview.md` | Conceptual introduction to Claude Code |
| `docs/setup.md` | Installation and environment configuration |
| `CONTRIBUTING.md` | Rules for proposing changes |
| `CHANGELOG.md` | Versioned history of documentation updates |
| `LICENSE` | Reuse and distribution terms |
This separation keeps conceptual content (`overview.md`) distinct from procedural content (`setup.md`), which makes the guide easier to maintain.
## Claude Code Setup Workflow
Setup is presented as a linear, four-step pipeline. Each step has a clear pre-condition and produces a verifiable artifact.
```mermaid
flowchart LR
A[Install Claude Code CLI] --> B[Authenticate with Anthropic API]
B --> C[Initialize project with CLAUDE.md]
C --> D[Run first agentic task]
```
### 1. Install the CLI
The guide recommends installing the Claude Code CLI via the official installer for the host operating system. On macOS and Linux this is typically done through the `curl`-based install script that places the `claude` binary on the user's `PATH`. After installation, `claude --version` should return a non-error response. Source: [docs/setup.md:1-30]().
### 2. Authenticate
Authentication requires an Anthropic API key. The key is provided either via the `ANTHROPIC_API_KEY` environment variable or through an interactive `claude login` flow. The setup doc warns that keys should never be committed to version control. Source: [docs/setup.md:32-60]().
### 3. Initialize the Project
A `CLAUDE.md` file at the repository root serves as persistent project context: it tells the agent about the codebase, conventions, and allowed tools. The overview page stresses that a well-written `CLAUDE.md` materially improves agent accuracy because it anchors every subsequent prompt. Source: [docs/overview.md:20-55]().
### 4. Run a First Task
With the binary installed, credentials in place, and `CLAUDE.md` populated, the user can launch an interactive session with `claude` and issue a first prompt such as "summarize this repo" to verify end-to-end behavior. Source: [docs/setup.md:62-80]().
## Community Signals and Known Quirks
The repository's issue tracker surfaces practical feedback. Issue **#6 ("TEST WIX")**, now closed, originated as a low-engagement test ticket; it does not indicate a real bug but illustrates that the tracker has historically been used for sanity checks rather than substantive defect reports. Readers should rely on `CHANGELOG.md` for authoritative updates rather than on stray test issues. Source: [CHANGELOG.md:1-15](), community_context — Issue #6.
## Conventions for Contributing
`CONTRIBUTING.md` defines the review standards: pull requests should cite a source line where possible, avoid speculative features, and preserve the document's tone, which is concise and direct. Source: [CONTRIBUTING.md:10-35]().
## Summary
In short, the repository is a focused onboarding manual: `README.md` orients the reader, `docs/overview.md` explains the conceptual model, `docs/setup.md` walks through installation, authentication, and initialization, and the contributor docs keep the knowledge base trustworthy as Claude Code itself evolves.
---
## Skills and Slash Commands
### Related Pages
Related topics: [Hooks System and Lifecycle Events](#page-3), [Configuration, Models, and Reference](#page-7)
Related Source Files
The following source files were used to generate this page:
- [.claude/commands/pr.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/commands/pr.md)
- [.claude/commands/review.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/commands/review.md)
- [.claude/commands/tdd.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/commands/tdd.md)
- [.claude/commands/test.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/commands/test.md)
- [.claude/commands/five.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/commands/five.md)
- [.claude/commands/ux.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/commands/ux.md)
# Skills and Slash Commands
## Overview
Slash commands are a core customization feature of Claude Code that let users invoke reusable, parameterized prompts directly from the chat input by typing a leading `/`. Each slash command is defined as a standalone Markdown file inside the `.claude/commands/` directory of a project. The Markdown body becomes the prompt that Claude Code expands when the user invokes the command, allowing teams to standardize recurring workflows (PR creation, code review, test writing, UX critique, etc.) without re-typing them.
In this repository, the `.claude/commands/` directory ships six ready-to-use commands that demonstrate how to package team knowledge as invocable skills: `pr`, `review`, `tdd`, `test`, `five`, and `ux` (`Source: [.claude/commands/pr.md]()`).
## Command Discovery and File Structure
Claude Code discovers commands by scanning `.claude/commands/*.md`. The file's basename (without the `.md` extension) becomes the command's invocation name, so `.claude/commands/review.md` is triggered by typing `/review` in the Claude Code chat. This convention is consistent across the six files shipped in this repo, where each filename is a verb or noun that describes a single, focused action:
| File | Invocation | Purpose |
|------|-----------|---------|
| `.claude/commands/pr.md` | `/pr` | Draft pull request description and metadata |
| `.claude/commands/review.md` | `/review` | Run a structured code review |
| `.claude/commands/tdd.md` | `/tdd` | Drive a test-first development loop |
| `.claude/commands/test.md` | `/test` | Generate or run tests |
| `.claude/commands/five.md` | `/five` | Apply the "five whys" or similar lightweight analysis |
| `.claude/commands/ux.md` | `/ux` | Critique user experience of a feature or flow |
Because every command is plain Markdown, teams can version them alongside code, edit them with any text editor, and review changes through the normal pull-request workflow.
## Anatomy of a Slash Command
Each Markdown file under `.claude/commands/` follows the same minimal shape:
1. **Front matter (optional)** — YAML at the top can declare the command's description, allowed arguments, and any tool restrictions.
2. **Prompt body** — The Markdown content below the front matter is treated as the system/user prompt that Claude Code sends to the model when the command runs.
3. **Placeholder arguments** — `$ARGUMENTS`, `$1`, `$2`, etc., are substituted from whatever the user types after the command name, letting a single command adapt to context (for example, `/review src/auth/login.ts`).
This means a slash command is essentially a parameterized template: the author writes it once, and every team member invokes it the same way, getting consistent behavior across the codebase (`Source: [.claude/commands/tdd.md]()`).
## Workflow: From Invocation to Output
```mermaid
flowchart LR
A[User types /command args] --> B[Claude Code loads .claude/commands/command.md]
B --> C[Substitutes $ARGUMENTS / $1, $2, ...]
C --> D[Sends expanded prompt to Claude]
D --> E[Claude executes task and returns result]
E --> F[Result rendered in chat]
```
The flow above applies uniformly to every command shipped in this repository. For example, invoking `/test` loads `.claude/commands/test.md`, expands any placeholders with the user's arguments, and asks Claude to perform the testing workflow described in that file (`Source: [.claude/commands/test.md]()`). The `/pr` command follows the same path but specializes the prompt for pull-request generation (`Source: [.claude/commands/pr.md]()`), and `/review` specializes it for code review (`Source: [.claude/commands/review.md]()`).
## The Shipped Skills
### `/pr` — Pull Request Authoring
`.claude/commands/pr.md` packages the workflow of writing a PR description, summarizing diffs, and proposing a title. It is the team's shared template so that every PR opened through Claude Code has a consistent format (`Source: [.claude/commands/pr.md]()`).
### `/review` — Code Review
`.claude/commands/review.md` defines a structured review checklist that Claude applies to the code under inspection. By externalizing the review rubric into a file, the team ensures the same quality criteria are applied on every invocation (`Source: [.claude/commands/review.md]()`).
### `/tdd` — Test-Driven Development
`.claude/commands/tdd.md` encodes the red-green-refactor loop: write a failing test, implement the minimum code to pass, then refactor. The command guides Claude step-by-step through the cycle for a given feature (`Source: [.claude/commands/tdd.md]()`).
### `/test` — Test Generation and Execution
`.claude/commands/test.md` is a lighter-weight companion to `/tdd`, focused on producing or running tests for an existing change rather than driving a full TDD cycle (`Source: [.claude/commands/test.md]()`).
### `/five` — Lightweight Analysis
`.claude/commands/five.md` provides a short, focused analysis routine (commonly a "five whys"-style decomposition) for quickly understanding the root cause of a problem or the shape of a task (`Source: [.claude/commands/five.md]()`).
### `/ux` — UX Critique
`.claude/commands/ux.md` asks Claude to evaluate a feature or flow from a user-experience perspective, surfacing friction points and improvement opportunities (`Source: [.claude/commands/ux.md]()`).
## Authoring Your Own Skills
To add a new slash command to this project, create a Markdown file under `.claude/commands/` whose filename matches the desired invocation name. Reuse one of the shipped files as a template, replace the prompt body with your workflow, and commit. Because commands are plain files, they are easy to fork per-team: a `frontend` team might add `.claude/commands/a11y.md`, while a `platform` team adds `.claude/commands/incident.md`, without touching the others.
## Community Notes
The repository's open issue tracker shows very low engagement so far; the only closed issue (#6, "TEST WIX") is a placeholder and does not describe a real bug or feature request related to slash commands (`Source: [issues/6]()`). As adoption grows, this section should be updated with user-reported limitations (for example, how `$ARGUMENTS` are parsed or how commands interact with subagents), drawing directly from new community evidence.
---
## Hooks System and Lifecycle Events
### Related Pages
Related topics: [Skills and Slash Commands](#page-2), [Configuration, Models, and Reference](#page-7)
Related Source Files
The following source files were used to generate this page:
- [.claude/hooks/pre_tool_use.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/pre_tool_use.py)
- [.claude/hooks/post_tool_use.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/post_tool_use.py)
- [.claude/hooks/notification.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/notification.py)
- [.claude/hooks/stop.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/stop.py)
- [.claude/hooks/subagent_stop.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/subagent_stop.py)
- [.claude/hooks/utils/tts/elevenlabs_tts.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/utils/tts/elevenlabs_tts.py)
# Hooks System and Lifecycle Events
The repository ships a collection of lifecycle hooks under the `.claude/hooks/` directory that let users attach Python scripts to specific moments in Claude Code's execution loop. Each hook is an independently runnable Python entry point that Claude invokes at a defined point — before a tool runs, after a tool runs, when a notification is emitted, when the main agent stops, or when a subagent stops. The hooks form a lightweight, event-driven extension layer that sits alongside Claude's tool-use pipeline and agent orchestration.
## Hook Events Overview
The `.claude/hooks/` directory contains one module per lifecycle event. Each module is expected to be self-contained and receive its input through standard input as JSON, matching Claude Code's hook contract.
- `pre_tool_use.py` — executes immediately before any tool invocation, giving users a chance to inspect, transform, or block the pending call. Source: [.claude/hooks/pre_tool_use.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/pre_tool_use.py)()
- `post_tool_use.py` — runs after a tool finishes, useful for logging, post-processing results, or triggering downstream side effects. Source: [.claude/hooks/post_tool_use.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/post_tool_use.py)()
- `notification.py` — fired when Claude Code emits a notification (for example, an attention prompt or status update). Source: [.claude/hooks/notification.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/notification.py)()
- `stop.py` — invoked when the main agent loop terminates, suitable for cleanup or final reporting. Source: [.claude/hooks/stop.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/stop.py)()
- `subagent_stop.py` — sibling of `stop.py`, but scoped to a subagent finishing rather than the top-level agent. Source: [.claude/hooks/subagent_stop.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/subagent_stop.py)()
## Lifecycle Flow
Hooks are dispatched at well-defined checkpoints in Claude Code's run loop. The diagram below summarizes the order in which the configured hooks fire relative to a tool invocation and the surrounding agent lifecycle.
```mermaid
flowchart LR
A[Agent Loop] --> B[pre_tool_use.py]
B --> C[Tool Execution]
C --> D[post_tool_use.py]
D --> A
A -->|notification| E[notification.py]
A -->|main agent ends| F[stop.py]
A -->|subagent ends| G[subagent_stop.py]
```
The pairing of `pre_tool_use.py` and `post_tool_use.py` brackets every tool call, while `notification.py`, `stop.py`, and `subagent_stop.py` cover asynchronous and termination events. Source: [.claude/hooks/pre_tool_use.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/pre_tool_use.py)(), [.claude/hooks/post_tool_use.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/post_tool_use.py)(), [.claude/hooks/notification.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/notification.py)()
## Shared Utilities
To keep hook scripts focused on event logic, reusable helpers live under `.claude/hooks/utils/`. The `utils/tts/` subdirectory currently exposes an ElevenLabs-backed text-to-speech helper, `elevenlabs_tts.py`, which any of the lifecycle hooks can import to render spoken feedback (for example, announcing a stop event or a notification aloud). Source: [.claude/hooks/utils/tts/elevenlabs_tts.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/utils/tts/elevenlabs_tts.py)()
Hook authors are expected to import from this path rather than reimplement integration code, keeping the top-level hook modules thin and declarative.
## Reference: Hook Matrix
| Hook File | Trigger Point | Typical Use |
|---|---|---|
| `pre_tool_use.py` | Before each tool call | Validation, mutation, blocking |
| `post_tool_use.py` | After each tool call | Logging, follow-up actions |
| `notification.py` | On system notification | UI feedback, audio alerts |
| `stop.py` | Main agent termination | Cleanup, final summary |
| `subagent_stop.py` | Subagent termination | Scoped cleanup, telemetry |
Sources for the matrix entries: [.claude/hooks/pre_tool_use.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/pre_tool_use.py)(), [.claude/hooks/post_tool_use.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/post_tool_use.py)(), [.claude/hooks/notification.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/notification.py)(), [.claude/hooks/stop.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/stop.py)(), [.claude/hooks/subagent_stop.py](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/hooks/subagent_stop.py)()
## Community Notes
Repository issue tracking does not currently surface hook-specific bugs. The single closed issue on record ([#6](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/issues/6), titled "TEST WIX") is a placeholder and unrelated to the hooks system. Readers evaluating this module should rely on the source files cited above as the authoritative reference.
---
## Subagents and Agent Teams
### Related Pages
Related topics: [Specialized Agent Library](#page-5)
Related Source Files
The following source files were used to generate this page:
- [.claude/agents/coder-reviewer.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/agents/coder-reviewer.md)
- [.claude/agents/frontend-engineer.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/agents/frontend-engineer.md)
- [.claude/agents/project-manager.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/agents/project-manager.md)
- [.claude/agents/tech-lead-architect.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/agents/tech-lead-architect.md)
- [.claude/agents/ux-designer.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/agents/ux-designer.md)
- [specialized-agents/agent-creation-workflow.canvas](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/specialized-agents/agent-creation-workflow.canvas)
# Subagents and Agent Teams
## Purpose and Scope
Subagents are scoped, role-specific Claude Code personas defined as standalone Markdown configuration files under `.claude/agents/`. Each file declares a single specialist (for example a reviewer, engineer, or architect) that the main Claude Code session can delegate work to instead of solving every task with the generic assistant. The repository ships a pre-built "team" of five such specialists, illustrating how to compose a multi-role workforce from independent agent definitions.
The `.claude/agents/` directory is the canonical location Claude Code reads at runtime to discover subagents, so adding, renaming, or removing a Markdown file in that folder directly changes which roles are available to the host session. `Source: [.claude/agents/coder-reviewer.md]()` and `Source: [.claude/agents/frontend-engineer.md]()` are part of this discovery surface, alongside the project-manager, tech-lead-architect, and ux-designer files.
## The Bundled Agent Roster
The repository's bundled team covers the main phases of a software project — review, implementation, planning, architecture, and design — so a single Claude Code session can hand off to the right specialist depending on the task at hand.
| Agent File | Role |
|---|---|
| `coder-reviewer.md` | Code review specialist — audits changes for correctness, style, and regressions |
| `frontend-engineer.md` | UI implementation specialist — builds client-side features and components |
| `project-manager.md` | Planning specialist — breaks work into tasks, tracks scope and status |
| `tech-lead-architect.md` | Architecture specialist — makes structural and cross-cutting technical decisions |
| `ux-designer.md` | Design specialist — owns user experience, interaction, and visual concerns |
`Source: [.claude/agents/coder-reviewer.md]()`, `Source: [.claude/agents/frontend-engineer.md]()`, `Source: [.claude/agents/project-manager.md]()`, `Source: [.claude/agents/tech-lead-architect.md]()`, and `Source: [.claude/agents/ux-designer.md]()` together form the shipped team. Because each role lives in its own file, you can adopt the whole team, drop the roles you don't need, or duplicate one as a starting point for a new specialist.
## Structure of an Agent Definition
Although each agent file encodes a different persona, they share the same shape: a Markdown document with a small YAML-style header that declares metadata (such as `name`, `description`, and the `tools` the agent is allowed to use), followed by a free-form system prompt body that defines the agent's behavior, responsibilities, and constraints. The header is what Claude Code parses to register the subagent; the body is the instruction set the model follows once that subagent is invoked.
This split matters because it separates **capability** (which tools the subagent may call, declared in the front matter) from **persona** (how it reasons, prioritizes, and responds, declared in the body). For example, a `coder-reviewer` would typically be restricted to read-only tools so it cannot "fix" code on its own, while a `frontend-engineer` would be granted file-editing tools. The exact field names and values are encoded in each file — for instance, `Source: [.claude/agents/coder-reviewer.md]()` and `Source: [.claude/agents/tech-lead-architect.md]()` are good references for the read-only vs. read-write split. To author a new specialist, copy one of the existing files, change the header fields, and rewrite the body; no separate registration step is required.
## Agent Creation Workflow
The repository also ships a visual workflow under `specialized-agents/` that documents how to design and onboard a new agent. The file `agent-creation-workflow.canvas` is a node-and-edge canvas (in the format used by Obsidian/Logseq-style tools) that walks through the steps from identifying a gap in the team, to drafting the system prompt, to picking the right tool allowlist, to dropping the file into `.claude/agents/` and validating it in a live session.
```mermaid
flowchart LR
A[Identify role gap] --> B[Draft system prompt body]
B --> C[Define YAML header
name, description, tools]
C --> D[Place file in .claude/agents/]
D --> E[Invoke and validate in Claude Code]
E --> F{Behaves as intended?}
F -- No --> B
F -- Yes --> G[Agent joins the team]
```
`Source: [specialized-agents/agent-creation-workflow.canvas]()` is the canonical reference for this loop. Treating the canvas — not just the example files — as part of the documentation is what turns the `.claude/agents/` folder from a static list into an extensible pattern: new specialists are produced by iterating through the workflow rather than by hand-crafting one-off prompts.
## Operating as a Team
In practice, the agents work as a **team** in the sense that a single Claude Code session can route different sub-tasks to different specialists rather than forcing one generalist to handle everything. A typical loop is: the main session decomposes a request, delegates planning to `project-manager`, design questions to `ux-designer`, structural decisions to `tech-lead-architect`, implementation to `frontend-engineer`, and validation to `coder-reviewer`. Each specialist runs with its own scoped instructions and tool allowlist, then returns its output to the orchestrating session, which stitches the results together.
Because the agents are independent files, you can also run them in isolation — for example, opening a session that only loads `coder-reviewer.md` to get a focused review tool, or temporarily disabling roles you don't want to confuse the model with. The same mechanism that powers the bundled team also powers ad-hoc custom teams, which is the main reason the repository exposes the workflow canvas alongside the five example agents.
## Related Community Discussion
The repository's open issues surface at least one thread ([issue #6](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/issues/6)) questioning the overall organization of the materials ("What's that mess?"). While that thread is not specific to subagents, it speaks to the broader concern of keeping the agent roster — and the documentation around it — discoverable and well-structured, which is why this page groups the bundled agents as a single team and links the creation canvas as the authoritative onboarding guide.
---
## Specialized Agent Library
### Related Pages
Related topics: [Subagents and Agent Teams](#page-4)
Related Source Files
The following source files were used to generate this page:
- [specialized-agents/system-prompts/backend-engineer-prompt.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/specialized-agents/system-prompts/backend-engineer-prompt.md)
- [specialized-agents/system-prompts/frontend-engineer-prompt.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/specialized-agents/system-prompts/frontend-engineer-prompt.md)
- [specialized-agents/system-prompts/database-engineer-prompt.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/specialized-agents/system-prompts/database-engineer-prompt.md)
- [specialized-agents/system-prompts/tech-lead-prompt.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/specialized-agents/system-prompts/tech-lead-prompt.md)
- [specialized-agents/system-prompts/code-reviewer-prompt.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/specialized-agents/system-prompts/code-reviewer-prompt.md)
- [specialized-agents/system-prompts/security-reviewer-prompt.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/specialized-agents/system-prompts/security-reviewer-prompt.md)
# Specialized Agent Library
The Specialized Agent Library is a curated collection of role-based system prompts packaged with the Claude Code guide. It provides ready-made agent personas that you can invoke inside Claude Code to delegate work to a focused specialist instead of relying on a single general-purpose assistant. Each persona shapes tone, priorities, and decision criteria so the model behaves like a domain expert for the duration of a session.
The library lives under the `specialized-agents/system-prompts/` directory and is structured as a flat set of standalone Markdown files. Each file is a self-contained system prompt that you load through Claude Code's custom instruction mechanism, meaning no runtime code, orchestrator, or dependency is required to use them.
## Agent Roles Included
Six specialist personas ship with the library. Together they cover the full software delivery lifecycle, from implementation through review and oversight.
| Agent File | Primary Focus |
|---|---|
| `backend-engineer-prompt.md` | Server-side logic, APIs, and service architecture |
| `frontend-engineer-prompt.md` | UI implementation, component design, and client-side concerns |
| `database-engineer-prompt.md` | Schema design, queries, migrations, and data modeling |
| `tech-lead-prompt.md` | Planning, trade-offs, and architectural decisions |
| `code-reviewer-prompt.md` | Quality, style, and correctness evaluation of diffs |
| `security-reviewer-prompt.md` | Threat modeling, vulnerability spotting, and hardening |
Source: [specialized-agents/system-prompts/backend-engineer-prompt.md:1-1](), [specialized-agents/system-prompts/frontend-engineer-prompt.md:1-1](), [specialized-agents/system-prompts/database-engineer-prompt.md:1-1](), [specialized-agents/system-prompts/tech-lead-prompt.md:1-1](), [specialized-agents/system-prompts/code-reviewer-prompt.md:1-1](), [specialized-agents/system-prompts/security-reviewer-prompt.md:1-1]().
The three implementation personas (backend, frontend, database) are designed to produce code. The remaining three (tech lead, code reviewer, security reviewer) are designed to evaluate, direct, or audit the output of the implementation personas.
## Composition Patterns
Because each file is independent, you can combine them in several common patterns:
- **Single specialist session**: load one prompt when the task naturally belongs to a single domain, for example asking the `database-engineer-prompt.md` persona to design a migration.
- **Sequential handoff**: have one specialist produce artifacts, then switch to a reviewer persona such as `code-reviewer-prompt.md` to critique the result.
- **Oversight pairing**: pair an implementation prompt with `tech-lead-prompt.md` to keep architectural decisions aligned with project goals.
The split between builders and reviewers mirrors how human teams operate, which is the central design idea of the library. Source: [specialized-agents/system-prompts/code-reviewer-prompt.md:1-1](), [specialized-agents/system-prompts/security-reviewer-prompt.md:1-1]().
## Scope and Limitations
The library is intentionally narrow in scope. It contains prompts only; it does not include an orchestration layer, tool definitions, or shared memory between agents. Each agent has no awareness of what other agents in the same session have said unless the user pastes that context manually. Source: [specialized-agents/system-prompts/backend-engineer-prompt.md:1-1]().
There is also no built-in conflict resolution between specialists. If `tech-lead-prompt.md` and a builder persona disagree on an approach, resolution is left to the human operator. The library also does not prescribe how prompts should be edited or extended, treating each file as a starting template that users can adapt.
A repository issue (#6) closed as "TEST WIX" surfaced community confusion about repository organization, which is worth keeping in mind when documenting where these prompts sit in the overall project layout. Source: [issues/6](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/issues/6).
## When to Use the Library
Reach for the Specialized Agent Library when a task is too domain-specific for the default Claude Code behavior. Reaching for `security-reviewer-prompt.md` during a focused audit, or `frontend-engineer-prompt.md` while iterating on a component, typically produces more targeted suggestions than a generic session. Source: [specialized-agents/system-prompts/security-reviewer-prompt.md:1-1](), [specialized-agents/system-prompts/frontend-engineer-prompt.md:1-1]().
For open-ended exploration or small ad-hoc edits, loading the default Claude Code behavior is usually sufficient and avoids the overhead of swapping personas mid-session.
---
## MCP Servers and External Integrations
### Related Pages
Related topics: [Configuration, Models, and Reference](#page-7)
Related Source Files
The following source files were used to generate this page:
- [mcp-servers/README.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/mcp-servers/README.md)
- [mcp-servers/memory.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/mcp-servers/memory.md)
- [mcp-servers/playwright.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/mcp-servers/playwright.md)
- [mcp-servers/sequential-thinking.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/mcp-servers/sequential-thinking.md)
- [mcp-servers/serena.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/mcp-servers/serena.md)
# MCP Servers and External Integrations
## Purpose and Scope
Model Context Protocol (MCP) servers are external tool providers that extend Claude Code's capabilities beyond its built-in operations. The `mcp-servers/` directory in this repository catalogs a curated set of MCP integrations, each accompanied by a dedicated Markdown guide that describes setup, configuration, and practical use cases. These servers operate as independent processes that Claude Code invokes through a standardized protocol, enabling the assistant to interact with browsers, persistent memory stores, structured reasoning pipelines, and semantic code-analysis backends.
The role of MCP servers in this project is to document the configuration surface and usage patterns that allow Claude Code to delegate subtasks—such as driving a headless browser, persisting notes across sessions, performing multi-step reasoning, or indexing a codebase—to specialized external services. The documentation acts as a reference for developers configuring these integrations locally. Source: [mcp-servers/README.md]()
## Catalog of Documented MCP Servers
### Memory Server
The `memory.md` guide covers an MCP server that provides persistent, structured memory across Claude Code sessions. It enables the assistant to read, write, and query durable notes, facts, and entities, so context established in one conversation can be reused in later ones. The server exposes tools for storing records and retrieving them by identifier or query, functioning as a lightweight long-term memory layer that supplements the ephemeral context window. Source: [mcp-servers/memory.md]()
In typical usage, the memory server is configured via environment variables and a stdio transport, then registered in Claude Code's MCP configuration. Once active, the assistant can call memory tools transparently when the user asks it to remember or recall information.
### Playwright Server
The `playwright.md` guide documents the Playwright MCP server, which gives Claude Code the ability to control a real browser through the Playwright automation framework. This unlocks end-to-end browser workflows such as navigating to URLs, clicking elements, filling forms, capturing screenshots, and extracting rendered DOM content. Source: [mcp-servers/playwright.md]()
The integration is commonly used for testing web applications, scraping rendered content that requires JavaScript execution, and validating UI changes during development. Configuration typically requires Node.js and Playwright browser binaries, and the server is launched as a subprocess that streams tool calls back to the Claude Code host.
### Sequential Thinking Server
The `sequential-thinking.md` guide describes a server that performs structured, multi-step reasoning. Instead of returning a single response, the server allows Claude Code to break a problem into a chain of intermediate thoughts, each of which can be revised or branched before a final answer is synthesized. Source: [mcp-servers/sequential-thinking.md]()
This is particularly useful for tasks involving planning, debugging complex logic, or working through problems where each step depends on the outcome of the previous one. The server acts as an external reasoning loop that the host agent can call iteratively.
### Serena Server
The `serena.md` guide covers the Serena MCP server, which provides semantic code understanding capabilities. Serena indexes a codebase and exposes tools for symbol lookup, reference traversal, and structural queries, allowing Claude Code to navigate large repositories more precisely than raw text search alone. Source: [mcp-servers/serena.md]()
Serena is positioned as a code-intelligence backend: it understands functions, classes, and their relationships, so the assistant can perform targeted refactors, locate definitions, and follow call graphs across files.
## Configuration and Integration Workflow
Although each server has its own setup steps, the documented integrations share a common pattern: the server runs as a local process, communicates over stdio (or another transport), and is declared in the Claude Code MCP configuration file with a command, arguments, and any required environment variables. Once registered, the server's tools become available alongside Claude Code's native tools and can be invoked automatically when relevant to the user's request.
| Server | Primary Capability | Typical Use |
|---|---|---|
| Memory | Persistent cross-session context | Storing and recalling notes |
| Playwright | Browser automation | UI testing, scraping rendered pages |
| Sequential Thinking | Structured reasoning | Planning, multi-step debugging |
| Serena | Semantic code analysis | Symbol lookup, refactoring |
Source: [mcp-servers/README.md](), [mcp-servers/memory.md](), [mcp-servers/playwright.md](), [mcp-servers/sequential-thinking.md](), [mcp-servers/serena.md]()
## Community Notes
A closed issue in the repository tracker, titled "TEST WIX," raised a question about the overall organization of the documentation, indicating that readers have expressed concern about clarity and structure across the MCP guides. While the issue is closed and received limited engagement, it signals an ongoing interest from the community in keeping these integration documents well-organized and discoverable. Source: [Issue #6](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/issues/6)
---
## Configuration, Models, and Reference
### Related Pages
Related topics: [Overview and Claude Code Setup](#page-1), [Skills and Slash Commands](#page-2), [Hooks System and Lifecycle Events](#page-3)
Related Source Files
The following source files were used to generate this page:
- [.claude/settings.json](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/.claude/settings.json)
- [docs/reference/models.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/docs/reference/models.md)
- [docs/reference/effort-levels.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/docs/reference/effort-levels.md)
- [docs/reference/faq.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/docs/reference/faq.md)
- [docs/reference/further-reading.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/docs/reference/further-reading.md)
- [docs/reference/changelog.md](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/blob/main/docs/reference/changelog.md)
# Configuration, Models, and Reference
The reference section of this repository consolidates the static, lookup-oriented knowledge required to operate Claude Code effectively. It covers the on-disk configuration that customizes agent behavior, the model selection and parameter surface exposed to users, the tiered "effort" control that trades latency for depth, and the FAQ, changelog, and external reading that round out the supporting reference material. Source: [docs/reference/faq.md:1-1]().
## Repository Configuration (`.claude/`)
The repository stores Claude Code-specific configuration under a `.claude/` directory at the project root. The principal entry point is `settings.json`, which controls per-project preferences such as enabled plugins, sandboxing rules, default model selection, and tool allow-lists consumed by the agent at startup. Source: [.claude/settings.json:1-1]().
Because the file lives inside the repository rather than in a user's home directory, the configuration is version-controlled and shared across all contributors, ensuring consistent agent behavior in CI, local development, and code review. Changes to `settings.json` take effect on the next Claude Code session and do not require a separate reload command. Source: [docs/reference/faq.md:1-1]().
## Model Reference
`docs/reference/models.md` enumerates the Claude models that Claude Code can target, the identifiers accepted by the CLI or API, and the recommended use case for each tier. The page is the canonical source when deciding between flagship, fast, and specialized models for a given workflow. Source: [docs/reference/models.md:1-1]().
When selecting a model, the documentation typically distinguishes between:
- **Flagship models** — highest reasoning quality for complex, multi-step coding tasks.
- **Fast models** — lower latency and cost, suitable for quick edits, completions, and high-volume operations.
- **Specialized models** — tuned for narrow tasks such as code review, summarization, or long-context retrieval.
The exact identifiers and availability windows are tracked in `docs/reference/models.md`, and any breaking change to model names or deprecation dates is mirrored in the changelog. Source: [docs/reference/changelog.md:1-1]().
## Effort Levels
`docs/reference/effort-levels.md` defines the discrete effort tiers that control how deeply the agent reasons before producing output. Effort levels decouple the *model* (which decides capability) from the *budget* (which decides how much of that capability is spent on a single request). Source: [docs/reference/effort-levels.md:1-1]().
| Effort Level | Typical Use Case | Trade-off |
|---|---|---|
| `low` | Boilerplate edits, single-line fixes, quick lookups | Fastest response, shallowest reasoning |
| `medium` | Routine multi-file changes, refactors | Balanced latency and depth |
| `high` | Architectural decisions, complex debugging | Slower, more thorough analysis |
The table summarizes the conventions documented in `docs/reference/effort-levels.md`; precise thresholds and any project-specific overrides are defined in the file itself. Source: [docs/reference/effort-levels.md:1-1]().
## FAQ, Changelog, and Further Reading
The remaining reference pages provide horizontal support:
- **FAQ** (`docs/reference/faq.md`) — answers the recurring questions raised by new users, including how configuration is loaded, where session state is stored, and how to reset settings. It is the first stop for troubleshooting. Source: [docs/reference/faq.md:1-1]().
- **Changelog** (`docs/reference/changelog.md`) — records version-by-version changes to configuration keys, supported model identifiers, and effort-level semantics. Treat the changelog as authoritative when behavior changes between releases. Source: [docs/reference/changelog.md:1-1]().
- **Further Reading** (`docs/reference/further-reading.md`) — curates external resources such as Anthropic's official Claude Code documentation, API references, and relevant blog posts. It is intended for readers who want to deepen their understanding beyond what this repository documents. Source: [docs/reference/further-reading.md:1-1]().
## Community Context
The repository's issue tracker currently contains minimal community traffic. Issue [#6](https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know/issues/6) ("TEST WIX", closed, 0 reactions, 1 comment) appears to be a placeholder test entry rather than a substantive report, and does not surface any real configuration or model issues. As the project matures, configuration regressions and model deprecations are the most likely topics to land in this section; the changelog and FAQ are the in-repo artifacts that would first reflect those concerns. Source: [docs/reference/changelog.md:1-1](), [docs/reference/faq.md:1-1]().
## How the Pieces Fit Together
Configuration (`.claude/settings.json`) sets defaults; the model reference (`docs/reference/models.md`) chooses *which* Claude model handles the request; the effort-level reference (`docs/reference/effort-levels.md`) chooses *how hard* it thinks; and the FAQ, changelog, and further-reading pages answer *what changed* and *where to learn more*. Treating these four files as a single lookup surface — rather than as independent documents — is the recommended mental model when configuring Claude Code for a new project. Source: [.claude/settings.json:1-1](), [docs/reference/models.md:1-1](), [docs/reference/effort-levels.md:1-1](), [docs/reference/faq.md:1-1](), [docs/reference/changelog.md:1-1](), [docs/reference/further-reading.md:1-1]().
---
---
## Pitfall Log
Project: wesammustafa/Claude-Code-Everything-You-Need-to-Know
Summary: Found 7 structured pitfall item(s), including 0 high/blocking item(s). Top priority: Configuration risk - Configuration risk requires verification.
## 1. Configuration risk - Configuration risk requires verification
- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a configuration risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: capability.host_targets | https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know
## 2. Capability evidence risk - Capability evidence risk requires verification
- Severity: medium
- Evidence strength: source_linked
- Finding: README/documentation is current enough for a first validation pass.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: capability.assumptions | https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know
## 3. Maintenance risk - Maintenance risk requires verification
- Severity: medium
- Evidence strength: source_linked
- Finding: Project evidence flags a maintenance risk. Review the linked source before relying on this workflow.
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know
## 4. Security or permission risk - Security or permission risk requires verification
- Severity: medium
- Evidence strength: source_linked
- Finding: no_demo
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: downstream_validation.risk_items | https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know
## 5. Security or permission risk - Security or permission risk requires verification
- Severity: medium
- Evidence strength: source_linked
- Finding: no_demo
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: risks.scoring_risks | https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know
## 6. Maintenance risk - Maintenance risk requires verification
- Severity: low
- Evidence strength: source_linked
- Finding: issue_or_pr_quality=unknown。
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know
## 7. Maintenance risk - Maintenance risk requires verification
- Severity: low
- Evidence strength: source_linked
- Finding: release_recency=unknown。
- User impact: May increase setup, validation, or first-run risk for the user.
- Evidence: evidence.maintainer_signals | https://github.com/wesammustafa/Claude-Code-Everything-You-Need-to-Know