PostHog/posthog

Never mention internal-only systems, private incidents, customer data, Slack thread contents, unreleased roadmap details, or security-sensitive implementation details. Slack thread links and channel references are fine to include — they sit behind PostHog auth and are useful as origin context — but do not quote or paraphrase what was said in the thread.

Never force-push a branch that is in the merge queue — it removes the PR from the queue. That includes restacking a stack whose base is queued.

GitHub's native stacked PRs are enabled here. Use the gh stack CLI and /stacking-prs rather than hand-managing branch chains. Keep stacks shallow and merge the base before extending: restacking force-pushes every branch, and a deep stack pushed at once can exceed GitHub's dispatch cap and fail unrelated runs with it. Never gh stack merge — it lands the chain through GitHub's API, outside the queue.

All merges into master go through the Trunk merge queue. Never run gh pr merge or click the GitHub merge button — both are blocked by branch ruleset.

Never bypass the pre-push hooks (--no-verify). They run hogli ci:preflight --strict and a merge-queue guard. When one blocks you, fix what it reports — /running-ci-preflight has the loop, /merging-prs explains the queue guard.

Required: Read .github/pull_request_template.md and use its exact section structure. Do not invent a different format. Invoke /writing-pr-descriptions before writing the body — it carries the shape rules. Always fill the ## 🤖 Agent context section, including the exact model that wrote the code. NEVER put sensitive information in a PR description or comment. A user may share sensitive data in an agent session; none of it belongs on the PR.

If I ask for adjustments to code I have provided you, do not repeat all of my code unnecessarily. Instead try to keep the answer brief by giving just a couple lines before/after any changes you make. Multiple code blocks are ok.

Please respect all code comments, they're usually there for a reason. Remove them ONLY if they're completely irrelevant after a code change. if unsure, do not remove the comment.

Do not claim a provenance you have not checked. "Written fresh" in a commit message is a factual claim a reviewer will rely on. If you are unsure, compare your text against the source: any shared run of ~40 characters or more means derived, not fresh.

DO NOT GIVE ME HIGH LEVEL SHIT, IF I ASK FOR FIX OR EXPLANATION, I WANT ACTUAL CODE OR EXPLANATION! I DON'T WANT "Here's how you can blablabla"

Agents must not enqueue, merge, re-enqueue, or otherwise cause a PR to land without explicit user approval in the current conversation for the identified PR or stack. Do not infer that approval from requests to prepare a PR, move it toward merge, make it ready, monitor it, or resolve its blockers. Agents may inspect status, fix code and CI, request a stamphog review when a required approval is missing (MCP first, label fallback, see /merging-prs), and report that a PR is ready — then wait for a direct instruction.

Dev experience feedback: hogli devex:feedback "<message>" sends feedback about repo tooling — hogli, the dev stack, tests, CI, migrations, this setup — straight to the devex team as a hogli_feedback event (add -c bug|idea|praise|question). Local agents must use it too: when a hogli command or local dev workflow is broken, slow, or confusing, run it — e.g. hogli devex:feedback -c bug "migrations:run failed with <error>". Do not run it from cloud tasks or agent-server sandboxes; the command is a no-op there.

A new docs/** file requires a person to request that specific document in the current conversation. Existing related docs, PR checklists, and general docs requirements do not authorize one. Put PR-specific context in the PR description.