announcing-behavior-changes

Builds gated in-app notices that inform affected users about behavior-changing fixes.

713|118|Updated Aug 11, 2020
One-click install
npx skills add https://github.com/PostHog/posthog-foss --skill announcing-behavior-changes
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: announcing-behavior-changes
Source: https://github.com/PostHog/posthog-foss/tree/main/.agents/skills/announcing-behavior-changes
Command: npx skills add https://github.com/PostHog/posthog-foss --skill announcing-behavior-changes

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

When a fix corrects wrong behavior, users see different numbers or charts without any explanation and mistake it for a regression. This Skill decides whether a change warrants an in-app notice and builds one that reaches only the affected users and can be removed later.

Core Features & Use Cases

  • Gate criteria: Applies a four-condition test and a narrowing predicate so notices only reach users actually affected by the change.
  • Five-part pattern: Provides an exported tested predicate, a feature flag in lib/constants.tsx, a LemonBanner component returning null by default, an anchor at the shared render site, and a removal date.
  • Copy and testing guidance: Supplies the two-clause copy shape (what changed, results may differ) and a parameterized unit test approach for the predicate.
  • Use Case: After fixing date filter resolution on SQL insights, ship a dismissible banner above the visualization, flagged and predicate-gated, in the same PR as the backend change.

Quick Start

Ask the AI to evaluate whether your behavior-changing fix needs an in-app notice and, if so, generate the predicate, feature flag, banner component, and tests following this pattern.

Frequently Asked Questions about announcing-behavior-changes

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I announce a breaking or behavior change to users in-app?

Ship a dismissible LemonBanner notice in the same PR as the change, gated by a feature flag and a predicate that identifies affected users. Anchor it where the changed result appears, and include a removal date comment.

When should I add an in-app change notice versus a changelog entry?

Add a notice only when users who do nothing see something different, cannot tell why, the difference is noticeable, and you can identify affected users in code. Minor changes affecting everyone belong in the changelog only.

How do I target a banner only at users affected by a change?

Write an exported predicate function that mirrors the backend rule determining who is affected, and unit test it with affected and unaffected cases. If only the backend can tell, use a per-object API field rendered where that object appears instead.

How do I remove a stale in-app notice or feature flag?

Turn the feature flag off to kill the notice immediately without a deploy, then delete the component, its test, the flag constant, and the render site together. Nothing in CI checks removal dates, so the cleanup must be done manually.

What are the limitations of time-boxed in-app notices?

Notices only work when the affected population is expressible as a client-side predicate and the condition is a one-time transition. Permanent conditions need computed per-object warnings, and removal dates are unenforced notes to humans.