- Read and follow CONTRIBUTING.md before contributing to the SDK.
- Read and follow RELEASING.md when adding changesets or working on publishing.
- Public API changes: follow "Public API changes" in CONTRIBUTING.md. As an agent, also:
- When reviewing or fixing someone else's PR, don't ask for or open an issue. Note an external contributor's public API change when it has neither an agreed issue nor an API-defining published spec.
- The author is a PostHog maintainer when the PR's
author_associationisMEMBERorOWNER(gh api repos/PostHog/posthog-flutter/pulls/<number> --jq .author_association) or, before a PR exists, whengh api orgs/PostHog/members/$(gh api user --jq .login)succeeds. If the check fails or can't run, treat the author as an external contributor. - A published sdk-spec that defines the API counts as the agreement, so no issue is needed.
- For an external contributor with no agreed issue and no spec, stop before implementing and draft the issue body for the user to post. Open it only if they ask.
- Before implementing or reviewing SDK behavior, check PostHog/sdk-specs for a spec covering it (its README lists every capability). If one exists, use it as the cross-SDK contract for the behavior the PR changes, and call out any divergence in that behavior in the PR description. Don't fix or flag discrepancies between the spec and code the PR doesn't touch. If none exists, carry on.
- Keep shared development guidance in
CONTRIBUTING.mdand release guidance inRELEASING.mdrather than duplicating it here.