菜单
Use when scanning latest upstream OpenAI Codex commits, PRs, releases, or changelog entries to decide which items deserve a GitHub bundle, code analysis, upstream-impact classification, site signal, or Publisher handoff evidence.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | codex-upstream-triage |
| description | Use when scanning latest upstream OpenAI Codex commits, PRs, releases, or changelog entries to decide which items deserve a GitHub bundle, code analysis, upstream-impact classification, site signal, or Publisher handoff evidence. |
Use this skill before deep analysis. Its job is to route the deterministic upstream review queue: group upstream Codex commits correctly, identify likely surfaces, and choose the next artifact without deciding final impact.
This is a Decodex repository-development instruction surface, not an installable Decodex plugin skill.
automations/radar/skills/codex-code-analysis/SKILL.mdautomations/radar/skills/codex-release-analysis/SKILL.mdopenai/codexUse the lightest source that can answer the triage question:
For normal Radar operation, start from upstream_review_queue/v1, scan recent
upstream commits first, and resolve each commit back to a PR when possible. A commit
list is a queue for understanding and classification, not final evidence.
For release or prerelease work, compare metadata is a rollup index over the commit/PR history already being analyzed. Do not let a release tag displace the underlying commit and PR evidence.
Classify each item as exactly one:
| Decision | Meaning | Next step |
|---|---|---|
skip | AI review confirms internal churn with no safe user or Decodex implication. | Keep ledger trace only. |
watch | Interesting but too weak, too hidden, or too broad. | Optional upstream_impact/v1 with control_plane_impact = "watch". |
bundle | Enough GitHub context exists for code analysis. | Build or reuse a github_change_bundle/v1. |
release_review | Release or changelog framing needs comparison against commits and signals. | Use codex-release-analysis. |
style_reference | Useful only as style or audience evidence. | Save no technical artifact; use only as optional style context when a separate source-backed publication candidate exists. |
confirmed claims.Escalate to codex-code-analysis when changed files or release text mention:
Escalate to codex-release-analysis when the source is a release, prerelease, app
update, or public changelog. For Codex releases and prereleases, summarize from prior
commit/PR analysis whenever possible, then use compare data to find gaps.
Record a Publisher angle only after there is technical source evidence. Style references from X must not start a Publisher handoff by themselves.
Return a compact triage note with:
Do not draft signal_entry/v1 or control_plane_upgrade_candidate/v1 directly from
this skill. Do not treat
deterministic queue hints as technical claims. The durable review layer is
upstream_review/v1; public and Control Plane artifacts are promotions from that
source-backed review.
Use when routing Decodex work.
Use when publishing a checked `social_candidate/v1` or explicit operator handoff to @decodexspace, or writing the matching `social_post/v1` non-published record.
Use when Decodex X Publisher needs to decide whether an artifact-backed @decodexspace post or generated media is worth publishing.
Use when reading upstream OpenAI Codex PR, commit, file, or patch evidence to understand what changed, whether it is user-visible, and how it affects Decodex Radar, Control Plane, Publisher, or follow-up engineering.
Use when evaluating upstream Codex releases, prereleases, app updates, or changelog entries and deciding what Radar evidence Decodex should publish, watch, or absorb from the release.
Use when turning a reviewed GitHub bundle and code-analysis result into a Decodex signal draft, especially for writing or updating the local editorial analysis JSON that feeds `radar render-signal`.