メニュー
Analyzes upstream fork PR changes and ports selected items into the local branch. Use when checking upstream PRs, porting upstream changes, or planning selective upstream integration.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Orchestrates the full powerball-harness plugin release with build, validation, version bump, CHANGELOG, tag, and GitHub Release. Use when releasing this plugin.
Generates product demo videos and release walkthroughs via Remotion. Use when creating video documentation or animated demos.
Plans and tracks tasks in .claude/harness/plans.json. Use when creating plans, adding tasks, updating markers, checking progress, or brainstorming an idea into tasks.
Initializes and configures Harness in a project — CI, memory, duo workflow, Codex. Use when setting up a new project or adding Harness configuration.
Executes plans.json tasks — solo, parallel, or breezing team mode. Use when implementing tasks or running the work loop.
Periodic housekeeping and session lifecycle management. Use when performing cleanup, pruning, or session commands.
| name | port-upstream |
| description | Analyzes upstream fork PR changes and ports selected items into the local branch. Use when checking upstream PRs, porting upstream changes, or planning selective upstream integration. |
| when_to_use | port upstream, upstream PR, check upstream, upstream changes, upstream fork, bring changes from upstream |
| user-invocable | true |
| argument-hint | [release_tag | compare_url | pr_url] |
| allowed-tools | ["Agent","Bash","Read","Glob","Grep"] |
The input to analysis must be a git diff between two tags (or two commits) — not release-notes prose. Release notes are summaries; the diff is ground truth.
From the user's input, identify the upstream repo and the two endpoints:
v4.4.0)v4.3.0), or whatever tag we last successfully ported up toIf only a release URL is given, infer BASE from the upstream's tag list (gh release list --repo <upstream> --limit 5) — the immediately preceding semver tag.
# Option A — GitHub compare endpoint (no local fetch needed; works for any public fork)
gh api repos/<owner>/<repo>/compare/<BASE>...<HEAD> \
--jq '.files[] | {filename, status, additions, deletions, patch}' > /tmp/upstream-diff.json
# Option B — local git (if upstream is wired as a git remote)
git fetch upstream --tags
git diff upstream/<BASE>..upstream/<HEAD> -- ':!*.lock' ':!bin/' ':!*.min.*'
Exclude generated artifacts (bin/, lock files, minified output) — they're noise.
Pass the diff file path (not the release URL) as the agent's primary input. Brief:
Release notes are prose summaries written by the upstream author. They invite subject-line matching — "upstream said X, local commit says X, must be the same." That heuristic produces false-positive merge claims. Diffs eliminate the abstraction: the hunks either are or are not in the working tree, no interpretation needed.
/harness-planThis skill exists in a fork of an upstream repo. After git fetch upstream, every commit upstream pushes is reachable by hash from the local repo, even if no local branch points at it. This makes hash-based "proof" unreliable.
git show <hash> — works on any fetched object, including unmerged upstream commits.git log --oneline | grep <hash> — same problem; the hash is in the object DB, not necessarily on master.grep -rn 'headingTaskRe' . # if it's missing, the change is not present, full stop
master:
git branch --contains <hash> # empty output = not merged, ignore the citation
When verifying "is this in local?", default the framing to "what would prove this is missing?" — not "what would prove it's present?". Confirmation bias is the recurring failure mode in port reviews; refutation-first framing is the cheapest counter.