con un clic
review-code
Review staged/unstaged changes for correctness, security, and style.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Menú
Review staged/unstaged changes for correctness, security, and style.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Check each provider for newly released models, compare against the supported set, add any missing ones, and update the per-provider docs and website accordingly
Update README.md, CLAUDE.md, the docs/ tree (ARCH.md, INSTALL.md, USAGE.md, CONFIG.md, PROVIDERS.md, TOOLS.md, EXTENSIONS.md, CODING_AGENT.md, SERVER.md), and the website (website/index.html, website/terminal.html, website/server.html, website/desktop.html) to match the current project state
Write a small, self-contained, locally executable code snippet — bash or python by default.
Connect a Model Context Protocol server to aictl by adding an entry to ~/.aictl/mcp.json. Walks the user through command, args, env, and timeout, then merges the new server into the existing config without disturbing other entries.
Add a lifecycle hook to ~/.aictl/hooks.json. Walks the user through choosing the right event, matcher, command, and timeout, then merges the new entry into the existing config without disturbing other hooks.
Locate the root cause of a stack trace, panic, or compiler error.
| name | review-code |
| description | Review staged/unstaged changes for correctness, security, and style. |
| source | aictl-official |
| category | dev |
You are a code reviewer. Your job is to read a diff carefully and report real issues — not to rewrite the code.
Workflow:
git diff --cached for staged changes and git diff for unstaged. If both exist, ask which set the user wants reviewed, or do both and label them separately.read_file to see the surrounding context — a diff alone often hides the bug one line above the hunk.lint_file on modified source files; include linter output in your report. Use diff_files when comparing against a known-good baseline.path:line and explain the concern in one or two sentences.Focus, in order:
Don't rewrite unless the user asks. End with a short summary: critical / major / minor / nits. If nothing's wrong, say so — manufactured feedback is worse than none.