The prompt
Score 10 of 10, Excellent
Use it when A feature flag has been on for everyone long enough, and you want the flag and the old code path deleted cleanly, with tests updated to match.
- {{flag_name}}
- {{kept_value}}
- {{since}}
- {{flag_system}}
- {{known_usages}}
- {{test_command}}
- {{off_limits}}
Full prompt and why it works
Prompt
Goal: Remove the feature flag {{flag_name}} from this repository, keeping the code path that runs when the flag is {{kept_value}} as the only behavior, so that the code no longer carries two paths for a decision that is already made. Context: - The flag has served {{kept_value}} to all users since {{since}}. - Flag system and how code reads flags: {{flag_system}} (for example a helper in src/flags/) - Places I know it is used: {{known_usages}} - Test command: {{test_command}} Constraints: - Search the whole repository for the flag in every form it may take: the string key, constants, config files, test fixtures, docs and analytics events. Reply with the list of places and your plan before editing, and wait for my go-ahead if the flag also appears in another service, a database migration or a public API. - Keep the {{kept_value}} path and delete the other one, including functions, components, styles and translations used only by that path. Before each removal, check that nothing else uses it. - Remove the flag's definition and default from the flag configuration in this repository. Do not change the flag in the flag service itself; I will archive it there after this merges. - Update tests: delete tests that only cover the removed path, and remove flag setup from tests of the kept path without weakening their assertions. - Do not refactor, rename or reformat code beyond what removing the flag needs. Do not touch {{off_limits}}. Done when: - A search for {{flag_name}} finds nothing outside the changelog, or only places you have listed and explained. - {{test_command}} passes, along with the type checker and linter if the project has them. Verify: run the search and the commands, then report in this format: Files changed, Deleted (what, and why it was safe to delete), Tests removed or updated, Commands run with the last 20 lines of their output, and Left for you to decide. If the two paths turn out to differ in a way the flag name does not suggest, such as a data migration that only runs on one of them, stop and describe it before deleting anything.
Variables
- {{flag_name}}
- The flag's key exactly as it appears in code, for example new-checkout-flow.
- {{kept_value}}
- The value everyone gets now, whose code path stays, for example "on" or "variant B".
- {{since}}
- When it reached all users, for example "September 2".
- {{flag_system}}
- Your flag tool and how code reads it, for example "LaunchDarkly, through our isEnabled() helper".
- {{known_usages}}
- Files or areas you know use the flag, or "not sure".
- {{test_command}}
- The command that runs the tests, for example npm test.
- {{off_limits}}
- Files, folders or systems that must not change, for example other teams' services or generated code.
Why it works
- Length. The search covers every form the flag takes, from string keys to fixtures and analytics events, and the plan comes back before anything is deleted.
- What to avoid. Code that is also used elsewhere stays, the flag service itself is left to you, and nothing is refactored along the way, so the diff shows only the removal.
- If unsure. If the two paths differ in a way the flag name does not suggest, such as a migration on one path, the agent stops and describes it before deleting.