[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CTDSYA4GG227JCKJZ2SJCB":3,"skill-same:01M6CTDSYA4GG227JCKJZ2SJCB":83},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":28,"linkOnly":29,"markdownContent":30,"markdownBody":31,"frontMatter":32,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":6,"ownerDescription":41,"updatedAt":42,"install":43,"resources":56},"01M6CTDSYA4GG227JCKJZ2SJCB","feature-flags",null,"Designs a feature flag strategy and per-feature flag specs for safe rollouts. Use when releasing a feature gradually or planning flag cleanup.","vibbs\u002Fcompany-os","vibbs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F7379149?v=4","01M6CT6M03CAS1H7RA89F3965B","Vibbs Dod","01M6CT6M4MY60C9FFQ3AAR2RSK",6,"MIT","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Ffeature-flags\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27],"feature flags","flags","safe","cleanup","planning","strategy","flag cleanup","use","rollouts","2026-11-10 10:12:30",false,"---\nname: feature-flags\ndescription: Designs a feature flag strategy and per-feature flag specs for safe rollouts. Use when releasing a feature gradually or planning flag cleanup.\nruntimes:\n  claude:\n    user-invocable: false\n---\n\n# Feature Flags\n\n## Reference\n- **ID**: S-ENG-10\n- **Category**: Engineering\n- **Inputs**: company.config.yaml (feature_flags section), RFC\u002Farchitecture document, activation-onboarding output (aha moment mapping)\n- **Outputs**: company-level flag strategy (standards\u002Fengineering\u002Ffeature-flag-conventions.md), per-feature flag specifications\n- **Used by**: Engineering Agent\n- **Tool scripts**: .\u002Ftools\u002Fartifact\u002Fvalidate.sh\n\n## Purpose\n\nDesign a comprehensive feature flag strategy that goes beyond simple on\u002Foff toggles. This skill produces flag naming conventions, lifecycle management rules, cleanup SLAs, and -- when configured -- progressive discovery patterns that reveal product capabilities based on user maturity. The result is safe rollouts, clean experimentation, and an onboarding experience where users never feel overwhelmed because features appear when they are relevant.\n\n## When to Use\n\n- Setting up feature flag conventions for a new product\n- Building a new feature that needs gated rollout\n- Designing progressive disclosure of product capabilities\n- Auditing existing flags for cleanup or debt\n- Planning A\u002FB experiments that require flag infrastructure\n\n## Feature Flag Procedure\n\n### Step 1: Load Context\n\nBefore designing any flag strategy:\n\n1. **Read `company.config.yaml`** -- extract:\n   - `feature_flags.provider` (e.g., LaunchDarkly, Flagsmith, Unleash, custom, config-file)\n   - `feature_flags.strategy` (e.g., `release-only`, `progressive-discovery`, `full`)\n   - `feature_flags.cleanup_sla_days` (e.g., 14, 30, 60)\n2. **Read existing activation-onboarding output** in `artifacts\u002Fgrowth\u002F` -- extract aha moment mapping and onboarding milestones (these feed into progressive discovery levels)\n3. **Read existing RFCs** in `artifacts\u002Frfcs\u002F` -- understand what features are being built and need flag specs\n4. **Check `standards\u002Fengineering\u002F`** -- see if flag conventions already exist (update rather than overwrite)\n\n### Step 2: Generate Company-Level Flag Strategy\n\nProduce `standards\u002Fengineering\u002Ffeature-flag-conventions.md` with the following structure:\n\n#### Flag Naming Convention\n\nFormat: `ff.\u003Cdomain>.\u003Cfeature>`\n\n**Rules**:\n- Prefix is always `ff.` to distinguish flags from other configuration\n- `\u003Cdomain>` is the product area (e.g., `billing`, `onboarding`, `editor`, `auth`)\n- `\u003Cfeature>` is the specific capability (e.g., `annual_plans`, `ai_assist`, `sso`)\n- Lowercase throughout, underscores within segments\n\n**Examples**:\n```\nff.billing.annual_plans\nff.editor.ai_assist\nff.auth.sso_login\nff.onboarding.interactive_tour\nff.dashboard.advanced_analytics\n```\n\n#### Flag Lifecycle\n\nEvery flag progresses through a defined lifecycle:\n\n```\ncreated → testing → rolling_out → fully_enabled → cleanup\n```\n\n| State | Description | Who Owns |\n|-------|-------------|----------|\n| `created` | Flag defined in code and provider, default OFF | Engineer |\n| `testing` | Enabled for internal team and staging | Engineer |\n| `rolling_out` | Gradual percentage rollout to production users | Engineer + Product |\n| `fully_enabled` | 100% of users, monitoring for issues | Product |\n| `cleanup` | Flag code removed, feature is permanent | Engineer |\n\n#### Flag Types\n\nThe available flag types depend on the `feature_flags.strategy` config value:\n\n| Strategy Config | Available Flag Types |\n|-----------------|---------------------|\n| `release-only` | Release, Ops |\n| `progressive-discovery` | Discovery, Ops |\n| `full` | Release, Experiment, Ops, Discovery |\n\n**Release flag**: Temporary. Gates a deployment. Default OFF, rolled out by percentage, removed within `cleanup_sla_days` of reaching 100%. Use for any new feature deployment.\n\n**Experiment flag**: Temporary. A\u002FB test variant selector. Default OFF, assigns users to control\u002Ftreatment groups. Removed after experiment concludes and decision is made. Requires metrics definition before creation.\n\n**Ops flag**: Semi-permanent. Kill switch or circuit breaker. Default ON (feature active), flipped OFF to disable a misbehaving feature instantly. Reviewed quarterly -- either promote to permanent config or remove.\n\n**Discovery flag**: Progressive. Reveals features based on user maturity level. Default determined by discovery level (Level 0 = ON for all, Level 1+ = OFF until unlocked). Transitions happen automatically based on trigger conditions. See Step 3 for the progressive discovery pattern.\n\n#### Cleanup SLA\n\n- Release flags: must be removed within `cleanup_sla_days` (from config) of reaching `fully_enabled`\n- Experiment flags: must be removed within `cleanup_sla_days` of experiment conclusion\n- Ops flags: reviewed quarterly; either promoted to permanent configuration or removed\n- Discovery flags: remain active as long as progressive discovery is the product strategy\n\n#### Flag Debt Tracking\n\nFlags older than the cleanup SLA without a cleanup commit are flagged during code review (see `code-review` skill). Track flag debt with:\n\n- A comment in the flag definition file noting the creation date and expected cleanup date\n- A periodic audit (monthly) that lists all flags past their SLA\n- CI warning (optional) that flags code referencing stale flags\n\n#### Provider-Specific Patterns\n\n**LaunchDarkly**: Use targeting rules for percentage rollouts. Use segments for discovery levels. Use custom attributes for tenant\u002Fuser maturity data.\n\n**Flagsmith**: Use environment-level flags for release. Use segments with trait-based rules for discovery. Use remote config for ops kill switches.\n\n**Unleash**: Use gradual rollout strategy for release flags. Use custom strategies for discovery level evaluation. Use variants for experiment flags.\n\n**Custom (in-house)**: Implement a flag evaluation service that reads from database\u002Fconfig. Support percentage-based, user-attribute-based, and segment-based evaluation. Cache aggressively with short TTL.\n\n**Config-file**: Use environment-specific config files (e.g., `flags.production.yaml`). Suitable for release and ops flags only. Not recommended for experiment or discovery flags (requires deploy to change).\n\n### Step 3: Progressive Discovery Pattern\n\n**Only applies when `feature_flags.strategy` is `progressive-discovery` or `full`.**\n\nProgressive discovery prevents user overwhelm by revealing product capabilities as users demonstrate readiness. Features are classified into levels, and users unlock levels through natural product usage.\n\n#### Discovery Levels\n\n| Level | Name | Visibility | Trigger to Unlock |\n|-------|------|------------|-------------------|\n| **Level 0** | Core | Always visible to all users | None -- these are essential product value |\n| **Level 1** | Foundations | Unlocked after user completes core flow | Action-based: user completes the \"aha moment\" action (e.g., first project created, first report generated) |\n| **Level 2** | Power | Unlocked after proficiency demonstrated | Compound trigger: e.g., 5+ projects created AND 7+ days active AND core feature used 10+ times |\n| **Level 3** | Expert | Unlocked on request or after sustained engagement | Time + action: e.g., 30+ days active AND advanced action performed, OR user explicitly requests via settings |\n\n#### Trigger Condition Types\n\nEach level transition is governed by one or more trigger conditions:\n\n- **Action-based**: User performs a specific action N times (e.g., `projects.created >= 1`)\n- **Time-based**: User has been active for N days (e.g., `days_since_signup >= 7`)\n- **Milestone-based**: User reaches a product milestone (e.g., `onboarding.completed == true`)\n- **Compound**: Multiple conditions combined with AND\u002FOR logic\n- **Manual override**: User requests access via settings, or admin grants access\n\n#### Coordination with Activation-Onboarding\n\nProgressive discovery levels map directly to the activation-onboarding skill's aha moment flow:\n\n- **Level 0 to Level 1 transition** = the user has reached the aha moment (first value realization)\n- **Level 1 to Level 2 transition** = the user has moved from activated to retained (habitual usage)\n- **Level 2 to Level 3 transition** = the user is a power user or champion\n\nWhen the activation-onboarding skill defines the aha moment action, that same action becomes the Level 1 unlock trigger for progressive discovery.\n\n#### User Experience Rules\n\n- Features appearing at a new level should have a subtle introduction (tooltip, badge, \"New\" label)\n- Users should never lose access to a feature they have unlocked (levels only go up, never down)\n- A \"Show all features\" toggle in settings allows power users to bypass progressive discovery\n- Discovery level is per-user, not per-tenant (different team members may be at different levels)\n\n### Step 4: Per-Feature Flag Specification\n\nFor each feature being built (read from the RFC):\n\n1. **Define the flag specification**:\n\n   | Field | Value |\n   |-------|-------|\n   | **Flag name** | `ff.\u003Cdomain>.\u003Cfeature>` |\n   | **Flag type** | Release \u002F Experiment \u002F Ops \u002F Discovery |\n   | **Default state** | ON or OFF (with rationale) |\n   | **Rollout plan** | Percentage stages and timeline (e.g., 5% day 1, 25% day 3, 50% day 5, 100% day 7) |\n   | **Cleanup date** | Calculated from rollout completion + `cleanup_sla_days` |\n   | **Discovery level** | Level 0 \u002F 1 \u002F 2 \u002F 3 (only if strategy includes discovery) |\n\n2. **Define metrics per flag state**:\n   - What to measure when the flag is ON vs OFF\n   - Success criteria for rolling out further (e.g., error rate \u003C 0.1%, latency p99 \u003C 200ms)\n   - Failure criteria that trigger automatic rollback\n   - Coordinate with the `instrumentation` skill for event taxonomy -- flag toggle events should follow the `object.action` convention (e.g., `feature_flag.evaluated`, `feature_flag.toggled`)\n\n3. **Define the kill switch** (for Ops and Release flags):\n   - What conditions trigger automatic disable (e.g., error rate spike, latency degradation, user complaints threshold)\n   - Who is notified when the kill switch activates\n   - What the fallback behavior is when the flag is OFF\n   - How to re-enable after a kill switch event (requires explicit action, not automatic)\n\n### Step 5: Verify\n\nFinal verification checklist:\n\n- [ ] All new features in the RFC have a corresponding flag specification\n- [ ] Progressive discovery levels are defined with concrete trigger conditions (if strategy includes discovery)\n- [ ] Cleanup dates are calculated and set within `cleanup_sla_days`\n- [ ] Kill switches are defined for all release and ops flags\n- [ ] Flag naming follows the `ff.\u003Cdomain>.\u003Cfeature>` convention\n- [ ] Metrics are defined for both flag-ON and flag-OFF states\n- [ ] Provider-specific implementation notes are included\n- [ ] Flag specifications are saved and artifact is validated with `.\u002Ftools\u002Fartifact\u002Fvalidate.sh`\n\n## Cross-References\n\n- **activation-onboarding** skill: Aha moment mapping feeds directly into progressive discovery Level 1 unlock triggers. When activation-onboarding defines the first-value action, use it as the Level 0 to Level 1 transition condition.\n- **instrumentation** skill: Event taxonomy for flag-related events (`feature_flag.evaluated`, `feature_flag.toggled`). Per-flag metrics should follow the instrumentation conventions and integrate into the analytics dashboard.\n- **code-review** skill: Flag debt detection during reviews. Flags past their cleanup SLA should be raised as code quality issues during the Code Quality section of reviews.\n- **experiment-framework** skill: For experiment-type flags, a corresponding experiment spec should exist with hypothesis, sample size calculation, and analysis plan. The feature-flags skill defines the flag; the experiment-framework skill ensures the experiment behind it is statistically sound.\n\n## Quality Checklist\n\n- [ ] Flag naming follows `ff.\u003Cdomain>.\u003Cfeature>` convention\n- [ ] Flag type is classified (release, experiment, ops, discovery)\n- [ ] Default state is explicit (enabled or disabled)\n- [ ] Rollout plan has percentages and timeline\n- [ ] Cleanup date is set within `cleanup_sla_days`\n- [ ] Progressive discovery level is assigned (if strategy includes discovery)\n- [ ] Kill switch conditions defined for ops and release flags\n","# Feature Flags\n\n## Reference\n- **ID**: S-ENG-10\n- **Category**: Engineering\n- **Inputs**: company.config.yaml (feature_flags section), RFC\u002Farchitecture document, activation-onboarding output (aha moment mapping)\n- **Outputs**: company-level flag strategy (standards\u002Fengineering\u002Ffeature-flag-conventions.md), per-feature flag specifications\n- **Used by**: Engineering Agent\n- **Tool scripts**: .\u002Ftools\u002Fartifact\u002Fvalidate.sh\n\n## Purpose\n\nDesign a comprehensive feature flag strategy that goes beyond simple on\u002Foff toggles. This skill produces flag naming conventions, lifecycle management rules, cleanup SLAs, and -- when configured -- progressive discovery patterns that reveal product capabilities based on user maturity. The result is safe rollouts, clean experimentation, and an onboarding experience where users never feel overwhelmed because features appear when they are relevant.\n\n## When to Use\n\n- Setting up feature flag conventions for a new product\n- Building a new feature that needs gated rollout\n- Designing progressive disclosure of product capabilities\n- Auditing existing flags for cleanup or debt\n- Planning A\u002FB experiments that require flag infrastructure\n\n## Feature Flag Procedure\n\n### Step 1: Load Context\n\nBefore designing any flag strategy:\n\n1. **Read `company.config.yaml`** -- extract:\n   - `feature_flags.provider` (e.g., LaunchDarkly, Flagsmith, Unleash, custom, config-file)\n   - `feature_flags.strategy` (e.g., `release-only`, `progressive-discovery`, `full`)\n   - `feature_flags.cleanup_sla_days` (e.g., 14, 30, 60)\n2. **Read existing activation-onboarding output** in `artifacts\u002Fgrowth\u002F` -- extract aha moment mapping and onboarding milestones (these feed into progressive discovery levels)\n3. **Read existing RFCs** in `artifacts\u002Frfcs\u002F` -- understand what features are being built and need flag specs\n4. **Check `standards\u002Fengineering\u002F`** -- see if flag conventions already exist (update rather than overwrite)\n\n### Step 2: Generate Company-Level Flag Strategy\n\nProduce `standards\u002Fengineering\u002Ffeature-flag-conventions.md` with the following structure:\n\n#### Flag Naming Convention\n\nFormat: `ff.\u003Cdomain>.\u003Cfeature>`\n\n**Rules**:\n- Prefix is always `ff.` to distinguish flags from other configuration\n- `\u003Cdomain>` is the product area (e.g., `billing`, `onboarding`, `editor`, `auth`)\n- `\u003Cfeature>` is the specific capability (e.g., `annual_plans`, `ai_assist`, `sso`)\n- Lowercase throughout, underscores within segments\n\n**Examples**:\n```\nff.billing.annual_plans\nff.editor.ai_assist\nff.auth.sso_login\nff.onboarding.interactive_tour\nff.dashboard.advanced_analytics\n```\n\n#### Flag Lifecycle\n\nEvery flag progresses through a defined lifecycle:\n\n```\ncreated → testing → rolling_out → fully_enabled → cleanup\n```\n\n| State | Description | Who Owns |\n|-------|-------------|----------|\n| `created` | Flag defined in code and provider, default OFF | Engineer |\n| `testing` | Enabled for internal team and staging | Engineer |\n| `rolling_out` | Gradual percentage rollout to production users | Engineer + Product |\n| `fully_enabled` | 100% of users, monitoring for issues | Product |\n| `cleanup` | Flag code removed, feature is permanent | Engineer |\n\n#### Flag Types\n\nThe available flag types depend on the `feature_flags.strategy` config value:\n\n| Strategy Config | Available Flag Types |\n|-----------------|---------------------|\n| `release-only` | Release, Ops |\n| `progressive-discovery` | Discovery, Ops |\n| `full` | Release, Experiment, Ops, Discovery |\n\n**Release flag**: Temporary. Gates a deployment. Default OFF, rolled out by percentage, removed within `cleanup_sla_days` of reaching 100%. Use for any new feature deployment.\n\n**Experiment flag**: Temporary. A\u002FB test variant selector. Default OFF, assigns users to control\u002Ftreatment groups. Removed after experiment concludes and decision is made. Requires metrics definition before creation.\n\n**Ops flag**: Semi-permanent. Kill switch or circuit breaker. Default ON (feature active), flipped OFF to disable a misbehaving feature instantly. Reviewed quarterly -- either promote to permanent config or remove.\n\n**Discovery flag**: Progressive. Reveals features based on user maturity level. Default determined by discovery level (Level 0 = ON for all, Level 1+ = OFF until unlocked). Transitions happen automatically based on trigger conditions. See Step 3 for the progressive discovery pattern.\n\n#### Cleanup SLA\n\n- Release flags: must be removed within `cleanup_sla_days` (from config) of reaching `fully_enabled`\n- Experiment flags: must be removed within `cleanup_sla_days` of experiment conclusion\n- Ops flags: reviewed quarterly; either promoted to permanent configuration or removed\n- Discovery flags: remain active as long as progressive discovery is the product strategy\n\n#### Flag Debt Tracking\n\nFlags older than the cleanup SLA without a cleanup commit are flagged during code review (see `code-review` skill). Track flag debt with:\n\n- A comment in the flag definition file noting the creation date and expected cleanup date\n- A periodic audit (monthly) that lists all flags past their SLA\n- CI warning (optional) that flags code referencing stale flags\n\n#### Provider-Specific Patterns\n\n**LaunchDarkly**: Use targeting rules for percentage rollouts. Use segments for discovery levels. Use custom attributes for tenant\u002Fuser maturity data.\n\n**Flagsmith**: Use environment-level flags for release. Use segments with trait-based rules for discovery. Use remote config for ops kill switches.\n\n**Unleash**: Use gradual rollout strategy for release flags. Use custom strategies for discovery level evaluation. Use variants for experiment flags.\n\n**Custom (in-house)**: Implement a flag evaluation service that reads from database\u002Fconfig. Support percentage-based, user-attribute-based, and segment-based evaluation. Cache aggressively with short TTL.\n\n**Config-file**: Use environment-specific config files (e.g., `flags.production.yaml`). Suitable for release and ops flags only. Not recommended for experiment or discovery flags (requires deploy to change).\n\n### Step 3: Progressive Discovery Pattern\n\n**Only applies when `feature_flags.strategy` is `progressive-discovery` or `full`.**\n\nProgressive discovery prevents user overwhelm by revealing product capabilities as users demonstrate readiness. Features are classified into levels, and users unlock levels through natural product usage.\n\n#### Discovery Levels\n\n| Level | Name | Visibility | Trigger to Unlock |\n|-------|------|------------|-------------------|\n| **Level 0** | Core | Always visible to all users | None -- these are essential product value |\n| **Level 1** | Foundations | Unlocked after user completes core flow | Action-based: user completes the \"aha moment\" action (e.g., first project created, first report generated) |\n| **Level 2** | Power | Unlocked after proficiency demonstrated | Compound trigger: e.g., 5+ projects created AND 7+ days active AND core feature used 10+ times |\n| **Level 3** | Expert | Unlocked on request or after sustained engagement | Time + action: e.g., 30+ days active AND advanced action performed, OR user explicitly requests via settings |\n\n#### Trigger Condition Types\n\nEach level transition is governed by one or more trigger conditions:\n\n- **Action-based**: User performs a specific action N times (e.g., `projects.created >= 1`)\n- **Time-based**: User has been active for N days (e.g., `days_since_signup >= 7`)\n- **Milestone-based**: User reaches a product milestone (e.g., `onboarding.completed == true`)\n- **Compound**: Multiple conditions combined with AND\u002FOR logic\n- **Manual override**: User requests access via settings, or admin grants access\n\n#### Coordination with Activation-Onboarding\n\nProgressive discovery levels map directly to the activation-onboarding skill's aha moment flow:\n\n- **Level 0 to Level 1 transition** = the user has reached the aha moment (first value realization)\n- **Level 1 to Level 2 transition** = the user has moved from activated to retained (habitual usage)\n- **Level 2 to Level 3 transition** = the user is a power user or champion\n\nWhen the activation-onboarding skill defines the aha moment action, that same action becomes the Level 1 unlock trigger for progressive discovery.\n\n#### User Experience Rules\n\n- Features appearing at a new level should have a subtle introduction (tooltip, badge, \"New\" label)\n- Users should never lose access to a feature they have unlocked (levels only go up, never down)\n- A \"Show all features\" toggle in settings allows power users to bypass progressive discovery\n- Discovery level is per-user, not per-tenant (different team members may be at different levels)\n\n### Step 4: Per-Feature Flag Specification\n\nFor each feature being built (read from the RFC):\n\n1. **Define the flag specification**:\n\n   | Field | Value |\n   |-------|-------|\n   | **Flag name** | `ff.\u003Cdomain>.\u003Cfeature>` |\n   | **Flag type** | Release \u002F Experiment \u002F Ops \u002F Discovery |\n   | **Default state** | ON or OFF (with rationale) |\n   | **Rollout plan** | Percentage stages and timeline (e.g., 5% day 1, 25% day 3, 50% day 5, 100% day 7) |\n   | **Cleanup date** | Calculated from rollout completion + `cleanup_sla_days` |\n   | **Discovery level** | Level 0 \u002F 1 \u002F 2 \u002F 3 (only if strategy includes discovery) |\n\n2. **Define metrics per flag state**:\n   - What to measure when the flag is ON vs OFF\n   - Success criteria for rolling out further (e.g., error rate \u003C 0.1%, latency p99 \u003C 200ms)\n   - Failure criteria that trigger automatic rollback\n   - Coordinate with the `instrumentation` skill for event taxonomy -- flag toggle events should follow the `object.action` convention (e.g., `feature_flag.evaluated`, `feature_flag.toggled`)\n\n3. **Define the kill switch** (for Ops and Release flags):\n   - What conditions trigger automatic disable (e.g., error rate spike, latency degradation, user complaints threshold)\n   - Who is notified when the kill switch activates\n   - What the fallback behavior is when the flag is OFF\n   - How to re-enable after a kill switch event (requires explicit action, not automatic)\n\n### Step 5: Verify\n\nFinal verification checklist:\n\n- [ ] All new features in the RFC have a corresponding flag specification\n- [ ] Progressive discovery levels are defined with concrete trigger conditions (if strategy includes discovery)\n- [ ] Cleanup dates are calculated and set within `cleanup_sla_days`\n- [ ] Kill switches are defined for all release and ops flags\n- [ ] Flag naming follows the `ff.\u003Cdomain>.\u003Cfeature>` convention\n- [ ] Metrics are defined for both flag-ON and flag-OFF states\n- [ ] Provider-specific implementation notes are included\n- [ ] Flag specifications are saved and artifact is validated with `.\u002Ftools\u002Fartifact\u002Fvalidate.sh`\n\n## Cross-References\n\n- **activation-onboarding** skill: Aha moment mapping feeds directly into progressive discovery Level 1 unlock triggers. When activation-onboarding defines the first-value action, use it as the Level 0 to Level 1 transition condition.\n- **instrumentation** skill: Event taxonomy for flag-related events (`feature_flag.evaluated`, `feature_flag.toggled`). Per-flag metrics should follow the instrumentation conventions and integrate into the analytics dashboard.\n- **code-review** skill: Flag debt detection during reviews. Flags past their cleanup SLA should be raised as code quality issues during the Code Quality section of reviews.\n- **experiment-framework** skill: For experiment-type flags, a corresponding experiment spec should exist with hypothesis, sample size calculation, and analysis plan. The feature-flags skill defines the flag; the experiment-framework skill ensures the experiment behind it is statistically sound.\n\n## Quality Checklist\n\n- [ ] Flag naming follows `ff.\u003Cdomain>.\u003Cfeature>` convention\n- [ ] Flag type is classified (release, experiment, ops, discovery)\n- [ ] Default state is explicit (enabled or disabled)\n- [ ] Rollout plan has percentages and timeline\n- [ ] Cleanup date is set within `cleanup_sla_days`\n- [ ] Progressive discovery level is assigned (if strategy includes discovery)\n- [ ] Kill switch conditions defined for ops and release flags\n",{"name":5,"runtimes":33,"description":7},{"claude":34},{"user-invocable":29},"main","e842fb6d0e04360c47db78bc2e2e2987314d64d4","os\u002Fskills\u002Ffeature-flags",2,"https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os","https:\u002F\u002Fgithub.com\u002Fvibbs","Principal Engineer · Applied AI · building ArcAI @ GrowthArc","2026-10-21 02:08:08",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add vibbs\u002Fcompany-os --skill feature-flags",{"tool":49,"command":50},"bunx","bunx skills add vibbs\u002Fcompany-os --skill feature-flags",{"tool":52,"command":53},"pnpm","pnpm dlx skills add vibbs\u002Fcompany-os --skill feature-flags","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Ffeature-flags\u002FSKILL.md",true,[57,63,67,71,75,79],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"references\u002Fbuilding.md","REFERENCE","参考文档",5917,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fcirq\u002Freferences\u002Fbuilding.md",{"path":64,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":65,"sourceHtmlUrl":66},"references\u002Fexperiments.md",15488,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fcirq\u002Freferences\u002Fexperiments.md",{"path":68,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Fhardware.md",11520,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fcirq\u002Freferences\u002Fhardware.md",{"path":72,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fnoise.md",13363,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fcirq\u002Freferences\u002Fnoise.md",{"path":76,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fsimulation.md",8239,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fcirq\u002Freferences\u002Fsimulation.md",{"path":80,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Ftransformation.md",10142,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fcirq\u002Freferences\u002Ftransformation.md",[84,93,101,111,127,145],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":28},"01M6CTHBW1E64ECYGD105N4S5E","typo-field","Fixture skill with a misspelled top-level field.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Ftypo-field\u002FSKILL.md",[],[91,92],"typo field","fixture skill",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":28},"01M6CTHABTV8FKVDHFMMKPAV51","spaced-comments","Fixture skill with comments and spaces after block keys.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fspaced-comments\u002FSKILL.md",[],[100,92],"spaced comments",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":28},"01M6CTH8MHC14KB65ZDHYBJW1N","crlf-comments","Fixture skill with Windows line endings.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fcrlf-comments\u002FSKILL.md",[],[108,109,110,92],"crlf comments","CRLF","windows",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":28},"01M6CTH6TBKTDP9G8QB1Z2K0TY","claude-fields","Fixture skill using top-level fields Claude Code documents.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fclaude-fields\u002FSKILL.md",[],[118,119,120,121,122,123,92,124,125,126],"claude fields","explore","documents","src","grep","read","Bash","code","testing",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":138,"publishedAt":28},"01M6CTH46BGKXH80RWS876Y2CW","workflow-router","Maps an objective to the artifacts, stages and agents it needs. Use when deciding what happens next or which agents to involve.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fworkflow-router\u002FSKILL.md",[133],{"categoryNo":134,"categoryName":135,"taxonomyType":136,"taxonomyTypeDesc":137},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[139,140,141,142,143,26,144],"workflow","router","workflow router","next","maps","artifacts",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":28},"01M6CTH27653SRVP2FMEQN3J5B","weekly-review","Summarizes your week: what shipped, AI spend, support themes, security health and next priorities. Use at the end of each week.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fweekly-review\u002FSKILL.md",[],[152,153,154,142,26,155,156,157,158],"weekly review","review","priorities","health","save","support","security"]