AI Coding Assistant CLI Quick Commands: Command Reference and Practical Guide

1. From Chat to Commands: What This Article Solves

When an AI coding assistant enters a real development workflow, pure natural-language conversation creates three types of problems: context bloat causes early constraints to be forgotten; high-risk operations such as deletion, overwrite, and configuration modification lack a confirmation entry point; task splitting, parallel processing, rollback, and review lack a unified entry point. CLI quick commands abstract these high-frequency actions into stable commands, allowing assistants to be operated like other engineering tools.

This article answers three questions:

• What quick commands are: the command and parameter boundaries corresponding to each capability.
• How to use them: command examples, prerequisites, and expected output.
• Common mistakes and cautions: context pollution, parallel write conflicts, overly broad permissions, and uncontrolled cost.

Command names use the / prefix for illustration and are not tied to a specific product. When adopting them in your team’s toolchain, only the names need to be replaced.

2. Design Goals

A usable command system is not about having more commands. It should converge on four goals:

1. Lower input cost: compress repeated descriptions such as “plan before executing”, “do not modify files”, and “keep key conclusions” into short commands.
2. Improve result determinism: /plan means produce a plan without modifying files; /review means analyze diffs without committing. Clearer semantic boundaries make outcomes more predictable.
3. Make context usage budgetable: support compression, summarization, retention of key items, and usage visualization so context is loaded by task phase instead of being filled at once.
4. Ensure safety and traceability: force confirmation for high-risk operations and leave traces; command combinations can be reproduced as fixed workflows.

3. Core Capabilities: Command Examples and Expected Output

1. Status Checks and Health Checks

The purpose is not to execute tasks but to troubleshoot: an incorrect working directory may prevent the assistant from reading project files; overly narrow permissions may cause tool calls to fail silently; model switching may cause code-style drift.

Command example	Key parameters	Prerequisites	Expected output
/status	--verbose	None	Current model, working directory, login identity, permission scope, loaded skills/plugins, and version
/status --doctor	--fix	Write permission	Health check items such as configuration conflicts, missing dependencies, and out-of-scope directories, plus repair suggestions

Use this as a prerequisite action for complex tasks. First confirm whether the directory is the target repository, whether the model is suitable for the task, and whether permissions are sufficient.

2. Project Initialization and Project Memory

To generate code that follows project conventions, an assistant must know the directory structure, dependency management, test commands, coding standards, and branching/release process.

Command example	Key parameters	Prerequisites	Expected output
/init	--scope with project, user, or session	Repository root directory; write permission	Skeleton of project documentation: goals, technology stack, directory responsibilities, common commands, directories that must not be modified, and notes on sensitive configuration
/memory add	--scope project	Same as above	Add one team-level stable convention

Scope boundaries should be clear: project-level stores team consensus, user-level stores personal preferences, and session-level stores only temporary context. This prevents personal preferences from polluting project rules. Memory should be updated after architecture changes, dependency upgrades, or release-process changes; otherwise the assistant may base advice on stale information.

3. Task Inspection and Background Execution

Command example	Key parameters	Prerequisites	Expected output
/tasks	--status with running, done, or failed	None	Task ID, type, creation time, status, progress summary, output summary, and dependencies
/tasks stop <id>	--force	Task belongs to the current session	Stop confirmation and explanation of side effects already produced
/tasks logs <id>	--tail 200	None	Tail of the log with the specified number of lines

Parallel tasks must record dependencies: defect localization is a prerequisite for the fix task, and a patch is a prerequisite for the test task. If dependencies are unclear, results may overwrite each other.

4. Subagents and Parallel Splitting

Command example	Key parameters	Prerequisites	Expected output
/agents	--json	None	Subtask list, file scope of each subtask, and status
/agents new	--files src/a/**	Plan confirmed	Create a new subtask and bind it to an exclusive file scope
/agents edit / /agents delete	--id <id>	Subtask not started	Modify or remove a subtask

Four principles for splitting:

• Each subtask has clear inputs, outputs, and acceptance criteria.
• Write operations are mutually exclusive by file scope; the same batch of files is not modified concurrently.
• Results must be aggregated and reviewed before entering the main branch; they cannot be directly concatenated.
• Key decisions remain in the main session and require human confirmation.

5. Context Compression and Summary Retention

Statistics definition: usage rate = actual prompt tokens sent in the current request ÷ model context window limit. Token count comes from the tool status bar or the prompt_tokens field returned by the API. Historical messages not included in the current request are not counted.

Observable trigger signals. Compress when any of the following occurs; do not rely on intuition:

• The tool shows context usage approaching the limit.
• Responses to the same question become noticeably slower for two consecutive rounds.
• The assistant starts violating early constraints or asks you to paste the same code again.
• Token count for a single request grows several times compared with the task start.

Command example	Key parameters	Prerequisites	Expected output
/context	--breakdown	None	Usage rate and source distribution: project background, logs, code snippets, and conversation history
/compact	--keep followed by items such as API contracts, failure cases, and rollback points; --drop followed by items such as duplicate logs and intermediate reasoning	Task is at a stable checkpoint	Structured summary: goals, completed/uncompleted items, key files and modification points, confirmed conventions, unresolved issues, acceptance criteria, and hard user constraints

Compression is not truncation; it is selective retention. Visualization helps determine whether project background or log accumulation is using too much context, which helps build a phase-based loading budget mindset.

6. Planning and Execution Separation

Command example	Key parameters	Prerequisites	Expected output
/plan <task description>	--allow-read	None	Problem definition and impact scope, files involved, candidate solutions and trade-offs, implementation steps, validation method, rollback strategy, and risks requiring human confirmation
/plan add "change only the service layer and do not introduce new dependencies"	None	In planning mode	Add a constraint and reconverge the plan
/exec	--confirm	Plan confirmed	Execute according to the plan and report changes file by file

The value of making decisions upfront is that discovering a misunderstanding during planning costs far less than rolling back after dozens of files have been modified. Tasks involving permissions, database schemas, or release processes should especially go through planning mode.

7. Code Review and Diff Analysis

Command example	Key parameters	Prerequisites	Expected output
/review	--base main; --scope staged or branch	A diff baseline exists	Issue list divided into three categories: blocking, advisory, and observational. Each item includes location, reason, and fix suggestion.
/review --fix-safe	--backup; --run-tests	Write allowed; hooks enabled	Fix only low-risk items, with backup path and test results

Blocking issues (clear defects, data-loss risk, permission bypass, or critical test failures) must be fixed before continuing. Advisory issues are handled according to project standards. Observational items need further validation. Automatic fixes must not bypass version control and must not overwrite unsaved content.

8. Model Selection and Reasoning Depth

Task type	Recommended model tier	Latency/cost trade-off	Switching record
Format conversion, comment generation, simple queries	Lightweight	Lowest latency and cost; quality is sufficient	No record needed; use as default tier
Daily completion, single-file refactoring	Balanced	Quality/cost compromise	Record in project default configuration
Cross-module refactoring, complex defect localization	High reasoning	Latency and cost rise noticeably; reduce round trips	Record task ID and duration comparison
Security audit, architecture design, pre-release review	High reasoning plus high reasoning depth	Highest cost; only for high-risk decisions	Record reason, impact scope, and conclusion
Large-scale mechanical rewriting	Lightweight plus parallel subtasks	Low cost per task; total cost grows linearly with quantity	Record batch and failure rate

Reasoning depth should not be enabled by default. The same project should maintain stable models and configurations at the same stage; otherwise review standards and code style will fluctuate. When a switch is required, record the reason and impact scope.

9. Permissions and Security Boundaries

Command example	Key parameters	Prerequisites	Expected output
/permissions list	--scope project	None	Current readable/writable directories, command allowlist, and network/external system authorization
/permissions deny <path>	--recursive	Admin identity	Deny rule written to configuration and effective immediately
/permissions audit	--since 7d	Log retention enabled	High-risk operation records: operator, time, command, target, and result

Follow the least-privilege principle: grant only the permissions necessary for the current task. Deletion, overwrite, batch rename, configuration modification, dependency installation, and environment variable reading require secondary confirmation by default. Secrets, tokens, certificates, and database passwords should not enter the context. When they must be referenced, use placeholders and let a controlled environment perform the actual call.

10. External System Connections and Tool Protocols

Command example	Key parameters	Prerequisites	Expected output
/mcp list	--auth-status	None	Connected services, authentication status, available tools, and call scope
/mcp test <server>	--tool <name>	Valid credentials	Connectivity and permission verification results
/mcp revoke <server>	--confirm	Admin identity	Revoke authorization and clear local credentials

Data minimization should be specific: by default, pass only field names and aggregate values, not raw rows; when samples are needed, use sampling with a fixed seed and replace identifier fields such as user ID, phone number, address, email, and token; queries should prefer structured APIs or SQL aggregation and limit result set size to fewer than a hundred rows; large results should first be written to a summary file for the assistant to read. External connections are suitable for auxiliary analysis; merges, releases, and database changes still require human approval.

11. Hooks and Automated Checks

Command example	Key parameters	Prerequisites	Expected output
/hooks list	--event pre-write,post-write,pre-commit	None	Events, scripts, timeouts, and failure policies
/hooks add post-write "make lint && make test-unit"	--risk high; --timeout 300	Script is executable	Register a hook and output a pass/fail summary after execution

Configure by risk level: run the fast lane of formatting and static checks for low-risk tasks; run full tests and builds for high-risk tasks. Avoid both extremes: too strict causes small changes to trigger long builds; too loose allows defects to flow into later stages.

12. Skill Packages and Workflow Reuse

Command example	Key parameters	Prerequisites	Expected output
/skills	--version; --category review,test,release	None	Loaded skill packages, versions, and applicable scenarios
/skills run code-review	--input diff.patch	A diff exists	Issue list in the required format and validation method

Skill packages must specify inputs, output formats, and execution steps; otherwise they degrade into vague suggestions. When team standards change, bump the version to avoid old rules remaining effective long-term.

13. Feedback, Help, and Custom Commands

Naming convention: verb + object + constraint. The verb expresses intent, the object defines scope, and the constraint limits behavior. Use lowercase and hyphen separation, and make each command do only one thing:

• /review-diff-blocker: review a diff and output only blocking issues, sorted by severity.
• /gen-test-edge: generate tests for a specified function, covering only boundary and exception branches, without modifying source code.
• /compact-keep-contract: compress context while keeping API contracts, failure cases, and rollback points; drop duplicate logs and intermediate reasoning.

Command example	Key parameters	Prerequisites	Expected output
/help	--category context, review, or perm	None	Searchable, categorized command descriptions and examples
/custom add <name> <template>	--output-format markdown	Configuration write permission	Register a custom command
/feedback	--attach-context	None	When submitting an issue, automatically attach task description, key output, error summary, model configuration, and runtime environment

4. Typical Workflow: A Pseudocommand Sequence

/status --doctor                     # confirm directory, model, and permissions
/init --scope project                # read or generate project notes and memory layers
/context --breakdown                 # record baseline usage rate as a budget reference
/plan fix login-state expiration --allow-read # produce a plan only; require human confirmation
/permissions list                    # confirm write scope covers only the service layer
/agents new --files src/auth/**      # split into localization, fix, test, and docs
/tasks --status running              # observe dependencies and progress; avoid duplicate launches
/review --base main                  # output by category: blocking / advisory / observational
/hooks add post-write "make test-unit" --risk high
/context                             # compress when trigger signals appear
/compact --keep API contracts,failure cases,rollback points

At the end, keep the task goal, final conclusion, key changes, unresolved issues, and follow-up suggestions to facilitate handoff and continuation in the next session.

5. Common Risks and Pre-Release Checklist

Risks concentrate in five areas:

• Context pollution: unrelated logs and stale conclusions enter the context; load by phase and compress regularly.
• Over-automation: automatic commits amplify errors; add human confirmation, patch previews, and test gates for high-risk operations.
• Parallel write conflicts: assign each subtask an exclusive file scope and serialize write operations.
• Overly broad permissions: authorize by project, role, and task type, and review periodically.
• Cost overrun: establish context budgets, model tiers, and task tiers, and review usage regularly.

Pre-release checklist:

• Permissions: write scope and command allowlist are narrowed for the current task, with no temporarily opened directories.
• Context budget: baseline and current usage rates are recorded, and key constraints are retained separately.
• Rollback point: a confirmed stable checkpoint or patch backup exists.
• Audit log: model version, command input, output summary, and change diff are traceable.
• Test gate: unit tests, static checks, and format checks all pass, with no skipped hooks.
• External calls: data minimization is completed, sensitive fields do not enter the context, and write operations are approved by a human.

6. Best Practices

• Unify and continuously maintain project documentation.
• Separate planning, execution, review, and rollback into independent stages; avoid a single long chain.
• Prefer structured output such as issue lists, patch summaries, test reports, and risk lists for easier downstream processing.
• Increase reasoning depth for high-risk tasks and keep regular tasks lightweight.
• Turn common operations into custom commands or skill packages.
• Periodically review context strategy, permissions, model configuration, and hook rules to prevent configuration drift.

7. Summary

The essence of CLI quick commands for AI coding assistants is to turn open-ended AI interaction into a manageable, auditable, and reusable engineering process. They solve more than input convenience: they address context governance, task orchestration, security control, cost optimization, and quality assurance. Truly effective AI-assisted coding does not give the assistant unlimited freedom. It uses stable commands, clear boundaries, and verifiable expected output to keep the assistant producing reliable results within a controlled scope.