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/skills/foundry-extension-scenario-authoring/SKILL.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/skills/azure/azure-dev/foundry-extension-scenario-authoring)<a href="https://agentmods.dev/skills/azure/azure-dev/foundry-extension-scenario-authoring"><img src="https://agentmods.dev/badge/skills/azure/azure-dev/foundry-extension-scenario-authoring/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/skills/azure/azure-dev/foundry-extension-scenario-authoring"><img src="https://agentmods.dev/badge/skills/azure/azure-dev/foundry-extension-scenario-authoring.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.00225 | $0.04195 |
| Opus 5.5 | $0.00090 | $0.01678 |
| Sonnet 5.5 | $0.00045 | $0.00839 |
| Haiku 4.5 | $0.00022 | $0.00419 |
Grade C, and why
foundry-extension-scenario-authoring scanned grade C with 1 finding 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 28d 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
- run: "rm -rf {cwd-or-path}" How it starts
The opening of the file, as written. The whole thing — 244 lines — stays where its author put it; the contents beside it link to each section on GitHub.
foundry-extension-scenario-authoring
Authors and validates goal-based scenarios for the azure.ai.agents
cli-interactive-tester suite under
cli/azd/extensions/azure.ai.agents/tests/cli-interactive-tester-scenarios/. This skill
writes and lints scenarios; it never runs them (running is foundry-extension-scenario-suite-run /
foundry-extension-scenario-pr-regression, driven by the foundry-extension-scenario-worker agent, and incurs Azure cost for
Tier 1b / Tier 2).
Tools invoked: the cli-interactive-tester MCP list_scenarios tool (for tag/lint validation
only — never start_session, which would incur Azure cost), read/edit of scenario YAML files,
and ask_user.
The authoring contract (read this first)
A scenario's goals: are its contract: a run PASSES only when the product's real behavior
matches what the goals literally describe. So the whole point of authoring is to write goals
that are a verifiable spec of correct behavior — not a loose description the driver has to
interpret charitably. The judging rules are single-sourced in the scenarios README:
How scenarios are judged (authoring contract).
The consequences for how you write goals:
- Write goals as literal, checkable assertions. "Confirm the process exits cleanly and prints a version string" is checkable; "make sure version works" is not. A driver will FAIL a scenario whose goals aren't met — it will not rationalize a near-miss into a pass.
- Never encode a workaround in a goal. If a goal names a flag/command that doesn't exist or expects output that never appears, the scenario FAILS by design. Keep goals current with the product; don't paper over a bug in the goal text.
- Key interactive pickers off stable text labels, not positions. The driver prefers
choice_textoverchoice_index, so phrase picker goals around the label (e.g. select "Use the code in the current directory") — indices shift between releases. - Enumerate expected product prompts. Goals define every product prompt allowed during the scenario. Name each prompt with stable user-visible text and state the response. Use "if asked" only for a genuinely optional prompt. Never write "follow the prompts" or another catch-all; an unlisted product prompt must fail the scenario.
- Give every executed invoke explicit input. Write the literal command with a quoted
positional message. Use
--input-fileonly when file input is what the scenario tests, and define the file contents first. Never leave command construction to the worker with wording such as "run invoke and send a simple message"; bare invoke does not prompt for a message. - Guard pre-filled prompts. When a prompt comes pre-populated (e.g. the agent name), the
goal must tell the driver to clear the field first before typing, or the typed value
appends to the default. See the RESOURCE NAMING / AGENT NAME goals in
tier1/1.04-init-from-code.yamlfor the canonical phrasing. - Gate cost explicitly. Any goal that reaches
azd provision/ real resource creation belongs in Tier 1b or Tier 2 and must be tagged and tiered accordingly (see below).
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.
- 28d ago Changed · +6 lines 1c51ae845e6c
- 1mo ago Changed · +1 lines · -78 tokens per session 286bf4808504
- 1mo ago First seen · 237 lines · 303 tokens per session scan C ae96bb114d5b
foundry-extension-scenario-authoring is a skill published in the GitHub repository Azure/azure-dev (570 stars, last pushed today), licensed MIT. It adds 225 tokens to every session and 4,195 once invoked, about $0.0009 per session on Opus 5.5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-10.
Other skills, from other repositories
azure-microsoft-playwright-testing-ts
Run Playwright tests at scale using Azure Playwright Workspaces (formerly Microsoft Playwright Testing). Use when scaling browser tests across cloud-hosted browsers, integrating with CI/CD pipelines, or publishing test results to the Azure portal.
agent-browser
Use the host-side agent-browser CLI for local browser smoke tests, screenshots, snapshots, and simple UI validation against forwarded localhost URLs.
browser-qa
Testing web apps through a real browser: reconnaissance before acting, selector discovery, state capture, console errors and screenshot evidence. Use on a web surface end to end, or to reproduce a front-end bug.
hatch3r-browser-verify
Opt-in browser verification skill — spec-run-first Playwright verification (assertions execute in the runner, agent reads only failures), axe-core a11y audits, toHaveScreenshot() regression diffs, E2E test scaffolds, and snapshot-mode exploratory driving. Default ON for UI-affecting agent invocations; disable globally…
hatch3r-qa-path
Produces a human-run manual QA test path from a PR, branch diff, or uncommitted working tree — a risk-ordered table of steps, expected results, and automated-coverage references plus a shippability sign-off. Rows are auto-proven via delegated verification sub-agents before emission, so the human walks only what…
hatch3r-a11y-audit
Runs a WCAG AA accessibility audit with findings and fixes across 7 scan categories (keyboard, contrast, ARIA, reduced motion, screen reader, high contrast, automated axe). Use when auditing and remediating accessibility.