Getting Started with Agentic Coding Tools: Core Slash Commands and Configuration Practices

Most teams first judge a command-line AI coding agent on a single question: can it write correct code? Once the tool becomes part of daily development, the bottlenecks move fast. The context window fills up with conversation history. The model drifts away from project conventions during long tasks. One wrong edit is hard to undo. And different team members get different behavior on their own machines.

So what you need to set up at the start is not a bag of prompt tricks, but a mental model of three things: how the agent is billed, how you control it within a session, and how you keep its behavior consistent across projects. These correspond to choosing an access method, using session-level commands, and setting up configuration and automation.

The features and terminology described here are common to agentic coding CLIs in general. Command names and configuration keys may vary slightly from one implementation to another, so always check your tool’s own help output.

Integration Options and Billing: Choose the Path First, Then Optimize

How you connect determines how you are billed, and the billing model in turn shapes how you use the tool. There are three common paths.

Path 1: Model platform API key (pay-as-you-go)
You connect directly to a model service with an API key, and usage is metered in tokens through the cloud provider’s console. There is no long-term commitment, keys can be isolated per project, and you can evaluate an agent’s capabilities before committing to a subscription. The risk is that long-running tasks can quickly run up costs, so you need organization-level budget alerts and a key rotation policy.

Path 2: Subscription plan
A monthly fee gives you a usage allowance, often together with access to higher-tier models and team management features. It suits individual developers and small teams with heavy, predictable usage. Quotas are usually counted over a rolling window rather than a calendar month, so evaluate them against your actual concurrency and task volume.

Path 3: Cloud-managed or enterprise gateway
Keys and quotas are consolidated on the platform side, and a gateway handles authentication, rate limiting, auditing, and cost allocation centrally. This is the more practical option for mid-sized and large enterprises. It keeps API keys from spreading across individual machines and brings agent usage into your existing observability stack. For example, on Baidu AI Cloud, enterprises can complete model access, key management, and usage monitoring through its enterprise model platform. Developers then only need to configure a unified endpoint and credentials.

Recommendations:

• Start with Path 1 to validate value. Measure real token consumption with representative task samples before deciding whether to switch to a subscription or a shared gateway.
• Never store keys in a repository, whichever path you choose. Inject them through environment variables or a system credential manager instead.
• Check whether prompt caching is available. Re-reading the same large file cuts input cost and latency significantly when prompt caching is enabled.
• Check the context compaction strategy. Automatic compaction is better than manually clearing the session, but compaction itself also consumes tokens.

Slash Commands: Your Control Panel for Sessions and Context

Slash commands are the dashboard you use to interact with the agent in a session. They fall into five categories.

Context Management

• Check context usage: see what share of the current window is taken by the system prompt, tool definitions, file contents, and conversation history. Make checking this a habit during long tasks. Once context usage exceeds roughly 70%, the model’s ability to follow instructions drops noticeably.
• Compact the history: summarize earlier messages and tool results to free up space while keeping key decisions. Use this when a task is well underway and you don’t want to start over.
• Clear the session: a full reset. It’s the cheapest and cleanest option when switching tasks.

Task and Plan Management

• Plan mode (analyze first, act later): the agent investigates the codebase in read-only mode and produces an implementation plan. It edits code only after you approve the plan. This approach is most valuable for multi-file refactors.
• Parallel subtasks: independent research is handed off to sub-agents, each with its own context, and only their conclusions are returned to the main session. This significantly reduces main-context pollution.

Permissions and Trust

• Permission management: view and edit the tool allow and deny lists. A good starting point is “allow read-only operations, require confirmation for writes,” then loosen the rules gradually as you gain confidence.
• Mode switching: choose between step-by-step confirmation, auto-accepting edits, and full autonomy. Use the high-autonomy modes only for tasks that are protected by version control and have a clearly defined scope.

Configuration and Environment

• Switch models: complex architectural design and large-scale mechanical changes benefit from different model tiers. Matching the model to task difficulty is the more cost-effective choice.
• Inspect extensions and hooks: list the custom commands, skills, hooks, and memory sources that are loaded. This is the first thing to check when you wonder why the agent isn’t behaving as expected.

Session Assets

• Roll back (rewind): see the “Checkpoints and Rewind” section below.
• Export and share: export a session as text to attach the agent’s reasoning to a code review, or to use as retrospective material for the team.

Layered Configuration: Make Agent Behavior Versionable

Inconsistent agent behavior almost always comes from scattered configuration. The standard approach is to set up clear layers with a defined precedence (from lowest to highest):

Layer	Location	Typical use	Version-controlled
User	Config directory in the home directory	Personal preferences: theme, default model, editor habits	No
Project	Config directory inside the repository	Shared by the team: permission allowlist, environment variables, hooks, commands	Yes
Local project	In the repository, but gitignored	Personal experiments: temporarily loosened permissions, debug hooks	No

The key practice: commit only what the team agrees on. Allowing npm test and npm run lint is team consensus. git push --force should never be on an allowlist.

Example (project-level permission configuration, illustrative):

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

The deny list is your last line of defense and takes precedence over any auto-accept mode. Always explicitly deny secret files and destructive commands.

Hooks: Turning Conventions from Reminders into Rules

Slash commands only do something when you type them. Hooks fire automatically when an event occurs, which makes them essential for actually enforcing engineering conventions.

Common event semantics (naming varies by implementation):

• Before a tool call: validate or rewrite the command about to run. For example, block a git commit when the tests haven’t been run.
• After a tool call: format code and run static checks. For example, format files automatically after an edit, then let the agent fix any issues based on the result.
• Session start: inject environment information such as the current branch, dependency versions, and a list of files pending migration.
• Subtask complete: summarize the results and update the task board.
• Stop / notification: send a desktop or messaging notification when a task finishes or needs your decision.

Example (formatting hook, illustrative):

{
  "hooks": {
    "post_tool_use": [
      {
        "matcher": "Edit|Write",
        "command": "npx prettier --write \"$CLAUDE_FILE_PATH\" && npm run lint --silent"
      }
    ]
  }
}

Three design principles:

1. Keep hooks fast and idempotent. A single hook that takes more than a few seconds noticeably slows down the interaction.
2. Make failures explainable. The exit code and standard output are passed back to the agent, so a clear error message is far more useful than a silent failure.
3. Never run dangerous operations in hooks. Hooks run with your user permissions, which effectively grants configuration files unsupervised, automated execution power. Be especially careful with hook configurations from third-party repositories. Inspect the hooks and command definitions before cloning an unfamiliar repo.

Memory: Carry Project Conventions Across Sessions

Memory is how an agent “remembers” a project. At its core, it consists of instruction files in the repository that are loaded in layers:

• Project memory: committed to the repository. It documents the tech stack, directory conventions, build and test commands, prohibitions, and code style. It’s the single source of truth shared by every new team member, human or agent.
• User memory: applies only to you. It records personal preferences, such as “reply in Chinese” or “give me a diff instead of the whole file.”
• Local private memory: not committed. It holds temporary context for the branch you’re currently working on.
• Imports: reference other files with @relative/path to split long documents across multiple files and keep any single file from growing too large.

How to write a high-quality memory file:

# Project conventions
## Tech stack
Backend service A (language/framework), frontend B, database C.
## Common commands
- Install dependencies: `<cmd>`
- Unit tests: `<cmd>` (must pass before committing)
- Full check: `<cmd>`
## Directory conventions
- `src/<domain>/`: code is split into packages by business domain; do not reference another domain's internal implementation directly
- New endpoints must be documented in `docs/api/` at the same time
## Prohibited
- Do not modify code under `src/legacy/` unless the task explicitly requires it
- Do not add runtime dependencies; prefer the standard library
- Never commit `.env` files or any credentials
## Style
Commit messages follow Conventional Commits; public functions must have type annotations and docstrings.

The core rule: record information the model cannot infer from the code. Build commands, domain terminology, the reasoning behind past decisions, and prohibitions are worth writing down. Implementation details that can be read directly from the code don’t need to be recorded; they only take up valuable context.

Checkpoints and Rewind: Make Autonomous Execution Safe

This is the line between demonstrating an agentic workflow and running it in production. A single agent task can modify a dozen or more files. Without the ability to roll back, every mistake means manually cleaning up with git checkout.

Typical implementations offer two levels of rollback:

• Revert code only: undo file changes while keeping the conversation history. Use this when the direction is right but the implementation has flaws.
• Revert code and conversation together: return to an earlier point in the session, with the discarded branch kept in the sidebar so you can retrieve it. Use this when the approach was wrong and you need to rethink and start over.

Practical tips:

1. Checkpoints are not a replacement for version control. They provide snapshot-level protection at the operating-system level, while a meaningful change history should still rely on Git. The two work together: after rolling back, lock in what’s worth keeping with small commits.
2. Start with a clean working tree. If there are already uncommitted changes, rollback semantics become ambiguous, so commit or stash your work before starting a task.
3. Combine checkpoints with hooks for verification. Run tests automatically on the session-end event, so deciding whether to roll back is based on evidence rather than guesswork.

Skills (Custom Commands): Productize Repetitive Workflows

Skills are reusable sets of instructions stored as directories in the repository and invoked with /command-name. The difference from memory is that memory is always-on background knowledge, while a skill is an execution playbook triggered on demand.

A typical structure (illustrative):

.claude/commands/
├── add-endpoint.md      # Full steps for adding a CRUD endpoint
├── migrate-db.md        # Database migration workflow
├── review-pr.md         # Code review following team conventions
└── release.md           # Release checklist

A high-quality command file should include a goal (what the result should look like), preconditions (required inputs), steps (numbered, actionable actions), constraints (prohibited actions and a rollback strategy), and acceptance criteria (how to tell the task is complete).

Example:

---
description: Add a REST endpoint following project conventions
argument-hint: <resource-name>
---
Add a complete CRUD endpoint for the `$1` resource.
Steps:
1. Create handler, service, and repository files for the resource under `src/<domain>/`
2. Reuse the existing validation middleware; do not add dependencies
3. Write unit tests covering the success case, invalid input, and a missing resource
4. Document the endpoint in `docs/api/`
Constraints:
- Do not modify any file under `src/legacy/`
- If you think a new dependency is needed, stop and explain why; wait for my confirmation
Acceptance: `<test-command>` passes in full, with no lint warnings.

Three lessons for designing skills: give each command a single responsibility, list prohibited actions explicitly rather than only describing the goal, and declare parameterized inputs at the top so the model doesn’t have to guess.

Using the Agent from the IDE and the Terminal Together

In most teams, the practical setup is long-running tasks and automation in the terminal, with small edits and code reviews in the IDE. If you adopt an IDE plugin, check three things. First, does it share the same configuration and hooks as the CLI? If not, behavior will be inconsistent between the two. Second, can you view diffs and jump directly to the relevant code inside the editor? Third, can you pass selected text as context without polluting the main session? Sharing a configuration directory is key, because two separately maintained copies will inevitably drift apart.

Rollout Checklist and Common Pitfalls

A phased rollout

1. Read-only (1 week): allow only read and search operations, and block writes. See how accurately the agent understands your real repositories.
2. Controlled writes (2–4 weeks): allow edits with step-by-step confirmation, configure the deny list, and write the first version of your memory file.
3. Automation: add hooks for formatting and testing, and turn high-frequency workflows into skills.
4. Scale: connect an enterprise gateway and bring agent usage under auditing, cost allocation, and compliance controls.

Four common mistakes

• Treating context as unlimited: not checking context usage or compacting in time, so the agent’s ability to follow instructions drops sharply later in a task.
• Writing memory like an encyclopedia: including everything that can be read from the code, which crowds out useful context.
• Enabling full autonomy by default: once a task involves builds, deployments, or data operations, the risks far outweigh the benefits.
• Keeping configuration out of version control: every team member ends up with different behavior, problems can’t be reproduced, and the team can’t build on what it learns.

Conclusion

The value of an agentic coding tool doesn’t come from the quality of any single generation. It comes from whether you can constrain it into an engineering component that is predictable, reversible, and auditable. Access and billing define your cost limits. Slash commands control each session. Configuration and hooks determine default behavior. Memory holds project knowledge. Checkpoints protect you from mistakes. Skills turn experience into reusable assets. Build these six layers one by one, and the tool becomes genuine infrastructure for your team rather than just an interesting assistant.