What I do
Automate the full upstream release sync workflow for openclaw-go when a new OpenClaw gateway version is published.
When to use me
Use this skill when handling GitHub issues labeled upstream-release or when a new OpenClaw gateway version needs to be synced into this library.
Workflow
Read the issue — extract the changelog excerpt and identify API/protocol deltas (new RPCs, changed params, removed fields, new event types).
Create or update the spec doc — write
docs/specs/<version>.mdsummarizing upstream deltas and required work items.Update protocol types — add or modify types in
protocol/to match the upstream wire format:- New
*Paramsand*Resultstructs - New constants (methods, event names, scopes)
- Updated
jsontags and field types - Run
go vet ./protocol/...after changes
- New
Update gateway methods — add typed convenience methods in
gateway/methods.go:- Follow the existing pattern: marshal params →
client.Send()→ unmarshal result - Method name matches the RPC name in PascalCase
- Include GoDoc comment referencing the RPC method string
- Follow the existing pattern: marshal params →
Update tests — add test cases in
gateway/methods_test.go:- Follow existing table-driven test pattern
- Mock the expected request/response exchange
- Cover both success and error paths
Update CHANGELOG.md — add entries under
[Unreleased] > Addedfollowing Keep a Changelog format.Update docs-site package pages — add new methods to
docs-site/packages/gateway.mdand any new types todocs-site/packages/protocol.md.Run validation:
go test ./... -race go vet ./...Complete review gates before marking the PR ready:
- Architecture review — confirm type design matches upstream semantics
- Go standards review — idiomatic naming, error handling, documentation
- API coverage review — every new upstream RPC has a typed method and test
- Security review — no credential leaks, safe defaults
Open PR to
mainwith:- Summary of upstream changes
- Link to the upstream-release issue
- Test results pasted in the PR body
After PR merge only — create tag and GitHub release:
git tag v<version> gh release create v<version> --title "v<version>" --notes "..."Close the issue with a link to the release.
Key files
protocol/types.go— wire typesprotocol/constants.go— method strings, scopes, rolesgateway/methods.go— typed RPC methodsgateway/methods_test.go— method testsCHANGELOG.md— release notesdocs/specs/— version spec documentsdocs-site/packages/— published package docs
Rules
- Never push directly to
main— always use feature branches and PRs. - Branch naming:
issue/<number>-upstream-release-v<version> - One upstream version per PR — do not batch multiple releases.
- Every new RPC must have a typed method, a test, a CHANGELOG entry, and a docs update.
Source: a3tai/openclaw-go — distributed by TomeVault.