[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71F9VS59YQ7FQTQPTGJSHA6":3,"skill-same:01M71F9VS59YQ7FQTQPTGJSHA6":116},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":14,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M71F9VS59YQ7FQTQPTGJSHA6","feature-flags-architect",null,"Use when adding, retiring, or auditing feature flags. Triggers on \"add a flag\", \"ship behind a flag\", \"rollout plan\", \"kill switch\", \"stale flags\", \"flag debt\", \"LaunchDarkly\", \"GrowthBook\", \"Statsig\", \"Unleash\", \"Flipt\", or any progressive-delivery question. Ships flag debt scanner, rollout planner, and kill-switch auditor (all stdlib Python), 4 references on flag taxonomy + provider trade-offs + rollout strategies + lifecycle, plus a \u002Fflag-cleanup slash command.","agency-black\u002FSkills","agency-black","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F234862658?v=4","01M6HWVFPNGNR5N2CX9ECSAD57","agencia.black","01M719WF77BF3HN0N9FK1APEFY",0,"MIT","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fengineering\u002Fskills\u002Ffeature-flags-architect\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"architect","feature flags","feature flags architect","feature","flags","growthbook","when","trade-offs","scanner","release-engineering","flipt","unleash","statsig","cleanup","launchdarkly","rollout","progressive-delivery","feature-flags","question","code","2026-11-10 10:12:30",false,"---\nname: feature-flags-architect\ndescription: Use when adding, retiring, or auditing feature flags. Triggers on \"add a flag\", \"ship behind a flag\", \"rollout plan\", \"kill switch\", \"stale flags\", \"flag debt\", \"LaunchDarkly\", \"GrowthBook\", \"Statsig\", \"Unleash\", \"Flipt\", or any progressive-delivery question. Ships flag debt scanner, rollout planner, and kill-switch auditor (all stdlib Python), 4 references on flag taxonomy + provider trade-offs + rollout strategies + lifecycle, plus a \u002Fflag-cleanup slash command.\ncontext: fork\nversion: 2.9.0\nauthor: claude-code-skills\nlicense: MIT\ntags: [feature-flags, progressive-delivery, rollout, kill-switch, launchdarkly, growthbook, statsig, unleash, flipt, release-engineering]\ncompatible_tools: [claude-code, codex-cli, cursor, antigravity, opencode, gemini-cli]\n---\n\n# Feature Flags Architect\n\nEnd-to-end discipline for feature flags: classify them, ship them, ramp them, and retire them. Most teams treat flags as throwaway `if`-statements; this skill treats them as a controlled lifecycle with measurable debt.\n\n## When to use\n\n- Adding a new flag and need a rollout plan\n- Auditing a codebase for stale or orphaned flags\n- Choosing a flag provider (LaunchDarkly vs GrowthBook vs Statsig vs Unleash vs Flipt vs build-your-own)\n- Designing a kill-switch path for a risky launch\n- Cleaning up flag debt before a release freeze\n- Reviewing whether a feature should ship behind a flag at all\n\n## Core principle: flags are a lifecycle, not an `if`\n\n```\nrequest → design → ship → ramp → cleanup → archive\n```\n\nFlags that skip cleanup become debt: dead branches, stale defaults, untested code paths, unbounded blast radius. The three scripts in this skill enforce the lifecycle.\n\n## Quick start\n\n```bash\n# 1. Audit the repo for flag debt\npython scripts\u002Fflag_debt_scanner.py --repo . --max-age-days 90\n\n# 2. Plan a progressive rollout for a new flag\npython scripts\u002Frollout_planner.py --population 100000 --target-percent 100 --duration-days 14 --strategy ring\n\n# 3. Verify every flag has a documented kill switch\npython scripts\u002Fkill_switch_audit.py --repo . --flag-doc docs\u002Ffeature-flags.md\n```\n\n## The 4 flag types (taxonomy)\n\nDifferent flag types have different lifespans and ownership. Misclassifying creates debt.\n\n| Type | Purpose | Typical lifespan | Owner | Cleanup trigger |\n|---|---|---|---|---|\n| **Release** | Hide unfinished features in production | days–weeks | Eng | 100% rollout reached |\n| **Experiment** | A\u002FB test variants | weeks | Product\u002FMarketing | Test concluded; winner picked |\n| **Operational** | Circuit breakers, perf toggles, kill switches | months–years | Eng\u002FSRE | Replaced by autoscaling\u002Ffeature retirement |\n| **Permission** | Entitlements per user\u002Faccount\u002Fplan | years (permanent) | Product | Plan\u002Frole removed |\n\nOnly Release and Experiment flags should be on a debt-scanner watchlist. Operational and Permission flags are by design long-lived. See `references\u002Fflag_taxonomy.md` for decision tree.\n\n## The 3 Python tools\n\nAll three are stdlib-only. Run with `--help`.\n\n### `flag_debt_scanner.py`\n\nFinds flags older than `--max-age-days` with low usage, suggesting candidates for cleanup.\n\n```bash\npython scripts\u002Fflag_debt_scanner.py --repo . --max-age-days 90 --format text\npython scripts\u002Fflag_debt_scanner.py --repo . --max-age-days 60 --format json > debt.json\n```\n\n**Detection heuristic:**\n1. Walk `--repo` for code references matching common flag-call patterns:\n   - `flag(\"...\")`, `isFlagEnabled(\"...\")`, `featureFlag(\"...\")`, `getFlag(\"...\")`\n   - `client.variation(\"...\", ...)`, `unleash.isEnabled(\"...\")`, `growthbook.feature(\"...\")`\n2. For each unique flag identifier, find the oldest commit that introduced it (`git log --diff-filter=A -S \u003Cname>`).\n3. Flag as DEBT if introduced > `--max-age-days` ago AND used in ≤`--min-uses` places.\n\nOutputs flag name, age in days, file references, suggested action. JSON mode is CI-friendly.\n\n### `rollout_planner.py`\n\nGenerates a phased rollout schedule from population size, target percent, duration, and strategy.\n\n```bash\npython scripts\u002Frollout_planner.py --population 100000 --target-percent 100 --duration-days 14 --strategy ring\npython scripts\u002Frollout_planner.py --population 50000 --target-percent 25 --duration-days 7 --strategy linear\npython scripts\u002Frollout_planner.py --population 1000000 --target-percent 100 --duration-days 30 --strategy log\n```\n\n**Strategies:**\n- `ring`: 1% → 5% → 25% → 50% → 100%, evenly spaced. Default for risky launches.\n- `linear`: constant rate per day. Default for medium-risk.\n- `log`: rapid early, slow tail. Default for low-risk launches with confidence.\n- `cohort`: by named cohort (internal → beta → free → paid → all).\n\nOutputs a markdown table with date, percent, expected user count, abort criteria, and verification step per phase.\n\n### `kill_switch_audit.py`\n\nCross-references code-discovered flags against documentation to verify each has a kill switch path written down.\n\n```bash\npython scripts\u002Fkill_switch_audit.py --repo . --flag-doc docs\u002Ffeature-flags.md\npython scripts\u002Fkill_switch_audit.py --repo . --flag-doc runbooks\u002Fflags.md --format json\n```\n\n**What it checks:**\n1. Every code-discovered flag has an entry in `--flag-doc`\n2. Each entry declares: owner, type, kill-switch trigger, monitoring dashboard\n3. Reports flags missing documentation (FAIL) or missing fields (WARN)\n\nUse as a pre-merge gate before any new flag ships.\n\n## Provider chooser (5 + DIY)\n\n| Provider | Best for | Pricing model | Lock-in risk | OSS option |\n|---|---|---|---|---|\n| **LaunchDarkly** | Enterprise, complex targeting, audit\u002Fcompliance | Per-MAU, expensive | High | No |\n| **GrowthBook** | Mid-market, A\u002FB testing focused, OSS-friendly | Per-MAU + OSS | Low | Yes (self-host) |\n| **Statsig** | Growth\u002Fproduct teams, advanced experimentation | Free tier + per-MAU | Medium | No |\n| **Unleash** | OSS-first, self-hosted, dev-friendly | OSS + Enterprise | Low | Yes |\n| **Flipt** | Lightweight, k8s-native, simple needs | OSS-only | None | Yes |\n| **DIY** | \u003C100 flags, no targeting, full control | None | None | N\u002FA |\n\nDecision rules:\n- \u003C50 flags + no targeting → DIY with config file or env vars\n- Need analytics + experimentation → Statsig or GrowthBook\n- Compliance\u002FSOC2 audit logs required → LaunchDarkly\n- Self-hosting required (data residency \u002F air-gapped) → Unleash or Flipt\n- See `references\u002Fprovider_comparison.md` for detail.\n\n## Workflows\n\n### Workflow 1: Ship a new feature behind a flag\n\n```\n1. Classify: which of the 4 flag types?\n   → Release (most common for engineering work)\n2. Run rollout_planner.py to design the ramp\n3. Add flag entry to docs\u002Ffeature-flags.md BEFORE writing code:\n   - name, owner, type, kill-switch trigger, dashboard URL\n4. Write the code with the flag\n5. Run kill_switch_audit.py — must pass before merge\n6. Deploy at 0%; verify kill switch works\n7. Execute rollout schedule; abort if abort criteria met\n8. At 100% for 7+ days: remove flag, delete dead branch, archive doc entry\n```\n\n### Workflow 2: Quarterly flag cleanup\n\n```\n1. Run flag_debt_scanner.py --repo . --max-age-days 90 > debt.md\n2. For each flagged item:\n   a. Confirm it reached 100% (or was killed)\n   b. Find the issue\u002FPR that introduced it; verify owner agrees to remove\n   c. Delete dead branches; remove flag config\n   d. Run kill_switch_audit.py — should now show one fewer flag\n3. Update CHANGELOG: \"Removed N stale flags\"\n```\n\n### Workflow 3: Choose a provider\n\n```\n1. Estimate flag count (current + 12-month projection)\n2. Required features:\n   - Targeting rules (user, account, geo, %)?\n   - A\u002FB testing + stats?\n   - Audit log \u002F SOC2?\n   - Self-hosting \u002F data residency?\n3. Pricing budget (MAU * cost-per-MAU)\n4. See provider_comparison.md decision tree\n5. Build a 30-day proof-of-concept before signing\n```\n\n### Workflow 4: Design a kill switch\n\n```\n1. Identify the failure modes:\n   - Latency spike (which threshold?)\n   - Error rate spike (which threshold?)\n   - Business metric regression (which threshold?)\n2. Wire each to an abort:\n   - Manual: dashboard link + on-call playbook\n   - Automated: alert threshold flips flag back to 0%\n3. Test the kill switch in staging BEFORE production rollout\n4. Document in flag-doc; pass kill_switch_audit.py\n```\n\n## References\n\n- `references\u002Fflag_taxonomy.md` — 4 types, decision tree, ownership, lifespan\n- `references\u002Fprovider_comparison.md` — LaunchDarkly \u002F GrowthBook \u002F Statsig \u002F Unleash \u002F Flipt \u002F DIY trade-offs\n- `references\u002Frollout_strategies.md` — ring \u002F linear \u002F log \u002F cohort \u002F geo, abort criteria, monitoring\n- `references\u002Fflag_lifecycle.md` — request → design → ship → ramp → cleanup → archive\n\n## Slash command\n\n`\u002Fflag-cleanup` — Run the full cleanup workflow on the current repo: scan for debt, generate a removal plan, audit kill switches.\n\n## Asset templates\n\n- `assets\u002Fflag_request_template.md` — fill-in form for new flag requests (name, owner, type, kill switch, rollout plan)\n\n## Anti-patterns\n\n- **Permanent flag with `if (FLAG_FOO)` 50 places** — should be a Permission flag with a runtime config, not a Release flag\n- **Flag with no owner** — when the original engineer leaves, no one cleans it up\n- **No kill switch documented** — when the feature breaks, no one knows how to disable it\n- **A\u002FB test that ran 6 months** — pick a winner; running indefinitely is debt\n- **Flags as feature toggles for cosmetic changes** — ship via deploy, not flag\n\n## Verifiable success\n\nA team using this skill should achieve:\n- 100% of new flags pass `kill_switch_audit.py` at merge time\n- `flag_debt_scanner.py --max-age-days 90` returns ≤5 stale flags repo-wide\n- Every flag has a documented owner, type, and kill switch\n- Mean time to retire a Release flag: \u003C60 days from 100% rollout\n","# Feature Flags Architect\n\nEnd-to-end discipline for feature flags: classify them, ship them, ramp them, and retire them. Most teams treat flags as throwaway `if`-statements; this skill treats them as a controlled lifecycle with measurable debt.\n\n## When to use\n\n- Adding a new flag and need a rollout plan\n- Auditing a codebase for stale or orphaned flags\n- Choosing a flag provider (LaunchDarkly vs GrowthBook vs Statsig vs Unleash vs Flipt vs build-your-own)\n- Designing a kill-switch path for a risky launch\n- Cleaning up flag debt before a release freeze\n- Reviewing whether a feature should ship behind a flag at all\n\n## Core principle: flags are a lifecycle, not an `if`\n\n```\nrequest → design → ship → ramp → cleanup → archive\n```\n\nFlags that skip cleanup become debt: dead branches, stale defaults, untested code paths, unbounded blast radius. The three scripts in this skill enforce the lifecycle.\n\n## Quick start\n\n```bash\n# 1. Audit the repo for flag debt\npython scripts\u002Fflag_debt_scanner.py --repo . --max-age-days 90\n\n# 2. Plan a progressive rollout for a new flag\npython scripts\u002Frollout_planner.py --population 100000 --target-percent 100 --duration-days 14 --strategy ring\n\n# 3. Verify every flag has a documented kill switch\npython scripts\u002Fkill_switch_audit.py --repo . --flag-doc docs\u002Ffeature-flags.md\n```\n\n## The 4 flag types (taxonomy)\n\nDifferent flag types have different lifespans and ownership. Misclassifying creates debt.\n\n| Type | Purpose | Typical lifespan | Owner | Cleanup trigger |\n|---|---|---|---|---|\n| **Release** | Hide unfinished features in production | days–weeks | Eng | 100% rollout reached |\n| **Experiment** | A\u002FB test variants | weeks | Product\u002FMarketing | Test concluded; winner picked |\n| **Operational** | Circuit breakers, perf toggles, kill switches | months–years | Eng\u002FSRE | Replaced by autoscaling\u002Ffeature retirement |\n| **Permission** | Entitlements per user\u002Faccount\u002Fplan | years (permanent) | Product | Plan\u002Frole removed |\n\nOnly Release and Experiment flags should be on a debt-scanner watchlist. Operational and Permission flags are by design long-lived. See `references\u002Fflag_taxonomy.md` for decision tree.\n\n## The 3 Python tools\n\nAll three are stdlib-only. Run with `--help`.\n\n### `flag_debt_scanner.py`\n\nFinds flags older than `--max-age-days` with low usage, suggesting candidates for cleanup.\n\n```bash\npython scripts\u002Fflag_debt_scanner.py --repo . --max-age-days 90 --format text\npython scripts\u002Fflag_debt_scanner.py --repo . --max-age-days 60 --format json > debt.json\n```\n\n**Detection heuristic:**\n1. Walk `--repo` for code references matching common flag-call patterns:\n   - `flag(\"...\")`, `isFlagEnabled(\"...\")`, `featureFlag(\"...\")`, `getFlag(\"...\")`\n   - `client.variation(\"...\", ...)`, `unleash.isEnabled(\"...\")`, `growthbook.feature(\"...\")`\n2. For each unique flag identifier, find the oldest commit that introduced it (`git log --diff-filter=A -S \u003Cname>`).\n3. Flag as DEBT if introduced > `--max-age-days` ago AND used in ≤`--min-uses` places.\n\nOutputs flag name, age in days, file references, suggested action. JSON mode is CI-friendly.\n\n### `rollout_planner.py`\n\nGenerates a phased rollout schedule from population size, target percent, duration, and strategy.\n\n```bash\npython scripts\u002Frollout_planner.py --population 100000 --target-percent 100 --duration-days 14 --strategy ring\npython scripts\u002Frollout_planner.py --population 50000 --target-percent 25 --duration-days 7 --strategy linear\npython scripts\u002Frollout_planner.py --population 1000000 --target-percent 100 --duration-days 30 --strategy log\n```\n\n**Strategies:**\n- `ring`: 1% → 5% → 25% → 50% → 100%, evenly spaced. Default for risky launches.\n- `linear`: constant rate per day. Default for medium-risk.\n- `log`: rapid early, slow tail. Default for low-risk launches with confidence.\n- `cohort`: by named cohort (internal → beta → free → paid → all).\n\nOutputs a markdown table with date, percent, expected user count, abort criteria, and verification step per phase.\n\n### `kill_switch_audit.py`\n\nCross-references code-discovered flags against documentation to verify each has a kill switch path written down.\n\n```bash\npython scripts\u002Fkill_switch_audit.py --repo . --flag-doc docs\u002Ffeature-flags.md\npython scripts\u002Fkill_switch_audit.py --repo . --flag-doc runbooks\u002Fflags.md --format json\n```\n\n**What it checks:**\n1. Every code-discovered flag has an entry in `--flag-doc`\n2. Each entry declares: owner, type, kill-switch trigger, monitoring dashboard\n3. Reports flags missing documentation (FAIL) or missing fields (WARN)\n\nUse as a pre-merge gate before any new flag ships.\n\n## Provider chooser (5 + DIY)\n\n| Provider | Best for | Pricing model | Lock-in risk | OSS option |\n|---|---|---|---|---|\n| **LaunchDarkly** | Enterprise, complex targeting, audit\u002Fcompliance | Per-MAU, expensive | High | No |\n| **GrowthBook** | Mid-market, A\u002FB testing focused, OSS-friendly | Per-MAU + OSS | Low | Yes (self-host) |\n| **Statsig** | Growth\u002Fproduct teams, advanced experimentation | Free tier + per-MAU | Medium | No |\n| **Unleash** | OSS-first, self-hosted, dev-friendly | OSS + Enterprise | Low | Yes |\n| **Flipt** | Lightweight, k8s-native, simple needs | OSS-only | None | Yes |\n| **DIY** | \u003C100 flags, no targeting, full control | None | None | N\u002FA |\n\nDecision rules:\n- \u003C50 flags + no targeting → DIY with config file or env vars\n- Need analytics + experimentation → Statsig or GrowthBook\n- Compliance\u002FSOC2 audit logs required → LaunchDarkly\n- Self-hosting required (data residency \u002F air-gapped) → Unleash or Flipt\n- See `references\u002Fprovider_comparison.md` for detail.\n\n## Workflows\n\n### Workflow 1: Ship a new feature behind a flag\n\n```\n1. Classify: which of the 4 flag types?\n   → Release (most common for engineering work)\n2. Run rollout_planner.py to design the ramp\n3. Add flag entry to docs\u002Ffeature-flags.md BEFORE writing code:\n   - name, owner, type, kill-switch trigger, dashboard URL\n4. Write the code with the flag\n5. Run kill_switch_audit.py — must pass before merge\n6. Deploy at 0%; verify kill switch works\n7. Execute rollout schedule; abort if abort criteria met\n8. At 100% for 7+ days: remove flag, delete dead branch, archive doc entry\n```\n\n### Workflow 2: Quarterly flag cleanup\n\n```\n1. Run flag_debt_scanner.py --repo . --max-age-days 90 > debt.md\n2. For each flagged item:\n   a. Confirm it reached 100% (or was killed)\n   b. Find the issue\u002FPR that introduced it; verify owner agrees to remove\n   c. Delete dead branches; remove flag config\n   d. Run kill_switch_audit.py — should now show one fewer flag\n3. Update CHANGELOG: \"Removed N stale flags\"\n```\n\n### Workflow 3: Choose a provider\n\n```\n1. Estimate flag count (current + 12-month projection)\n2. Required features:\n   - Targeting rules (user, account, geo, %)?\n   - A\u002FB testing + stats?\n   - Audit log \u002F SOC2?\n   - Self-hosting \u002F data residency?\n3. Pricing budget (MAU * cost-per-MAU)\n4. See provider_comparison.md decision tree\n5. Build a 30-day proof-of-concept before signing\n```\n\n### Workflow 4: Design a kill switch\n\n```\n1. Identify the failure modes:\n   - Latency spike (which threshold?)\n   - Error rate spike (which threshold?)\n   - Business metric regression (which threshold?)\n2. Wire each to an abort:\n   - Manual: dashboard link + on-call playbook\n   - Automated: alert threshold flips flag back to 0%\n3. Test the kill switch in staging BEFORE production rollout\n4. Document in flag-doc; pass kill_switch_audit.py\n```\n\n## References\n\n- `references\u002Fflag_taxonomy.md` — 4 types, decision tree, ownership, lifespan\n- `references\u002Fprovider_comparison.md` — LaunchDarkly \u002F GrowthBook \u002F Statsig \u002F Unleash \u002F Flipt \u002F DIY trade-offs\n- `references\u002Frollout_strategies.md` — ring \u002F linear \u002F log \u002F cohort \u002F geo, abort criteria, monitoring\n- `references\u002Fflag_lifecycle.md` — request → design → ship → ramp → cleanup → archive\n\n## Slash command\n\n`\u002Fflag-cleanup` — Run the full cleanup workflow on the current repo: scan for debt, generate a removal plan, audit kill switches.\n\n## Asset templates\n\n- `assets\u002Fflag_request_template.md` — fill-in form for new flag requests (name, owner, type, kill switch, rollout plan)\n\n## Anti-patterns\n\n- **Permanent flag with `if (FLAG_FOO)` 50 places** — should be a Permission flag with a runtime config, not a Release flag\n- **Flag with no owner** — when the original engineer leaves, no one cleans it up\n- **No kill switch documented** — when the feature breaks, no one knows how to disable it\n- **A\u002FB test that ran 6 months** — pick a winner; running indefinitely is debt\n- **Flags as feature toggles for cosmetic changes** — ship via deploy, not flag\n\n## Verifiable success\n\nA team using this skill should achieve:\n- 100% of new flags pass `kill_switch_audit.py` at merge time\n- `flag_debt_scanner.py --max-age-days 90` returns ≤5 stale flags repo-wide\n- Every flag has a documented owner, type, and kill switch\n- Mean time to retire a Release flag: \u003C60 days from 100% rollout\n",{"name":5,"tags":44,"author":46,"context":47,"license":15,"version":48,"description":7,"compatible_tools":49},[36,35,34,45,33,24,31,30,29,28],"kill-switch","claude-code-skills","fork","2.9.0",[50,51,52,53,54,55],"claude-code","codex-cli","cursor","antigravity","opencode","gemini-cli","main","681496e0662f4c45c4758fae9d4510ae87311bf2","engineering\u002Fskills\u002Ffeature-flags-architect","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills","https:\u002F\u002Fgithub.com\u002Fagency-black","http:\u002F\u002Fwww.dogma.black","Las grandes ideas merecen una ejecución impecable. Construimos plataformas web, aplicaciones y ecosistemas digitales completos. Esta Trinidad es nuestro dogma.","2026-05-29 16:13:55",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add agency-black\u002FSkills --skill feature-flags-architect",{"tool":70,"command":71},"bunx","bunx skills add agency-black\u002FSkills --skill feature-flags-architect",{"tool":73,"command":74},"pnpm","pnpm dlx skills add agency-black\u002FSkills --skill feature-flags-architect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fengineering\u002Fskills\u002Ffeature-flags-architect\u002FSKILL.md",true,[78,84,90,94,98,102,108,112],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"assets\u002Fflag_request_template.md","ASSET","资产文件",1770,"https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fengineering\u002Fskills\u002Ffeature-flags-architect\u002Fassets\u002Fflag_request_template.md",{"path":85,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fflag_lifecycle.md","REFERENCE","参考文档",5869,"https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fengineering\u002Fskills\u002Ffeature-flags-architect\u002Freferences\u002Fflag_lifecycle.md",{"path":91,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fflag_taxonomy.md",4511,"https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fengineering\u002Fskills\u002Ffeature-flags-architect\u002Freferences\u002Fflag_taxonomy.md",{"path":95,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fprovider_comparison.md",5148,"https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fengineering\u002Fskills\u002Ffeature-flags-architect\u002Freferences\u002Fprovider_comparison.md",{"path":99,"resourceType":86,"resourceTypeDesc":87,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Frollout_strategies.md",5024,"https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fengineering\u002Fskills\u002Ffeature-flags-architect\u002Freferences\u002Frollout_strategies.md",{"path":103,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":106,"sourceHtmlUrl":107},"scripts\u002Fflag_debt_scanner.py","SCRIPT","脚本",4827,"https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fengineering\u002Fskills\u002Ffeature-flags-architect\u002Fscripts\u002Fflag_debt_scanner.py",{"path":109,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":110,"sourceHtmlUrl":111},"scripts\u002Fkill_switch_audit.py",5000,"https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fengineering\u002Fskills\u002Ffeature-flags-architect\u002Fscripts\u002Fkill_switch_audit.py",{"path":113,"resourceType":104,"resourceTypeDesc":105,"sizeBytes":114,"sourceHtmlUrl":115},"scripts\u002Frollout_planner.py",4533,"https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fengineering\u002Fskills\u002Ffeature-flags-architect\u002Fscripts\u002Frollout_planner.py",[117,144,173,203,228,252],{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":39},"01M71JZVZ0TVW7Z5DQBRWSBG8A","zarr-python","Chunked N-D arrays for cloud storage (Zarr-Python 3). Compressed arrays, parallel I\u002FO, S3\u002FGCS via fsspec, NumPy\u002FDask\u002FXarray compatible, for large-scale scientific computing pipelines.","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fzarr-python\u002FSKILL.md",[],[124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143],"zarr python","python","zarr","arrays","Cloud Storage","remote","workflows","scientific","read","write","edit","parallel","dask","for","s3fs","use","numpy","s3","scientific computing","scale",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":148,"sourceHtmlUrl":149,"categories":150,"keywords":156,"publishedAt":39},"01M71JYXC5VAEJT8KXN5GRK32S","xvary-stock-research","Thesis-driven equity analysis from public SEC EDGAR and market data; \u002Fanalyze, \u002Fscore, \u002Fcompare workflows with bundled Python tools (Claude Code, Cursor, Codex).","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fxvary-stock-research\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fxvary-stock-research\u002FSKILL.md",[151],{"categoryNo":152,"categoryName":153,"taxonomyType":154,"taxonomyTypeDesc":155},"01JBSEEDCAT000000000000021","资料检索与研究","SCENARIO","使用场景",[157,158,159,160,161,162,163,125,164,130,165,38,166,167,168,169,170,171,52,172],"xvary","stock","research","xvary stock research","sec edgar","community","equity","thesis","analysis","Market","compare","market data","analyze","with","codex","2026",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":177,"licenseFileUrl":178,"sourceHtmlUrl":179,"categories":180,"keywords":187,"publishedAt":39},"01M71JVSDPDQ5040YBN6J1ASKY","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fwebapp-testing\u002FSKILL.md",[181,184],{"categoryNo":182,"categoryName":183,"taxonomyType":154,"taxonomyTypeDesc":155},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":185,"categoryName":186,"taxonomyType":154,"taxonomyTypeDesc":155},"01JBSEEDCAT000000000000009","前端开发",[188,189,190,137,191,192,193,194,195,196,197,170,198,199,200,201,202],"webapp","testing","webapp testing","applications","local","frontend","debugging","toolkit","logs","browser","playwright","web","behavior","ui","screenshots",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":177,"licenseFileUrl":207,"sourceHtmlUrl":208,"categories":209,"keywords":211,"publishedAt":39},"01M71JV64CW7R6FYYK9JWWGW0X","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fweb-artifacts-builder\u002FSKILL.md",[210],{"categoryNo":185,"categoryName":186,"taxonomyType":154,"taxonomyTypeDesc":155},[212,213,214,199,215,216,217,137,218,219,193,220,139,221,222,223,224,225,226,227],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","file","components","react","multi","state","routing","state management",{"skillNo":229,"name":230,"nameZh":6,"description":231,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":232,"categories":233,"keywords":235,"publishedAt":39},"01M71JS4X2FRY41DE84DEP06MN","vercel-react-view-transitions","Guide for implementing smooth, native-feeling animations using React's View Transition API (`\u003CViewTransition>` component, `addTransitionType`, and CSS view transition pseudo-elements). Use this skill whenever the user wants to add page transitions, animate route changes, create shared element animations, animate enter\u002Fexit of components, animate list reorder, implement directional (forward\u002Fback) navigation animations, or integrate view transitions in Next.js. Also use when the user mentions view transitions, `startViewTransition`, `ViewTransition`, transition types, or asks about animating between UI states in React without third-party animation libraries.","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fvercel-react-view-transitions\u002FSKILL.md",[234],{"categoryNo":185,"categoryName":186,"taxonomyType":154,"taxonomyTypeDesc":155},[223,236,237,238,239,240,241,242,243,217,244,245,246,247,25,222,248,249,250,251],"vercel react view transitions","view","react view transitions","vercel","transitions","shared","back","Animation","types","states","element","implementing","api","route","create","libraries",{"skillNo":253,"name":254,"nameZh":6,"description":255,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":256,"categories":257,"keywords":259,"publishedAt":39},"01M71JS1WZ1J4F9YVC2203JBJW","vercel-react-native-skills","React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.","https:\u002F\u002Fgithub.com\u002Fagency-black\u002FSkills\u002Fblob\u002Fmain\u002Fvercel-react-native-skills\u002FSKILL.md",[258],{"categoryNo":185,"categoryName":186,"taxonomyType":154,"taxonomyTypeDesc":155},[239,260,223,261,262,263,264,265,266,137,267,247,268,139,269,270,25,271,272,222],"vercel react native skills","react native","native","react native skills","modules","platform","animations","performance","triggers","react native components","apps","best practices","tasks"]