Morrison-Lab
Morrison-Lab/ai-config
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/Morrison-Lab/ai-config --skill sup명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
| name | sup |
| description | Send issue or fix upstream. |
| user-invocable | true |
| allowed-tools | ["Bash","Read","Edit","Write"] |
File an issue or open a PR on an upstream repository — a fork's parent, a dependency, or any external project where you've found a bug, want to propose a fix, or need to request a feature.
The upstream repo is not ours; its rules bind us, and ignoring them can get the user's account banned. Before drafting a title or body, read:
CODE_OF_CONDUCT.md — some projects (e.g. quarto-dev/quarto-cli)
ban issues/PRs from autonomous AI agents acting without human oversight
and treat it as account-bannable on first offense. If the repo bans
AI-agent submissions, stop — do not file. Give the user the draft and let
them decide whether to submit it themselves.CONTRIBUTING.md + issue/PR templates (.github/ISSUE_TEMPLATE/,
.github/PULL_REQUEST_TEMPLATE.md) — follow the required template and fill in
every required field instead of the generic bodies below.Pull these via the GitHub MCP get_file_contents (remote) or
gh api repos/<owner>/<repo>/contents/<path> / a quick clone (local). If a
required check can't be read, say so and ask the user rather than guessing.
This is in addition to — not a replacement for — the human-approval gate in steps 3A/3B below.
| Situation | Action |
|---|---|
| Bug report, feature request, question — no code to contribute | Issue (or Discussion, if the repo routes it there) |
| You have a fix ready (patch, config change, doc fix) | PR |
| You have a fix but aren't sure upstream wants it | Issue first, mention you have a fix ready |
| Fork divergence — your fork has improvements the parent should get | PR |
If unclear, ask the user: "Issue (report only) or PR (with fix)?"
Try these in order:
# Fork parent (GitHub)
gh repo view --json parent --jq '.parent.owner.login + "/" + .parent.name'
# Fork parent (GitLab)
glab repo view --output json | python3 -c "import json,sys; r=json.load(sys.stdin); print(r.get('forked_from_project',{}).get('path_with_namespace',''))"
# Dependency — user must specify or you infer from context
# e.g., "the bug is in rlang" → "r-lib/rlang"
If you can't determine the upstream repo, ask the user.
# Can you push/PR to this repo?
gh repo view <owner>/<repo> --json viewerPermission --jq '.viewerPermission'
# WRITE or ADMIN → can PR directly
# READ → fork first, then PR from fork
Gather from context:
reprexes skill output)Show the full draft (title + body) to the user and wait for explicit approval
before posting. Output the text as a markdown block, then ask "OK to post?"
Do NOT run gh issue create until the user confirms.
gh issue create --repo <owner>/<repo> \
--title "<title>" \
--body "<body>" # CREATE_ISSUE
Or for GitLab:
glab issue create --repo <owner>/<repo> \
--title "<title>" \
--description "<body>"
After filing, report the issue URL back to the user.
Show the full draft (title + body) to the user and wait for explicit approval
before running gh pr create. Same rule as issues — draft first, post after "OK."
# Clone or add remote
git remote add upstream https://github.com/<owner>/<repo>.git 2>/dev/null || true
git fetch upstream # FETCH
# Branch from upstream's default branch
git checkout -b fix/<slug> upstream/main # CREATE_BRANCH — or upstream/master, upstream/develop
# Apply your fix (copy from local workaround, write fresh, cherry-pick)
# ... make edits ...
git add -A && git commit -m "<conventional commit message>" # COMMIT
git push upstream fix/<slug> # PUSH
# Open PR
gh pr create --repo <owner>/<repo> \
--base main \
--head fix/<slug> \
--title "<title>" \
--body "<body>" # CREATE_PR
# Fork (idempotent — won't re-fork if already forked)
gh repo fork <owner>/<repo> --clone=false
# Your fork is now at <your-username>/<repo>
gh repo clone <your-username>/<repo> /tmp/upstream-fix
cd /tmp/upstream-fix
# Branch, fix, commit, push to YOUR fork
git checkout -b fix/<slug> # CREATE_BRANCH
# ... make edits ...
git add -A && git commit -m "<conventional commit message>" # COMMIT
git push origin fix/<slug> # PUSH
# Open PR from your fork to upstream
gh pr create --repo <owner>/<repo> \
--base main \
--head <your-username>:fix/<slug> \
--title "<title>" \
--body "<body>" # CREATE_PR
After filing the upstream issue/PR:
# WORKAROUND: upstream <owner>/<repo>#<N> — remove when fixedworkaround-watcher, set it to watch the new issue/PRProvide:
## Problem
<What's broken / missing — 2-3 sentences>
## Reproduction
<Minimal steps or reprex>
## Fix
<What this PR does — 1-2 sentences>
## Notes
- Found while working on <context> in <your-repo>
- Currently working around this with <workaround description>
## Problem
<What's broken / missing>
## Reproduction
<Minimal steps, version info, reprex>
## Expected behavior
<What should happen instead>
## Workaround
<If you have one — helps others and shows investigation>
## Environment
- Package version: X.Y.Z
- R/Python/Node version: ...
- OS: ...
prefer-upstream — discovers that an upstream solution exists; sup
contributes fixes back to itworkaround-watcher — watches an upstream issue for resolution; sup
creates that upstream issue in the first placedefer-issue — files issues on YOUR repo; sup files on THEIR reporeprexes — creates minimal examples; sup includes them in the
upstream reportCODE_OF_CONDUCT.md / CONTRIBUTING.md
/ templates — you can't file correctly without knowing the rules.