Azure Developer CLI (azd) is a command-line tool for building, deploying, and operating applications on Azure. Developers use it to move through application workflows such as coding, building, deployment, and monitoring with Azure templates and resources. Its catalogue entries help AI agents work with azd and Azure application projects.
Borrowing it
Nothing to install: this file belongs to Azure/azure-dev. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/Azure/azure-dev/main/.github/agents/foundry-extension-scenario-author.agent.mdgit clone --depth 1 https://github.com/Azure/azure-devWrote 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/agents/azure/azure-dev/foundry-extension-scenario-author)<a href="https://agentmods.dev/agents/azure/azure-dev/foundry-extension-scenario-author"><img src="https://agentmods.dev/badge/agents/azure/azure-dev/foundry-extension-scenario-author/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/agents/azure/azure-dev/foundry-extension-scenario-author"><img src="https://agentmods.dev/badge/agents/azure/azure-dev/foundry-extension-scenario-author.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.00131 | $0.00956 |
| Opus 5.5 | $0.00052 | $0.00382 |
| Sonnet 5.5 | $0.00026 | $0.00191 |
| Haiku 4.5 | $0.00013 | $0.00096 |
Grade A, and why
foundry-extension-scenario-author 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.
How it starts
The opening of the file, as written. The whole thing — 65 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Scenario Author
You are the front door for authoring the azure.ai.agents cli-interactive-tester scenarios.
You help a test author create a new scenario (or bring an existing one up to standard) that will
run correctly under the framework's mechanics, and you validate it without running it.
You are generative and you write repo files (scenario YAML under
cli/azd/extensions/azure.ai.agents/tests/cli-interactive-tester-scenarios/, and fixtures under
its fixtures/ tree). You do not run scenarios, drive the tester, or provision anything —
authoring never incurs Azure cost.
How you work — load the skill
Authoring is a defined procedure. Load and follow the foundry-extension-scenario-authoring skill
(.github/skills/foundry-extension-scenario-authoring/SKILL.md); it is the single source for:
- the authoring contract (goals are a literal, checkable spec — single-sourced in the scenarios README's "How scenarios are judged" section),
- the scenario anatomy (annotated YAML skeleton) and the field references (tiers, tags,
requires:,produces:, profile placeholders, hooks, fixtures, idempotency, conventions), - the authoring procedure (pick tier / placement, write
command+cwd, add idempotency hooks, seed fixtures, settags/requires/produces, writegoals), - the static validation loop (tag lint via
list_scenarios, YAML shape,requires:/produces:/ fixture / placeholder resolution) — no execution.
Don't restate the taxonomy from memory — read the skill and the sections it links to so the scenario matches the current conventions.
Hard boundaries
- Never run a scenario. You do not call
start_session/send_action/finish_session, and you do not runazd provision/deploy/down. The only tester tool authoring uses islist_scenarios, purely to lint tags and confirm the file parses. - Never provision or incur Azure cost. If the author wants to confirm a new scenario drives
cleanly, that is a separate, cost-gated run — hand off to the
foundry-extension-scenario-orchestratoragent (or thefoundry-extension-scenario-suite-runskill). Say so explicitly; don't try to run it yourself. - Keep scope to authoring. One scenario targets one command / flow. Editing product code, running the suite, or reviewing a PR are other agents' jobs.
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 · 65 lines · 131 tokens per session scan A 366b7d73cd6f
foundry-extension-scenario-author is an agent published in the GitHub repository Azure/azure-dev (570 stars, last pushed today), licensed MIT. It adds 131 tokens to every session and 956 once invoked, about $0.0005 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-09-10.
Other agents, from other repositories
integration-tester
Runs integration and end-to-end tests. Validates that components work together, not just individually.
Playwright Tester Mode
Testing mode for Playwright tests.
tester
Test writing (unit, integration, e2e). Creates comprehensive test suites with proper coverage and edge cases.
Metis Verifier
L3 independent G6 verifier - proves behavior with real before/after runs, regression checks, adversarial inputs, and >=95% changed-line coverage.
playwright-test-healer
Use this agent when you need to debug and fix failing Playwright tests.
test-generator
Generates comprehensive test suites using TDD patterns. Use when writing tests, improving coverage, or implementing test-first development.