Data Formulator is an interactive workspace where AI agents connect to data sources, answer questions, and create visualizations. It is used to explore and analyze data while branching into related questions without losing the context of each investigative path.
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.
git clone --depth 1 https://github.com/microsoft/data-formulatorWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/microsoft/data-formulator/test-driven-workflow)<a href="https://agentmods.dev/rules/microsoft/data-formulator/test-driven-workflow"><img src="https://agentmods.dev/badge/rules/microsoft/data-formulator/test-driven-workflow/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/rules/microsoft/data-formulator/test-driven-workflow"><img src="https://agentmods.dev/badge/rules/microsoft/data-formulator/test-driven-workflow.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00496 | $0.00496 |
| Opus 5.5 | $0.00198 | $0.00198 |
| Sonnet 5.5 | $0.00099 | $0.00099 |
| Haiku 4.5 | $0.00050 | $0.00050 |
Grade A, and why
test-driven-workflow 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 1mo ago.
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
Test-Driven Workflow
1. 测试优先：新功能 / Bug 修复必须有测试
开发新功能或修复 Bug 时，必须同步编写测试，不能只提交业务代码：
- 新功能 → 先写测试（或至少同步写），描述期望行为，再实现代码使测试通过
- Bug 修复 → 先写复现测试，确认测试失败，再修复代码使测试通过
- 重构 → 确保重构前已有测试覆盖，重构后测试仍然全部通过
完成实现后，主动运行相关测试验证：
- 后端：
python -m pytest tests/backend/ -q - 前端：
yarn test
2. 测试保护：不要轻易修改测试代码
测试失败时，禁止直接修改测试代码来让测试通过。必须执行以下流程：
- 复现并定位：运行失败的测试，确认失败现象
- 诊断分类：
- A：测试本身有问题（断言错误、setup 不正确）
- B：业务实现有 Bug
- C：需求/规格变更导致测试过时
- 给出方案：至少提供两个可选方案（改测试 / 改实现 / 补规格），说明各自影响和风险
- 等待确认：由用户决定采用哪个方案，再执行修改
绝对禁止：
- 测试一红就直接改测试代码
- 删除或跳过（
@pytest.mark.skip）失败的测试来"解决"问题 - 修改测试的断言值来匹配错误的实现
3. 精准修改：不动无关测试
与 Karpathy 编码准则的"精准修改"一致：
- 不"顺手改进"与当前任务无关的测试代码
- 不重构正在通过的测试
- 不改变已有测试的断言逻辑，除非被明确要求
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.
- 1mo ago First seen · 45 lines · 496 tokens per session scan A 2029dda8d557
test-driven-workflow is a cursor rule published in the GitHub repository microsoft/data-formulator (17,610 stars, last pushed today), licensed MIT. It adds 496 tokens to every session, about $0.0020 per session on Opus 5.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-30.
Other cursor rules, from other repositories
mcpnuke-tests
Test conventions for mcpnuke — enforces TDD workflow.
debug-issue
When the user reports a bug, an error, or unexpected behavior. Enforces four structured phases — reproduction, failing test, root cause isolation, fix and verify — to stop guess-and-check loops.
common-testing
Testing requirements: 80% coverage, TDD workflow.
testing_rules
A testing guide covering TDD, where tests are written before code, and BDD, where expected behavior is described in Given-When-Then form.
tdd
Test-driven development — red-green-refactor cycle.
testing-standards
testing guidelines and expectations.