菜单
Use when a verified owner-worker branch is ready to publish, or when an open pull request needs blocking lifecycle management through CI failures, review feedback, conflicts, and merge.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Write or rewrite concise reviewer-first pull request titles and descriptions for Pardes manager publication. Use approved intent, owner reports, conditional verifier reports, and narrow factual details without filler.
Use when a completed or active Codex coding session should be evaluated as a workflow run, especially to identify where orchestration skills, sub-agent delegation, worktree routing, verification handoffs, PR monitoring, or compaction recovery worked well or caused friction.
Use when a user installs the Codex workstreams plugin, asks to set it up, or sees permission prompts for workstream checkpoints, reports, or temporary pull-request body files.
Use when a coding objective spans multiple workflow phases or pull requests and needs a persistent manager to coordinate investigation, architecture, planning, implementation, verification, PR creation, review feedback, and merge gates across a long-running session.
Use when an approved PR-sized coding goal needs execution through an owner worker and optional supporting workers in manually managed Git worktrees.
Use when a coding task is not understood well enough to choose an implementation direction, including broad feature requests, unfamiliar code paths, bugs with multiple plausible causes, and work that benefits from parallel read-only exploration before architecture or planning.
基于 SOC 职业分类
| name | run-pr-cycle |
| description | Use when a verified owner-worker branch is ready to publish, or when an open pull request needs blocking lifecycle management through CI failures, review feedback, conflicts, and merge. |
Publish a verified owner-worker branch, hand the pull request to the user, and block until GitHub reports activity that needs attention.
write-pr-description.gh, write the PR body to
${CODEX_ARTIFACTS_DIR:-$HOME/codex-artifacts}/pr-bodies/codex-pr-body-<branch-slug>.md,
pass it with --body-file <path>, and delete it immediately after GitHub
accepts the pull request. Do not use a system temporary directory or the
ignored .worktrees/ directory.gh pr create command simple so persisted prefix
approval can match it. Do not embed a multiline body with $'...', a
heredoc, redirection, command substitution, or a pipeline.gh pr view --web <pr-url>.
Run this outside the sandbox because it launches a host GUI.The manager publishes. Workers commit but do not push. Never amend, force-push, or merge.
Run the monitor outside the sandbox from the outset because gh needs local
authentication and GitHub access:
uv run "<run-pr-cycle-skill>/scripts/watch_pr.py" <pr-url>
The helper always blocks until attention is required. Give the shell command a wait of at least 30 minutes when the tool supports a timeout. If the shell yields a running session, block on that process with long waits. Do not create a model-side polling loop.
When the helper returns, treat its JSON as an immediate notification. Read
attention, action_types, and observation before deciding what to do next.
observation: initial_snapshot means an actionable state was already present
when monitoring began; it does not mean the helper is still waiting.
The helper stores machine state at:
${CODEX_HOME:-$HOME/.codex}/state/pr-monitor/github.com/<org>/<repo>/<number>/state.json
ci_failed: route the failing logs to the owner worker.conflict: route conflict resolution to the owner worker.merged: delete the completed PR's workstream note, sync the primary
checkout with the repository's normal workflow, and continue the next
approved PR automatically. Do not rebase active independent worker branches.
Create a fresh minimal note only if another approved PR remains.closed_unmerged: stop and ask the user how to proceed.After worker fixes, use verify-change, push the new commits, and start one
fresh blocking monitor.
The helper ignores unsubmitted draft reviews, green CI, pending CI transitions, routine head updates, bare approvals, deployment-bot conversation comments, and pre-existing discussion when it creates a new state file. It batches review bursts before returning.