用途：在 PostHog 当前活动项目内，查找指定时间窗口中被软删除（soft-deleted）的功能开关，输出开关列表、删除时间与删除人。适合回答“上周/最近 N 天删了哪些 flag”、做删除审计、或查某个 flag 何时被何人删除。清理仍存活的陈旧开关应使用 cleaning-up-stale-feature-flags，本技能只针对已删除项。
主要能力：第一步用 SQL 枚举 system.feature_flags 中 deleted = true 的项，按 created_at DESC 排序；第二步对候选 flag 并行调用活动日志接口，从中定位 activity == "deleted" 的事件取得真实删除时间与用户；第三步用脚本还原被重命名为 <原键>:deleted:<flag_id> 的原始键，并以表格呈现。
关键用法：SQL 查询为 SELECT id, key, created_at FROM system.feature_flags WHERE team_id = <team_id> AND deleted = true ORDER BY created_at DESC LIMIT 100。活动日志调用为 feature-flags-activity-retrieve {"id": <flag_id>, "limit": 5, "page": 1}，应在同一条消息中并发发起。还原键可用：echo '[{"id": 1001, "key": "example-banner:deleted:1001"}]' | python3 scripts/strip_deleted_suffix.py。
必要限制：system.feature_flags 只暴露 deleted 布尔值，不含 deleted_at/updated_at/last_modified_at，无法用单条 SQL 按删除时间过滤；删除时间只能逐 flag 查活动日志，且无批量接口。按 created_at DESC 排序只是启发式，较早创建但近期删除的 flag 可能不在前列。始终使用 UTC 计算截止时间；窗口含义（滚动 7 天或上一自然周）模糊时应先澄清或并列说明。与窗口边界相差约 1 小时内的删除应标注为临界情况。报告需说明实际检查的候选数量与软删除总数，必要时可提出继续遍历剩余候选。其余平台细节或收费信息暂未提供。