Find and remove stale feature flags with a cleanup SKILL.md

Write SKILL.md for finding and safely removing stale feature flags. The agent identifies unused flags, proposes removal, and produces a checklist to avoid breaking rollback or hidden dependencies.

Repository context:
[flag system: LaunchDarkly, Unleash, environment variables, custom config]
[where flags are defined: config/*.json, .env, LaunchDarkly dashboard link]
[how to search flag usage: grep pattern, IDE find, or API call]
[flag naming convention and typical lifecycle: feature_foo_enabled, experiment_bar_v2]

Cleanup scope (define when using):
[time threshold: flags shipped > N days ago, or flags toggled to 100% for > M weeks]
[exclude list: permanent operational flags like maintenance_mode, rate_limit_enabled]

SKILL.md must include:
1. Purpose — remove dead feature flags to reduce config surface, eliminate dead code paths, and prevent confusion when the flag looks live but does nothing.
2. When to use — after a feature ships to 100% and the rollback window closes; post-experiment when losing variant is deleted; periodic quarterly cleanup. When not to use — flags still ramping, operational toggles, experiments mid-flight.
3. Hard rules:
   - Never remove a flag shipped < 30 days ago unless explicitly confirmed by product/eng owner — rollback may still be needed.
   - Always remove code and config together in one PR — leaving one orphaned confuses the next reader.
   - Check test files separately: tests that mock the flag do not count as production usage.
4. Required inputs: flag name or list, shipped date or last-modified date, link to launch ticket or experiment results.
5. Cleanup steps the agent must execute:
   - Search codebase for flag key: [paste grep or rg command], list files and line numbers.
   - Classify usage:
     a. Production code: app logic that branches on flag value.
     b. Test-only: mocks, fixtures, test setup — does not count as active usage.
     c. Config/definition: where the flag is declared or fetched.
     d. Docs/comments: references that are informational only.
   - Check flag platform (LD/Unleash/etc.) for last evaluation date, current rollout %, and any active rules/schedules.
   - If flag is 100% on everywhere: propose removing flag checks and keeping only the "enabled" branch.
   - If flag is 0% or archived: propose removing all code paths and config.
   - For conditional removal (e.g. keep flag, remove experiment variant B): list exactly which code paths stay.
6. PR template the skill outputs:
   - Flag name, shipped date, last-changed date, rollout % before removal.
   - Usage summary: N files in prod, M files in tests, config locations.
   - Removal plan: which branches/code paths are deleted, which stay.
   - Risks: rollback impact (note if < 30 days), hidden dependencies (analytics, monitoring dashboards referencing flag).
   - Verify checklist: "Searched for flag key in code and docs, confirmed 100% rollout or archived, ran tests, checked dashboards for flag references, deleted flag from config/platform."
7. Two example prompts: remove a launched feature flag at 100% vs clean up losing experiment variant after A/B test concludes.
8. Pitfalls: removing a flag still used in monitoring queries or analytics, deleting flag config but leaving code that now defaults wrong, assuming test-only means unused (integration tests may reflect real behavior), cleaning up too soon when rollback is still plausible.
9. Done means: flag removed from code, config, and flag platform (LD/Unleash); tests still green; no orphaned references in docs or dashboards; PR links original launch ticket.

Rules:
- Do not remove flags without confirming shipped date and rollout % from flag platform or git log.
- Do not guess at safe removal timeframe; use the 30-day threshold or override explicitly.
- Output only SKILL.md markdown.