원클릭으로
gh-pr-opener
Open a conservative Robot SF PR with scope verification, freshness checks, and artifact discipline.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Open a conservative Robot SF PR with scope verification, freshness checks, and artifact discipline.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | gh-pr-opener |
| description | Open a conservative Robot SF PR with scope verification, freshness checks, and artifact discipline. |
| category | github-pr |
| kind | atomic |
| phase | context |
| requires_write | true |
| requires_slurm | false |
| requires_benchmark_artifacts | false |
| delegates_to | [] |
| output_schema | skill_run_summary.v1 |
Use this when a branch is ready for PR handoff and must follow Repository-grade evidence rules.
Fail-closed policy: do not open a PR until scope is implemented, proof is fresh, and artifacts are classified.
Freshness check:
uv run python scripts/dev/pr_ready_freshness.py status --base-ref origin/main --require-clean-treePR_READY_MODE=final BASE_REF=origin/main scripts/dev/pr_ready_check.sh; the wrapper records
clean committed-HEAD freshness after all gates pass.BASE_REF=origin/main scripts/dev/pr_ready_check.sh only for interim dirty-tree
feedback before PR handoff.Confirm branch/issue alignment.
Verify scope completion and linked issue status.
Sync latest origin/main, then rebase/merge according to repo policy.
Recheck readiness freshness post-sync.
Classify generated artifacts from output/ (discard/ignored/cache/durable evidence).
Run the review audit checklist for changed workflow/skill area.
Build PR body from .github/PULL_REQUEST_TEMPLATE/pr_default.md.
Downstream Propagation instead of leaving it implicit.
Check the parent issue, claim map or benchmark report, leaderboard or artifact catalog,
registry or config index, context index or memory note, and follow-up issue rows.Not applicable because: rationale so the
omission is intentional and reviewable.Open a ready PR by default using
gh pr create --base main --head <branch> --title "<type>: <summary> (#<n>)" --body-file <prepared_body.md>.
Use --draft only when the user explicitly requests draft status or when the branch is an
intentional handoff with incomplete validation, unresolved scope, or another clearly documented
reason that should block review.
For an existing PR, update its body with
uv run python scripts/dev/gh_pr_body_rest.py <pr-number> --repo ll7/robot_sf_ll7 --body-file <prepared_body.md>;
do not use gh pr edit --body-file while it queries retired Projects Classic fields.
For label operations on issues or PRs, use
uv run python scripts/dev/gh_pr_label_rest.py add <number> --label <name> --repo ll7/robot_sf_ll7
or
uv run python scripts/dev/gh_pr_label_rest.py remove <number> --label <name> --repo ll7/robot_sf_ll7
instead of gh pr edit --add-label / gh issue edit --label which route through the same
deprecated Projects Classic GraphQL path.
Keep parent issue open unless repository policy indicates closure wording in PR description.
output/; use manifests or external artifact pointers.Use this skill for the scope named in its frontmatter description and registry metadata.
.agents/skills/skills.yaml.Return the schema named by the output_schema frontmatter field, or a compact equivalent when the caller does not require YAML.
Use for an autonomous Robot SF issue-to-PR loop that selects eligible GitHub issues, implements one scoped issue at a time, validates, pushes, and opens PRs.
Guarded PR merger; merges merge-ready PRs after verifying label, CI status, branch protection, and preflight checks.
Use for an autonomous Robot SF PR review loop that fixes scoped review gaps, validates proof, resolves review threads, and applies merge-ready; not for merging.
Autonomous issue-to-PR workflow from next eligible issue to ready PR with consistent metadata handling.
Continuous goal autopilot; orchestrates implement, review, merge, and discover cycles with preflight validation and delegation failure recovery.
Clarify ambiguous GitHub issues by tightening scope and acceptance criteria, proposing solution options with pros/cons, and marking decision-required issues when maintainer input is needed.