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/using-flagsgit 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.00006 | $0.00334 |
| Opus 5 | $0.00003 | $0.00167 |
| Sonnet 5 | $0.00001 | $0.00067 |
| Haiku 4.5 | $0.00001 | $0.00033 |
Grade A, and why
using-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 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
Rule 1: LaunchDarkly Evaluation Must Be Centralized
- All variation and variationDetail calls must go through a shared evaluation function.
This wrapper must:
-
Use the singleton instance
-
Support mock/local overrides for development/testing
-
Enable optional instrumentation (e.g., metrics, logging)
-
Evaluation must occur as close as possible to where the flag value is used to support accurate flag status tracking.
Rule 2: LaunchDarkly Context Object Standards
-
Applications must document how context objects are constructed, including attribute sources.
-
Context objects:
-
Must have high cardinality (e.g., user ID, session ID)
-
Must not contain or be derived from PII (e.g., don’t hash emails)
-
Shared utilities should exist for creating context objects from application-specific data (e.g., createLDContextFor(userObject)).
Rule 3: LaunchDarkly Context Custom Attributes
-
Must include attributes that support release strategies:
-
Build version or commit SHA
-
Session ID or device ID
-
Developer identifier or PR ID in ephemeral environments
Client-side SDKs must:
-
Avoid frequent identify() or re-initialization calls
-
Use state transitions (e.g., anonymous → authenticated) to manage identity
-
Cache timestamps may be included
Rule 4: LaunchDarkly Flag Evaluation Predictable Fallback Behavior
-
Applications must handle fallback values deterministically.
-
Avoid using allFlags() in production due to inconsistent behavior across SDKs.
-
Fallbacks should always be passed to variation()/variationDetail() and tested in implementation.
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 · 56 lines · 6 tokens per session scan A 5d738ee2b22e
using-flags is a cursor rule published in the GitHub repository launchdarkly-labs/cursor-rules (2 stars, last pushed 5mo ago), licensed MIT. It adds 6 tokens to every session and 334 once invoked, about $0.0000 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-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.