Claude Code features

The features below matter at team scale because each one can be shared: commands, skills, hooks, and settings checked into .claude/ give every engineer the same setup on day one. The decision for each is whether it's team tooling (versioned in the repo, reviewed) or personal setup (in your home directory).

Slash commands

Built-in commands for common workflows. Full list: https://code.claude.com/docs/en/slash-commands

The ones that matter for team practice:

Session management: /resume picks up an earlier session, /rewind rolls back conversation and code, /export saves a transcript.

Custom slash commands

Custom commands turn a prompt that works into something the whole team runs the same way.

• Team commands live in .claude/commands/ and are checked in
• Personal commands live in ~/.claude/commands/

The filename becomes the command: .claude/commands/fix-issue.md → /fix-issue. The file content is the prompt.

<!-- .claude/commands/fix-issue.md -->
Fix GitHub issue #$ARGUMENTS. Read the issue, reproduce it with a failing test,
fix it, and run the test suite.

Usage: /fix-issue 123

<!-- .claude/commands/commit.md -->
---
description: Create a git commit with a conventional message
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git diff:*), Bash(git commit:*)
---

Review the staged changes and create a commit with a clear conventional commit message.
One behavior per commit. Follow the project's commit conventions.

<!-- .claude/commands/pr.md -->
---
description: Open a pull request for the current branch
allowed-tools: Bash(git:*), Bash(gh:*)
---

Push the branch if needed, then open a PR with gh. Title and description come from
the commits. Include a test plan.

Arguments and frontmatter:

• $ARGUMENTS captures everything after the command. $1 and $2 capture positional arguments
• @path/to/file pulls a file into the prompt
• allowed-tools scopes what the command may run. Scope it tightly
• model pins a model
• argument-hint documents the expected arguments

When a command grows into a multi-step workflow with its own reference material, make it a skill instead.

MCP prompts show up as commands too: /mcp__<server>__<prompt> [args].

Hooks

Hooks run shell commands at points in the agent lifecycle. They're how you turn "please remember to lint" into "linting always happens". They also run on every action, so a slow or buggy hook slows every engineer down. Test them like production code.

// .claude/settings.json (checked in)
{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [{ "type": "command", "command": "bun lint --fix" }]
      }
    ],
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": ".claude/hooks/block-secrets.sh" }]
      }
    ]
  }
}

Lifecycle events:

How hooks see the action: the hook receives JSON on stdin describing the event, including the tool name and its input. Exit code 0 continues. Exit code 2 blocks the action and sends your stderr back to the agent, so the agent can fix its approach.

#!/bin/bash
# .claude/hooks/block-secrets.sh - refuse edits to env and credential files
file=$(jq -r '.tool_input.file_path // empty')
if [[ "$file" == *.env* || "$file" == *credentials* ]]; then
  echo "Blocked: $file holds secrets. Edit it by hand." >&2
  exit 2
fi

Good hook candidates:

• Format and lint on every edit
• Block writes to secrets, to migrations that already ran, and to generated files
• Run the fast unit tests for the file that changed
• Audit-log every shell command in sensitive repos
• Notify when a long run needs input

Watch for permission creep. Review what hooks and background agents can touch, especially anything outside the repository.

Subagents

Subagents run a task in their own context and return only the result. That keeps the main session focused on the decision at hand instead of filling up with search output.

"Use a subagent to find every place we validate auth tokens.
Return file:line and one line per site. Don't load the files here."

When to use them:

• Research that would bloat the main context
• Parallel, independent investigations
• A fresh-eyes review of work the main session produced
• Fan-out audits: one subagent per service, results in one table

Built-in types:

Teams can define their own subagents in .claude/agents/: a reviewer with the team's checklist, a migration specialist with read-only database access. Shared definitions make results comparable across engineers.

Background agents

Background agents run while you keep working: test suites, long audits, large refactors.

"Run the full test suite in the background and report failures.
I'll keep working on the UI."

What they buy you: no blocking on long operations, and parallel workstreams. A task that took two days serially can land in an afternoon.

What they cost: review load. Parallel agents multiply output only if someone can review it. Size parallelism to reviewer capacity, not to how many terminals you can open.