Use when the user asks Codex to review a repository for improvement opportunities, feature inspiration, roadmap ideas, or implementation candidates before planning changes; exclude direct implementation-only, factual/explanation, trivial, or explicit no-plan requests.
SkillScore32Maintained
Automatic
◆Product Management pack
Last verified 8/24/2026
What it changes
Passed 3 of 9 test cases with the skill, and 2 of 9 without it.
Without skill23%
With skill32%
Checks it passed that the model alone missed
Sets source_tool to web
Places Auto-complete as the final option in the choice list
Places Other as the second-to-last option in the choice list
and 3 more in the full report
5 fixed2 passed either way12 still failing3 broke
Pass-rate lift
+9 pp
Tokens
+2%
Agent turns
0%
Response time
-36%
Model gemini-3.6-flashMeasured 8/24/2026v17 of 22 cases passed with skill · 9 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
When searching for UI design patterns on GitHub via web browser searches, what value should be populated in the schema field tracking the tool source?
What was checked, without and with the skill
Checked
Without skill
With skill
Sets source_tool to web
Missed
Passed
case-19 · gemini-3.6-flash · 8/24/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md34 linessingle file
Review And Plan
Discover opportunities first; implementation still goes through ../optim-plans/SKILL.md.
Required Flow
Inspect the target Git repo before asking product questions. Read the app shape, docs, tests, dependency files, entry points, recent change notes, and any obvious UX or safety-critical paths.
Search GitHub open-source projects for feature inspiration before ranking opportunities. Use gh search repos / gh search code when available; if gh is unavailable or unauthenticated, use the GitHub REST/search API or web search constrained to GitHub repository pages. Record sources either way.
Produce a ranked opportunity list grouped exactly by:
Documentation
Efficiency/cost
Feature completeness
UX
Safety/recoverability
For each opportunity, include stable fields:
id: stable ID such as OPP-001
category: one group above
rank: rank within category or overall list
title
repo_evidence: local file/behavior evidence
repository_url: GitHub source repository URL
supported_claim: concise claim supported by that source
source_tool: gh, github-api, or web
Ask one case-by-case opportunity question at a time before any accepted opportunity enters implementation scope. Use only planning-stage generic controller-backed choice questions.
Each opportunity question must recommend one disposition first: accept, defer, or reject, with evidence. Offer the other dispositions as alternatives, then Other second-last, then Auto-complete last.
Treat Auto-complete as acceptance of the recommended planning disposition only. It never approves execution.
Route accepted opportunity IDs into the normal optim-plans flow: PLAN_v1.md, refinement, immutable execution manifest approval, execution, validation, controller verification, and integration gates.
Hard Boundaries
Do not ask about preferences the repo or cited sources can answer.
Do not implement from the opportunity list directly.
Do not bypass execution approval, manifest binding, validator review, controller verification, path audits, or final integration checks.
If a GitHub source only loosely inspires an idea, say that in supported_claim; do not overstate the source.