[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HKYQ3F8ERRG4RPB2QWD2T":3,"skill-same:01M71HKYQ3F8ERRG4RPB2QWD2T":73},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":57,"updatedAt":58,"install":59,"resources":72},"01M71HKYQ3F8ERRG4RPB2QWD2T","update-schema-docs",null,"Detect schema.py changes and update front-matter-spec.md, architecture.md, and the public docs site (docs\u002Findex.md, docs\u002Fgetting-started.md) with examples and documentation. Use when schema.py has been modified as part of a feature to ensure documentation stays synchronized with the schema source of truth. Automatically generates usage examples, updates field descriptions, flags architecture changes that need manual review, and flags docs-site landing\u002Fonboarding copy that should mention new user-facing capabilities. Trigger on schema changes during feature development, or when asked to 'update docs for schema changes', 'sync schema documentation', 'add examples for new config fields', or 'update the docs site for this feature'.","Azure\u002Fazure-functions-agents-runtime","Azure","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6844498?v=4","01M6BT15ZBDTV4D9RM7HCC4D8A","Microsoft Azure","01M71HKP14C8K8JTRH03DHX821",13,"MIT","https:\u002F\u002Fgithub.com\u002FAzure\u002Fazure-functions-agents-runtime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fupdate-schema-docs\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"schema","update schema docs","docs","update","usage","as","add","source","flags","sync","config","documentation","review","capabilities","architecture","new user","updates","when","new","update docs","2026-11-10 10:12:30",false,"---\nname: update-schema-docs\ndescription: \"Detect schema.py changes and update front-matter-spec.md, architecture.md, and the public docs site (docs\u002Findex.md, docs\u002Fgetting-started.md) with examples and documentation. Use when schema.py has been modified as part of a feature to ensure documentation stays synchronized with the schema source of truth. Automatically generates usage examples, updates field descriptions, flags architecture changes that need manual review, and flags docs-site landing\u002Fonboarding copy that should mention new user-facing capabilities. Trigger on schema changes during feature development, or when asked to 'update docs for schema changes', 'sync schema documentation', 'add examples for new config fields', or 'update the docs site for this feature'.\"\n---\n\n# update-schema-docs — Schema-driven documentation synchronization\n\nThis skill ensures `docs\u002Ffront-matter-spec.md`, `docs\u002Farchitecture.md`, and the\npublic docs site's landing\u002Fonboarding pages (`docs\u002Findex.md`,\n`docs\u002Fgetting-started.md`) stay synchronized when\n`src\u002Fazure_functions_agents\u002Fconfig\u002Fschema.py` changes.\n`docs\u002Ffront-matter-reference.md` is already auto-generated (via\n`eng\u002Fscripts\u002Fgenerate_config_reference.py`), but spec, architecture, and\ndocs-site pages require intelligent example generation and contextual updates.\n\n## When to use\n\nUse this skill during **Phase 5 (Docs)** of the medium+ feature pipeline when:\n- `schema.py` has been modified (new fields, models, or validation logic)\n- New public configuration surface was added\n- After implementing config-related features\n- When asked to synchronize documentation with schema changes\n\n## What this skill does\n\n1. **Detect changes:** Compare current `schema.py` against the last commit or\n   baseline to identify added\u002Fmodified fields and models.\n2. **Update front-matter-spec.md:**\n   - Add usage examples for new fields\n   - Update existing examples if field semantics changed\n   - Add validation examples for new constraints\n   - Ensure Examples section coverage matches the reference\n3. **Review architecture.md:**\n   - Flag if new models suggest pipeline stage changes\n   - Check if module map needs updates\n   - Verify configuration precedence rules still hold\n4. **Sync the docs site landing pages:**\n   - If the change introduces a new **user-facing capability** (new trigger\n     type, new frontmatter field a typical user would reach for, new model\n     provider), check whether `docs\u002Findex.md`'s feature bullet list or\n     `docs\u002Fgetting-started.md`'s walkthrough should mention it\n   - Skip this step for internal-only or low-level schema changes (e.g.\n     tightened validation, refactors) that don't change what a new user sees\n5. **Generate PR checklist:** List all doc changes made + items needing human review\n\n## Prerequisites\n\n- `schema.py` changes committed or staged\n- Understanding of what the schema change enables (from the FRD)\n- `eng\u002Fscripts\u002Fgenerate_config_reference.py` already run (reference up to date)\n\n## Workflow\n\n### Step 1: Analyze schema changes\n\n1. Read the current `src\u002Fazure_functions_agents\u002Fconfig\u002Fschema.py`\n2. Identify what changed:\n   - New models (e.g., new trigger types, new capabilities)\n   - New fields on existing models (e.g., GlobalConfig, AgentSpec)\n   - Changed field types or validators\n   - New Pydantic constraints or defaults\n\n3. Categorize changes by impact:\n   - **Agent frontmatter surface:** affects `AgentSpec` → needs examples in spec\n   - **Global config surface:** affects `GlobalConfig` → needs global examples\n   - **Trigger surface:** affects trigger models → needs trigger examples\n   - **Structural:** new pipeline stage or module → needs architecture review\n\n### Step 2: Update front-matter-spec.md\n\nFor each new or changed field:\n\n1. **Locate the relevant section:**\n   - Agent fields → `### Agent Front Matter` examples\n   - Global fields → `### Global Configuration` examples\n   - Trigger fields → `### Triggers` or `### Advanced Examples`\n\n2. **Generate usage examples:**\n   - Start from the field's type, description, and default in schema.py\n   - Create realistic YAML examples showing:\n     - Basic usage (most common case)\n     - Edge cases (if validation is complex)\n     - Integration with related fields\n   - Follow existing example style (concise, commented, realistic values)\n\n3. **Add validation examples if needed:**\n   - If the field has custom validators (e.g., CRON expressions, URL patterns)\n   - Show valid and invalid examples with explanations\n\n4. **Cross-reference to the reference:**\n   - Link to `front-matter-reference.md#\u003Csection>` for full API details\n   - Ensure the spec focuses on *how to use*, reference on *what exists*\n\n### Step 3: Review architecture.md\n\n1. **Check if module map needs updates:**\n   - New models in `schema.py` may indicate new modules in `config\u002F`, `discovery\u002F`, etc.\n   - Verify the module map in §3 reflects reality\n   - If discovery logic changed, update the discovery stage description\n\n2. **Check if pipeline stages changed:**\n   - New configuration may affect discover → translate → register → execute flow\n   - Document new capabilities or constraints in the relevant stage\n\n3. **Check configuration precedence:**\n   - If new global\u002Fagent\u002Fenv interactions exist, update §4 precedence rules\n   - Ensure the precedence diagram (if present) is still accurate\n\n### Step 4: Sync docs-site landing pages\n\n1. **Decide if this change is docs-site-worthy:**\n   - New trigger type, new top-level frontmatter field, new model provider,\n     or any change that adds a bullet-worthy capability → yes\n   - Internal refactors, stricter validation, or field renames with no new\n     capability → no, skip\n\n2. **Update `docs\u002Findex.md`** (if worthy):\n   - Add a concise bullet to the feature list matching the existing bullet\n     style (bold lead-in, em dash, one sentence)\n\n3. **Update `docs\u002Fgetting-started.md`** (if worthy and walkthrough-relevant):\n   - Only touch the quickstart steps if the new capability changes the\n     minimal path to a working agent (e.g. a new required config file, a new\n     provider env var). Don't pad the walkthrough with optional features.\n\n4. **Cross-check `README.md`:** the docs site and README duplicate the same\n   feature bullet list — if you update one, flag (or update) the other so\n   they don't drift.\n\n### Step 5: Generate PR checklist\n\nCreate a checklist of:\n- [ ] front-matter-reference.md updated (auto-generated via script)\n- [ ] front-matter-spec.md examples added for: `\u003Clist new fields>`\n- [ ] architecture.md module map verified\n- [ ] docs\u002Findex.md and docs\u002Fgetting-started.md checked (updated \u002F not applicable)\n- [ ] Human review needed for: `\u003Clist architectural concerns>`\n- [ ] Validation examples added for: `\u003Clist complex validators>`\n\n## Example: Adding a new agent field\n\n**Scenario:** `AgentSpec` gained a new field `retry_policy: RetryPolicyConfig | None = None`\n\n**Actions:**\n\n1. **Analyze:** New optional field on `AgentSpec`, type is a nested model\n2. **Update front-matter-spec.md:**\n   ```yaml\n   ---\n   name: Resilient Agent\n   description: Agent with automatic retry logic\n   retry_policy:\n     max_attempts: 3\n     backoff_multiplier: 2\n     initial_delay_ms: 1000\n   trigger:\n     type: http_trigger\n     args:\n       route: resilient\n   ---\n   ```\n   Add to `### Agent Front Matter` examples with commentary explaining retry behavior\n\n3. **Review architecture.md:**\n   - Check if runner stage (§3.4) mentions retry logic\n   - If RetryPolicyConfig is in a new module, add to module map\n   - No pipeline stage changes needed (execution detail)\n\n4. **Checklist:**\n   - [x] front-matter-reference.md updated\n   - [x] front-matter-spec.md: added retry_policy example under Agent Front Matter\n   - [x] architecture.md: verified runner stage mentions retry (update if not)\n   - [x] docs\u002Findex.md, docs\u002Fgetting-started.md: not applicable (advanced\u002Foptional field, not quickstart-worthy)\n   - [ ] Human review: decide if retry belongs in runner or client_manager\n\n## Example: Adding a new trigger type\n\n**Scenario:** New `CosmosDbTrigger` model added to schema.py\n\n**Actions:**\n\n1. **Analyze:** New trigger model → new public surface in `trigger.type`\n2. **Update front-matter-spec.md:**\n   ```yaml\n   ---\n   name: Cosmos Change Feed Agent\n   description: Responds to Cosmos DB document changes\n   trigger:\n     type: cosmosdb_trigger\n     args:\n       database_name: my-database\n       container_name: my-container\n       connection: CosmosDbConnection\n       lease_container_name: leases\n   ---\n   ```\n   Add to `### Triggers` section with explanation of change feed behavior\n\n3. **Update docs\u002Ftriggers.md** (if it exists):\n   - Add detailed CosmosDB trigger documentation\n   - Explain lease container, change feed continuation, etc.\n\n4. **Review architecture.md:**\n   - Discovery stage: verify it mentions trigger discovery from schema\n   - Registration stage: confirm it handles new binding type\n   - Module map: ensure `registration\u002Ftriggers.py` is listed\n\n5. **Checklist:**\n   - [x] front-matter-reference.md updated (auto via TRIGGER_TYPES dict in script)\n   - [x] front-matter-spec.md: added cosmosdb_trigger example\n   - [x] docs\u002Ftriggers.md: added detailed CosmosDB section\n   - [x] architecture.md: verified trigger registration flow\n   - [x] docs\u002Findex.md: added \"Cosmos DB change feed\" to trigger bullet examples; docs\u002Fgetting-started.md: not applicable (not part of minimal quickstart path)\n   - [ ] Human review: binding extension dependency (needs host.json update?)\n\n## Output format\n\nWhen this skill completes, provide:\n\n1. **Summary of changes made:**\n   ```\n   Schema changes detected:\n   - Added field: AgentSpec.retry_policy (optional, nested config)\n   - Modified field: GlobalConfig.timeout (type widened to int | str)\n   \n   Documentation updates:\n   - front-matter-spec.md: Added retry_policy example (line 245)\n   - front-matter-spec.md: Updated timeout example to show string format (line 89)\n   - architecture.md: Verified runner stage docs (no changes needed)\n   - docs\u002Findex.md, docs\u002Fgetting-started.md: not applicable (advanced field, not quickstart-relevant)\n   ```\n\n2. **PR checklist** (markdown, ready to paste):\n   ```markdown\n   ## Documentation Updates (Schema Changes)\n   \n   - [x] `front-matter-reference.md` regenerated via `generate_config_reference.py`\n   - [x] `front-matter-spec.md` examples added for: `retry_policy`\n   - [x] `front-matter-spec.md` timeout example updated to show string support\n   - [x] `architecture.md` module map verified (no changes needed)\n   - [x] `docs\u002Findex.md` \u002F `docs\u002Fgetting-started.md` checked (not applicable)\n   - [ ] **Human review:** Retry logic placement (runner vs client_manager?)\n   ```\n\n3. **Architectural concerns** (if any):\n   ```\n   ⚠️ Human review needed:\n   - New RetryPolicyConfig model suggests retry logic in the runner.\n     Does this conflict with MAF's built-in retry? Check AgentClient docs.\n   - If retry is per-request, should it live in client_manager instead?\n   ```\n\n## Guardrails\n\n- **Do not auto-generate prose sections of architecture.md** — only verify module\n  map and flag inconsistencies. Design decisions require human judgment.\n- **Match the existing example style** in front-matter-spec.md — concise,\n  realistic, focused on common use cases.\n- **Link liberally** — examples in spec should reference the reference for\n  complete API details.\n- **Favor explicit over exhaustive** — one good example > ten variations.\n- **This skill complements, does not replace, human review** — complex\n  architectural implications still need human sign-off in the FRD Decisions log.\n\n## Integration with AGENTS.md Phase 5\n\nThis skill is invoked during **Phase 5 (Docs)** of the medium+ pipeline, after\n`eng\u002Fscripts\u002Fgenerate_config_reference.py` has been run. The workflow becomes:\n\n1. Run `generate_config_reference.py` → updates `front-matter-reference.md`\n2. Run **this skill** → updates `front-matter-spec.md` examples, reviews\n   `architecture.md`, and syncs `docs\u002Findex.md` \u002F `docs\u002Fgetting-started.md`\n   when the change adds a new user-facing capability\n3. Human reviews the PR checklist and architectural concerns\n4. Commit documentation updates alongside implementation\n\n## Files touched\n\n- **Input (read):**\n  - `src\u002Fazure_functions_agents\u002Fconfig\u002Fschema.py` (detect changes)\n  - `docs\u002Ffront-matter-reference.md` (understand new API surface)\n  - `docs\u002Ffrds\u002F\u003CNNNN>-\u003Cslug>.md` (understand intent of schema changes)\n\n- **Output (write):**\n  - `docs\u002Ffront-matter-spec.md` (add\u002Fupdate examples)\n  - `docs\u002Ftriggers.md` (if trigger surface changed)\n  - `docs\u002Findex.md` (if a new user-facing capability warrants a feature bullet)\n  - `docs\u002Fgetting-started.md` (if the new capability changes the minimal quickstart path)\n\n- **Output (review\u002Fflag):**\n  - `docs\u002Farchitecture.md` (flag inconsistencies, suggest updates)\n  - `README.md` (flag if user-facing quickstart examples need updates)\n\n## Success criteria\n\n- Every new field in schema.py has at least one usage example in front-matter-spec.md\n- Existing examples updated if field semantics changed\n- Architecture.md module map matches reality\n- docs\u002Findex.md and docs\u002Fgetting-started.md checked for every schema change that\n  adds a new user-facing capability (bullet added or explicitly deemed not applicable)\n- Clear PR checklist with human review items flagged\n- No \"orphaned\" documentation (examples for removed fields)\n","# update-schema-docs — Schema-driven documentation synchronization\n\nThis skill ensures `docs\u002Ffront-matter-spec.md`, `docs\u002Farchitecture.md`, and the\npublic docs site's landing\u002Fonboarding pages (`docs\u002Findex.md`,\n`docs\u002Fgetting-started.md`) stay synchronized when\n`src\u002Fazure_functions_agents\u002Fconfig\u002Fschema.py` changes.\n`docs\u002Ffront-matter-reference.md` is already auto-generated (via\n`eng\u002Fscripts\u002Fgenerate_config_reference.py`), but spec, architecture, and\ndocs-site pages require intelligent example generation and contextual updates.\n\n## When to use\n\nUse this skill during **Phase 5 (Docs)** of the medium+ feature pipeline when:\n- `schema.py` has been modified (new fields, models, or validation logic)\n- New public configuration surface was added\n- After implementing config-related features\n- When asked to synchronize documentation with schema changes\n\n## What this skill does\n\n1. **Detect changes:** Compare current `schema.py` against the last commit or\n   baseline to identify added\u002Fmodified fields and models.\n2. **Update front-matter-spec.md:**\n   - Add usage examples for new fields\n   - Update existing examples if field semantics changed\n   - Add validation examples for new constraints\n   - Ensure Examples section coverage matches the reference\n3. **Review architecture.md:**\n   - Flag if new models suggest pipeline stage changes\n   - Check if module map needs updates\n   - Verify configuration precedence rules still hold\n4. **Sync the docs site landing pages:**\n   - If the change introduces a new **user-facing capability** (new trigger\n     type, new frontmatter field a typical user would reach for, new model\n     provider), check whether `docs\u002Findex.md`'s feature bullet list or\n     `docs\u002Fgetting-started.md`'s walkthrough should mention it\n   - Skip this step for internal-only or low-level schema changes (e.g.\n     tightened validation, refactors) that don't change what a new user sees\n5. **Generate PR checklist:** List all doc changes made + items needing human review\n\n## Prerequisites\n\n- `schema.py` changes committed or staged\n- Understanding of what the schema change enables (from the FRD)\n- `eng\u002Fscripts\u002Fgenerate_config_reference.py` already run (reference up to date)\n\n## Workflow\n\n### Step 1: Analyze schema changes\n\n1. Read the current `src\u002Fazure_functions_agents\u002Fconfig\u002Fschema.py`\n2. Identify what changed:\n   - New models (e.g., new trigger types, new capabilities)\n   - New fields on existing models (e.g., GlobalConfig, AgentSpec)\n   - Changed field types or validators\n   - New Pydantic constraints or defaults\n\n3. Categorize changes by impact:\n   - **Agent frontmatter surface:** affects `AgentSpec` → needs examples in spec\n   - **Global config surface:** affects `GlobalConfig` → needs global examples\n   - **Trigger surface:** affects trigger models → needs trigger examples\n   - **Structural:** new pipeline stage or module → needs architecture review\n\n### Step 2: Update front-matter-spec.md\n\nFor each new or changed field:\n\n1. **Locate the relevant section:**\n   - Agent fields → `### Agent Front Matter` examples\n   - Global fields → `### Global Configuration` examples\n   - Trigger fields → `### Triggers` or `### Advanced Examples`\n\n2. **Generate usage examples:**\n   - Start from the field's type, description, and default in schema.py\n   - Create realistic YAML examples showing:\n     - Basic usage (most common case)\n     - Edge cases (if validation is complex)\n     - Integration with related fields\n   - Follow existing example style (concise, commented, realistic values)\n\n3. **Add validation examples if needed:**\n   - If the field has custom validators (e.g., CRON expressions, URL patterns)\n   - Show valid and invalid examples with explanations\n\n4. **Cross-reference to the reference:**\n   - Link to `front-matter-reference.md#\u003Csection>` for full API details\n   - Ensure the spec focuses on *how to use*, reference on *what exists*\n\n### Step 3: Review architecture.md\n\n1. **Check if module map needs updates:**\n   - New models in `schema.py` may indicate new modules in `config\u002F`, `discovery\u002F`, etc.\n   - Verify the module map in §3 reflects reality\n   - If discovery logic changed, update the discovery stage description\n\n2. **Check if pipeline stages changed:**\n   - New configuration may affect discover → translate → register → execute flow\n   - Document new capabilities or constraints in the relevant stage\n\n3. **Check configuration precedence:**\n   - If new global\u002Fagent\u002Fenv interactions exist, update §4 precedence rules\n   - Ensure the precedence diagram (if present) is still accurate\n\n### Step 4: Sync docs-site landing pages\n\n1. **Decide if this change is docs-site-worthy:**\n   - New trigger type, new top-level frontmatter field, new model provider,\n     or any change that adds a bullet-worthy capability → yes\n   - Internal refactors, stricter validation, or field renames with no new\n     capability → no, skip\n\n2. **Update `docs\u002Findex.md`** (if worthy):\n   - Add a concise bullet to the feature list matching the existing bullet\n     style (bold lead-in, em dash, one sentence)\n\n3. **Update `docs\u002Fgetting-started.md`** (if worthy and walkthrough-relevant):\n   - Only touch the quickstart steps if the new capability changes the\n     minimal path to a working agent (e.g. a new required config file, a new\n     provider env var). Don't pad the walkthrough with optional features.\n\n4. **Cross-check `README.md`:** the docs site and README duplicate the same\n   feature bullet list — if you update one, flag (or update) the other so\n   they don't drift.\n\n### Step 5: Generate PR checklist\n\nCreate a checklist of:\n- [ ] front-matter-reference.md updated (auto-generated via script)\n- [ ] front-matter-spec.md examples added for: `\u003Clist new fields>`\n- [ ] architecture.md module map verified\n- [ ] docs\u002Findex.md and docs\u002Fgetting-started.md checked (updated \u002F not applicable)\n- [ ] Human review needed for: `\u003Clist architectural concerns>`\n- [ ] Validation examples added for: `\u003Clist complex validators>`\n\n## Example: Adding a new agent field\n\n**Scenario:** `AgentSpec` gained a new field `retry_policy: RetryPolicyConfig | None = None`\n\n**Actions:**\n\n1. **Analyze:** New optional field on `AgentSpec`, type is a nested model\n2. **Update front-matter-spec.md:**\n   ```yaml\n   ---\n   name: Resilient Agent\n   description: Agent with automatic retry logic\n   retry_policy:\n     max_attempts: 3\n     backoff_multiplier: 2\n     initial_delay_ms: 1000\n   trigger:\n     type: http_trigger\n     args:\n       route: resilient\n   ---\n   ```\n   Add to `### Agent Front Matter` examples with commentary explaining retry behavior\n\n3. **Review architecture.md:**\n   - Check if runner stage (§3.4) mentions retry logic\n   - If RetryPolicyConfig is in a new module, add to module map\n   - No pipeline stage changes needed (execution detail)\n\n4. **Checklist:**\n   - [x] front-matter-reference.md updated\n   - [x] front-matter-spec.md: added retry_policy example under Agent Front Matter\n   - [x] architecture.md: verified runner stage mentions retry (update if not)\n   - [x] docs\u002Findex.md, docs\u002Fgetting-started.md: not applicable (advanced\u002Foptional field, not quickstart-worthy)\n   - [ ] Human review: decide if retry belongs in runner or client_manager\n\n## Example: Adding a new trigger type\n\n**Scenario:** New `CosmosDbTrigger` model added to schema.py\n\n**Actions:**\n\n1. **Analyze:** New trigger model → new public surface in `trigger.type`\n2. **Update front-matter-spec.md:**\n   ```yaml\n   ---\n   name: Cosmos Change Feed Agent\n   description: Responds to Cosmos DB document changes\n   trigger:\n     type: cosmosdb_trigger\n     args:\n       database_name: my-database\n       container_name: my-container\n       connection: CosmosDbConnection\n       lease_container_name: leases\n   ---\n   ```\n   Add to `### Triggers` section with explanation of change feed behavior\n\n3. **Update docs\u002Ftriggers.md** (if it exists):\n   - Add detailed CosmosDB trigger documentation\n   - Explain lease container, change feed continuation, etc.\n\n4. **Review architecture.md:**\n   - Discovery stage: verify it mentions trigger discovery from schema\n   - Registration stage: confirm it handles new binding type\n   - Module map: ensure `registration\u002Ftriggers.py` is listed\n\n5. **Checklist:**\n   - [x] front-matter-reference.md updated (auto via TRIGGER_TYPES dict in script)\n   - [x] front-matter-spec.md: added cosmosdb_trigger example\n   - [x] docs\u002Ftriggers.md: added detailed CosmosDB section\n   - [x] architecture.md: verified trigger registration flow\n   - [x] docs\u002Findex.md: added \"Cosmos DB change feed\" to trigger bullet examples; docs\u002Fgetting-started.md: not applicable (not part of minimal quickstart path)\n   - [ ] Human review: binding extension dependency (needs host.json update?)\n\n## Output format\n\nWhen this skill completes, provide:\n\n1. **Summary of changes made:**\n   ```\n   Schema changes detected:\n   - Added field: AgentSpec.retry_policy (optional, nested config)\n   - Modified field: GlobalConfig.timeout (type widened to int | str)\n   \n   Documentation updates:\n   - front-matter-spec.md: Added retry_policy example (line 245)\n   - front-matter-spec.md: Updated timeout example to show string format (line 89)\n   - architecture.md: Verified runner stage docs (no changes needed)\n   - docs\u002Findex.md, docs\u002Fgetting-started.md: not applicable (advanced field, not quickstart-relevant)\n   ```\n\n2. **PR checklist** (markdown, ready to paste):\n   ```markdown\n   ## Documentation Updates (Schema Changes)\n   \n   - [x] `front-matter-reference.md` regenerated via `generate_config_reference.py`\n   - [x] `front-matter-spec.md` examples added for: `retry_policy`\n   - [x] `front-matter-spec.md` timeout example updated to show string support\n   - [x] `architecture.md` module map verified (no changes needed)\n   - [x] `docs\u002Findex.md` \u002F `docs\u002Fgetting-started.md` checked (not applicable)\n   - [ ] **Human review:** Retry logic placement (runner vs client_manager?)\n   ```\n\n3. **Architectural concerns** (if any):\n   ```\n   ⚠️ Human review needed:\n   - New RetryPolicyConfig model suggests retry logic in the runner.\n     Does this conflict with MAF's built-in retry? Check AgentClient docs.\n   - If retry is per-request, should it live in client_manager instead?\n   ```\n\n## Guardrails\n\n- **Do not auto-generate prose sections of architecture.md** — only verify module\n  map and flag inconsistencies. Design decisions require human judgment.\n- **Match the existing example style** in front-matter-spec.md — concise,\n  realistic, focused on common use cases.\n- **Link liberally** — examples in spec should reference the reference for\n  complete API details.\n- **Favor explicit over exhaustive** — one good example > ten variations.\n- **This skill complements, does not replace, human review** — complex\n  architectural implications still need human sign-off in the FRD Decisions log.\n\n## Integration with AGENTS.md Phase 5\n\nThis skill is invoked during **Phase 5 (Docs)** of the medium+ pipeline, after\n`eng\u002Fscripts\u002Fgenerate_config_reference.py` has been run. The workflow becomes:\n\n1. Run `generate_config_reference.py` → updates `front-matter-reference.md`\n2. Run **this skill** → updates `front-matter-spec.md` examples, reviews\n   `architecture.md`, and syncs `docs\u002Findex.md` \u002F `docs\u002Fgetting-started.md`\n   when the change adds a new user-facing capability\n3. Human reviews the PR checklist and architectural concerns\n4. Commit documentation updates alongside implementation\n\n## Files touched\n\n- **Input (read):**\n  - `src\u002Fazure_functions_agents\u002Fconfig\u002Fschema.py` (detect changes)\n  - `docs\u002Ffront-matter-reference.md` (understand new API surface)\n  - `docs\u002Ffrds\u002F\u003CNNNN>-\u003Cslug>.md` (understand intent of schema changes)\n\n- **Output (write):**\n  - `docs\u002Ffront-matter-spec.md` (add\u002Fupdate examples)\n  - `docs\u002Ftriggers.md` (if trigger surface changed)\n  - `docs\u002Findex.md` (if a new user-facing capability warrants a feature bullet)\n  - `docs\u002Fgetting-started.md` (if the new capability changes the minimal quickstart path)\n\n- **Output (review\u002Fflag):**\n  - `docs\u002Farchitecture.md` (flag inconsistencies, suggest updates)\n  - `README.md` (flag if user-facing quickstart examples need updates)\n\n## Success criteria\n\n- Every new field in schema.py has at least one usage example in front-matter-spec.md\n- Existing examples updated if field semantics changed\n- Architecture.md module map matches reality\n- docs\u002Findex.md and docs\u002Fgetting-started.md checked for every schema change that\n  adds a new user-facing capability (bullet added or explicitly deemed not applicable)\n- Clear PR checklist with human review items flagged\n- No \"orphaned\" documentation (examples for removed fields)\n",{"name":5,"description":7},"main","986e781f82b453d5aef9ad3602bbf24a6bda7298",".github\u002Fskills\u002Fupdate-schema-docs",10,"https:\u002F\u002Fgithub.com\u002FAzure\u002Fazure-functions-agents-runtime","https:\u002F\u002Fazure.github.io\u002Fazure-functions-agents-runtime\u002F","https:\u002F\u002Fgithub.com\u002FAzure","https:\u002F\u002Fdocs.microsoft.com\u002Fen-us\u002Fazure\u002F","APIs, SDKs and open source projects from Microsoft Azure","2026-11-05 06:55:15",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add Azure\u002Fazure-functions-agents-runtime --skill update-schema-docs",{"tool":65,"command":66},"bunx","bunx skills add Azure\u002Fazure-functions-agents-runtime --skill update-schema-docs",{"tool":68,"command":69},"pnpm","pnpm dlx skills add Azure\u002Fazure-functions-agents-runtime --skill update-schema-docs","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAzure\u002Fazure-functions-agents-runtime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fupdate-schema-docs\u002FSKILL.md",true,[],[74,84,92,102,114,122],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":44},"01M71HMTNMPVDJR8JQW7VM4VD5","child","Nested document belonging to parent.","https:\u002F\u002Fgithub.com\u002FAzure\u002Fazure-functions-agents-runtime\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fconfig_scenarios\u002F21_skill_root_boundaries\u002Fskills\u002Fparent\u002Fchild\u002FSKILL.md",[],[76,81,82,83],"nested","parent","document",{"skillNo":85,"name":82,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":44},"01M71HMRYWE1TEC1GTCP0MTJXV","Parent skill with nested resources.","https:\u002F\u002Fgithub.com\u002FAzure\u002Fazure-functions-agents-runtime\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fconfig_scenarios\u002F21_skill_root_boundaries\u002Fskills\u002Fparent\u002FSKILL.md",[],[82,90,81,91],"resources","with",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":44},"01M71HMQ2YCF8868YQ37JVTY61","grouped","Skill at the permitted second directory level.","https:\u002F\u002Fgithub.com\u002FAzure\u002Fazure-functions-agents-runtime\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fconfig_scenarios\u002F21_skill_root_boundaries\u002Fskills\u002Fgroup\u002Fgrouped\u002FSKILL.md",[],[94,99,100,101],"at","directory","second",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":44},"01M71HMN26QD2FYGHYZACP2HAT","too-deep","Skill beyond the shared search depth.","https:\u002F\u002Fgithub.com\u002FAzure\u002Fazure-functions-agents-runtime\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fconfig_scenarios\u002F21_skill_root_boundaries\u002Fskills\u002Fgroup\u002Fdeep\u002Fleaf\u002FSKILL.md",[],[109,110,111,112,113],"deep","too deep","depth","search","shared",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":44},"01M71HMKTR22N746PD31NRRHFY","excluded","Independently discovered but excluded skill.","https:\u002F\u002Fgithub.com\u002FAzure\u002Fazure-functions-agents-runtime\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fconfig_scenarios\u002F21_skill_root_boundaries\u002Fskills\u002Fexcluded\u002FSKILL.md",[],[116,121],"but",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":44},"01M71HMJ5R8CS85MD36AFWT5KS","guide-child","Nested child skill guidance.","https:\u002F\u002Fgithub.com\u002FAzure\u002Fazure-functions-agents-runtime\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fconfig_scenarios\u002F20_scoped_skills\u002Fskills\u002Fguide-parent\u002Fguide-child\u002FSKILL.md",[],[76,129,130,131,132,133,81,134],"guide child","guide","nested child skill","nested child","child skill","guidance"]