routine-shipped-feature-inliner

Removes stale feature flags and inlines their permanently enabled code paths.

275|32|Updated Oct 2, 2020
One-click install
npx skills add https://github.com/bex-co/beancount-io --skill routine-shipped-feature-inliner-bex-co
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: routine-shipped-feature-inliner
Source: https://github.com/bex-co/beancount-io/tree/main/.agents/skills/routine-shipped-feature-inliner
Command: npx skills add https://github.com/bex-co/beancount-io --skill routine-shipped-feature-inliner-bex-co

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate feature flags, environment switches, and boolean guards that have held one value everywhere for a long time, leaving dead branches and obsolete plumbing that clutter the code and slow maintenance. ## Core Features & Use Cases - Gate Discovery: Greps the target package for gate shapes such as config.features constants, process.env boolean switches, and is*Enabled guards. - Deliberate vs Forgotten Triage: Proves a flag is forgotten by checking every setter and reader, .env.example, deploy configs, DO_NOT_DO.md files, ADRs, and git history before touching it. - Safe Removal and Shipping: Inlines the winning path, deletes the dead branch, flag definition, and obsolete tests, then ships each removal individually via /ship. - Use Case: A feature rolled out months ago still sits behind a flag set to true in every environment; invoke this routine to remove the flag, inline the enabled path, and ship the cleanup as one verified change. ## Quick Start Ask the agent to run /routine-shipped-feature-inliner on a specific package to find a fully shipped feature flag and remove it.

Frequently Asked Questions about routine-shipped-feature-inliner

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I remove a stale feature flag from my codebase?

Invoke /routine-shipped-feature-inliner with an optional package or path argument. It greps for gate shapes, proves the flag holds one value everywhere, inlines the enabled path, deletes the dead branch and flag definition, and ships the change via /ship.

How does the routine decide a feature flag is safe to delete?

A flag qualifies only if it holds one value in every environment, nothing in DO_NOT_DO.md files, ADRs, or code comments marks it deliberate, and git history shows it has sat at its final value with no pending decision. Any evidence of intent means it is skipped.

Can this routine turn on a feature flag to finish shipping a feature?

No. The routine never flips a flag value because that is a product decision, not maintenance. It only inlines flags already at their final value in every environment.

What kinds of feature gates does it detect?

It detects config.features compile-time constants, process.env variables used as boolean switches seeded in .env.example and deploy configs, is*Enabled or enable* booleans, route guards, and early returns on config values.

When should I not use the shipped feature flag cleanup routine?

Do not use it for unreachable code not behind a flag, which belongs to routine-dead-code-removal, or for cross-package contracts like a backend featureFlags GraphQL field, which require coordinated multi-package changes.