open-pr

작성자: cloudflare

클라우드플레어/에이전트 GitHub 이슈와 재현 결과를 바탕으로 수정 PR을 한 번에 생성합니다 — 브랜치 생성, 변경, 테스트, 푸시, 그리고 이슈에 연결된 PR 열기까지 수행합니다.

npx skills add https://github.com/cloudflare/agents --skill open-pr

The current user message contains an <agent-think-run> envelope with repository, issue, instruction, requested-by, and (when available) trigger-comment-id. Use those values exactly. Never infer or substitute another target from examples, workspace contents, GitHub searches, or concurrent issues. If the envelope or a required field is absent, stop without cloning/editing/pushing/posting and return a structured skipped result. When trigger-comment-id is present, your first container action is the liveness reaction:

gh api repos/<repository>/issues/comments/<trigger-comment-id>/reactions \
  -f content=rocket

Produce a focused fix PR, authored as yourself — the agent-think GitHub App. Do not impersonate any user.

The instruction is the free-form text the user typed after @agent-think (it may be empty). Treat it as a direct instruction — e.g. constraints on the fix, a preferred approach, or a pointer to the suspect area — and weight it highly, but stay within the scope of the issue.

All gh, git, npm, curl, and wrangler commands must run on the container backend (bash({ command, backend: "container" })) — the shell backend has no real binaries or network. gh is already authenticated as the app; use it directly (no token handling). Work under /workspace; put long logs and disposable scratch files in container-local /temp.

0. Clone the repo

Clone the target repo directly under /workspace using its repository name (cloudflare/agents/workspace/agents):

REPO_DIR="/workspace/$(basename <repo>)"
if [ ! -d "$REPO_DIR/.git" ]; then
  git clone https://github.com/<repo>.git "$REPO_DIR"
fi
cd "$REPO_DIR"

1. Gather everything known

gh issue view <issueNumber> --repo <repo> --json title,body,labels,author,comments

Read the body and every comment. In particular look for a comment from the prior repro run (@agent-think repro): it may contain a minimal reproduction, a live URL, observed-vs-expected behavior, and a root-cause hypothesis pointing at a file/line. Use it as your starting point — do not re-derive what is already known.

Decide if this is fixable in one shot. If the issue is a feature request needing design, is too vague, spans many subsystems, or you cannot locate a confident root cause, stop: return prOpened: false, skipped: true, and a summary explaining why. Post a brief, polite comment saying the pr-agent is skipping it and what additional detail would help; begin it with Requested by @<requestedBy> when the run envelope has a requester.

2. Locate the root cause

With the repo cloned at $REPO_DIR, read the relevant code in packages/agents, packages/think, etc. Confirm the hypothesis (or form your own) by reading the actual implementation. Identify the smallest change that fixes the reported behavior.

3. Branch and set commit identity

Commit as the agent-think app itself:

git config user.name "agent-think[bot]"
git config user.email "agent-think[bot]@users.noreply.github.com"
BRANCH="fix/issue-<issueNumber>-$(date +%s)"
git checkout -b "$BRANCH"

4. Make the fix

  • Smallest correct change. Fewest files. Match the existing code style.
  • Add or update a test that fails before the fix and passes after, when the area is testable.
  • Add a changeset if the repo uses them (.changeset/) for a user-facing fix: create a markdown file following the existing format in .changeset/.
  • Update examples and docs when the change affects behavior they show: if an examples/* app or a docs//README section demonstrates the code you touched, keep it truthful in the same PR.

5. Verify

Install and run the affected package's checks (monorepo uses pnpm + Nx):

# NOISY commands (installs, builds, test suites) MUST be redirected to a
# container-local /temp file and tailed — streaming megabytes of live output
# through the session can kill it irrecoverably:
mkdir -p /temp
CI=1 pnpm install --frozen-lockfile --reporter=append-only \
  > /temp/install.log 2>&1 || (tail -40 /temp/install.log; false)
tail -20 /temp/install.log
# Prefer scoped/affected runs; fall back to package scripts.
pnpm -w exec oxfmt --check . || pnpm -w exec oxfmt --write .
pnpm -w exec oxlint . || true
# Run the relevant package's typecheck + tests, redirected the same way:
pnpm --filter <package> typecheck > /temp/typecheck.log 2>&1; tail -30 /temp/typecheck.log
pnpm --filter <package> test > /temp/test.log 2>&1; tail -40 /temp/test.log

(/temp is outside the /workspace mount and is not synchronized.)

Record whether tests passed in testsPassed. If you cannot make tests pass and the failure is your change's fault, fix it; if tests are unrelated/flaky, note that in the PR body. Do not open a PR whose own new test fails.

6. Deploy a live demo of the PR

Every PR ships with a temporary deployment demoing the change so reviewers click a link and see the fixed behavior instead of imagining it.

  1. Build the fixed package(s) in the repo and pack them:
pnpm --filter <package> build
(cd packages/<package> && npm pack --pack-destination /workspace)   # -> /workspace/<package>-x.y.z.tgz
  1. Build a minimal demo app in /workspace/demo-<issueNumber> that exercises the fixed path. Follow the activated reproduce skill's "Minimal frontend (required)" recipe — same 7 files — but install the packed tarball so the demo runs YOUR fix:
npm install /workspace/<package>-x.y.z.tgz

If the repro run left a repro/issue-<issueNumber> branch, start from that project instead and just swap the dependency to the packed build — the same UI then demos broken-before / fixed-after.

  1. Deploy and verify the fix is actually observable in the page:
npm run deploy      # vite build && wrangler deploy --temporary
curl -sS -i "<demoUrl>/" | head -5

Capture the https://...workers.dev URL as demoUrl. Ignore the claim URL the deploy prints — it never goes in a PR.

Use judgment: changes with no runtime surface (docs-only, types-only, CI) skip the demo — say so in the PR body ("no runtime surface to demo") rather than deploying something meaningless.

7. Commit, push, open the PR

git status --short
git add -A
git commit -m "fix: <concise description> (#<issueNumber>)"
git push -u origin "$BRANCH"

gh pr create --repo <repo> \
  --base main \
  --head "$BRANCH" \
  --title "fix: <concise description> (#<issueNumber>)" \
  --body-file /temp/pr-body.md

Write the PR body outside the checkout at /temp/pr-body.md. It must include:

  • Requested by @<requestedBy> near the top, using the exact sanitized requested-by mention from the run envelope (omit only when it is unknown).
  • Closes #<issueNumber> so the issue auto-links.
  • What was wrong (root cause, citing the file/line).
  • What changed and why this is the minimal fix.
  • Testing: what you added/ran and the result.
  • Demo: phrase it exactly like "Demo URL (expires after 60 mins): " plus one line of click instructions and a note that it runs the packed build from this branch. If skipped, one line on why.
  • A link back to the repro-agent's reproduction (comment and/or the repro/issue-<issueNumber> branch) if one exists.
  • A "🤖 generated by the pr-agent — please review carefully" footer.

Capture the PR URL and branch name.

Do not post an acknowledgement or "opened a PR" comment on the issue. The PR links back to the issue via Closes #<issueNumber>. The only case where you comment is the skip path in the Gather everything known step (no PR exists to show).

8. Return the structured result

Return exactly:

  • prOpened (boolean)
  • skipped (boolean)
  • summary (string — one or two sentences)
  • prUrl (string, optional)
  • branch (string, optional)
  • testsPassed (boolean, optional)
  • demoUrl (string, optional)

cloudflare의 다른 스킬

workerd-api-review
cloudflare
workerd 코드 리뷰를 위한 성능 최적화, API 설계 및 호환성, 보안 취약점, 표준 사양 준수. tcmalloc 인식…
official
workerd-safety-review
cloudflare
메모리 안전성, 스레드 안전성, 동시성, 그리고 workerd 코드 리뷰를 위한 중요 탐지 패턴. V8/KJ 경계 위험 요소, 수명 관리 등을 다룹니다.
official
module-registry
cloudflare
workerd에서 모듈 레지스트리를 작업할 때 로드 — 모듈 해석, 컴파일, 평가, 등록을 읽기, 수정, 디버깅, 검토하는 경우…
official
reproduce
cloudflare
cloudflare/agents GitHub 이슈를 재현하기 위해 최소한의 Agents/Worker 프로젝트를 스캐폴딩하고 임시 Cloudflare 계정에 배포한 후 보고합니다…
official
local-explorer
cloudflare
로컬 탐색기 또는 로컬 API에 제품/리소스를 추가하는 방법. 새로운 로컬 API나 UI 라우트를 구현할 때 사용합니다.
official
commit-categories
cloudflare
커밋을 체인지로그와 "새로운 기능" 요약으로 분류하는 규칙입니다. 체인지로그 또는 whats-new 명령에서 커밋을 분류하기 전에 반드시 로드되어야 합니다. 제공하는 기능:
official
architecture
cloudflare
코드베이스를 처음 탐색할 때, 새 클라이언트 메서드를 추가할 때, 새 컨테이너 핸들러/서비스를 추가할 때, 또는 요청 흐름을 이해할 때 사용합니다.
official
changesets
cloudflare
변경셋을 생성하거나, 릴리즈를 준비하거나, 버전을 올릴 때 사용합니다. 참조할 패키지, 사용자 대상 변경셋 설명 작성 방법 등을 다룹니다.
official