Core Commands and Practical Guide for AI Coding Agents

Agentic coding is transforming how developers work: instead of relying solely on line-by-line completion, developers express intent via natural language, and AI coding agents handle retrieval, modification, verification, and summarization. To keep this collaboration stable and controllable, core commands serve as the most crucial control plane. A quick start isn’t about mechanically memorizing commands, but understanding the boundaries of their capabilities: which operations require explicit triggers, which capabilities can be reused, which phases need auditing, and which states must be recoverable. This article outlines the core commands and practical onboarding for AI coding agents from a neutral, general technical perspective.

1. Understanding the Entry Point: Slash Commands as the Explicit Control Plane

Slash commands typically appear in the format /command_name [parameters] and are used to explicitly trigger a specific workflow. Unlike natural language instructions, slash commands are more predictable, easier to audit, and better suited for repeated execution. Natural language is ideal for expressing ambiguous intent, whereas slash commands excel at executing deterministic operations.

Common command categories can be summarized as:

• Session: Viewing current state, switching working modes, cleaning or compressing context;
• Skill: Listing available skills, invoking a specific skill, viewing skill documentation;
• Checkpoint: Creating restore points, viewing checkpoints, rolling back to a specific state;
• Configuration: Viewing authentication methods, metering metrics, permissions, and budget status;
• Audit: Viewing hook trigger logs, tool call logs, and error summaries.

Schematic commands are shown below to illustrate the structure; actual command names and parameters should follow the tool’s official documentation:

/help
/skill_list
/skill_name [parameters]
/memory view
/checkpoint create
/rollback <checkpoint_id>
/config view

Command design should follow several principles: clear semantics, verifiable parameters, explainable failures, and rollbackable operations. Especially for commands involving file modifications, bulk refactoring, and external tool calls, sufficient confirmation and audit information must be provided to prevent the agent from executing continuously in an uncertain state.

2. Skill Invocation: Encapsulating Reusable Workflows into Capability Packages

Skills can be understood as reusable units for specific tasks, typically including task descriptions, input constraints, available tools, permission scopes, output specifications, and failure rollback strategies. A skill can be manually invoked via syntax like /skill_name, or routed on-demand by the agent during a natural language task. The value of manual invocation lies in its high determinism: it is suitable for high-risk modifications, standardized generation, and batch checks. Automatic routing, on the other hand, is better for exploratory tasks.

A maintainable skill should meet the following criteria:

1. Single Responsibility: One skill solves one type of problem, avoiding “almighty skills” that blur boundaries;
2. Clear I/O Contracts: Specify what context is needed, what results are produced, and how to validate them;
3. Minimum Privilege: Only grant the tools and directories necessary to complete the task;
4. Rollbackable Failures: Define timeout, retry, manual confirmation, and rollback conditions;
5. Observable: Log invocation reasons, key parameters, change summaries, and validation results.

The relationship between skills and commands can be summarized as: commands are the entry points, skills are the capability packages. Commands handle “triggering,” while skills handle “how to accomplish.” Distilling frequent, stable, and verifiable processes into skills can significantly reduce repetitive prompting and human omissions.

3. Hooks: Building Guardrails on Lifecycle Events

Hooks are used to execute validation logic on key lifecycle events during a session or tool call. Common events include session start, before/after tool calls, before/after file writes, before/after command execution, and session end. The primary value of hooks is not to replace business logic, but to establish guardrails: auditing changes, checking for sensitive information, executing formatting, intercepting dangerous operations, and logging costs and exceptions.

Hook design should follow:

• Idempotent: Repeated triggers should not produce side effects;
• Fail Fast: Provide clear reasons when validation fails;
• Observable: Log trigger time, input summaries, results, and duration;
• Disableable: Can be quickly turned off if issues arise to avoid blocking the main process;
• Minimum Privilege: Hooks themselves should not have excessive file or network permissions.

Schematic pseudo-configuration:

on_tool_call_before:
  validate_policy()
  record_audit()
on_file_write_after:
  run_formatter()
  check_sensitive_info()

Hooks are suitable as “goalkeepers,” not as “heavy pipelines.” Hooks that take too long will slow down interactions. It is recommended to offload complex checks to independent pipelines and feed the summarized results back.

4. Memory: Hierarchical Context Management to Prevent Pollution

Memory mechanisms reduce the cost of repeatedly explaining background context. It can generally be divided into short-term session memory, long-term project memory, and user preference memory. Short-term memory saves the current task context; project memory saves architectural conventions, directory norms, test commands, and domain terminology; user preferences save interaction styles and common constraints.

The key risks with memory are expiration, conflicts, and privacy leaks. In practice, you should: write explicitly rather than implicitly accumulating; version and review project memory; keep sensitive information out of the repository; provide commands to view, clean, and correct memory; and verify that memory is still valid before starting critical tasks. Context budget also needs management: load summaries and indexes first, then read details on demand, avoiding dumping irrelevant files entirely into the context.

5. Rollback: Ensuring Recoverability with Checkpoints

Rollback capabilities typically exist in the form of checkpoints: creating state snapshots before refactoring, bulk modifications, or agent-autonomous execution, and rolling back to a known good state if deviations occur. Rollback is not a replacement for version control, but a rapid recovery mechanism during human-machine collaboration. The best practice is “automatically create checkpoints at key nodes + manually create checkpoints for high-risk operations,” used in conjunction with version control commits, test results, and change summaries.

Schematic workflow:

/checkpoint create pre_modification_baseline
/skill_name batch_refactor
/test run
/rollback <checkpoint_id>

After a rollback, re-validation is mandatory because rolling back might affect dependencies, caches, or generated artifacts. Checkpoint naming should include time, task, and reason for easier auditing.

6. Authentication and Billing: How Auth Methods Define Metering

The authentication method for AI coding agents usually affects usage metering and cost attribution. Common methods include: pay-as-you-go access keys, subscription seat models, and enterprise single sign-on (SSO). Pay-as-you-go is suitable for evaluation and small-scale usage; subscriptions fit stable teams; enterprise SSO suits organizations with strict permission and audit requirements. Specific billing rules may adjust with service strategies, so always refer to the actual service terms and usage management portal.

Cost control can be approached from several angles: choosing models based on task complexity; trimming context to avoid invalid loading; reducing unnecessary tool call loops; setting budget alerts for batch tasks; and using hooks to log abnormal retries and high-consumption operations. Cost governance is not merely about minimizing usage, but establishing an explainable balance among quality, latency, and cost.

7. Quick Start Workflow

It is recommended to establish a reusable workflow following these steps:

1. Define task boundaries and acceptance criteria;
2. Complete authentication configuration and confirm metering metrics and budget;
3. Review command and skill inventories, and select explicit entry points;
4. Write necessary project memory and constraints;
5. Create checkpoints before high-risk operations;
6. Execute in small steps, running tests or static checks at each step;
7. Use hooks to log audit information and sensitive operations;
8. Roll back and re-verify if deviations occur;
9. Distill stable workflows into skills and documentation.

8. Common Pitfalls and Best Practices

Common pitfalls include: treating commands as universal switches; making skill granularity too coarse to be verifiable; letting hooks block the main process; failing to clean memory long-term, causing pollution; using rollback as a substitute for version control; and ignoring usage and budgets. Best practices are: minimum privilege, explicit triggering, observability, rollbackability, reusability, and documentation. Core commands are just entry points; true efficiency stems from the systematic combination of skills, hooks, memory, and rollback mechanisms.