Skip to content

Skills & Commands

Skills are slash commands your coding agent runs. Each wraps the full sequence — create/resume the session, upload the diff, call the MCP tool, surface the result — so you invoke one command and get a clean report.

All skills share three properties:

  • Single-shot. One call, report the output, done. No hidden retry loop.
  • Pre-commit. The diff is always git diff (working tree vs HEAD).
  • Intent-carrying. Each call passes a one-paragraph intent describing the change the agent just made. This focuses the review and, for Inspect, is the only way to tell the reviewer to leave a prior finding alone.
Command Purpose
/inspect Flag bugs and security-essential issues in the diff
/describe Summarize what the change does
/check_task Verify the diff against a task, ticket, or spec
/security_review Security-focused review across all security report types
/review The full review — every report type and category

/inspect

A single-shot inspect pass over the pending diff. Runs the 10-category INSPECT configuration — the essentials from BUG_REPORT and SECURITY_REPORT (logic errors, edge cases, input validation, concurrency, error handling, naming, code clarity, code signatures, auth/access, and injection).

When to run: after finishing a coding task, before you commit. The project policy snippet (Setup, Step 4) makes this part of "done".

What it does: 1. Resets the per-invocation workspace and creates/resumes the session from git identity. 2. Uploads git diff. If the diff is empty, it reports "nothing to inspect" and stops. 3. Writes a one-paragraph intent describing this round of edits (not the broader task). 4. Calls inspect_diff and reports the result.

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

Iterate: ask the agent to fix specific findings and run /inspect again. Because the session is keyed by (repo, branch, head), the server resumes it automatically. On re-inspection the agent writes a sharper intent — which prior findings it addressed and how, and which it intentionally left.

/describe

Produces a description of the pending change using describe_change. Returns plain markdown — a # Change Description paragraph followed by an ## Important Changes bullet list — meant for direct consumption. Trivial diffs short-circuit to a one-line "Trivial change —" 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/resumes the session, uploads the diff (skipping the upload if another skill already uploaded this exact diff this turn), refreshes the code-context graph when your repository is connected to CloudAEye, and calls describe_change. The intent passed is your original task request, verbatim.

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

/check_task

Verifies whether the pending diff fulfils a stated task, using check_task. 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 skill will prompt):

  • GitHub issue URL — https://github.com/<owner>/<repo>/issues/<n>. Fetched by CloudAEye and 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 CLOUDAEYE_TENANT_KEY in your environment plus the CloudAEye 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 skill does not summarize or paraphrase it, because the server extracts requirements from the exact text.

Output: the report field, printed as-is — 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, the agent asks whether to close the gaps before editing.

Persistence & reuse: the task is stored on the session. A later resume surfaces it as prior_task, so you are not re-prompted — the skill 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.

Graceful degradation: if a ticket can't be resolved (missing token, malformed URL, missing tenant key), the tool returns a structured error rather than a bogus verdict. A task that is only ticket refs 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.

/review and /security_review

These two share the exact same flow as /inspect — reset the workspace, create/resume the session, upload git diff, write a one-paragraph intent, call the tool, and report a verdict plus findings. The only difference is scope: they enable more report types and run a wider, deeper pass.

  • /review — the comprehensive pass: "contains all". Every report type and every category in one run, for a full pre-commit review before a significant PR or on a large change.
  • /security_review — a security-focused pass that enables the full security surface rather than just the essentials: SECURITY_REPORT (OWASP-style application security), LLM_SECURITY_REPORT, AIAGENT_SECURITY_REPORT, and MCP_REPORT. Intended for changes that touch authentication, input handling, deserialization, secrets, prompts, tool definitions, or agent orchestration.

Because the flow is identical to /inspect, everything on this page about sessions, intent, output, and iteration applies to both — only the enabled report types change.

For a fast, essentials-only check, run /inspect — it covers the auth_and_access and injection_protection security essentials.