From ritual
Use to finalize work — commits remaining changes, pushes branch, opens a PR with conventional title and structured body
npx claudepluginhub yanekyuk/arcana --plugin ritualThis skill is limited to using the following tools:
You are finalizing work and opening a pull request.
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.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
You are finalizing work and opening a pull request.
Read docs/ritual-config.json and extract:
Integration flags (store for use in later steps):
integrations.githubIssues → add Closes #N lines to PR bodyintegrations.linear → add Linear issue refs to PR bodyintegrations.coderabbit → add CodeRabbit review-requested note to PR bodyDirectives: 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.
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.
git push -u origin HEAD
If push fails, retry once. If still failing, report the error and stop.
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:
git log --oneline main..HEAD to understand the commit historygit diff main...HEAD --stat to see which files changedmain 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>
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
If the handoff frontmatter contains a milestone field, assign the PR to that milestone after creation.
gh pr create output.gh api repos/:owner/:repo/milestones --jq '.[] | select(.title=="<milestone-title>") | .number'
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.