Command-Line Coding Agents: Quick Start, Core Commands, and Configuration

1. First, Build a Mental Model: It Is Not Just Smarter Autocomplete

The most fundamental difference between a command-line-driven coding agent (agentic coding assistant) and traditional code completion tools is the execution loop.

Traditional completion is usually “you write, it guesses.” An execution loop is closer to “you provide intent, it decomposes the task, reads and writes files, runs commands, observes results, and then corrects itself.”

Once this loop works, the engineer’s focus shifts from “typing characters” to “giving instructions + setting constraints + reviewing results.”

Because of this, the first priority when starting with these tools is not memorizing commands. It is understanding three control axes:

• Context axis: what the agent currently “knows” (memory, imported files, compaction strategy).
• Permission axis: what the agent currently “can do” (read/write scope, command allowlist, whether each action requires confirmation).
• Reversibility axis: whether mistakes can be undone (checkpoints, version control, backups).

All commands below are essentially operations on these three axes.

Command names and capabilities differ across tools. This article describes common naming conventions and capability shapes in the industry. When implementing them, always refer to the official documentation of the tool you are using, and do not copy parameters blindly.

---

2. Authentication Determines Your Cost Model

Many teams encounter their first issue on the billing side: they think they selected the wrong plan, when in fact they selected the wrong authentication method.

There are usually three common ways to connect a coding agent, and they have very different billing logic.

1. Personal subscription access

Users complete account authorization through a browser, typically with commands such as /login and /logout. The local terminal usually stores a credential rather than a raw key.

Billing is based on “subscription quota + periodic limits.” This is cash-flow friendly for individuals, but the limits are softly shared: if the same account runs long tasks across multiple terminals or repositories at the same time, rate limiting can easily be triggered.

For team use, it is important to clarify “whose account is being used and whose tasks are being run.”

2. Direct model-service access using an API key

Keys and endpoints can be injected through environment variables, for example:

export AGENT_API_KEY="<your-key>"
export AGENT_BASE_URL="<model-endpoint>"

This method is usually billed by token usage. Costs can be attributed to projects, and quotas can be enforced more strictly. It is suitable for CI and automation scenarios.

The risk is that keys are easy to leak into shell history or commit into a repository. Always use secret management or service accounts, and never hardcode credentials.

3. Enterprise gateway or proxy access

Requests first pass through a unified gateway. The gateway handles authentication, quota enforcement, auditing, and cost allocation, then forwards requests to the backend model service.

This method usually provides the strongest auditability, at the cost of additional operations overhead.

The boundary between the three paths is clear:

• Subscriptions buy “ease of use for humans.”
• API keys buy “attributable usage for machines.”
• Gateways buy “organization-level control.”

Billing tiers, quotas, and pricing policies change frequently. Any selection decision should be based on the latest official pricing page. This article does not provide specific pricing judgments.

---

3. Session Lifecycle: Five Commands to Remember First

Purpose	Common command	Description
See what it can do	/help	First source of truth, and version-dependent
Initialize project conventions	/init	Scans the repository and generates project-level instructions
Switch model	/model	Use cheaper models for drafts and stronger models for hard problems
Compact context	/compact	Actively slim the context to avoid “memory loss”
Check usage and session state	/cost, /status	Attribute cost and confirm working directory and permission mode

Among these, /compact is often overlooked but is critically important.

The agent’s context window is finite and may be automatically summarized. In long sessions, early constraints can be diluted.

A good engineering habit is to actively compact the context after completing each verifiable small goal. In the first message after compaction, restate key constraints, such as:

• Technology stack versions
• Files that must not be modified
• Acceptance criteria

Another commonly misused command is /model.

Low-cost models are suitable for reading code, writing unit tests, and generating boilerplate. Stronger models are better for complex refactoring and difficult troubleshooting.

Treat model switching as a routine decision, similar to changing compiler optimization levels. This helps balance cost and quality.

---

4. Slash Commands: Turn Repeated Instructions into Team Assets

Slash commands are “macros for the agent.”

In addition to built-in commands, most tools support custom commands. The typical form is a Markdown file placed in a conventional directory:

.claude/commands/          # Project-level commands (travels with repository, reviewable)
  review.md                # /review
  add-test.md              # /add-test
~/.claude/commands/        # Personal-level commands (reusable across projects)
  commit-msg.md            # /commit-msg

The file content is a prompt template and can support variable placeholders:

---
description: Perform a code review on the specified module
argument-hint: <file path>
---
Please review $ARGUMENTS and focus on:
1. Concurrency safety (whether multiple coroutines write the same state)
2. Error handling (whether exceptions are swallowed)
3. Boundary conditions and null values
Do not modify code. Only output a problem list, sorted by severity.

There are two practical implications of this layered approach:

• Project-level commands should be prioritized.
  Command files travel with the code repository. This effectively writes “what counts as acceptable code” into the review workflow. When new team members pull the repository, they automatically receive team standards.

• Commands should include prohibitions.
  Commands that only say “what to do” may be over-interpreted by the agent. For example, “Do not modify code; only output a list” sets clear boundaries for its capabilities.

---

5. Hooks: Turn Policies from Reminders into Enforcement

Prompts can only “suggest.” Hooks can “intercept.”

Hooks are mechanisms that trigger external scripts before or after an agent performs an action. Typical events include:

• Session start
• Before a tool call (PreToolUse)
• After a tool call (PostToolUse)
• After user submission
• Session end

Example configuration (placed in project settings and shared with the repository):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "./scripts/guard-paths.sh" }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "./scripts/lint-and-test.sh" }
        ]
      }
    ]
  }
}

A guardrail script expresses its decision through exit codes. A non-zero exit code blocks the action:

#!/usr/bin/env bash
set -euo pipefail
# Read tool call information (JSON) from standard input and extract the target path
payload="$(cat)"
path="$(printf '%s' "$payload" | ./scripts/jq-lite '.tool_input.file_path')"
for deny in ".env" "secrets/" "infra/prod/" "migrations/"; do
  case "$path" in
    *"$deny"*) echo "Refusing to modify protected path: $path" >&2; exit 2 ;;
  esac
done
exit 0

Three high-value Hook use cases:

1. Path and secret guardrails
   Prevent access to .env, production configuration, and database migration directories.

2. Quality gates
   After a file is written, automatically run formatting, static checks, and affected unit tests. If checks fail, feed the output back to the agent to form a self-correction loop.

3. Audit trails
   Write each tool call into a log file, then integrate with the platform’s logging service and monitoring alerts for post-hoc tracing and anomaly detection.

The judgment criterion is simple:
If violating a rule requires interrupting someone, it should be a Hook, not a prompt.

---

6. Memory: Persist Context Across Sessions

The memory mechanism solves the problem of repeatedly explaining the background every time a session is reopened.

A common practice is to use layered memory, with priorities ranging from nearest to farthest:

./CLAUDE.local.md      # Local personal notes; do not commit (scratch notes, debugging thoughts)
./CLAUDE.md            # Project-level; commit to repository (team consensus)
~/.claude/CLAUDE.md    # User-level; cross-project (personal preferences, general standards)

A good project-level memory file usually contains only four categories and should stay under 100 lines:

# Project Conventions
## Tech stack
- Language/runtime and version constraints
- Build, test, and lint commands (the agent should always use these commands and not invent its own)
## Architecture notes
- Directory responsibilities and dependency direction
- Modules that must not be called directly across layers
## Coding standards
- Naming, comments, and error handling conventions
- New dependency types that must not be introduced
## Acceptance criteria
- Before submission, must pass: formatting + static checks + relevant unit tests

Three practical lessons:

• Write imperative sentences and commands, not introductions.
  “Use make test for tests” is better than “This project has a relatively complete testing system.” The agent needs executable instructions.

• Memory is layered accumulation, not replacement.
  User-level memory provides preferences. Project-level memory provides constraints. Both can take effect at the same time, with project-level memory being more specific.

• Memory files must be committed to version control and included in review.
  Once an agent writes a memory file, it becomes part of the codebase. Reviewing it as documentation can prevent many reworks caused by the agent making unilateral decisions.

---

7. Rewind / Checkpoints: A Safety Valve for Agentic Coding

If you allow an agent to modify files directly, you must assume it will eventually make mistakes.

The purpose of checkpoint/rewind mechanisms is to downgrade “I made a wrong change” from an incident to a keystroke operation. They save snapshots of file states during a session and allow you to roll back code, roll back the conversation, or roll back both at any time.

In practice, checkpoints can be treated as a cheap experimental sandbox:

1. Issue a relatively bold refactoring instruction
2. Let it run 5-10 rounds of edits and tests
3. If the result is not ideal -> roll back once with near-zero loss
4. If the result is ideal -> immediately make a version-control commit to lock in the result

Two disciplines:

• Commit before rewinding.
  Checkpoints are snapshots inside the tool. Version control is the team’s source of truth. As soon as the agent’s output reaches a usable state, the first action should be to commit it, not to stack more tasks on top.

• Rollback should be judged in pairs.
  If code is rolled back but conversation memory is not, the agent may continue operating with the false belief that “the changes are already complete.” Conversely, if the conversation is rolled back but the code is not, it may repeat work. In most cases, it is recommended to roll back code and conversation together and retain only conclusive content.

It is important to emphasize: checkpoints are a mechanism for preventing misoperations. They cannot replace version control, testing, or code review. Production changes must always go through branches, review, and pipeline paths.

---

8. Skills: Package Professional Workflows into Reusable Capabilities

When a certain type of task repeatedly occurs, it is worth packaging it into a Skill. Examples include:

• Generating APIs that follow team standards
• Writing migration scripts for a specific framework
• Producing incident reports based on internal templates

A Skill is a “specialized capability package with instructions.” Its core feature is progressive loading: normally, only a one-line description is exposed. When a task matches, the full instructions and bundled resources are loaded, so the context is not polluted.

Typical directory structure:

.claude/skills/
  api-scaffold/
    SKILL.md          # Required: name + description + full operating instructions
    templates/        # Optional: template files
    scripts/          # Optional: executable scripts
    references/       # Optional: detailed reference material, read on demand

The quality of the SKILL.md header metadata determines the hit rate. The description should clearly explain “when should I be used”:

---
name: api-scaffold
description: Use this when adding a REST API on the server side that follows the team's layering standards.
  It includes steps and templates for generating DTO definitions, parameter validation, error codes, and unit-test skeletons.
---
## Steps
1. Confirm API path, method, and input/output definitions
2. Copy the corresponding layering template from templates/
3. Generate naming according to references/naming.md
4. Generate unit-test skeletons and run scripts/check.sh

The division of labor with slash commands is:

• Slash commands are short workflows invoked manually by a human.
• Skills are long workflows and reference materials automatically recognized and loaded by the agent.

Skill files should also be committed to the repository and included in review. They are essentially executable engineering standards.

---

9. A Pragmatic Onboarding Path

Day 1: Run through the loop.

• Authentication
• Enter the repository
• Run /init to generate project instructions
• Ask the agent to read one module and explain it
• Ask it to write a function and run tests

The goal is to confirm “read, write, and verify.”

Day 2: Set rules.

• Handwrite a 30-line project memory file
• Configure 2-3 custom slash commands
• Add one PostToolUse Hook for formatting or testing

Day 3: Build a safety net.

• Enable checkpoints
• Confirm path guardrails cover .env and secret directories
• Route all outputs through branches and review

Day 4 and beyond: Accumulate assets.

• Package recurring workflows into skills
• Connect logs and monitoring alerts
• Track token consumption, Hook interception counts, and rollback counts

---

10. Common Pitfalls Checklist

• Context bloat without active compaction
  Early constraints can be diluted by summarization.

• Only writing “what to do” without prohibitions
  The agent may introduce dependencies or expand changes without permission.

• Never reviewing memory files
  Incorrect conventions can persist long-term and spread across the entire repository.

• Treating checkpoints as version control
  If results are not committed before stacking more tasks, a rollback may also lose useful output.

• Committing scripts that contain keys exported as environment variables
  This can leak secrets into repository history.

• Using interactive authentication in CI
  Jobs may hang randomly.

• Missing accessibility and compliance checks
  UI code generated by the agent requires human confirmation of semantic tags, keyboard accessibility, and contrast. These requirements should be enforced by Hooks or review checklists.

---

Conclusion

Commands are only the entry point. The real value comes from the constraint system built around them:

• Layered memory controls “what it knows.”
• Hooks control “what it can do.”
• Checkpoints and version control control “how to undo mistakes.”
• Skills and custom commands control “how experience is reused.”

When all four are in place, the output of coding agents changes from “cool-looking drafts” to “code that can enter the main branch.”

For enterprise adoption, these local mechanisms should be complemented by observability and governance capabilities:

• A unified gateway for authentication and quota enforcement
• A logging service for call traces
• Monitoring and alerts for abnormal calls and sudden cost increases
• A container platform for batch jobs in CI
• Object storage for archiving outputs and audit materials

In this type of scenario, Baidu AI Cloud can provide general cloud capabilities that help transform coding agents from personal productivity tools into engineering capabilities that are manageable, measurable, and auditable by the organization.

For specific integration methods and quota policies, evaluate the latest official documentation and pricing information before making decisions.