skillZs
★ LIVE SKILL TAGS ★
>>> LIVE SKILLS INDEX <<<
* OPEN SOURCE *
NO LOGIN, NO TRACKING
※ REAL INSTALL DATA ※
← back to all skills
tester-army/e2e265 installs

ship-pr

Take finished work in tester-army/e2e to a PR a human can review without fighting CI or bots - checks, verification against the built packages, a fresh-context self-review, the PR itself, then babysitting to the Ready for Human Review label. Use whenever you are asked to open, create, ship, or submit a PR, or when implementation is done and the next step is review.

How do I install this agent skill?

npx skills add https://github.com/tester-army/e2e --skill ship-pr
view source ↗

Is this agent skill safe to install?

  • Gen Agent Trust Hubpass

    This skill implements a comprehensive workflow for shipping pull requests in the tester-army/e2e repository, covering testing, verification, and code review. It uses standard development tools like pnpm, git, and the GitHub CLI. A low-severity risk of indirect prompt injection exists because the skill processes arbitrary code changes, but this is addressed by instructing a fresh-context review session.

  • Socketpass

    No alerts

  • Snykpass

    Risk: LOW · No issues

What does this agent skill do?

Ship a PR

Opening a PR is not the finish line. The finish line is a PR labeled Ready for Human Review: verified against the built packages, reviewed by a fresh pair of eyes, green, and every bot thread handled. A human should only ever spend time on judgment.

Run every step. If one cannot run, say which and why in the handoff instead of skipping it quietly.

1. Checks

Run what CI runs for what you touched, and fix everything:

pnpm check                    # lint, dead code, typecheck, error codes, peer ranges, docs
pnpm test                     # or the touched package: pnpm --filter e2e run test:unit
pnpm --filter @e2e-dev/testbed test
pnpm test:web-benchmark       # when the runner, web engine, or benchmark changed

Then the repo rules pnpm check cannot see (AGENTS.md, "Contracts"):

  • A user-visible change to a published package adds a .changeset/ entry.
  • Behavior changes update the matching docs/**/*.mdx page in the same change, "not implemented yet" callouts included, and skills/e2e/ when it describes the changed surface.
  • A public API change reviews the emitted .d.ts and updates packages/e2e/tests/types/sdk-types.ts; a wire change edits the schema, both fixtures, and the producer together.
  • A new build input or benchmark dependency goes into .github/filters.yml.

2. Verify

Prove the change with the verify skill on the surface it touches: the built CLI on the testbed or a benchmark, the MCP server, a scratch project for init, or the docs site. Bug fixes capture main against the branch. Keep the output and any video for the PR.

3. Self-review in a fresh context

The agent that wrote the change does not get to judge it. Spawn a reviewer with no memory of this conversation (a subagent, or a new session) and give it references/review-prompt.md with the base branch filled in. Fix every critical and important finding you agree with, then rerun steps 1 and 2 for what the fixes touched. For each finding you reject, keep the one-line reason for the PR body or handoff.

No way to spawn a reviewer: re-read the whole diff cold against the same prompt yourself, and say so in the handoff.

4. Commit and open

  • Branch off an up-to-date origin/main. Commits follow Conventional Commits.
  • Title and body with the writing-pr skill. The body carries the verification evidence from step 2.
  • Open it ready, not draft: gh pr create --base main --title ... --body-file <file> --attach <each screenshot and video> (gh 2.99+). The body must carry the ## Verified section writing-pr describes; fix a thin one with gh pr edit --body-file <file> --attach ....
  • Multi-PR change: open every layer, each based on the one below, before babysitting.

5. Babysit

Hand the PR to the babysit skill and run it to the end: green, threads handled, Ready for Human Review label. For a stack, babysit bottom-up; a layer is labeled only when it is ready on its own.

Handoff

Reply to the human with:

  • the PR URL and its label state
  • how it was verified (surface, what you ran, what you saw, the media)
  • what you fixed from review, what you dismissed and why
  • anything left for them: escalated threads, parts you could not verify, scope you declined

Add the canonical catalog link to the repository README so users can inspect current installs and available audits. The publishing guide covers the complete discovery path.

<a href="https://skillzs.dev/skills/tester-army/e2e/ship-pr">View ship-pr on skillZs</a>