Create Feature Flag Plan
Overview
Generate a feature flag lifecycle plan for progressive delivery. Covers flag naming, rollout stages from internal to beta to GA, kill switch behavior, monitoring requirements at each stage, and a cleanup plan with a deadline and owner for flag removal. Prevents flag debt and ensures safe, observable rollouts.
Workflow
Read engineering context -- Scan .chalk/docs/engineering/ for existing feature flag conventions, architecture docs, and monitoring infrastructure. Check .chalk/docs/product/ for the PRD or pitch that describes the feature being flagged.
Parse the feature -- Extract from $ARGUMENTS the feature to create a flag plan for. If unspecified, ask the user to name the feature.
Determine the next file number -- Read filenames in .chalk/docs/engineering/ to find the highest numbered file. The next number is highest + 1.
Define the flag -- Name the flag following conventions found in engineering docs, or default to enable_<feature_slug>. Specify the flag type (boolean, percentage, user-segment) and default value (always off).
Plan rollout stages:
- Internal (team only): Who tests, what to validate, success criteria to advance
- Beta (selected users/accounts): Selection criteria, opt-in mechanism, feedback channel, success criteria to advance
- GA (all users): Ramp schedule (e.g., 10% -> 25% -> 50% -> 100%), monitoring checkpoints at each ramp
Define kill switch behavior -- What happens when the flag is turned off mid-rollout: data handling, in-flight operations, user communication, rollback procedure.
Specify monitoring at each stage -- What metrics, alerts, and dashboards to watch. Define thresholds that trigger a rollback (e.g., error rate > 1%, p95 latency > 500ms).
Set cleanup plan -- Define: cleanup deadline (date by which the flag must be removed), owner responsible for removal, what "removal" means (delete flag checks, remove old code path, update tests).
Write the file -- Save to .chalk/docs/engineering/<n>_feature_flag_plan_<feature-slug>.md.
Confirm -- Share the file path and highlight the rollback triggers and cleanup deadline.
Output
- File:
.chalk/docs/engineering/<n>_feature_flag_plan_<feature-slug>.md
- Format: Plain markdown with flag definition, rollout stages table, kill switch section, and cleanup plan
- First line:
# Feature Flag Plan: <Feature Name>
Anti-patterns
- No cleanup deadline -- Flags without removal dates become permanent. Every flag plan must have a cleanup date and an owner. Treat it as tech debt with a due date.
- Binary rollout -- Going from 0% to 100% with no intermediate stages defeats the purpose of progressive delivery. Always define at least internal, beta, and GA stages.
- No rollback triggers -- "We will monitor" is not a plan. Define specific metric thresholds that trigger an automatic or manual rollback.
- Flag naming chaos -- Inconsistent naming (camelCase, snake_case, random prefixes) makes flags impossible to audit. Follow or establish a naming convention.
- Missing kill switch behavior -- What happens to in-flight requests when you flip the flag off? If you have not answered this, the rollback plan is incomplete.
1---2name: create-feature-flag-plan3description: Plan progressive delivery with feature flag lifecycle management when the user asks to create a feature flag plan, rollout strategy, or progressive delivery plan4---5
6# Create Feature Flag Plan
7
8## Overview
9
10Generate a feature flag lifecycle plan for progressive delivery. Covers flag naming, rollout stages from internal to beta to GA, kill switch behavior, monitoring requirements at each stage, and a cleanup plan with a deadline and owner for flag removal. Prevents flag debt and ensures safe, observable rollouts.
11
12## Workflow
13
141. **Read engineering context** -- Scan `.chalk/docs/engineering/` for existing feature flag conventions, architecture docs, and monitoring infrastructure. Check `.chalk/docs/product/` for the PRD or pitch that describes the feature being flagged.
15
162. **Parse the feature** -- Extract from `$ARGUMENTS` the feature to create a flag plan for. If unspecified, ask the user to name the feature.
17
183. **Determine the next file number** -- Read filenames in `.chalk/docs/engineering/` to find the highest numbered file. The next number is `highest + 1`.
19
204. **Define the flag** -- Name the flag following conventions found in engineering docs, or default to `enable_<feature_slug>`. Specify the flag type (boolean, percentage, user-segment) and default value (always off).
21
225. **Plan rollout stages**:
23 - **Internal** (team only): Who tests, what to validate, success criteria to advance
24 - **Beta** (selected users/accounts): Selection criteria, opt-in mechanism, feedback channel, success criteria to advance
25 - **GA** (all users): Ramp schedule (e.g., 10% -> 25% -> 50% -> 100%), monitoring checkpoints at each ramp
26
276. **Define kill switch behavior** -- What happens when the flag is turned off mid-rollout: data handling, in-flight operations, user communication, rollback procedure.
28
297. **Specify monitoring at each stage** -- What metrics, alerts, and dashboards to watch. Define thresholds that trigger a rollback (e.g., error rate > 1%, p95 latency > 500ms).
30
318. **Set cleanup plan** -- Define: cleanup deadline (date by which the flag must be removed), owner responsible for removal, what "removal" means (delete flag checks, remove old code path, update tests).
32
339. **Write the file** -- Save to `.chalk/docs/engineering/<n>_feature_flag_plan_<feature-slug>.md`.
34
3510. **Confirm** -- Share the file path and highlight the rollback triggers and cleanup deadline.
36
37## Output
38
39- **File**: `.chalk/docs/engineering/<n>_feature_flag_plan_<feature-slug>.md`
40- **Format**: Plain markdown with flag definition, rollout stages table, kill switch section, and cleanup plan
41- **First line**: `# Feature Flag Plan: <Feature Name>`
42
43## Anti-patterns
44
45- **No cleanup deadline** -- Flags without removal dates become permanent. Every flag plan must have a cleanup date and an owner. Treat it as tech debt with a due date.
46- **Binary rollout** -- Going from 0% to 100% with no intermediate stages defeats the purpose of progressive delivery. Always define at least internal, beta, and GA stages.
47- **No rollback triggers** -- "We will monitor" is not a plan. Define specific metric thresholds that trigger an automatic or manual rollback.
48- **Flag naming chaos** -- Inconsistent naming (camelCase, snake_case, random prefixes) makes flags impossible to audit. Follow or establish a naming convention.
49- **Missing kill switch behavior** -- What happens to in-flight requests when you flip the flag off? If you have not answered this, the rollback plan is incomplete.
majiayu000