| name | making-prs |
| description | Use when creating a pull request, preparing changes for review, or pushing work to GitHub. Handles quality checks, branch management, conventional commits, openspec archival, and PR creation end-to-end. |
| license | MIT |
| metadata | {"author":"Robert Hafner","source":"https://github.com/tedivm/opencode-config"} |
Quick start
Run quality checks, verify openspec status, create a feature branch, commit with conventional format, and open a PR.
Workflow
1. Run Quality Checks
Load and execute the quality-checks skill to ensure all tests, lints, and formatting pass before proceeding. Do not skip this step.
If quality checks fail, fix everything until the full suite passes green. Only continue to step 2 once all checks pass.
2. Check OpenSpec Proposal Status
If the project uses OpenSpec (check for .openspec/ directory or openspec.json):
- Run
openspec list --json to find active changes.
- Identify the change relevant to the current work (match by name or title).
- Check if the change has been archived:
- If
openspec list shows the change as active (not archived), ask the user: "The OpenSpec proposal [name] is still active. Should I archive it before creating the PR?"
- If the user says yes, look for an openspec archive skill (e.g.,
openspec-archive) and load it to handle the archival. If no archive skill exists, fall back to running openspec archive <change-name> --yes.
- If the user says no, proceed without archiving.
- If no active changes exist or the change is already archived, proceed.
3. Branch Management
- Get the default branch:
git symbolic-ref refs/remotes/origin/HEAD or check git remote show origin for the HEAD branch.
- Get the current branch:
git branch --show-current.
- If the current branch is the default branch:
- Generate a descriptive branch name from the changes using
git diff --stat --cached or git status --short.
- Use conventional prefix format:
feat/..., fix/..., chore/..., refactor/..., docs/....
- Create and checkout the new branch:
git checkout -b <branch-name>.
- If already on a non-default branch, proceed.
4. Stage and Commit
-
Stage all changes: git add -A.
-
Determine the conventional commit type by analyzing the changes:
feat — new functionalityfix — bug fixesrefactor — code restructuring without behavior changeschore — maintenance, deps, configdocs — documentation onlytest — adding or modifying testsstyle — formatting, missing semicolons, etcperf — performance improvements
Functional markdown: AGENTS.md files and skills (.opencode/skills/ or skills/) are markdown but function as agent instructions. Changes to them alter agent behavior — classify them as feat (new behavior), fix (corrected behavior), or refactor (restructured guidance), never chore or docs.
-
Write a conventional commit message:
- Format:
<type>(<scope>): <description>
- Scope is optional but encouraged (use the main module, feature, or file changed).
- Description is a concise, imperative summary (under 72 chars).
- If changes are substantial, add a body paragraph explaining what changed and why.
Examples:
feat(auth): add JWT-based session management
fix(payments): retry failed transactions with exponential backoff
chore(deps): bump redis client to v4.2
refactor(parser): extract tokenization into standalone module
- Commit:
git commit -m "<title>" [-m "<body>"].
5. Push and Create PR
- Push the branch:
git push -u origin <branch-name>.
- Generate a PR title and body:
- Title: Clear, concise summary of the change (match conventional commit style).
- Body summary (first paragraph): High-level overview of what changed and why.
- Body details (following sections):
- What changed (bullet points of key modifications)
- What reviewers should focus on (specific areas needing attention, tricky logic, potential edge cases)
- Testing notes (how to verify, any manual testing required)
- Reference the OpenSpec change if applicable:
Implements [change-name] or link to the spec.
- Create the PR using
gh-cli skill:
gh pr create --title "TITLE" --body "BODY"
- Present the PR URL to the user.
6. Post-Merge Cleanup
When the user confirms the PR has been merged:
- Switch back to the default branch:
git checkout <default-branch>.
- Pull the latest changes:
git pull origin <default-branch>.
- Confirm the merge is local.
Constraints
- Never commit directly to the default branch.
- Always run quality checks before committing.
- Always verify openspec status if the project uses it.
- Use conventional commit format for all commit messages.
- PR bodies should focus on what changed and what reviewers should focus on, not a line-by-line diff.
