Menu
This skill should be used when the user asks to "review PR
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
This skill provides the source-of-truth GitHub conventions, the gh CLI cookbook, and the settings schema that every Octoperator action consults. It should be loaded whenever Octoperator turns a request into GitHub artifacts — when the user asks to "plan an epic", "create an issue", "implement an issue", "review a PR", or "sync project status", or otherwise works with GitHub epics, issues, sub-issues, milestones, branches, pull requests, reviews, or Projects v2 board updates. It is the shared knowledge layer, not a substitute for the action skills that perform the writes.
This skill should be used when the user asks to "implement issue
This skill should be used when the user asks "what should we build next", "research improvements for this repo", "propose new features", "what should we refactor", "find tech debt", "what's missing in this project", "find things to improve", or invokes /octoperator:research. Analyzes the repository and produces a ranked list of proposed work across new features, refactoring, tech debt, test coverage, docs, and DX — not just new features — optionally filing them as GitHub issues.
This skill should be used when the user asks to "run autopilot", "keep shipping until there's nothing left", "drain the ready issues automatically", "autopilot this repo", or invokes /octoperator:autopilot. Bounded orchestrator that loops over the lifecycle — discover work, run auto (implement -> review -> merge), and when no work remains, research proposes more.
This skill should be used when the user asks to "auto-ship issue
This skill should be used when the user asks to "set up octoperator", "configure octoperator", "octoperator setup", "bootstrap octoperator settings", "initialize the project board", "create the octoperator config", or invokes /octoperator:setup. Detects the repo, probes whether the token can access Projects v2, optionally selects or creates a board, and writes .claude/octoperator.local.md. Projects is treated as optional and auto-detected.
| name | review |
| description | This skill should be used when the user asks to "review PR |
| argument-hint | <pr-number> [--approve|--request-changes|--comment] [--dry-run] |
| allowed-tools | Bash(gh:*), Bash(git:*), Read, Task |
| version | 0.1.0 |
Produce a structured review of a pull request and post it to GitHub, preserving the review as a
durable artifact. Follow the github-conventions skill for the review recipe and the self-approval
constraint. Octoperator is autonomous: post immediately unless --dry-run is passed.
Load settings. Read .claude/octoperator.local.md for repo. Take the PR number from the
argument.
Gather context. Fetch PR metadata and diff:
gh pr view <pr#> --repo <repo> --json title,author,body,headRefName,baseRefName,files,additions,deletions
and gh pr diff <pr#> --repo <repo>.
Run the reviewer. Dispatch the pr-reviewer agent (Task tool) with the PR metadata and diff. It
returns structured findings (each with severity, path:line, explanation, suggested fix) and an
overall verdict (approve / request_changes / comment).
Resolve the review action. An explicit --approve/--request-changes/--comment flag wins;
otherwise use the agent's verdict. Self-approval guard: if the PR author equals the
authenticated user (gh api user --jq '.login'), GitHub forbids APPROVE and REQUEST_CHANGES —
downgrade to --comment and state the intended verdict in the body.
Dry-run gate. If --dry-run is present, print the assembled review body and the chosen action,
then stop without posting.
Post the review. Format the body as Markdown: a one-line verdict, then findings grouped by
severity with path:line references and suggested fixes. Post with the resolved action:
gh pr review <pr#> --repo <repo> --comment --body "<body>" # or
gh pr review <pr#> --repo <repo> --approve --body "<body>" # or
gh pr review <pr#> --repo <repo> --request-changes --body "<body>"
Report. Print the verdict, the count of findings by severity, and the PR URL.
path:line; this is reliable across all repos.
Inline line comments are optional and require the REST review API (see the cookbook).