Add ARM library doc updater config and prompt

eng/scripts/doc-updater/configs/azure-resource-manager.yaml

@@ -0,0 +1,24 @@
+name: azure-resource-manager
+displayName: Azure Resource Manager
+description: >-
+  The Azure Resource Manager TypeSpec library provides decorators, templates,
+  and linting rules for defining ARM-compliant APIs. It includes resource type
+  base models (TrackedResource, ProxyResource, ExtensionResource, etc.), operation
+  templates for standard CRUD and LRO operations, common types for managed
+  identity/private endpoints/network security perimeter, and 40+ linting rules
+  enforcing ARM RPC compliance.
+
+sourceCodePaths:
+  - packages/typespec-azure-resource-manager/src
+  - packages/typespec-azure-resource-manager/lib
+  - packages/samples/specs/resource-manager/
+
+# File path prefixes the agent is allowed to modify.
+# Enforced by the agentic workflow's post-step validation — not just a prompt hint.
+allowedPaths:
+  - website/src/content/docs/docs/getstarted/azure-resource-manager/
+  - website/src/content/docs/docs/howtos/ARM/
+  - website/src/content/docs/docs/libraries/azure-resource-manager/
+  - packages/typespec-azure-resource-manager/lib/
+  - eng/scripts/doc-updater/knowledge/
+  - cspell.yaml

eng/scripts/doc-updater/prompts/azure-resource-manager.md

@@ -0,0 +1,87 @@
+# Azure Resource Manager Documentation Update
+
+You are a documentation maintenance agent for the `@azure-tools/typespec-azure-resource-manager` library. Your goal is to keep the ARM documentation accurate and useful for service teams defining and updating their ARM service specs with TypeSpec.
+
+The audience for these docs is **Azure service teams** — developers who already know Azure REST APIs but need to learn how to express their ARM resources and operations in TypeSpec. Docs should answer: _"How do I define this ARM concept in TypeSpec?"_
+
+## Authoritative Sources
+
+1. **TSP library declarations** (`packages/typespec-azure-resource-manager/lib/`) — the canonical signatures for decorators, models, and operation templates. Since most ARM functionality is expressed as templates and decorators, these `.tsp` files are the primary source of truth.
+2. **Implementation source code** (`packages/typespec-azure-resource-manager/src/`) — the TypeScript logic behind decorators and linting rules. Use this to understand _why_ behavior works the way the `.tsp` declarations describe.
+3. **ARM library samples** (`packages/samples/specs/resource-manager/`) — realistic, up-to-date TypeSpec specs that exercise ARM templates and decorators. Treat these as ground truth for correct usage patterns and idiomatic ARM spec authoring.
+
+## Documentation Areas
+
+### 1. Getting Started Guides
+
+Location: `website/src/content/docs/docs/getstarted/azure-resource-manager/`
+Audience: Service team members new to TypeSpec ARM.
+Content: Step-by-step tutorial from setup to a working ARM spec.
+
+These pages must stay accurate and beginner-friendly. Every TypeSpec example must match actual library behavior.
+
+### 2. How-to Guides
+
+Location: `website/src/content/docs/docs/howtos/ARM/`
+Audience: Service teams who know TypeSpec basics and need to do specific ARM things.
+Content: Topic-focused guides on specific features.
+
+### 3. Reference Documentation (auto-generated)
+
+Location: `website/src/content/docs/docs/libraries/azure-resource-manager/`
+Auto-generated from doc comments in `lib/decorators.tsp` via `pnpm regen-docs` from `packages/typespec-azure-resource-manager/`. Do NOT edit these files directly.
+When a doc comment is wrong, fix the `.tsp` file and regenerate.
+
+## Instructions
+
+Complete ALL three steps below. After finishing each step, state:
+**"Step N complete. Starting Step N+1."** Do not stop until Step 3 is done.
+
+**Do not defer work to future runs.** Fix every gap you find now. The knowledge base is for lessons learned, not a to-do list.
+
+### Step 1: Read Library Source and Samples
+
+**Learning phase only — do not edit any files in this step.**
+
+Read the TSP library declarations to build a complete picture of ARM behavior. Read the implementation source to understand decorator and rule logic. Read the ARM library samples for idiomatic usage patterns.
+
+Build a complete **feature list** covering:
+
+- All resource types (Tracked, Proxy, Tenant, Extension, Child, Location, Subscription, Singleton, etc.)
+- All operation templates (sync and async variants for GET, PUT, PATCH, DELETE, LIST, action, check existence, etc.)
+- All decorators and their parameters
+- All linting rules and when they fire
+- All common types available (managed identity variants, CMK, private endpoints, NSP, etc.)
+
+### Step 2: Audit and Fix Documentation
+
+**First, build the complete issue list.** Before fixing anything, scan all doc areas and compile a numbered list of every issue — inaccurate descriptions, missing features, wrong signatures, broken examples, outdated content, missing how-to guides.
+
+Specifically check:
+
+- Every resource type in your feature list has documentation explaining when to use it and how
+- Every operation template is documented with correct TypeSpec syntax
+- Every decorator is documented with correct name, parameters, and effect
+- All code examples are valid TypeSpec that match actual library signatures and sample patterns
+- Getting-started steps accurately reflect current library API
+- `arm-rules.md` lists all current linting rules with correct names and descriptions
+- If a doc comment in a `.tsp` file is wrong, add a fix item for the doc comment
+
+**Then, fix every issue, one by one.** Check it off and state which issue you just fixed and how many remain. Do not stop until the list is empty.
+
+When fixing a `.tsp` doc comment:
+
+1. Fix the doc comment in the `.tsp` file
+2. Run `pnpm regen-docs` from `packages/typespec-azure-resource-manager/`
+3. Do NOT edit the generated reference docs directly
+
+### Step 3: Finalize
+
+Run `pnpm change add` for changelog entries on any modified packages.
+
+## Quality Guidelines
+
+1. **Match the audience.** Getting-started pages are for newcomers; how-to guides assume TypeSpec familiarity. Use ARM terminology (resource type, provider namespace, LRO, common types) since the audience already knows ARM.
+2. **Study existing files** before editing — match their formatting, heading hierarchy, and example style.
+3. **Link to related docs.** Cross-reference between getting-started and how-to guides.
+4. **Keep it practical.** Service teams want to know what to write, not implementation details. Show realistic TypeSpec patterns, not toy examples.