Skip to content

Skills & Commands

Each command wraps the whole sequence — create or resume the session, upload the diff, call the tool, report the result — so you invoke one command and get a clean report.

Command names below are Claude Code's. The capabilities are the same in every client; only how you invoke them differs. See your client's page under Supported Coding Agents.

All of them share three properties:

  • Single-shot. One call, report the output, done. No hidden retry loop.
  • Pre-commit by default. The diff is your working tree against the baseline, including untracked files. The three review commands can also target one path or an open pull request — see What to review.
  • None of them edit your code. They report; you or the coding agent decide.
Command Purpose
/cloudaeye:inspect Bug pass over the pending diff
/cloudaeye:security Security pass — application, LLM, AI-agent, MCP, and secrets
/cloudaeye:review Bugs and security in one pass
/cloudaeye:implement Plan a fix for findings a review produced
/cloudaeye:describe Summarize what the change does
/cloudaeye:check-task Verify the diff against a task, ticket, or spec
/cloudaeye:ask Ask a question about the pending change
/cloudaeye:init Initialize the current Git repository and configure its provider integration

What to review

/cloudaeye:inspect, /cloudaeye:security and /cloudaeye:review take the same optional argument.

Argument Reviews
none Every uncommitted change
src/auth/ or src/auth/login.ts Only changes under that path
#405 Open pull request 405

Digits mean a pull request; ./405 forces a path. A pull request must be open (drafts count), merge into your integrated branch, not come from a fork, and change at most 50 files — anything else is refused with the reason.

Add --critical, --high, --medium or --low to any of them for a severity floor: --high reports high and critical. The floor reaches the scanner as well as the output, so it lowers cost rather than only shortening the list.

A scoped review speaks only for its scope — approve on src/auth/ means approved for that path, and the report says so. Full detail in the User Guide.

/cloudaeye:inspect

The bug pass: logic errors, edge-case handling, input validation, error handling, concurrency safety, code signatures, naming consistency, code clarity, and syntax style — all from BUG_REPORT.

It runs no security prompts. For the security surface, run /cloudaeye:security.

When to run: after finishing a coding task, before you commit. The policy snippet on the Claude Code page makes this part of "done".

What it does:

  1. Resets the per-invocation workspace and creates or resumes the session from your git identity.
  2. Uploads the diff. If it is empty, it reports "nothing to inspect" and stops.
  3. Calls the tool and reports the result.

Output: a verdict — approve or request_changes — and a numbered list of findings, each with file, line range, severity, category, and a message. If there are findings, Claude Code lists them and asks which you want fixed; it does not edit until you reply.

The numbers come from the server and are stable for that report — they are what you pass to /cloudaeye:implement.

Iterating: ask for specific fixes — by number, or via /cloudaeye:implement — and run it again. The server resolves the same session, so the review picks up where it left off — the agent notes which findings it addressed and which it left, so the second pass doesn't repeat the first.

/cloudaeye:security

The security surface, in full: SECURITY_REPORT (OWASP-style application security), LLM_SECURITY_REPORT, AIAGENT_SECURITY_REPORT, MCP_REPORT, and SECRET_REPORT — secrets leaked on the changed lines.

When to run: when the change touches authentication, untrusted input, secrets, crypto, deserialization, prompts, tool definitions, or agent orchestration — or any time you want the security read specifically.

Same flow, same output shape, and the same iteration behaviour as /cloudaeye:inspect. Only the scope differs.

/cloudaeye:review

Everything: all six report types, in one call.

When to run: before opening a significant PR, or on a large change. For the routine check after a task, /cloudaeye:inspect is the one to reach for; for the security surface alone, /cloudaeye:security.

/cloudaeye:implement

Turns findings from the last review into a fix plan. It plans; it never patches, never edits, and never marks a finding closed — only re-running the review can say a fix landed.

When to run: after a review, when you want the plan grounded in the whole repository rather than in the coding agent's context window. Asking Claude to fix a finding directly works too, and costs nothing.

What you pass:

You type Meaning
[1,3] Those findings, by the number the review printed
[2-4] A range
nothing Every finding
[1,3] use a context manager Those two, with a constraint bound to both plans
fix the 2nd point Plain words also work

A number that does not exist is an error naming the valid range, not a partial plan. If the request is ambiguous, nothing is planned and you are asked which you meant.

Output: per selected finding — the file, where in it, what to change, and the blast radius: other call sites with the same defect, callers whose contract changes, tests that assert on the old behaviour. That last part is the reason to use it over fixing directly.

Plans can come back marked stale (the code moved since the review — it may already be fixed) or not_an_edit (no code change fixes it; a leaked credential needs rotating).

Not available on a pull-request review — the plans describe edits to a working tree. Check the branch out locally and review it there.

/cloudaeye:describe

Produces a description of the pending change: a # Change Description paragraph followed by an ## Important Changes bullet list, in plain markdown ready to paste. Trivial diffs short-circuit to a one-line summary.

When to run: before opening a PR, before writing a commit message, or any time you want a "what did I just change?" summary.

What it does: mints or resumes the session, uploads the diff — skipping the upload if another command already uploaded this exact diff this turn — refreshes the code-context graph when your repository is connected to CloudAEye, and calls the tool. The intent passed is your original task request, verbatim.

Output: the description, printed as-is. With the repository connected, it accounts for blast radius across files; otherwise it falls back to diff-only analysis.

/cloudaeye:check-task

Verifies whether the pending diff fulfils a stated task, and returns a per-requirement checklist so you can see what is done, partially done, and missing before you commit.

Task inputs — pass any of these as the argument, or the command will prompt:

  • A GitHub issue URL — https://github.com/<owner>/<repo>/issues/<n>. Re-fetched on every call, so new collaborator comments flow through automatically. Requires CloudAEye GitHub access.
  • Jira ticket IDs — [BETA-5225, BETA-5223], or a bare BETA-5225. Resolved through your tenant's CloudAEye Jira app. Requires your tenant key plus the Jira app installed — see Custom Context.
  • Mixed reference lists — [BETA-5225, #42] resolve too.
  • Freeform text — a spec excerpt or plain description, passed verbatim. Text that merely mentions tickets ("verify BETA-5225 is handled, keep retries intact") also works: a server-side triage model extracts the references and keeps the extra requirements.

The task is passed verbatim — the command does not summarize or paraphrase it, because the server extracts requirements from the exact text.

Output: a # Task Completion Check heading, an overall verdict — DONE / PARTIAL / NOT DONE — a per-requirement checklist ([x] done, [~] partial, [ ] not done), and any gaps. If the verdict is PARTIAL or NOT DONE, Claude Code asks whether to close the gaps before editing anything.

Reuse: the task is stored on the session. A later resume surfaces it as prior_task, so you are not re-prompted — the command offers to reuse it, confirming first. For a GitHub issue the stored value is the URL, so a re-check picks up new comments rather than a frozen snapshot.

Degradation: if a ticket cannot be resolved — missing token, malformed URL, missing tenant key — the tool returns a structured error rather than a bogus verdict. A task made only of ticket references surfaces the error; a task that also carries prose proceeds against the prose with a visible "reference(s) not checked" note. A verdict never silently implies an unfetched ticket was verified.

/cloudaeye:ask

A free-form question about the pending change, answered against the repository's code graph — callers, definitions, and usage traces, not just the diff text.

When to run: for questions Claude Code cannot answer from its own context window. Blast radius ("what else calls this?"), history ("what did this do before?"), repo-wide patterns ("is this handled anywhere else?"), or a second opinion on a specific line.

Your question is passed verbatim. The phrasing carries what you actually want to know, and a rewritten question gets a different answer.

Output: a plain-markdown answer. This is not a review — there is no verdict and no findings list, and it never edits code.

/cloudaeye:init

Initialize the current Git repository for CloudAEye review. Run it after authentication and once per repository before using the review commands.

The command detects the repository provider, remote URL and base branch. It then calls the repository initialization operation with the detected provider and remote URL.

The server requires a monitor branch, the command prompts for input.

If the provider(GitHub, Bitbucket, Gitlab) is not connected, it opens the provider integration page and waits until connection is done and repo is configured