Create GitHub PR

Open a pull request (GitHub)

Project-local skill for ScienceDiscovery.

This is the only path. Changes are proposed here and GitHub syncs to GitCode; CONTRIBUTING.md's Repositories table is the authority. That direction is the reverse of what it once was, and the GitCode side no longer has a pipeline at all, so older merge requests and any documentation describing GitCode as the place to propose are out of date.

How to call gh, and the rule that issue and pull request text is English: github. Pipeline internals — which platform runs which layer, the workflow files, run logs, failure attribution: ci. Journey design and reporting: e2e-testing.

Rules

1. The layers are a gate, not a suggestion. CONTRIBUTING says run all three locally. GitHub Actions runs them too, but on a pull request that is feedback arriving twenty minutes later, not permission to skip them.
2. Push the branch to the operator's own fork, never to the upstream. Resolve the login from gh api user --jq .login; do not hard-code a person. origin is openJiuwen-ai/sciencediscovery. Do not git push origin a task branch, and do not assume origin is a personal fork. Open the pull request with --repo openJiuwen-ai/sciencediscovery --head <login>:<branch> --base main.
3. Exactly one release:* label, from the whitelist below. The release note is grouped by it.
4. Read the pull request back after creating it, and read its Actions run before saying anything about CI.
5. Say what was verified, with the actual numbers. "Tests pass" is not reviewable; "UT 382 API + 100 runner, ST smoke ok, mocked E2E 42 passed / 2 skipped / 0 failed" is.
6. This skill stops at the pull request. It does not merge, tag, or publish a release.
7. The title and the body are English. See github. Write Chinese only when the person who asked explicitly wants Chinese.

Run the layers first

bwrap --ro-bind / / --dev /dev true && echo sandbox ok      # ci:ut and ci:e2e need it
CI_RESULTS_DIR=.tmp/ci-results CI_RUNTIME_DIR=.tmp/ci-runtime pnpm ci:ut
CI_RESULTS_DIR=.tmp/ci-results CI_RUNTIME_DIR=.tmp/ci-runtime pnpm ci:st
CI_RESULTS_DIR=.tmp/ci-results CI_RUNTIME_DIR=.tmp/ci-runtime pnpm ci:e2e

Run them on the commit you will push and collect the per-layer numbers for the body: the per-package # pass / # skipped lines in the UT run.log, the ST smoke line, and the E2E discovered / passed / failed / skipped split. Each layer leaves run.log and a summary under CI_RESULTS_DIR/<layer>/; with a relative CI_RESULTS_DIR, ci:e2e writes its journey reports under .e2e/.tmp/… instead, because Playwright runs from .e2e/.

When a layer fails, attribute it before touching anything: run the same layer on unmodified main in a separate detached worktree (git worktree add --detach .worktrees/<name> <sha>). An identical failure is pre-existing — say so in the body with the step, the error and the baseline run, and leave the fix to its own pull request. A failure only on your commit is yours. Never weaken an assertion or skip a layer to get green; if a layer cannot run on this host, say which and why. Report the numbers each layer's summary.json gives — planned, executed, passed — not "tests pass".

pnpm ci:e2e is the mocked browser subset only. Changed user-observable behaviour also needs the relevant API, CLI or local-stack journey.

The two hosts are different repositories

GitHub is where changes are proposed and GitCode mirrors it, but the two have separate histories either way. Two consequences bite here:

• Never compare SHAs across hosts. The same change has a different commit id on each. Compare trees: git rev-parse <a>^{tree} on both.
• Never push a GitCode-based branch to GitHub, or the reverse. Rebase onto the host's own main first (git rebase --onto github/main <old-base>), and check the result does not contain the other host's base: git merge-base --is-ancestor <other-base> HEAD must fail.

Choose exactly one release category

These are mutually exclusive: the label answers "which one section of the release note does this belong under", not "which properties does this change have".

• A breaking change is release:breaking and nothing else. That it is also a feature is already in the title, and an upgrading reader needs it in one place.
• A fix that also adds tests is release:fix. The tests are how it was proved, not what it is.
• A dependency bump whose purpose is fixing a user-visible bug is release:fix; a routine update is release:dependency.
• A new product capability is release:feature even when it is delivered as a Skill; maintaining a developer-facing agent skill is release:internal.
• Never choose release:skip because the author is a bot, because the change arrived by sync, or because the diff is small. Category follows content. If there is any user impact, or the category is unclear, ask rather than silently skipping — a skipped pull request leaves no trace in the note.

The categories and their order live in .github/release.yml. An unlabelled pull request is not dropped, it lands in Other Changes — which is a backstop to read and fix, not a default to rely on.

Applying a label needs write access to the upstream repository. An outside contributor can open the pull request and cannot label it. When the label cannot be applied, put the intended category in the body, say plainly that the GitHub label is pending a maintainer, and do not report it as applied. Do not invent a category outside the whitelist, and do not touch the ci-*, priority/*, sync-managed or general classification labels — they serve other purposes and this skill has no business rewriting them.