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.
npx agentmods add rules/launchdarkly-labs/cursor-rules/implementing-launchdarklygit clone --depth 1 https://github.com/launchdarkly-labs/cursor-rulesWhat 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.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.00446 |
| Opus 5 | $0.00000 | $0.00223 |
| Sonnet 5 | $0.00000 | $0.00089 |
| Haiku 4.5 | $0.00000 | $0.00045 |
Grade A, and why
implementing-launchdarkly 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 yesterday.
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.
What it actually says
implementing-launchdarkly.mdc:
Rule 1: Use LaunchDarkly SDK Wrappers and Utility Functions
- All applications must use shared SDK utility libraries or wrappers to standardize implementation.
Wrappers must expose:
-
getLDConfig() – returns a pre-configured LDConfig object with environment-specific defaults
-
getSDKKey() – securely retrieves the SDK key for the environment
-
initializeLaunchDarkly() – performs singleton-safe client initialization with timeout handling
-
Wrappers must not fully abstract the core SDK. They should return SDK-native objects to allow flexibility and upgrades.
Rule 2: LaunchDarkly Configuration Must Be Environment-Aware
- SDK configuration wrappers must integrate with existing environment-specific configuration management systems (e.g., environment variables, secrets managers).
If a proxy is required:
-
A shared function like defaultLaunchDarklyHTTPConfiguration() must parse and apply proxy settings from environment variables (e.g., http_proxy).
-
Configuration wrappers must allow consumers to override defaults without modifying shared code.
Rule 3: LaunchDarkly Client Singleton Initialization Pattern
- SDK must be initialized once, at application startup, using a singleton-safe pattern.
Initialization must include:
-
A timeout (recommended: 1–5 seconds)
-
Metrics collection for latency/error tracking
-
Graceful fallback to default values if initialization fails
-
Example: use Promise.race() or equivalent to cap startup latency in async environments.
Rule 4: LaunchDarkly Client Clean Shutdown Required
-
All applications must flush and close the SDK on shutdown.
-
Use shared setCleanupHandlers() utilities that hook into process signals (SIGINT, SIGTERM, etc.).
Rule 5: LaunchDarkly Optional Enhancements
Implement optional helpers for:
-
Bootstrapping flag values at startup
-
Subscribing to flag changes
-
Exporting metrics for initialization and flag evaluations
Rule 6: LaunchDarkly SDK Config Must Be Lightweight and Reproducible
- Config utilities must be easy to consume and adapt across environments and teams.
The default configuration must support:
-
Proxy settings
-
Logging
-
Event buffer tuning
-
Relay proxy or daemon mode
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.
- yesterday First seen · 80 lines · 0 tokens per session scan A 90997f8c795c
implementing-launchdarkly is a cursor rule published in the GitHub repository launchdarkly-labs/cursor-rules (2 stars, last pushed 5mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 446 tokens. 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-31.
Other cursor rules, from other repositories
code-optimization
Guidelines for optimizing duplicate and poorly structured code.
new_features
Guidelines for integrating new features into the Task Master CLI.
utilities
// ✅ DO: Create focused, reusable utilities /.
dev_workflow
Guide for using Taskmaster to manage task-driven development workflows.
mcp
Guidelines for implementing and interacting with the Task Master MCP Server.
commands
Guidelines for implementing CLI commands using Commander.js.