Finding Deleted Feature Flags

1---
2name: finding-deleted-feature-flags
3description: 'Find feature flags that were soft-deleted in the active project within a recent time window. Use when the user asks "what flags were deleted in the last N days", "show me recently deleted feature flags", "who deleted flag X", "audit recent flag deletions", or anything similar. Handles the non-obvious gotcha that system.feature_flags exposes the deleted boolean but does not expose a deletion timestamp — the actual deleted-at time lives in the per-flag activity log and must be cross-referenced.'
4---
5 
6# Finding recently deleted feature flags
7 
8This 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.
9 
10## When to use this skill
11 
12- The user asks "what flags got deleted last week / in the last N days?"
13- The user wants an audit of recent flag deletions (who, when, what was removed)
14- The user wants to find when a specific flag was deleted, or by whom
15- Any "recently deleted feature flags" framing
16 
17Don'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.
18 
19## The gotcha that makes this non-trivial
20 
21`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`.
22 
23The 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.
24 
25So the workflow is two-stage: SQL to enumerate candidates, then parallel activity-log lookups to find each deletion event.
26 
27## Workflow
28 
29### 1. Clarify the window if ambiguous
30 
31"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.
32 
33Always compute the cutoff in UTC and keep the user's local interpretation in your head separately.
34 
35### 2. Enumerate soft-deleted flags via SQL
36 
37Query `system.feature_flags` for `deleted = true` in the active project, ordered by `created_at DESC`:
38 
39```sql
40SELECT id, key, created_at
41FROM system.feature_flags
42WHERE team_id = <team_id> AND deleted = true
43ORDER BY created_at DESC
44LIMIT 100
45```
46 
47Order 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.
48 
49`team_id` defaults to the active project, but include it explicitly for clarity.
50 
51### 3. Fan out activity-log lookups in parallel
52 
53For 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.
54 
55```text
56call feature-flags-activity-retrieve {"id": <flag_id>, "limit": 5, "page": 1}
57```
58 
59Reasonable batch sizes:
60 
61- "last 7 days" → top 20–25 candidates
62- "last 30 days" → top 50
63- "last 90 days" → walk the full ~100
64 
65If you sample fewer than the full set, say so in the report and offer to walk the rest as a follow-up.
66 
67### 4. Extract the deletion event from each response
68 
69In each response, find the entry where `activity == "deleted"`. That entry's `created_at` is the actual deletion time, and `user.email` / `user.first_name` identify the deleter.
70 
71The deletion event's `detail.changes` array typically contains:
72 
73- `{field: "deleted", before: false, after: true}` — the actual delete
74- `{field: "key", before: "<original>", after: "<original>:deleted:<id>"}` — Django renames the key on delete to free up the unique constraint
75- `{field: "name", ...}` — the name sometimes gets reset
76 
77For 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.
78 
79### 5. Filter and report
80 
81Filter the collected deletion events to those whose `created_at` falls inside the requested window. Present as a table:
82 
83| Flag ID | Key | Deleted at (UTC) | Deleted by |
84 
85State 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.
86 
87## Watch-outs
88 
89- **Borderline cases**: if a deletion is within ~1 hour of the window cutoff, surface it as borderline rather than silently dropping it.
90- **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.
91- **Renamed keys are normal**: a flag with key `foo:deleted:12345` was the flag originally keyed `foo`. The original key/name appears in the delete event's `detail.changes` array — surface that to the user, not the renamed form.
92- **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.
93 
94## Example interaction
95 
96User: "what flags got deleted in the last week?"
97 
981. Clarify if needed, or note both interpretations: "rolling 7 days ending now (UTC), in the active project"
992. Run the SQL enumeration to get up to 100 soft-deleted candidates ordered by `created_at DESC`
1003. Fan out activity-log lookups in parallel across the top ~25 candidates
1014. Extract `activity: deleted` entries; filter to those whose `created_at >= now - 7 days`
1025. Report:
103 
104   ```text
105   Found 2 feature flags deleted in the last 7 days (rolling, ending 2026-05-22 19:04 UTC):
106 
107   | Flag ID | Key                                       | Deleted at (UTC)     | Deleted by  |
108   |---------|-------------------------------------------|----------------------|-------------|
109   | 687432  | high_frequency_alerts                     | 2026-05-22 17:23     | Matt P.     |
110   | 676665  | tasks-sendblue-prewarmed-sandbox-pool     | 2026-05-15 13:45     | Alessandro  |
111 
112   Methodology: walked the activity log for the 25 most-recently-created soft-deleted
113   flags. Team 2 has ~100 soft-deleted flags total; the remaining ~75 were created
114   before mid-March 2026 and were not checked. Want me to walk the rest?
115   ```
116 
117## Related tools
118 
119- `posthog:execute-sql`: Used in step 2 to enumerate soft-deleted candidates against `system.feature_flags`
120- `posthog:feature-flags-activity-retrieve`: Used in step 3 to find the actual deletion event for each candidate
121- `posthog:feature-flag-get-definition`: Useful if the user then wants to inspect what the deleted flag looked like
122