opencode-rebase

Re-apply Birdhouse fork commits onto a new upstream opencode tag one commit at a time.

36|5|Updated Feb 27, 2026
One-click install
npx skills add https://github.com/Birdhouse-Labs/birdhouse --skill opencode-rebase-birdhouse-labs
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: opencode-rebase
Source: https://github.com/Birdhouse-Labs/birdhouse/tree/main/.agents/skills/internal/birdhouse-development/opencode-rebase
Command: npx skills add https://github.com/Birdhouse-Labs/birdhouse --skill opencode-rebase-birdhouse-labs

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Rebasing a long-lived fork onto a new upstream release with a traditional git rebase hides conflicts and silently drops behavior when upstream restructures code. This Skill provides a disciplined workflow for porting each Birdhouse fork commit onto a fresh opencode tag while validating behavior at every step. ## Core Features & Use Cases - Commit-by-commit porting: Read each old diff from the birdhouse branch, state its intent, and recreate it against the current upstream architecture using cherry-pick or manual porting. - Absorbed-commit detection: Search upstream for function names, error types, and constants to drop commits whose behavior was already absorbed, avoiding duplicate patches. - Clean-environment CI validation: Run typecheck and tests via turbo in an isolated environment with temp XDG directories so machine-local config never pollutes results. - Use Case: When opencode releases v1.4.11, create a worktree from the tag, port each fork commit from BIRDHOUSE.md, run CI after each one, then tag and force-push the rebased birdhouse branch. ## Quick Start Ask the agent to rebase the Birdhouse opencode fork onto the latest upstream tag, starting by creating a worktree from that tag and reading the commit inventory in BIRDHOUSE.md.

Frequently Asked Questions about opencode-rebase

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I rebase a fork onto a new upstream release without losing patches?▼

Port each fork commit individually instead of running git rebase. Read the old diff, state its intent, check whether upstream already absorbed the behavior, then cherry-pick or manually recreate it and run CI before committing.

When should I use git cherry-pick versus manual porting?▼

Use cherry-pick when the commit applies cleanly and the surrounding upstream code confirms the behavior is still correct. Port manually when conflicts exist or upstream restructuring means cherry-pick would hide important judgment calls.

How do I know if upstream already absorbed my fork commit?▼

Search the new upstream code for the function name, error type, or constant from the old diff rather than the literal changed lines. If the same logic exists upstream, drop the commit; if similar code differs in a load-bearing way, keep it.

Why do fork tests fail due to local machine config?▼

Provider and config tests can pick up real local auth, config files, or XDG paths. Run CI in a clean environment with temporary HOME and XDG directories so machine state never pollutes test results.

What are the limitations of this rebase workflow?▼

It is specific to the Birdhouse opencode fork and depends on BIRDHOUSE.md as the commit inventory. It requires manual judgment per commit, so it is slower than a mechanical rebase and not suited to forks without documented commit inventories.