A Practical Guide to Terminal Coding Agents: From First Session to Enterprise Rollout

1. Introduction: What It Is, Who Should Read It, and What to Know First

A terminal coding agent is an AI coding agent that runs in the command line: it can read and write local files, execute shell commands, call external tools on demand, and complete a closed loop of read code → change code → run tests → fix problems across multiple turns. Compared with inline completion inside an IDE, the difference is not “writes faster” but “can act”: it makes cross-file edits, runs commands, and verifies results.

Three categories of friction shape how this article is organized:

• The tool itself: failed installs, broken authentication, a model that does not match the runtime environment;
• How it is used: staying at the level of ad-hoc questions, without understanding the command system, permission modes, and context mechanisms;
• Engineering and governance: not knowing how to wire subagents, hooks, and language services into a real workflow; no permission boundaries, audit trail, isolation, or cost control.

Naming conventions and scope (read this first)

The ai-cli command, the .claude/ directory, settings.json / .mcp.json, and CLAUDE.md mentioned below are the common conventions used by mainstream terminal agents today. They are used as placeholders throughout this article and do not represent a single standard shared by every tool:

• Directory and file names differ: some tools use .ai/, AGENTS.md, or config.toml;
• Configuration capabilities evolve between versions: the syntax for permission declarations, hooks, subagents, and MCP may change — check the official documentation that matches the output of <tool> --version;
• Slash commands and keybindings are not universal: run /help when you enter a session to confirm.

The most effective way to read what follows: treat it as a “capability map plus design principles,” and treat every concrete field as an example that needs to be verified against your version.

2. Getting Started: Installation, Authentication, First Conversation

2.1 Three installation methods and how to handle failures

Most agents ship as command-line programs, usually in one of three forms:

1. A global install from the language ecosystem’s package manager (for example npm i -g);
2. The vendor’s one-line install script;
3. Running a container image.

The first two depend on a runtime such as Node.js, and a runtime that is too old is the leading cause of install or startup failures. The container approach isolates well, but you must mount the working directory correctly and persist configuration.

node -v                                  # Confirm the runtime version meets the tool's requirements first
npm install -g <assistant-cli-name>      # Package name depends on the tool you use
ai-cli --version && ai-cli               # Check the version and enter an interactive session

Common failures and what to do:

• Permission errors (EACCES): do not reach for sudo; switch to a Node version manager (nvm/volta) or reinstall with the official install script;
• The install script fails to download: usually a network or registry issue — verify proxy settings, switch to an internal mirror, or run the container image on an isolated network;
• The process exits immediately on startup: add a debug flag such as --verbose or -d to see logs, then check the runtime version first, followed by JSON syntax errors in config files and permission-mode settings that prevent writing to the config directory;
• The command disappears after an upgrade: check whether PATH matches the global package manager’s prefix.

Once installed, do three things: run any built-in self-check command (such as ai-cli doctor) to work through environment and dependency issues; confirm your terminal font renders monospaced text correctly so output does not wrap awkwardly; and start the agent from the project root so it gets the right context.

2.2 Authentication, model choice, and credential safety

There are usually two ways to connect: a subscription account login (one browser authorization, credentials managed locally — good for individuals) or API key access (injectable via environment variables — good for team billing and centralized control).

Credential rules: never hard-code them into scripts, never commit them to a repository, never store them in plaintext in a config file. If a leak has already happened, revoke and rotate the key in the console immediately, use git log -S and secret-scanning tools to search the history, and then assess the blast radius — deleting the file is not enough to remove the risk. In CI/CD, always inject credentials through the pipeline’s credential management.

Match the model to the task: use a more capable model for reasoning-heavy work such as architecture design and complex refactoring; use a lightweight model for batch formatting or log summarization to balance speed and cost. You can switch at any time with /model.

2.3 Your first conversation: turn “a request” into “an assignment”

Describe the work in four parts — task, context, constraints, acceptance criteria:

Task: Add a "cancel order" endpoint to the order module.
Context: Code lives in src/order/; the state machine is defined in src/order/state.ts; the "payment succeeded" branch can serve as a reference.
Constraints: Follow the existing error-handling and logging conventions; do not introduce new third-party dependencies.
Acceptance: Unit tests cover "unpaid can be cancelled", "paid must be refunded first", and "completed cannot be cancelled", and all pass.

Let the agent investigate before it writes code: confirm the directory structure, tech stack, and dependency management, and have it find the closest existing implementation to use as a reference. After it makes changes, ask it to run the build, tests, and static analysis itself and fix what fails, then review the result yourself. This generate → verify → fix loop is the foundation for everything more advanced.

Learn the escape hatches up front too: press Ctrl+C once to interrupt the current output; press Esc twice to go back to the previous message and re-edit it; and use version control to revert when you do not like the changes — which is exactly why you should commit before letting the agent make large edits.

3. Command Reference: The Slash Command System

Think of slash commands as the agent’s built-in manual. Knowing the categories is more valuable than memorizing individual commands.

Category	Typical capabilities	When to use it
Session management	Clear context, compress history, resume a session, export the conversation	Free up context on long tasks; continue work across days
State and cost	Check token usage, current model, context occupancy	Control cost; decide whether to split a task
Configuration	Switch models, adjust permission mode, set output style and reasoning effort	Switch strategy per task
Memory and rules	Edit the project memory file, append project notes	Capture team conventions
Ecosystem management	Install/update plugins, manage skills and subagents, configure external services	Extend what the agent can do
Custom commands	Package a frequently used prompt as a reusable command	Standardize reviews, generate commit messages
Other	View keybindings and help, exit	Everyday operations

High-frequency cases: /init scans the repository and generates a memory file — the first step when taking over an existing project. /compact compresses a long history into a summary, freeing context while keeping conclusions. /cost shows usage and spend for the current session, which matters a lot for teams billed by usage. /model switches models per task. /doctor runs an environment and permission self-check to diagnose “can’t connect” or “can’t install” problems.

Custom commands are the most underrated efficiency lever. Put a Markdown file in .claude/commands/ (some tools use .ai/commands/); the file name becomes the command name.

---
description: Review the current changes against team standards
---
Review all changes in `git diff` relative to the merge base of the current branch, focusing on:
1. Whether boundary conditions and error handling are complete;
2. Whether circular dependencies or cross-layer direct calls were introduced;
3. Whether new public interfaces have corresponding tests.
Output: a list grouped into "critical / normal / suggestion", each item with the file path, line number, and a suggested fix.

Command files accept arguments via $ARGUMENTS and reference files with @path. Hand the fixed procedure to the tool and keep the judgment with the human.

4. Interaction Modes and Tools: Make the Agent Act Without Breaking Things

4.1 Permission modes: the more capability, the clearer the boundary

An agent is more useful than a chatbot precisely because it can read and write files and execute commands — and the risk comes from the same place.

Mode	Behavior	When to use it
Default	Asks for confirmation before each sensitive action	Everyday development, production-related repositories
Auto-accept edits	Edits without confirmation; commands still confirm	Well-scoped batch modifications
Plan mode	Read-only analysis, outputs a plan	Aligning on an approach before a complex refactor
Fully open	No per-action confirmation	Only automated tasks inside an isolated container

At the configuration level you can grant permissions per tool (usually in settings.json at the project root or in your user directory):

{
  "permissions": {
    "allow": ["Read", "Edit", "Grep", "Glob", "Bash(npm run test:*)", "Bash(git status)"],
    "ask": ["Bash(git push:*)"],
    "deny": ["Bash(rm -rf:*)", "Read(.env)", "Read(./secrets/**)"]
  }
}

The minimum-necessary rule in three parts: frequent and safe operations go on the allow list; operations that affect shared state (pushing branches, deploying) require confirmation each time; irreversible or highly destructive operations (recursive deletion, reading credential files) are denied outright.

High-risk warning: allowing wildcard execution of arbitrary commands (for example a full wildcard on Bash) or turning on “fully open” means giving up command-level safety controls, and a single model misjudgment can execute something destructive. If you have already opened it up, restore the default mode immediately, check your shell history and git records to confirm whether anything actually changed, and redo that kind of task in an isolated environment or under a low-privilege account.

4.2 Edit modes and input tricks

Some tools ship key-driven edit modes that noticeably speed up input once you are fluent:

• In normal mode, h/j/k/l move the cursor, w/b jump by word, and 0 and $ jump to the start and end of the line, while gg/G jump to the top and bottom of the file;
• i enters insert mode, Esc returns to normal mode;
• dw, cw, dd, and x delete a word, change a word, delete a line, and delete a character;
• u undoes.

Two prefixes cover two high-frequency actions: @ references a file or directory, used to “give context”; # quickly writes to the memory file, used to “store knowledge”. The difference matters — the former affects the current session, the latter affects every future session.

4.3 Long-running tasks and background execution

Slow builds, test suites, and load tests can run in the background. Have the agent redirect output to a file and cap its size:

Run the full test suite, redirect the output to test-output.log, keep only the last 200 lines of the log,
and when it finishes report a list of failing cases with causes categorized.

The corresponding commands for inspecting and alerting (subcommands vary by tool):

ai-cli tasks list                 # List background tasks and their status
ai-cli tasks logs <task-id> -n 200   # Read the tail of a specific task's log
tail -n 200 test-output.log       # Generic approach: look at the last 200 lines only
tail -f test-output.log           # Follow the file as it grows
timeout 15m npm run test:e2e > test-output.log 2>&1 \
  || echo "Timed out or failed, exit code $?" >> test-alert.log   # Timeout fallback and alert

Background tasks do not wake you up, so keep doing other work and check the results periodically. For critical tasks, set a timeout alert with timeout or a scheduler so a hung job does not sit unnoticed.

4.4 Hooks: turn “manual checks” into “automatic rules”

Prompts constrain the model’s behavior; hooks enforce it with code. They fire before a tool call or after the response completes, and can block, modify, or append context:

{
  "hooks": {
    "PreToolUse": [
      { "matcher": "Bash", "hooks": [{ "type": "command", "command": "$CLAUDE_PROJECT_DIR/.hooks/check-command.sh" }] },
      { "matcher": "Write|Edit", "hooks": [{ "type": "command", "command": "$CLAUDE_PROJECT_DIR/.hooks/guard-paths.sh" }] }
    ],
    "PostToolUse": [
      { "matcher": "Write|Edit", "hooks": [{ "type": "command", "command": "$CLAUDE_PROJECT_DIR/.hooks/format-changed.sh" }] }
    ],
    "Stop": [
      { "matcher": "", "hooks": [{ "type": "command", "command": "$CLAUDE_PROJECT_DIR/.hooks/run-tests.sh" }] }
    ]
  }
}

A script decides by exit code: 0 allows the call; 2 blocks it and feeds stderr back to the model so it can correct itself. For example, check-command.sh blocks direct pushes to main such as git push origin main, and guard-paths.sh prevents changes to production config directories. The value of hooks is that you no longer have to repeat “don’t do that” in every conversation.

5. The Model Context Protocol (MCP): What It Is, What It Solves, How to Connect

By default an agent can only touch local files and terminal commands. To let it look up tickets, search a knowledge base, read monitoring metrics, or query an internal database, the traditional approach is to write glue scripts for each system — which becomes repetitive and hard to maintain as systems multiply. MCP (Model Context Protocol) defines a standard interface for this: external systems expose capabilities as “servers”, and the agent consumes them as a “client” on demand.

Where it fits and where it doesn’t: MCP solves unified access to tools and data. It does not solve authorization or compliance — those still belong in a gateway and policy layer. If you only need to run one query occasionally, a custom command is usually cheaper than standing up an MCP server.

There are two transport styles: a local process communicating over standard input/output, and a remote service over HTTP, which also supports the server pushing data proactively. A server can expose three kinds of capability: tools (operations the model invokes), resources (readable data), and prompt templates (pre-built task prompts).

Configuration usually goes in a project-level .mcp.json (shared by the team) or a user-level ~/.claude.json (personal):

{
  "mcpServers": {
    "issue-tracker": {
      "type": "http",
      "url": "https://issues.internal.example.com/mcp",
      "headers": { "Authorization": "Bearer ${ISSUE_TRACKER_TOKEN}" }
    },
    "docs-search": {
      "command": "npx",
      "args": ["-y", "@your-org/docs-search-mcp"],
      "env": { "INDEX_URL": "https://search.internal.example.com" }
    }
  }
}

Use /mcp in a session to check connection status and approve each server individually. ${VAR} is read from the system environment, so no plaintext secrets land in the config file. Four governance points: issue a separate token per server with least privilege; prefer read-only and gate writes behind approval; treat content returned by external systems with suspicion to avoid prompt injection; and mount only the servers the current task needs in a single session, so tool definitions do not crowd out the context.

6. Skills and Memory: Teach the AI Your Team’s “House Style”

A skill usually lives in a folder with a SKILL.md at its core, plus optional scripts and templates:

.claude/skills/
└── api-endpoint/
    ├── SKILL.md          # Trigger conditions + procedure
    ├── templates/endpoint.ts
    └── scripts/scaffold.sh

---
name: api-endpoint
description: Add a REST endpoint. Use when the user asks to create, add, or implement a new API.
---
## Steps
1. Create the route file under src/modules/<module>/routes/, following templates/endpoint.ts;
2. Implement the business logic in service/;
3. Generate the test skeleton with scripts/scaffold.sh <module> <resource>;
4. Update the endpoint list in docs/api.md.
## Conventions
- Parameters must be validated with a Zod schema;
- Error responses must use the error codes in src/common/errors.ts;
- When done, run npm run test -- <module> and confirm it passes.

Skills load progressively: at the start of a session only the metadata enters the context, and the model reads the full body once it judges the skill relevant. That is why the description must state the trigger situation clearly — otherwise the skill never activates.

The three knowledge carriers each have a role:

Carrier	Scope	Location	Characteristics
Memory file	Project-level conventions	CLAUDE.md / AGENTS.md in the repo	Loaded automatically in every session; good for stable rules
Personal memory	User-level preferences	~/.claude/CLAUDE.md	Applies across projects; not committed
Skills	Task-specific procedures	Project- or user-level skills directory	Loaded on demand; good for long, specialized knowledge

Writing the memory file: use imperative sentences that say “how to do it” rather than background descriptions; start with a directory map and the common commands (build, test, lint), which should take up about a third of the file; write down only the conventions a model cannot infer from code or a code review; commit it and update it as the code changes. When you see signs like “the agent keeps violating the same convention” or “answers the wrong question and cites files that do not exist”, the memory is probably polluted — /compact or clearing the session beats asking more follow-up questions.

7. The Plugin System: Assemble Capabilities Like Building Blocks

A plugin bundles commands, subagents, skills, hooks, and MCP configuration into a distributable unit. It can come from a public marketplace, a private repository, or your own work.

ai-cli plugin marketplace add <repo-url>
ai-cli plugin install <plugin-name>@<marketplace-name>

A typical homegrown plugin layout:

my-plugin/
├── .claude-plugin/plugin.json   # Manifest: name, version, description
├── commands/  agents/  skills/  # Custom commands, subagents, skills
├── hooks/hooks.json             # Hook configuration
└── .mcp.json                    # External service configuration (optional)

For company-wide adoption, run an internal plugin marketplace: security and code review before anything is added, unified version management once published, and members install on demand. This reuses best practices while keeping code of unknown origin out of the development environment.

8. Engineering Practice: From a Personal Assistant to an “AI Delivery Team”

8.1 Subagents: specialization and context isolation

A subagent is a Markdown file under .claude/agents/ — essentially an independent session with a specialized prompt. The main agent only receives the conclusion; the many files the subagent reads never enter the main session, which saves context substantially.

---
name: code-reviewer
description: Reviews code changes and outputs a list of issues; use proactively after feature code is written.
tools: Read, Grep, Glob, Bash
---
1. Review the current changes against docs/coding-style.md;
2. Check boundary conditions, error handling, concurrency safety, and performance risks;
3. Output the issue location (file:line), severity, and suggested fix;
4. Report only, do not fix; the main agent decides what to do.

Subagents can run in parallel: “check security”, “check performance”, “verify docs are in sync” all start at once and the main agent consolidates. The precondition is that the tasks are genuinely independent; otherwise you get duplicated work and conflicting conclusions.

8.2 The Language Server Protocol (LSP): let the agent understand the whole project

LSP defines a standard way for editors and language services to communicate. With it, an agent can get exact symbol definitions, reference locations, type information, and diagnostics instead of guessing from text search — which matters most for cross-file renames, large-scale interface changes, and locating problems from compiler errors.

Preconditions (the configuration is useless if these are not met):

1. The relevant language server is installed, for example npm i -g typescript typescript-language-server;
2. Your agent version supports a languageServers (or similarly named LSP) configuration key; field names vary by version, so check the official documentation;
3. The language version matches the project’s tech stack (a monorepo needs a correct pointer to the tsconfig root).

{
  "languageServers": {
    "typescript": {
      "command": "typescript-language-server",
      "args": ["--stdio"],
      "extensionToLanguage": { ".ts": "typescript", ".tsx": "typescriptreact" }
    }
  }
}

If LSP is not supported, the alternatives are: use Grep/Glob plus a symbol-search script to locate references; use compiler and static-analysis output from tsc --noEmit, eslint, or mypy as the authoritative source of truth; or do the rename in your editor with LSP and paste the diagnostics to the agent to handle.

8.3 A recommended workflow: explore — plan — implement — verify — commit

1. Explore: subagents survey the relevant modules in parallel and produce a "current state report"
2. Plan: enter plan mode, output the change list and risk points, and get human confirmation
3. Implement: work through the list item by item, running the relevant tests after each one
4. Verify: hooks format, lint, and run tests automatically; a subagent reviews independently
5. Commit: generate a conforming commit message, get human approval, then push

Supporting rules: commit in small steps, one per testable feature point; write tests before implementation so acceptance criteria become failing cases first; and when something requires an architecture decision, stop and ask a human rather than letting the model guess.

8.4 CI/CD and code platform integration

Practical capabilities include automatic review of pull requests published as comments, automatic fixing of lint and formatting issues on a fix branch, generating or updating documentation based on the diff, and picking up a desktop session from a phone or browser through a remote control interface.

Pipeline integration must be low-privilege and reversible: use least-privilege credentials, forbid direct changes to protected branches, and require human review before any AI-produced change is merged.

9. How Coding Agents Work: Understanding the Loop from Scratch

The core loop has four steps: assemble the context (system prompt + tool definitions + message history); call the model (which returns text or a tool-call request); execute the tools (the client validates arguments, runs them, and writes results back into the history); decide whether to stop (no tool request means exit, otherwise return to step two).

def agent_loop(client, tools, user_input, max_steps=30):
    messages = [{"role": "system", "content": SYSTEM_PROMPT},
                {"role": "user", "content": user_input}]
    for _ in range(max_steps):
        resp = client.chat(model=MODEL, messages=messages, tools=tools)
        messages.append(resp.message)
        if not resp.tool_calls:
            return resp.content
        for call in resp.tool_calls:
            messages.append({"role": "tool", "content": dispatch(call, tools)})
    return "Maximum steps reached; please split the task and retry"

Context engineering determines the real-world result: read on demand (search to locate, then read the relevant slice), compress and summarize, isolate messy work in subagents, use prompt caching (put stable content first to exploit the cache and cut latency and cost), and control the number of tools (tool definitions themselves consume tokens).

Four principles for tool design: right-sized granularity (support exact replacement rather than whole-file overwrite), structured parameters (constrained with a JSON Schema), diagnosable errors (include path, line number, and cause), and built-in safety checks (check for path escapes before writing, match against an allow list before executing).

10. Enterprise Deployment: Five Dimensions That Reassure the Security Team

Individual productivity comes from habits; enterprise adoption comes from governance. Work through these five summary cards:

Architecture and access. Public cloud subscriptions send code off the internal network — fine for non-sensitive projects, but confirm the data retention and training-use terms. An enterprise proxy or gateway makes key management and traffic auditing easier. Private or dedicated cloud deployment keeps code inside the network and fits highly sensitive sectors such as finance and government, but costs more compute and iterates on models more slowly.

Identity and permissions. Use SSO for unified identity and ban shared accounts. Assign by role (regular developers get read-only plus a development environment; technical leads can approve deployments). Deliver managed configuration as policy-as-code, locking down which models are available, which tools are allowed and forbidden, and which hooks are mandatory, so personal configuration cannot override the red lines.

Audit and logging. Record who did what and when, in which repository, which commands were executed and which files changed, model and token consumption, and whether a permission denial or a hook block was triggered. Store it centrally with a retention period, and configure alerts for anomalies such as repeatedly reading credential files or bulk deletion.

Sandboxing and isolation. Use containers or lightweight VMs to cap CPU, memory, and duration, with a read-only root filesystem and only the necessary directories mounted. Restrict network access to an allow list of internal mirrors and required APIs. Run under a separate low-privilege account. Require all output to be reviewed by a human as a patch, and forbid automatic merging.

Cost and results. Build a token dashboard per team or project with monthly budget alerts; pick models by task tier; use prompt caching and context compression to cut wasted consumption; and reconcile usage periodically to trace anomalies. Also build an evaluation set of 30–50 real cases covering bug fixes, feature additions, refactoring, and test writing, run it as a regression before upgrades, and track first-pass rate, human rework rate, review issue density, and average task duration.

A note on infrastructure options. Model access can go through enterprise AI infrastructure — for example, a large model platform offered by a public cloud provider such as Baidu AI Cloud — to get unified multi-model access, token quota allocation, call log collection, and content safety controls, instead of each team requesting keys separately. This is only one option, and whether to adopt it requires your own assessment: confirm the data retention period and whether data is used for model training, the data storage region and cross-border requirements, industry regulatory and compliance obligations (finance and government need dedicated compliance review), and the vendor’s security qualifications and contract terms — while keeping the ability to connect multiple vendors to avoid lock-in.

Rollout path. Pilot for 1–2 months with 3–5 seed users on typical scenarios; spend 1 month producing standards documentation, memory templates, and an internal plugin library; spend 2–3 months on company-wide training and a support channel; then keep tuning based on usage and evaluation data.

11. Learning Paths by Role

Role	Learn first	Goal
Developer new to AI coding	Installation and configuration, slash commands, permission modes, project memory	Reliable everyday coding assistance
Senior developer	Subagents, hooks, LSP, writing skills	Embed the agent in complex engineering workflows
Team lead	Custom commands, internal plugin marketplace, evaluation set, usage dashboard	Consistent usage and measurable gains
Architect	MCP integration, sandboxing, private deployment, security compliance	A design that is auditable and controllable

12. Common Mistakes: A 12-Point Self-Check

1. The runtime is too old to install, and you keep reinstalling instead;
2. Using sudo npm i -g creates permission chaos, and the command disappears after an upgrade;
3. Keys are hard-coded into scripts or committed to a repo, and after a leak you only delete the file instead of revoking;
4. Starting the agent outside the repository root, so context is missing and the answers miss the point;
5. Asking only “write me an endpoint” with no constraints or acceptance criteria, leading to heavy rework;
6. Turning on “fully open” or a Bash wildcard right away, so a deletion command gets executed by mistake;
7. Letting the agent change an uncommitted working tree, leaving no way to roll back;
8. Never compressing a long session, so context is eaten by logs and whole files and quality drops noticeably;
9. Writing a vague skill description, so the skill never triggers;
10. Writing the memory file as background prose rather than executable conventions, so it grows long and self-contradictory;
11. Mounting too many MCP servers in one session, so tool definitions fill the context;
12. Judging adoption by “it feels faster” with no evaluation set and no usage dashboard, so the benefit cannot be quantified.

13. FAQ

How is a terminal agent different from IDE completion? Completion passively suggests code at a single point. A terminal agent proactively reads across files, executes commands, and verifies results, which suits task-level work at the cost of needing stronger permission and process controls.

Subscription or API key? A subscription login is easier for individual trials and everyday development; use an API key when you need unified billing, centralized control, and auditing, and inject it through a gateway or environment variables.

Will company code leak? That depends on the deployment model and the provider’s terms. For sensitive projects, choose private or dedicated cloud, or an enterprise gateway, and confirm data retention, training use, and data residency requirements in the contract.

How do I tell whether the context is polluted? The typical signals are repeatedly violating the same convention, citing files that do not exist, and forgetting changes already made. Use /compact, and if needed clear the session and rebuild a baseline from the memory file.

How do you measure the gain? Use the four evaluation metrics — first-pass rate, human rework rate, code review issue density, and average task duration — running the evaluation set before and after a tool or model upgrade.

14. Conclusion

The value of a terminal coding agent is not whether it can write code, but whether it can take over repetitive, mechanical, easy-to-miss work so people can focus on design, judgment, and decisions. A sensible pace: one week to get fluent with basic operations and the command system; one month to embed the agent in your personal workflow; and at the team level, build standards, evaluation, and audit mechanisms at the same time.

Tools will keep evolving, but four principles will not age: clear context, explicit constraints, verifiable results, and controlled permissions. Understand the underlying logic and you will stay in control through every change of tooling.