skills/opus-2nd/SKILL.md
Second opinion from Claude Opus on a plan or approach. Use when: (1) Planning phase of /big-plan needs a higher-quality review than /codex-2nd, (2) User says 'opus 2nd' or 'opus opinion', (3) Wanting Anthropic's larger model to critique a plan. Spawns a general-purpose Agent with model: opus that reads the plan file and returns structured feedback. Anthropic quota — not free.
npx skillsauth add takazudo/claude-resources opus-2ndInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Provide a second opinion on a development plan by spawning a general-purpose Agent with model: opus. Mirrors the Sonnet-subagent pattern already used by /big-plan's Step 9 verification, just with Opus.
$ARGUMENTS is the absolute path to the plan markdown file (and optionally extra free-text context after the path).
Invoke the Agent tool with:
subagent_type: general-purposemodel: opusdescription: Opus 2nd opinion on planprompt: the self-contained prompt template in Step 2 below, with $ARGUMENTS substituted into the plan path.You are providing an independent Opus second opinion on a development plan.
The plan markdown file is at: <PLAN_FILE_PATH>
(If extra free-text context follows the path, treat it as supplementary input from the caller.)
Read the plan file. If it references source GitHub issues you need to understand intent, fetch them with `gh issue view <number>` (if `gh` is unavailable — e.g. Claude Code web — use the GitHub MCP issue-read tool instead, or rely on the plan file's Source section summaries).
Answer concretely:
1. Are there any risks, edge cases, or correctness traps in this approach?
2. Is the sub-task breakdown sound? Any sub-task too large, too coupled, or too vague to start without questions?
3. Are there missing sub-tasks or hidden dependencies the plan glossed over?
4. Is the dependency order correct? Can more sub-tasks run in parallel? Are the wave assignments sensible?
5. Are any items from the plan's "Original requirements checklist" missing from the sub-tasks?
6. Is there a simpler or materially better alternative worth flagging?
Be concise and practical. Focus on actionable feedback. If the plan looks solid, say so briefly — do not invent problems to look thorough.
Return a single markdown response with this shape:
## Opus review
### Verdict
<one-sentence overall judgment: solid / minor revisions / significant rework>
### Concrete suggestions
- <suggestion 1>
- ...
### Risks / edge cases
- <risk 1>
- ...
### Missing or under-specified
- <gap 1>
- ...
Omit any subsection with nothing to report rather than padding it with filler.
Read-only — do not edit any files. The caller decides what to incorporate.
When this skill is called from /big-plan's Step 9 (verification), replace the review-questions block with the verification questions/report format specified in that step instead.
The Agent's response IS the review. Hand it back to the caller verbatim or under a ### Opus review / ### Opus verification subsection of the caller's review log.
/codex-2nd. Justify the cost with concrete, actionable feedback~ in paths — use $HOMEtools
Acceptance gate for a branch produced by an OpenAI Codex CLI run — usually Codex implementing a /big-plan epic that was handed off to it. Codex reports the work 'done' (or the user flags it WIP with corrections); this skill confirms the branch actually fulfils the original spec, fixes what falls short, and routes larger discoveries into GitHub issues. Use when: (1) User says '/finalize-codex-work', 'finalize codex work', 'confirm the codex work', 'check the codex branch', or 'codex said it's done', (2) A branch is the result of a Codex CLI session and needs verification against its spec issue/PR, (3) After assigning a /big-plan epic to Codex CLI. Pass -m/--merge to run /pr-complete -c at the end.
tools
Read a Figma design node directly from a share URL via the Figma REST API — no Dev Mode subscription, no MCP, no desktop app. Renders the node to PNG and dumps its full style/layout JSON so the design can be described, compared, or implemented. Use whenever the user gives a Figma design URL (figma.com/design/... or /file/...) and wants to see, read, inspect, reference, or implement that node — including `/fig-url-refer <url>`. This is the URL-based counterpart to `/figrefer` (which needs a Dev-plan desktop MCP); prefer this one when the input is a URL rather than a live desktop selection.
tools
Sync the user's Claude Code workflow skills into the OpenAI Codex CLI settings repo ($HOME/.codex) as Codex-native ports, fix the Codex .gitignore for new local state, then commit and push. Use when: (1) user says '/dev-codex-sync-settings-from-claude', 'sync codex settings', 'sync claude skills to codex', 'port skills to codex', or 'update codex from claude'; (2) after updating ~/.claude workflow skills (big-plan, x, x-as-pr, x-wt-teams) and Codex should catch up; (3) the $HOME/.codex repo has drifted behind $HOME/.claude. The ports are condensed Codex-native REWRITES, never file copies.
development
Analyze a video file (mov, mp4, webm, etc.) or a YouTube video by extracting still frames with ffmpeg and reading them chronologically with vision — Claude cannot ingest video files directly. Use whenever the user provides a video file path or YouTube URL and wants to know what happens in it: "read this video", "watch this video", "check this recording", "what happens in this .mov/.mp4", analyzing a screen recording of a UI bug, or verifying UI behavior captured in a video, even if they don't name this skill.