feature-flags

A guide for adding feature flags, which are switches that turn experimental parts of software on or off. It covers registering flags, checking them in code, and changing them through configuration or the command line.

In plain words
What is it for?
Use it when adding a new experimental feature, gating code behind a setting, or configuring how flag values are chosen.
Why use it?
It lets developers release unfinished functionality safely, enable it for selected users or environments, and turn it off without removing the code.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/marcus/sidecar/feature-flags
Any agent
npx skills add marcus/sidecar --skill feature-flags
Clone the repo
git clone --depth 1 https://github.com/marcus/sidecar

Made for: Claude Code, Codex.

Per session 53 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 1,165 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00053 $0.01165
Opus 5 $0.00026 $0.00583
Sonnet 5 $0.00011 $0.00233
Haiku 4.5 $0.00005 $0.00117

Measured 2d ago against content hash ce0b60511012, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

feature-flags scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.claude/skills/feature-flags/SKILL.md · 146 lines

How it starts

The opening of the file, as written. The whole thing — 146 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Feature Flags

Feature flags gate experimental functionality behind user-configurable settings, enabling safe rollout (default off), user opt-in, and easy rollback.

Checking Feature State

import "github.com/marcus/sidecar/internal/features"

if features.IsEnabled("tmux_interactive_input") {
    // Feature-gated code
}

Adding a New Feature Flag

  1. Define the feature in internal/features/features.go:
var MyNewFeature = Feature{
    Name:        "my_new_feature",
    Default:     false,
    Description: "Description of what this enables",
}
  1. Add to the allFeatures slice:
var allFeatures = []Feature{
    TmuxInteractiveInput,
    MyNewFeature, // Add here
}
  1. Use the feature check in your code:
if features.IsEnabled("my_new_feature") {
    // New functionality
}

That is all a flag needs to be reachable. Configuration → System → Feature Flags derives its list from features.ListAll(), so registering a feature puts a working switch on the page with the registry's own Name as the label and Description as the help text. There is no second list to remember.

Giving a flag better copy (optional)

previewCopy in internal/configui/page_flags.go overrides the registry's wording per flag. Only fill in what you want to change:

features.MyNewFeature.Name: {
    label:   "Human-readable name",
    help:    "One sentence on what turning this on does.",
    restart: true, // only if a consumer reads it once at startup
    note:    "An honest scope line for a flag that applies live but not retroactively.",
},

restart must be checked against what actually consumes the flag, never added as blanket caution — a flag read at the point of use applies immediately and must not claim otherwise. Both restart and note render when both are set.

A flag that another page already owns as a first-class setting sets owner and ownerControl instead. It is then listed read-only with a jump to the control that owns it, because two switches over one value is how surfaces start disagreeing. If the owning page's control means more than the raw flag — Panels' Conversations switch is the flag and the plugin's own enabled key — also set reads so the row reports the owner's answer rather than the flag's.

Read the full file on GitHub · 146 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 146 lines · 53 tokens per session scan A ce0b60511012

Subscribe to this mod's changes

feature-flags is a skill published in the GitHub repository marcus/sidecar (1,049 stars, last pushed 2d ago), licensed MIT. It adds 53 tokens to every session and 1,165 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.

Related

Other skills, from other repositories

intake

The planning front-door. Captures feature ideas and bugs as graded rows in the root INTAKE.md ledger. Use it when the user says "log an idea", "capture a bug", "add to the backlog", "note this down", "track this feature", or invokes /intake. Owns the requirements interview — fleshes out thin ideas, proactively…

ndisisnd/msg · 239 tokens

merge

The ship gate — the only skill that merges. --staging merges the feature→staging PR on green CI, deploys, verifies, emits a human test script and stamps the staging sign-off on approval. --production ships the double-confirmed release to main and deploys production. Never self-certifies staging; nothing reaches main…

ndisisnd/msg · 94 tokens

pre-merge

The CI gate. Takes a feature branch from "eng says done" to "PR open against staging with green checks". Runs the project's preflight-resolved pipeline from devkit/policy.json components[]: sync → parallel correctness + security waves → coverage → regression tail → security/migration → PRD-consistency → open PR. Emits…

ndisisnd/msg · 101 tokens

msg

Root menu for msg skills, plus harness modes. --init is the one-time project bootstrap — use it when the user says "initialise project", "bootstrap repo", "set up the framework", "start a new project", or asks to set up project structure in an empty repo. Other modes: --init-staging (add a staging branch), --update…

ndisisnd/msg · 162 tokens

lorekeeper-reconcile

Reconcile and fact-check Lorekeeper memories against source materials, existing documentation, and internal consistency. Use when (1) the user provides reference materials to verify against, (2) the user requests a general knowledge audit, or (3) the user wants to verify specific topics. Updates memory scores and…

Jessinra/Lorekeeper · 72 tokens

backlog-management

Lorekeeper backlog management — ticket lifecycle, numbering, scripts, and conventions. Load this when filing tickets, moving ticket states, checking what's ready to work on, or onboarding to the project workflow.

Jessinra/Lorekeeper · 43 tokens