finding-deleted-feature-flags

Finding recently deleted feature flags

This skill produces a list of feature flags that were soft-deleted in the active project within a user-specified time window, along with who deleted each one and when.

When to use this skill

• The user asks "what flags got deleted last week / in the last N days?"
• The user wants an audit of recent flag deletions (who, when, what was removed)
• The user wants to find when a specific flag was deleted, or by whom
• Any "recently deleted feature flags" framing

Don't use this for active stale-flag cleanup — that's cleaning-up-stale-feature-flags. This skill is for flags that have already been removed.

The gotcha that makes this non-trivial

system.feature_flags exposes deleted as a boolean but does not expose deleted_at, updated_at, or last_modified_at. There's no way to filter soft-deleted flags by deletion time in a single SQL query — trying to use those columns will return Unable to resolve field.

The actual deletion timestamp lives in the per-flag activity log, reachable only via posthog:feature-flags-activity-retrieve (one call per flag id). There is no bulk activity endpoint.

So the workflow is two-stage: SQL to enumerate candidates, then parallel activity-log lookups to find each deletion event.

Workflow

1. Clarify the window if ambiguous

"Last week" is ambiguous — it can mean rolling 7 days from now, or the previous calendar week (Mon–Sun). If the user wasn't explicit, ask, or surface both interpretations in the final report.

Always compute the cutoff in UTC and keep the user's local interpretation in your head separately.

2. Enumerate soft-deleted flags via SQL

Query system.feature_flags for deleted = true in the active project, ordered by created_at DESC:

SELECT id, key, created_at
FROM system.feature_flags
WHERE deleted = true
ORDER BY created_at DESC
LIMIT 100

Order by created_at DESC because deletions empirically cluster near creation — most flags get deleted within a few days of being created — so walking the most-recently-created candidates first finds recent deletions fastest. But this is a heuristic, not a guarantee: an older flag deleted recently won't be at the top of this list. Be explicit about that limitation when you report.

3. Fan out activity-log lookups in parallel

For each candidate id, call posthog:feature-flags-activity-retrieve with limit: 5, page: 1. Issue all calls in one message so they run concurrently — sequential calls are dramatically slower.

call feature-flags-activity-retrieve {"id": <flag_id>, "limit": 5, "page": 1}

Reasonable batch sizes:

• "last 7 days" → top 20–25 candidates
• "last 30 days" → top 50
• "last 90 days" → walk the full ~100

If you sample fewer than the full set, say so in the report and offer to walk the rest as a follow-up.

4. Extract the deletion event from each response

In each response, find the entry where activity == "deleted". That entry's created_at is the actual deletion time, and user.first_name identify the deleter. These fields are reliable on every delete path.

For most flags there's exactly one delete event. If a flag has been deleted-and-restored multiple times, take the most recent activity: deleted event within the window.

5. Recover the original key and report

Feature flags are renamed to <original>:deleted:<flag_id> when soft-deleted while still referenced elsewhere (e.g. a stopped experiment) — the id-based suffix frees the original key for reuse. Don't try to recover the original from the activity log's own fields: detail.changes only carries the rename on UI/ORM deletes (and is often empty, or missing the key entry, on API/MCP/programmatic deletes), and detail.name just mirrors whatever the current key is — tombstoned or not.

Instead, strip the suffix deterministically with scripts/strip_deleted_suffix.py. Pass it the whole step 2 candidate list as JSON in one call — not one invocation per flag:

python3 scripts/strip_deleted_suffix.py
# prints the same array back (pretty-printed), each object gaining an "original_key" field:
# "original_key": "example-banner"

Filter the collected deletion events to those whose created_at falls inside the requested window. Present as a table, using each row's recovered original key (not the raw tombstoned form) for the "Key" column:

| Flag ID | Key | Deleted at (UTC) | Deleted by |

State your methodology in the report (how many candidates you walked vs. how many soft-deleted flags exist total), so the user knows what was and wasn't checked.

Watch-outs

• Borderline cases: if a deletion is within ~1 hour of the window cutoff, surface it as borderline rather than silently dropping it.
• Don't trust created_at as a proxy for deletion time: a flag created in 2024 can still have been deleted last week. The activity log is the only authority.
• Renamed keys are normal: a flag with key foo:deleted:12345 was the flag originally keyed foo — see step 5 for how to recover it.
• Walking all candidates is possible but slow: ~100 parallel activity-log calls is doable. Offer it as a follow-up rather than the default for short windows.

Example interaction

User: "what flags got deleted in the last week?"

1. Clarify if needed, or note both interpretations: "rolling 7 days ending now (UTC), in the active project"

2. Run the SQL enumeration to get up to 100 soft-deleted candidates ordered by created_at DESC

3. Fan out activity-log lookups in parallel across the top ~25 candidates

4. Extract activity: deleted entries; filter to those whose created_at >= now - 7 days

5. Recover original keys with scripts/strip_deleted_suffix.py and report. The values below are illustrative, not real project data:

   Found 2 feature flags deleted in the last 7 days (rolling, ending 2026-08-14 09:30 UTC):
   
   | Flag ID | Key                     | Deleted at (UTC)     | Deleted by  |
   |---------|-------------------------|----------------------|-------------|
   | 1001    | example-banner          | 2026-08-13 15:12     | Jane D.     |
   | 1002    | example-checkout-test   | 2026-08-09 21:48     | John S.     |
   
   Methodology: walked the activity log for the 25 most-recently-created soft-deleted flags.
   The step 2 query hit its 100-row cap, so the project may have more soft-deleted flags than that.
   The other 75 returned candidates were created before late June 2026 and were not checked.
   Want me to walk the rest?

Related tools

• posthog:execute-sql: Used in step 2 to enumerate soft-deleted candidates against system.feature_flags
• posthog:feature-flags-activity-retrieve: Used in step 3 to find the actual deletion event for each candidate
• posthog:feature-flag-get-definition: Useful if the user then wants to inspect what the deleted flag looked like

Scripts

• scripts/strip_deleted_suffix.py: recovers original flag keys — see step 5.