메뉴
Submit a pull request following the repo's contribution guidelines. Reviews the diff, checks for common rejection reasons, and helps the user write their own PR description. The LLM reviews. the user writes. Use when implementation is complete and tests pass.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Debug CI failures in unfamiliar repo pipelines. Reads CI configs, fetches failure logs, classifies the failure type, and guides the user through diagnosing and fixing the issue. Use when CI fails on your PR in an OSS repo, when you don't understand a CI error, or when debugging GitHub Actions/CircleCI/other CI systems. Not for setting up CI from scratch — this is for debugging existing pipelines.
Evaluate whether an OSS repo is worth long-term investment before committing time. Assesses project health, governance, community, bus factor, and trajectory. Use when deciding whether to contribute to a specific repo, choosing between multiple repos, or evaluating a project's sustainability. Not for checking if a repo accepts contributions — use oss-find-issue for that.
Handle PR review feedback - understand reviewer comments, research their concerns, and help the user address them. The LLM explains what reviewers want and why; the user decides how to respond and writes the code. Use when you receive review comments on a submitted PR.
Review other contributors' PRs to learn the codebase and build maintainer trust. Guides structured diff reading, helps formulate review comments, and teaches how to distinguish blocking issues from nits. Use when you want to learn a codebase by reviewing PRs, build trust with maintainers before contributing code, or practice code review on OSS repos. Not for reviewing your own PR — use oss-submit-pr for that.
Plan and execute your second and third contributions to become a regular contributor. Covers relationship building, progressive complexity escalation, and community presence. Use when your first PR was merged and you want to keep contributing, when transitioning from one-off contributor to regular, or when planning a sustained OSS involvement. Not for your first contribution — use the oss-find-issue → oss-contribute chain for that.
Set up a complete development environment for an unfamiliar OSS repo. Handles dependency installation, building, running tests, and configuring dev tooling. Use when cloning a new OSS repo and setting up for development, when the repo's setup instructions don't work, or when you need to debug environment issues. Not for setting up your own project — this is for getting someone else's repo running.
| name | oss-submit-pr |
| description | Submit a pull request following the repo's contribution guidelines. Reviews the diff, checks for common rejection reasons, and helps the user write their own PR description. The LLM reviews. the user writes. Use when implementation is complete and tests pass. |
Get your PR right the first time. This skill checks your work against the repo's rules, catches common rejection reasons, and helps you write a PR description that maintainers actually want to read. You write the description. the LLM reviews it.
A clean PR gets reviewed and merged. A sloppy PR gets ignored or closed. Most new contributors get rejected not because their code is bad, but because they didn't follow the process. wrong branch, missing tests, unclear description, scope creep. This skill catches all of that before you hit submit.
oss-contribute)oss-contribute step 6)Even if oss-prep-to-contribute already read these, read them again. specifically for PR submission rules:
# Fetch latest CONTRIBUTING.md
gh api repos/{owner}/{repo}/contents/CONTRIBUTING.md --jq '.content' | base64 -d 2>/dev/null
# Check for PR template - all standard locations
for path in \
".github/PULL_REQUEST_TEMPLATE.md" \
".github/pull_request_template.md" \
"PULL_REQUEST_TEMPLATE.md" \
"pull_request_template.md" \
"docs/PULL_REQUEST_TEMPLATE.md" \
"docs/pull_request_template.md"; do
if content=$(gh api "repos/{owner}/{repo}/contents/$path" --jq '.content' 2>/dev/null); then
printf '%s' "$content" | base64 -d 2>/dev/null
break
fi
done
# Check for multiple PR templates (directory-based)
gh api "repos/{owner}/{repo}/contents/.github/PULL_REQUEST_TEMPLATE" \
--jq '.[] | .name' 2>/dev/null
If a single template is found: use it. The PR description must follow its structure exactly.
If a template directory exists with multiple templates: present each template name to the user and ask which one matches their contribution type (bug fix, feature, docs, etc.). Fetch the selected template and use it.
If no template is found: no template required. follow the general PR description guidance below.
Extract PR-specific requirements:
Run every check the CI will run. locally, before pushing:
# Rebase on latest upstream
git fetch upstream
git rebase upstream/main
# Run tests
# {repo-specific test command}
# Run linting/formatting
# {repo-specific lint command}
# Check the diff is focused
git diff upstream/main...HEAD --stat
Go through the entire diff and flag issues:
git diff upstream/main...HEAD
Check for:
| Check | What to look for |
|---|---|
| Scope creep | Changes to files unrelated to the issue |
| Debug leftovers | console.log, print(), debugger, TODO comments |
| Style drift | Naming that doesn't match repo conventions |
| Missing tests | Code changes without corresponding test changes |
| Commented-out code | Dead code that shouldn't be committed |
| Unrelated formatting | Whitespace-only changes to lines you didn't modify |
| Hardcoded values | Magic numbers, hardcoded strings that should be constants |
| Error handling | New code paths without error handling (if repo expects it) |
For each issue found, present it to the user with the exact location:
"Found a potential issue at
src/foo.ts:42: you left aconsole.logfrom debugging. Remove it before submitting."
Don't auto-fix. Tell the user what and where.
# Check commit messages against repo conventions
git log upstream/main..HEAD --oneline
If the repo uses conventional commits and the user's messages don't conform, explain the format and ask them to amend. If sign-off is required:
# Check for sign-off
git log upstream/main..HEAD --format='%B' | grep -c 'Signed-off-by'
The user writes the PR description, not the LLM.
Tell the user:
"Write your PR description. Start with one sentence: what does this PR do?
Then add:
- Link to the issue ('Fixes #{number}')
- Why this approach. remember the trade-offs from /oss-contribute? Mention the key one
- How you tested it. what did you run, what passed?
Keep it short. If the repo has a PR template, follow it. Write in your own words. I'll review it after."
Wait for the user to write it.
Once the user has written their description, review it for conciseness and clarity:
Writing rules for PR descriptions:
Give specific feedback:
"Your description is good, but trim the first paragraph. the reviewer doesn't need the backstory. Lead with what changed."
Don't rewrite it. give feedback and let the user revise.
Once the description passes review:
# Push the branch
git push origin {branch-name}
# Create the PR
gh pr create \
--repo {owner}/{repo} \
--title "{title following repo convention}" \
--body "$(cat <<'EOF'
{user's PR description}
EOF
)"
# Check CI status
gh pr checks {pr-number} -R {owner}/{repo} --watch
If CI fails:
Present these before submission as a final checklist:
oss-contribute: the implementation workoss-post-pr: handle review feedback after submission| Shortcut | Why It Fails |
|---|---|
| "CI will catch any issues, I don't need to run checks locally" | CI failures are public. Every maintainer sees your red check. Running locally first is basic professionalism. and saves a round-trip of push-wait-fix-push. |
| "The code speaks for itself, I don't need a detailed description" | Maintainers review 10+ PRs a week. They skim descriptions first to decide priority. No description = no context = bottom of the queue. |
| "Let me just submit and iterate based on feedback" | First impressions matter. A sloppy first submission signals carelessness. Maintainers are less likely to invest review time in a PR that wasn't polished before submission. |
| "I'll write the description later, let me just get the PR up" | The description IS the PR for the reviewer. They read it before the code. A PR without a description is a PR without context. it gets deprioritized or closed. |
| "The diff is small, I don't need to review it" | Small diffs still contain debug leftovers, commented-out code, unrelated formatting changes. A 5-line diff with a console.log gets the same rejection as a 500-line mess. |