Add all new CI/CD workflow files for the staged branch promotion pipeline (develop alpha beta main). Push triggers are intentionally disabled workflows use workflow_dispatch or workflow_call only. No changes to existing ci.yml. All workflows are inert until activated in a follow-up PR. New workflows: - feature-pr.yml: auto-create PRs to develop (disabled) - hotfix-pr.yml: emergency hotfix PRs to main (disabled) - promote-branch.yml: staged promotion (disabled) - release-orchestrator.yml: release pipeline (disabled) - deployment-strategy.yml: npm + Docker deploy (workflow_call) - testing-strategy.yml: progressive test gates (workflow_call) - generate-changelog.yml: changelog generation (workflow_call) - version-operations.yml: version bumping (workflow_call) - release.yml: manual release trigger (workflow_dispatch) - rollback.yml: emergency rollback (workflow_dispatch) - discord-notify action: reusable notification Also adds pipeline docs and updates CONTRIBUTING.md with future branch strategy (clearly marked as not yet active). Split from #10755 for safe, additive merge.
5.1 KiB
Contributing to OpenClaw
Welcome to the lobster tank! 🦞
Quick Links
- GitHub: https://github.com/openclaw/openclaw
- Discord: https://discord.gg/qkhbAGHRBT
- X/Twitter: @steipete / @openclaw
Maintainers
-
Peter Steinberger - Benevolent Dictator
-
Shadow - Discord + Slack subsystem
- GitHub: @thewilloftheshadow · X: @4shad0wed
-
Jos - Telegram, API, Nix mode
-
Christoph Nakazawa - JS Infra
- GitHub: @cpojer · X: @cnakazawa
-
Gustavo Madeira Santana - Multi-agents, CLI, web UI
- GitHub: @gumadeiras · X: @gumadeiras
-
Maximilian Nussbaumer - DevOps, CI/CD
- GitHub: @quotentiroler
How to Contribute
- Bugs & small fixes → Open a PR!
- New features / architecture → Start a GitHub Discussion or ask in Discord first
- Questions → Discord #setup-help
Before You PR
- Test locally with your OpenClaw instance
- Run tests:
pnpm build && pnpm check && pnpm test - Keep PRs focused (one thing per PR)
- Describe what & why
Control UI Decorators
The Control UI uses Lit with legacy decorators (current Rollup parsing does not support
accessor fields required for standard decorators). When adding reactive fields, keep the
legacy style:
@state() foo = "bar";
@property({ type: Number }) count = 0;
The root tsconfig.json is configured for legacy decorators (experimentalDecorators: true)
with useDefineForClassFields: false. Avoid flipping these unless you are also updating the UI
build tooling to support standard decorators.
AI/Vibe-Coded PRs Welcome! 🤖
Built with Codex, Claude, or other AI tools? Awesome - just mark it!
Please include in your PR:
- Mark as AI-assisted in the PR title or description
- Note the degree of testing (untested / lightly tested / fully tested)
- Include prompts or session logs if possible (super helpful!)
- Confirm you understand what the code does
AI PRs are first-class citizens here. We just want transparency so reviewers know what to look for.
Current Focus & Roadmap 🗺
We are currently prioritizing:
- Stability: Fixing edge cases in channel connections (WhatsApp/Telegram).
- UX: Improving the onboarding wizard and error messages.
- Skills: Expanding the library of bundled skills and improving the Skill Creation developer experience.
- Performance: Optimizing token usage and compaction logic.
Check the GitHub Issues for "good first issue" labels!
Core vs ClawHub
Not everything belongs in the main repo. Here's how to decide:
| Belongs in Core | Belongs on ClawHub |
|---|---|
| Channel integrations (Telegram, Discord, etc.) | Domain-specific skills (QR codes, image tools, etc.) |
| CLI commands and infrastructure | Custom workflows and automations |
| Provider integrations (LLM backends) | Niche or experimental utilities |
| Security, routing, and core plumbing | Third-party service integrations |
Rule of thumb: if it adds new dependencies or is useful to some users but not most, it belongs on ClawHub. When in doubt, ask in Discord or open a Discussion before writing code.
Skills submitted as PRs to this repo will be redirected to ClawHub. If the core maintainers later decide certain functionality should be first-party, it will be integrated into core.
Branch Strategy
Note: The staged promotion pipeline is not yet active. Workflows are in place but dormant. For now, open PRs targeting
mainas usual. Once the pipeline is activated, the flow below will apply.
We will use staged branch promotion to keep main stable:
dev/* / feature/* / fix/* → develop → alpha → beta → main
For External Contributors (once pipeline is active)
- Fork the repo
- Create your branch (
dev/my-feature,fix/some-bug, etc.) - Open a PR targeting
develop(notmain) - CI runs lightweight checks only — no heavy platform tests on your PR
- Once merged to
develop, your changes promote through alpha → beta → main automatically
For Maintainers (once pipeline is active)
- Regular changes: merge to
develop, let the pipeline promote - Hotfixes: use
hotfix/*branches for emergency fixes that bypass staging directly tomain - Docs-only changes: skip the test pipeline automatically (paths-ignore)
See Pipeline docs for full details.