[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HKSG8WP0XHMX8EYXGWDV6":3,"skill-same:01M71HKSG8WP0XHMX8EYXGWDV6":79},{"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},"01M71HKSG8WP0XHMX8EYXGWDV6","add-feature",null,"Use when adding a medium or larger feature (or a non-trivial change) to the azure-functions-agents-runtime repository — i.e. anything that introduces new public surface, spans multiple modules, or changes authoring\u002Fdiscovery\u002Fregistration behavior. Drives the full feature lifecycle defined in AGENTS.md: triage + worktree, writing a Feature Requirements Document (FRD) with a Decisions log, an architecture-review checkpoint, surgical implementation, a testing checkpoint, and documentation updates. Trigger on requests like 'add a feature', 'I want to implement X', 'let's design X', or when a change is clearly larger than a nit\u002Fbug\u002Fsmall fix. Do NOT use for typos, formatting, comments, or self-contained one-module fixes — those follow the lightweight lane in AGENTS.md.","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\u002Fadd-feature\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"add feature","add","feature","modules","new","when","updates","typos","self","log","testing","fix","azure-functions","worktree","documentation","architecture","change","review","writing","design","2026-11-10 10:12:30",false,"---\nname: add-feature\ndescription: \"Use when adding a medium or larger feature (or a non-trivial change) to the azure-functions-agents-runtime repository — i.e. anything that introduces new public surface, spans multiple modules, or changes authoring\u002Fdiscovery\u002Fregistration behavior. Drives the full feature lifecycle defined in AGENTS.md: triage + worktree, writing a Feature Requirements Document (FRD) with a Decisions log, an architecture-review checkpoint, surgical implementation, a testing checkpoint, and documentation updates. Trigger on requests like 'add a feature', 'I want to implement X', 'let's design X', or when a change is clearly larger than a nit\u002Fbug\u002Fsmall fix. Do NOT use for typos, formatting, comments, or self-contained one-module fixes — those follow the lightweight lane in AGENTS.md.\"\n---\n\n# add-feature — feature lifecycle for azure-functions-agents-runtime\n\nThis skill operationalizes the lifecycle in [`AGENTS.md`](..\u002F..\u002F..\u002FAGENTS.md) §1\nfor **medium+ features**. Run the phases in order; each has an exit gate — do not\nadvance until it is met. Record consequential **feature-behavior** choices in\nthe FRD Decisions log, not delivery or PR-management decisions.\n\n## When to use\n\nUse for medium+ features: new public surface (frontmatter keys, config, endpoints),\ncross-module changes, or new discovery\u002Fregistration\u002Fauthoring behavior.\nSkip (use the lightweight lane) for nits, typos, and self-contained one-module\nbug fixes.\n\n## Prerequisites\n\n- Read `AGENTS.md` (process) and `docs\u002Farchitecture.md` §2–§3 (design + module map).\n- Know the canonical gate commands (`AGENTS.md` §3).\n\n## Phase 0 — Triage + worktree  *(gate: scope + lane agreed)*\n\n1. Confirm the change is genuinely medium+. If not, drop to the lightweight lane.\n2. Agree a short slug and create a worktree off `main`:\n   ```bash\n   git worktree add \\\n     ..\u002Fcopilot-worktrees\u002Fazure-functions-agents-runtime\u002F\u003Cuser>-\u003Cslug> \\\n     -b \u003Cuser>\u002F\u003Cslug> main\n   ```\n\n## Phase 1 — FRD  *(gate: FRD drafted)*\n\n1. Determine the next FRD number: highest `docs\u002Ffrds\u002FNNNN-*.md` + 1, zero-padded.\n2. Copy `docs\u002Ffrds\u002F_template.md` → `docs\u002Ffrds\u002F\u003CNNNN>-\u003Cslug>.md`.\n3. Fill every section. Map the **Proposed design** onto the pipeline stages\n   (discover → translate → register → execute) and describe the intended\n   behavior, compatibility boundaries, and acceptance criteria. Do not describe\n   the PR sequence, slice scope, ownership, schedule, or rollout plan in the FRD.\n4. Seed the **Decisions log** with feature-contract choices and who made them\n   (Human vs Agent). Do not record implementation or delivery planning there.\n5. If the implementation is too large or risky for one reviewable PR, read\n   [`references\u002Fsplit-rules.md`](references\u002Fsplit-rules.md). Discuss the PR\n   sequence and dependencies in PR descriptions or a separate delivery plan,\n   never in the FRD.\n6. Keep the FRD focused on intended behavior, contracts, and durable decisions.\n   Do not encode delivery mechanics such as PR numbers, commit SHAs, temporary\n   slice\u002Fphasing labels, or package versions already owned by `pyproject.toml`.\n7. Write in crisp, plain English. Use short sentences, define terms on first use,\n   assume little background context, and state conclusions as facts. Do not narrate\n   investigation history in the FRD; put evidence in PR descriptions.\n8. Never cite Decisions-log numbers in FRD prose or cross-references; describe the\n   decision instead, because numbers shift on merges\u002Frenumbering.\n\n## Phase 2 — Architecture review (planning mode)  *(gate: human sign-off → `status: Finalized`)*\n\n1. Run a dedicated review pass — prefer a review sub-agent (e.g. `rubber-duck`)\n   so the author's context does not bias it. Ask it to judge the FRD for:\n   - completeness (all sections answered, edge cases, compatibility);\n   - alignment with the `docs\u002Farchitecture.md` module map and pipeline boundaries\n     (discovery read-only; registration is the only Azure-aware stage; lazy runner);\n   - whether the public surface stays consistent with `docs\u002Ffront-matter-spec.md`.\n2. Iterate on the FRD until findings are resolved. Append decisions to the log.\n3. Get explicit human sign-off, record it in §8, and set `status: Finalized`.\n   **Do not implement before the FRD is Finalized.**\n\n## Phase 3 — Implementation  *(gate: `ruff` + `mypy` clean)*\n\nFor multi-PR delivery, repeat phases 3–5 for every approved slice. Give each\nslice its own branch and worktree as described in `AGENTS.md`.\n\n1. Implement **product changes only**, per the finalized FRD. Keep diffs surgical;\n   no unrelated refactors.\n2. For multi-PR delivery, implement only the agreed delivery slice and keep its\n   dependency and review scope explicit in the PR, not the FRD.\n3. Follow `AGENTS.md` §5 conventions (PEP 695 type aliases, strict typing,\n   Pydantic v2 base-class fields, MAF default with only AGENTS.md's bounded\n   app-level Copilot preview exception, shared `_logger`).\n4. Run and pass:\n   ```bash\n   python -m ruff check src tests\n   python -m mypy src\n   ```\n\n## Phase 4 — Testing  *(gate: full gate green)*\n\n1. Design coverage for the current slice's behavior — prefer a separate testing review pass\n   (sub-agent or fresh checklist) so gaps are caught independently.\n2. Add tests under `tests\u002F`, mirroring source modules. For config\u002Fauthoring\n   changes, add a scenario folder under `tests\u002Ffixtures\u002Fconfig_scenarios\u002F`.\n3. For bug-adjacent work, add a failing regression test first.\n4. Run the full CI-equivalent gate:\n   ```bash\n   python -m pytest --cache-clear --cov=.\u002Fsrc\u002Fazure_functions_agents --cov-report=xml --cov-branch tests\n   ```\n\n## Phase 5 — Docs  *(gate: DoD met)*\n\n1. Update documentation made inaccurate by the current slice.\n   `docs\u002Farchitecture.md` (module map \u002F pipeline) is the design source of truth\n   and must stay accurate.\n2. **If schema.py changed:**\n   - Run `python eng\u002Fscripts\u002Fgenerate_config_reference.py` to regenerate the reference\n   - Use the **`update-schema-docs` skill** to add examples to `docs\u002Ffront-matter-spec.md`\n     and review `docs\u002Farchitecture.md` for consistency\n   - Review the skill's PR checklist and address architectural concerns\n3. Update relevant docs under `docs\u002F` (commonly `front-matter-spec.md`, `triggers.md`, \n   or other files as needed) if the authoring surface changed (for non-schema changes, \n   or to refine schema-generated examples).\n4. Update `README.md` if user-facing behavior changed.\n5. Update the FRD index in `docs\u002Ffrds\u002FREADME.md`.\n6. Verify the `AGENTS.md` §8 Definition of Done, then open the PR.\n7. After each PR merges, remove its worktree (`git worktree remove \u003Cpath>`).\n   Set the FRD `status: Implemented` only after the final planned PR merges.\n\n## Guardrails\n\n- Never skip a gate. If a gate fails, fix before advancing.\n- Keep the Decisions log focused on the feature contract; it is not a delivery diary.\n- Never cite Decisions-log numbers in FRD prose or cross-references; describe the\n  decision instead, because numbers shift on merges\u002Frenumbering.\n- Keep implementation diffs surgical and scoped to the FRD.\n- This skill is repo dev-tooling under `.github\u002Fskills\u002F`; it is unrelated to the\n  runtime's user-authored agent skills discovered from an app's `skills\u002F` folder.\n","# add-feature — feature lifecycle for azure-functions-agents-runtime\n\nThis skill operationalizes the lifecycle in [`AGENTS.md`](..\u002F..\u002F..\u002FAGENTS.md) §1\nfor **medium+ features**. Run the phases in order; each has an exit gate — do not\nadvance until it is met. Record consequential **feature-behavior** choices in\nthe FRD Decisions log, not delivery or PR-management decisions.\n\n## When to use\n\nUse for medium+ features: new public surface (frontmatter keys, config, endpoints),\ncross-module changes, or new discovery\u002Fregistration\u002Fauthoring behavior.\nSkip (use the lightweight lane) for nits, typos, and self-contained one-module\nbug fixes.\n\n## Prerequisites\n\n- Read `AGENTS.md` (process) and `docs\u002Farchitecture.md` §2–§3 (design + module map).\n- Know the canonical gate commands (`AGENTS.md` §3).\n\n## Phase 0 — Triage + worktree  *(gate: scope + lane agreed)*\n\n1. Confirm the change is genuinely medium+. If not, drop to the lightweight lane.\n2. Agree a short slug and create a worktree off `main`:\n   ```bash\n   git worktree add \\\n     ..\u002Fcopilot-worktrees\u002Fazure-functions-agents-runtime\u002F\u003Cuser>-\u003Cslug> \\\n     -b \u003Cuser>\u002F\u003Cslug> main\n   ```\n\n## Phase 1 — FRD  *(gate: FRD drafted)*\n\n1. Determine the next FRD number: highest `docs\u002Ffrds\u002FNNNN-*.md` + 1, zero-padded.\n2. Copy `docs\u002Ffrds\u002F_template.md` → `docs\u002Ffrds\u002F\u003CNNNN>-\u003Cslug>.md`.\n3. Fill every section. Map the **Proposed design** onto the pipeline stages\n   (discover → translate → register → execute) and describe the intended\n   behavior, compatibility boundaries, and acceptance criteria. Do not describe\n   the PR sequence, slice scope, ownership, schedule, or rollout plan in the FRD.\n4. Seed the **Decisions log** with feature-contract choices and who made them\n   (Human vs Agent). Do not record implementation or delivery planning there.\n5. If the implementation is too large or risky for one reviewable PR, read\n   [`references\u002Fsplit-rules.md`](references\u002Fsplit-rules.md). Discuss the PR\n   sequence and dependencies in PR descriptions or a separate delivery plan,\n   never in the FRD.\n6. Keep the FRD focused on intended behavior, contracts, and durable decisions.\n   Do not encode delivery mechanics such as PR numbers, commit SHAs, temporary\n   slice\u002Fphasing labels, or package versions already owned by `pyproject.toml`.\n7. Write in crisp, plain English. Use short sentences, define terms on first use,\n   assume little background context, and state conclusions as facts. Do not narrate\n   investigation history in the FRD; put evidence in PR descriptions.\n8. Never cite Decisions-log numbers in FRD prose or cross-references; describe the\n   decision instead, because numbers shift on merges\u002Frenumbering.\n\n## Phase 2 — Architecture review (planning mode)  *(gate: human sign-off → `status: Finalized`)*\n\n1. Run a dedicated review pass — prefer a review sub-agent (e.g. `rubber-duck`)\n   so the author's context does not bias it. Ask it to judge the FRD for:\n   - completeness (all sections answered, edge cases, compatibility);\n   - alignment with the `docs\u002Farchitecture.md` module map and pipeline boundaries\n     (discovery read-only; registration is the only Azure-aware stage; lazy runner);\n   - whether the public surface stays consistent with `docs\u002Ffront-matter-spec.md`.\n2. Iterate on the FRD until findings are resolved. Append decisions to the log.\n3. Get explicit human sign-off, record it in §8, and set `status: Finalized`.\n   **Do not implement before the FRD is Finalized.**\n\n## Phase 3 — Implementation  *(gate: `ruff` + `mypy` clean)*\n\nFor multi-PR delivery, repeat phases 3–5 for every approved slice. Give each\nslice its own branch and worktree as described in `AGENTS.md`.\n\n1. Implement **product changes only**, per the finalized FRD. Keep diffs surgical;\n   no unrelated refactors.\n2. For multi-PR delivery, implement only the agreed delivery slice and keep its\n   dependency and review scope explicit in the PR, not the FRD.\n3. Follow `AGENTS.md` §5 conventions (PEP 695 type aliases, strict typing,\n   Pydantic v2 base-class fields, MAF default with only AGENTS.md's bounded\n   app-level Copilot preview exception, shared `_logger`).\n4. Run and pass:\n   ```bash\n   python -m ruff check src tests\n   python -m mypy src\n   ```\n\n## Phase 4 — Testing  *(gate: full gate green)*\n\n1. Design coverage for the current slice's behavior — prefer a separate testing review pass\n   (sub-agent or fresh checklist) so gaps are caught independently.\n2. Add tests under `tests\u002F`, mirroring source modules. For config\u002Fauthoring\n   changes, add a scenario folder under `tests\u002Ffixtures\u002Fconfig_scenarios\u002F`.\n3. For bug-adjacent work, add a failing regression test first.\n4. Run the full CI-equivalent gate:\n   ```bash\n   python -m pytest --cache-clear --cov=.\u002Fsrc\u002Fazure_functions_agents --cov-report=xml --cov-branch tests\n   ```\n\n## Phase 5 — Docs  *(gate: DoD met)*\n\n1. Update documentation made inaccurate by the current slice.\n   `docs\u002Farchitecture.md` (module map \u002F pipeline) is the design source of truth\n   and must stay accurate.\n2. **If schema.py changed:**\n   - Run `python eng\u002Fscripts\u002Fgenerate_config_reference.py` to regenerate the reference\n   - Use the **`update-schema-docs` skill** to add examples to `docs\u002Ffront-matter-spec.md`\n     and review `docs\u002Farchitecture.md` for consistency\n   - Review the skill's PR checklist and address architectural concerns\n3. Update relevant docs under `docs\u002F` (commonly `front-matter-spec.md`, `triggers.md`, \n   or other files as needed) if the authoring surface changed (for non-schema changes, \n   or to refine schema-generated examples).\n4. Update `README.md` if user-facing behavior changed.\n5. Update the FRD index in `docs\u002Ffrds\u002FREADME.md`.\n6. Verify the `AGENTS.md` §8 Definition of Done, then open the PR.\n7. After each PR merges, remove its worktree (`git worktree remove \u003Cpath>`).\n   Set the FRD `status: Implemented` only after the final planned PR merges.\n\n## Guardrails\n\n- Never skip a gate. If a gate fails, fix before advancing.\n- Keep the Decisions log focused on the feature contract; it is not a delivery diary.\n- Never cite Decisions-log numbers in FRD prose or cross-references; describe the\n  decision instead, because numbers shift on merges\u002Frenumbering.\n- Keep implementation diffs surgical and scoped to the FRD.\n- This skill is repo dev-tooling under `.github\u002Fskills\u002F`; it is unrelated to the\n  runtime's user-authored agent skills discovered from an app's `skills\u002F` folder.\n",{"name":5,"description":7},"main","986e781f82b453d5aef9ad3602bbf24a6bda7298",".github\u002Fskills\u002Fadd-feature",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 add-feature",{"tool":65,"command":66},"bunx","bunx skills add Azure\u002Fazure-functions-agents-runtime --skill add-feature",{"tool":68,"command":69},"pnpm","pnpm dlx skills add Azure\u002Fazure-functions-agents-runtime --skill add-feature","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAzure\u002Fazure-functions-agents-runtime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fadd-feature\u002FSKILL.md",true,[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fsplit-rules.md","REFERENCE","参考文档",5762,"https:\u002F\u002Fgithub.com\u002FAzure\u002Fazure-functions-agents-runtime\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fadd-feature\u002Freferences\u002Fsplit-rules.md",[80,90,98,108,120,128],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"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",[],[82,87,88,89],"nested","parent","document",{"skillNo":91,"name":88,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"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",[],[88,96,87,97],"resources","with",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"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",[],[100,105,106,107],"at","directory","second",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"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",[],[115,116,117,118,119],"deep","too deep","depth","search","shared",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"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",[],[122,127],"but",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"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",[],[82,135,136,137,138,139,87,140],"guide child","guide","nested child skill","nested child","child skill","guidance"]