Skip to content

docs: agree on public API changes before implementing them #273

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
turnipdabeets wants to merge 1 commit into
base: main
Choose a base branch
from
+18 −0
Open

docs: agree on public API changes before implementing them #273

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,6 @@
# Agent Instructions

- Read and follow [CONTRIBUTING.md](./CONTRIBUTING.md) before contributing to the SDK. It covers local development, running the example, CI-aligned checks, and the Rails package.
- Read and follow [RELEASING.md](./RELEASING.md) when adding changesets or working on publishing.
- Before adding or changing public API, follow "Public API changes" in [CONTRIBUTING.md](./CONTRIBUTING.md): the API shape must be agreed on the issue first. For SDK design guidance, read https://posthog.com/handbook/engineering/sdks/guidelines.md.
- Keep shared development guidance in `CONTRIBUTING.md` and release guidance in `RELEASING.md` rather than duplicating it here.
12 changes: 12 additions & 0 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,6 +45,18 @@ The public API snapshot covers both `posthog-ruby` and `posthog-rails`. If you i
bundle exec rake public_api:generate
```

## Public API changes

Public API is hard to change once it ships, so agree on it before writing the implementation. Our [SDK guidelines](https://posthog.com/handbook/engineering/sdks/guidelines) explain how we design it.

- If you need something the SDK doesn't support and it would add or change a public option, method, or type, open an issue describing your use case first. At this stage, context is more useful to us than code.

@greptile-apps greptile-apps Bot Sep 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Public constants are omitted

The approval requirement lists public options, methods, and types but omits public constants, even though the API snapshot explicitly tracks them. Contributors changing constants may therefore assume that prior agreement is unnecessary. Include public constants in this list.

Suggested change
- If you need something the SDK doesn't support and it would add or change a public option, method, or type, open an issue describing your use case first. At this stage, context is more useful to us than code.
- If you need something the SDK doesn't support and it would add or change a public option, method, type, or constant, open an issue describing your use case first. At this stage, context is more useful to us than code.
Prompt To Fix With AI 
This is a comment left during a code review.
Path: CONTRIBUTING.md
Line: 52

Comment:
**Public constants are omitted**

The approval requirement lists public options, methods, and types but omits public constants, even though the API snapshot explicitly tracks them. Contributors changing constants may therefore assume that prior agreement is unnecessary. Include public constants in this list.

```suggestion
- If you need something the SDK doesn't support and it would add or change a public option, method, type, or constant, open an issue describing your use case first. At this stage, context is more useful to us than code.
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

- Wait for a maintainer to agree on the API shape on the issue before implementing it.
- Check first whether an existing option or hook, such as `before_send`, already covers the use case. We avoid offering two ways to do the same thing.
- If a reviewer suggests a different API on your PR, confirm it with them before re-implementing. Treat it as a question, not an instruction.
- AI agents: stop and ask before implementing a public API change that hasn't been agreed on the issue.

A diff in `public_api_snapshot.txt` (see "CI-aligned checks" above) means your change touches public API.

## Rails package

The `posthog-rails` package has its own package-specific guide in [posthog-rails/CONTRIBUTING.md](posthog-rails/CONTRIBUTING.md).