Skill

run-open-pr

Use to finalize work — commits remaining changes, pushes branch, opens a PR with conventional title and structured body

Install

npx claudepluginhub yanekyuk/arcana --plugin ritual

Tool Access

This skill is limited to using the following tools:

ReadBashGrep

Preview

You are finalizing work and opening a pull request.

SKILL.md

Similar Skills

using-git-worktrees

Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.

superpowers

168.3k

subagent-driven-development

3 files

Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.

superpowers

168.3k

dispatching-parallel-agents

Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.

superpowers

168.3k

Stats

Parent Repo Stars1

Parent Repo Forks0

Last CommitApr 20, 2026

Actions

View Source View Plugin View on GitHub View README

Open PR

You are finalizing work and opening a pull request.

Step 0: Load config

Read docs/ritual-config.json and extract:

Integration flags (store for use in later steps):

integrations.githubIssues → add Closes #N lines to PR body
integrations.linear → add Linear issue refs to PR body
integrations.coderabbit → add CodeRabbit review-requested note to PR body

Directives: Read directives.delivery from the config. These are soft guidelines that influence PR conventions, merge preferences, and changelog notes. Apply them when building the PR title and body. If the field is missing or empty, proceed without directives.

If the config file does not exist, proceed without integration features or directives.

Step 1: Stage and commit any remaining changes

git status

If there are unstaged changes, review git status output first. Do NOT stage files matching .env, credentials*, *.key, or other sensitive patterns. Stage specific files:

git add <specific-changed-files>
git commit -m "<type>: <final changes description>"

Use Conventional Commits format. Valid types: feat, fix, refactor, docs, test, chore, ci, perf, style, build. The <type> should match the handoff classification.

Step 2: Push

git push -u origin HEAD

If push fails, retry once. If still failing, report the error and stop.

Step 3: Determine PR content

Determine the worktree folder name from the current directory:

basename "$PWD"

Read docs/handoffs/<folder-name>.md for trigger and scope context. Extract the base-branch field from the frontmatter — this is the branch the PR should target. If base-branch is not present, default to main.

If the handoff file does not exist (e.g., it was already git rm'd by the orchestrator pipeline), derive context from git instead:

Run git log --oneline main..HEAD to understand the commit history
Run git diff main...HEAD --stat to see which files changed
Infer the work type from commit prefixes (feat/fix/refactor/docs)
Build the PR title and body from the commit messages and diff summary
Use main as the base branch (handoff is unavailable to determine the original base)

Title format: <type>: <short description> where type comes from the handoff type field (or inferred from commits if handoff is missing).

Body: Use this template:

## Summary
<What changed and why, derived from handoff scope>

## Changes
<Bulleted list of key changes>

## Test Plan
<How this was tested — list test files and what they cover>

## Knowledge Warnings
<Any clash-check warnings from the pipeline, or "None">

Integration-driven sections (add these when the corresponding integration is enabled):

If integrations.githubIssues is true and the handoff (or Related Issues section) contains GitHub issue numbers:

## Closes
Closes #<issue-number>

Add one Closes #N line per related GitHub issue. GitHub will automatically link and close these issues when the PR is merged.

If integrations.linear is true and the handoff contains Linear issue references:

## Linear Issues
- <LINEAR-ID>: <issue title>

If integrations.coderabbit is true:

## Review
CodeRabbit review has been requested for this PR.

If run-sync-docs detected that CLAUDE.md might need updating, add a section:

## Recommended CLAUDE.md Updates
<Suggested changes for human review>

Step 4: Create PR

gh pr create --title "<title>" --body "<body>" --base <base-branch>

Use the base-branch value extracted from the handoff frontmatter in Step 3. If no base-branch was found (handoff missing or field absent), use main.

If this is a WIP (pipeline stopped early), use:

gh pr create --title "[WIP] <title>" --body "<body>" --base <base-branch> --draft

Step 4b: Assign milestone to PR

If the handoff frontmatter contains a milestone field, assign the PR to that milestone after creation.

Get the PR number from the gh pr create output.
Find the milestone number by title:

gh api repos/:owner/:repo/milestones --jq '.[] | select(.title=="<milestone-title>") | .number'

Assign the milestone to the PR:

gh api repos/:owner/:repo/issues/<pr-number> -X PATCH -F milestone=<milestone-number>

If the milestone is not found (e.g., it was closed or deleted), log a warning and continue without assignment. Do not block PR creation.

Report the PR URL when done.