[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X2SCCVTC18RN9FYRK7PEHF":3,"skill-same:01M6X2SCCVTC18RN9FYRK7PEHF":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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":68},"01M6X2SCCVTC18RN9FYRK7PEHF","draft-customer-reply",null,"Drafts a reviewable customer-facing support reply grounded in known facts, applicable policy, and the customer's actual needs. Use when a ticket, incident, issue, request, or complaint needs a reviewable customer-facing reply grounded in the known facts, applicable policy, customer need, and communication context. Triggers include \"draft a reply,\" \"respond to the customer,\" \"write a status update,\" and requests to adjust tone, length, or language. Do not use to research an unresolved answer or to send automatically.","microsoft\u002Fcat-agent-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69A1AHE1MABT7GVP5143M5Z",105,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fdraft-customer-reply\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"draft customer reply","customer","reply","draft","adjust","when","send","facts","requests","answer","respond","ticket","triggers","policy","tone","incident","do","use","communication","research","2026-11-10 10:12:30",false,"---\r\nname: draft-customer-reply\r\ndescription: Drafts a reviewable customer-facing support reply grounded in known facts, applicable policy, and the customer's actual needs. Use when a ticket, incident, issue, request, or complaint needs a reviewable customer-facing reply grounded in the known facts, applicable policy, customer need, and communication context. Triggers include \"draft a reply,\" \"respond to the customer,\" \"write a status update,\" and requests to adjust tone, length, or language. Do not use to research an unresolved answer or to send automatically.\r\nmetadata:\r\n  displayname: Draft Customer Reply\r\n---\r\n\r\n# Draft Customer Reply\r\n\r\nDomain: Customer Service.\r\n\r\nFollow this skill's evidence, artifact, privacy, action-control, and outcome-reporting rules below.\r\n\r\n## Evidence and connectivity\r\n\r\nBegin with authorized user-provided material and accessible work sources. Discover optional CRM, knowledge, communication, quality, and workflow capabilities at runtime and use them only to enrich or execute the job; never require a vendor, connector, record identifier, object name, or field name when the minimum semantic evidence is otherwise available.\r\n\r\nIf a capability is unconfigured, unavailable, denied, stale, partial, or unsupported, continue with the supported baseline, disclose the affected scope, and block only the dependent conclusion or action. Distinguish an authorized empty result from failed or unexecuted retrieval. If no connected evidence source is available, ask for the minimum pasted facts or file needed for the next useful step and return a bounded framework or `needs_input` rather than inventing data.\r\nUse supplied material and authorized issue, interaction, policy, knowledge, attachment, and fulfillment evidence needed for the reply. Connected CRM and communication systems are optional enrichment. Separate verified facts, customer statements, approved policy language, proposed commitments, and unknowns before drafting.\r\n\r\n## Data Sources\r\n\r\nUse relevant supplied material or applicable tools and sources you are authorized to access. These are options, not a mandatory checklist. Ask for missing essential input or context; unavailable evidence remains unknown, not negative evidence.\r\n\r\n- Email & Interaction Records for the customer's actual need, prior messages and intended recipient or thread.\r\n- Record Snapshots & Exports for verified issue facts, fulfillment results and remedy state.\r\n- Knowledge & Files for established answers, approved policy language, attachments and applicable communication constraints.\r\n- Supplied Preferences for the customer's language and the requested tone or length, without inventing facts.\r\n\r\nRetain provenance, freshness limits and the existing evidence, privacy and authorization rules.\r\n\r\n## Purpose\r\nProduce a reviewable customer-facing draft that answers the customer's actual need with\r\nthe right policy basis, completeness, tone, language, and privacy treatment.\r\n\r\n## Applicability\r\nApplies when the customer need and enough supporting evidence are known to draft a useful\r\nresponse. The evidence may be a message, issue description, interaction history, verified\r\nanswer, or applicable policy. A saved email record or complete logged history is not\r\nrequired.\r\n\r\nThin evidence can support a bounded acknowledgment or request for information. It cannot\r\nsupport invented facts, promises, compensation, deadlines, or resolution claims.\r\n\r\n## Usage situations\r\n- \"Draft a response to this complaint.\"\r\n- \"Reply to the customer's last message.\"\r\n- \"Write a concise update in the customer's language.\"\r\n- \"Explain the verified resolution and next steps.\"\r\n- \"Make this draft warmer and shorter.\"\r\n\r\n## Procedure\r\n1. Identify the customer need, intended recipient, communication channel, and purpose.\r\n2. Assemble the facts, commitments, applicable policy, and prior communications that\r\n   materially constrain the response.\r\n3. Separate verified outcomes from attempted or proposed remedies and identify answer gaps.\r\n4. Decide whether the response should provide a direct answer, acknowledgment, request for\r\n   information, status update, next steps, or verified resolution.\r\n5. Draft in an appropriate tone, length, and language while excluding unnecessary personal,\r\n   confidential, and internal information.\r\n6. Check policy correctness, answer completeness, promise language, dates, compensation,\r\n   recipients, and privacy.\r\n7. Present the draft with unresolved factual or approval dependencies. Stop before sending.\r\n\r\n## Judgment\r\n- **Correctness:** ground every factual, policy, eligibility, deadline, and remedy claim in\r\n  available evidence.\r\n- **Completeness:** answer each material customer question or identify it as unresolved.\r\n  Empathy does not substitute for an answer.\r\n- **Remedy state:** distinguish attempted, proposed, approved, completed, and verified\r\n  effective remedies.\r\n- **Commitments:** do not promise timelines, compensation, exceptions, or outcomes without\r\n  evidence of the relevant authority and agreement.\r\n- **Privacy:** include only information appropriate for the named recipient and channel.\r\n- **Contradictions:** surface material conflicts in the grounding rather than silently\r\n  selecting the most convenient version.\r\n\r\n## Output\r\n\r\nDeliver two parts: one concise chat summary and one saved primary editable artifact containing the complete customer-only reply draft. The chat summary does not replace the saved artifact. When the user requests an email or CRM draft, use that saved native draft as the primary artifact rather than creating an additional Word file.\r\n\r\n### Chat summary\r\n\r\nIn chat, summarize the reply purpose, recommended message posture, the most important fact or commitment requiring validation, and the next review or send decision. Do not expose internal rationale, permission findings, or policy deliberation in the customer-ready text.\r\n\r\n### Artifact content\r\n\r\n- A reviewable subject or opening and message body.\r\n- Any evidence-dependent caveat that should remain visible.\r\n- Any factual, policy, privacy, or approval item that must be resolved before sending.\r\n\r\nA bounded acknowledgment or information request is useful when a full answer is not yet\r\nsupported. Do not present it as a complete resolution response.\r\n\r\nInclude only the customer-appropriate subject or opening and message body in the draft;\r\nrecipient, channel, purpose, and language may be represented as customer-safe document metadata\r\nwhen useful. Keep the evidence\r\ncutoff, unresolved approvals or fact checks, source references, and validation outcome in the\r\nchat run report or a separately identified internal note when requested; never mix them into the\r\ncustomer copy. Do not claim that the reply was sent.\r\n\r\n### Artifact selection\r\n\r\nChoose one format for the complete customer-only reply draft, respecting the user's requested format:\r\n\r\n- **Word (.docx):** Default for reviewing, editing and copying the subject or opening and full body into the intended channel.\r\n- **Markdown (.md):** When requested or Word creation or saving fails; keep the message customer-only and disclose fallback outside it.\r\n\r\nUse authorized, format-specific workflows. Keep content concise and styling simple. Plan changes together and apply them in as few supported batches as practical. Update authorized existing artifacts without creating duplicates or changing unrelated content. Follow Delivery and control for saving and reporting.\r\n\r\n### Delivery and control\r\n\r\nCreate and save the customer-only reply draft as the primary editable review artifact. When the user specifies an email or CRM draft, create or update it on that surface instead of substituting a separate file.\r\n\r\nVerify the save before reporting success and provide the actual link or location. If saving fails, disclose it outside the customer-only draft and provide clearly labeled unsaved reply text in chat. A saved draft is not a sent reply.\r\n\r\n## Guardrails\r\nCreating and saving the requested file artifact in an authorized location is permitted.\r\nDrafting does not require send approval because it sends no communication. Sending\r\nrequires applicable authorization and explicit approval of the final recipients,\r\nchannel\u002Fthread, subject, and body, plus a recheck — at the moment of sending — of the\r\nmessage's purpose and any applicable contact or communication policy for that recipient\r\nand channel. Operator approval to send is separate from the recipient's own contact\r\npermission: an unresolved required permission blocks sending, but a support reply does not\r\nneed marketing-style opt-in consent by default — apply whichever policy is actually in\r\nforce rather than inventing one. A substantive change after approval requires renewed\r\napproval. A drafted or saved message is not a sent message; when sending is not permitted\r\nor the applicable policy cannot be confirmed, keep the draft available for review rather\r\nthan withholding it.\r\n\r\n## When NOT to Use\r\n- Not for researching an unresolved policy or factual answer; use `answer-research`.\r\n- Not for closing the underlying issue.\r\n- Do not send automatically or imply delivery without confirmation.\r\n\r\n## Required information\r\n- **Baseline:** the customer need and enough issue evidence to support the intended\r\n  message.\r\n- **Broader scope:** fuller history, applicable policy, recipient\u002Fthread details, language\r\n  preference, and communication constraints improve precision without making a persisted\r\n  record a prerequisite.\r\n","# Draft Customer Reply\r\n\r\nDomain: Customer Service.\r\n\r\nFollow this skill's evidence, artifact, privacy, action-control, and outcome-reporting rules below.\r\n\r\n## Evidence and connectivity\r\n\r\nBegin with authorized user-provided material and accessible work sources. Discover optional CRM, knowledge, communication, quality, and workflow capabilities at runtime and use them only to enrich or execute the job; never require a vendor, connector, record identifier, object name, or field name when the minimum semantic evidence is otherwise available.\r\n\r\nIf a capability is unconfigured, unavailable, denied, stale, partial, or unsupported, continue with the supported baseline, disclose the affected scope, and block only the dependent conclusion or action. Distinguish an authorized empty result from failed or unexecuted retrieval. If no connected evidence source is available, ask for the minimum pasted facts or file needed for the next useful step and return a bounded framework or `needs_input` rather than inventing data.\r\nUse supplied material and authorized issue, interaction, policy, knowledge, attachment, and fulfillment evidence needed for the reply. Connected CRM and communication systems are optional enrichment. Separate verified facts, customer statements, approved policy language, proposed commitments, and unknowns before drafting.\r\n\r\n## Data Sources\r\n\r\nUse relevant supplied material or applicable tools and sources you are authorized to access. These are options, not a mandatory checklist. Ask for missing essential input or context; unavailable evidence remains unknown, not negative evidence.\r\n\r\n- Email & Interaction Records for the customer's actual need, prior messages and intended recipient or thread.\r\n- Record Snapshots & Exports for verified issue facts, fulfillment results and remedy state.\r\n- Knowledge & Files for established answers, approved policy language, attachments and applicable communication constraints.\r\n- Supplied Preferences for the customer's language and the requested tone or length, without inventing facts.\r\n\r\nRetain provenance, freshness limits and the existing evidence, privacy and authorization rules.\r\n\r\n## Purpose\r\nProduce a reviewable customer-facing draft that answers the customer's actual need with\r\nthe right policy basis, completeness, tone, language, and privacy treatment.\r\n\r\n## Applicability\r\nApplies when the customer need and enough supporting evidence are known to draft a useful\r\nresponse. The evidence may be a message, issue description, interaction history, verified\r\nanswer, or applicable policy. A saved email record or complete logged history is not\r\nrequired.\r\n\r\nThin evidence can support a bounded acknowledgment or request for information. It cannot\r\nsupport invented facts, promises, compensation, deadlines, or resolution claims.\r\n\r\n## Usage situations\r\n- \"Draft a response to this complaint.\"\r\n- \"Reply to the customer's last message.\"\r\n- \"Write a concise update in the customer's language.\"\r\n- \"Explain the verified resolution and next steps.\"\r\n- \"Make this draft warmer and shorter.\"\r\n\r\n## Procedure\r\n1. Identify the customer need, intended recipient, communication channel, and purpose.\r\n2. Assemble the facts, commitments, applicable policy, and prior communications that\r\n   materially constrain the response.\r\n3. Separate verified outcomes from attempted or proposed remedies and identify answer gaps.\r\n4. Decide whether the response should provide a direct answer, acknowledgment, request for\r\n   information, status update, next steps, or verified resolution.\r\n5. Draft in an appropriate tone, length, and language while excluding unnecessary personal,\r\n   confidential, and internal information.\r\n6. Check policy correctness, answer completeness, promise language, dates, compensation,\r\n   recipients, and privacy.\r\n7. Present the draft with unresolved factual or approval dependencies. Stop before sending.\r\n\r\n## Judgment\r\n- **Correctness:** ground every factual, policy, eligibility, deadline, and remedy claim in\r\n  available evidence.\r\n- **Completeness:** answer each material customer question or identify it as unresolved.\r\n  Empathy does not substitute for an answer.\r\n- **Remedy state:** distinguish attempted, proposed, approved, completed, and verified\r\n  effective remedies.\r\n- **Commitments:** do not promise timelines, compensation, exceptions, or outcomes without\r\n  evidence of the relevant authority and agreement.\r\n- **Privacy:** include only information appropriate for the named recipient and channel.\r\n- **Contradictions:** surface material conflicts in the grounding rather than silently\r\n  selecting the most convenient version.\r\n\r\n## Output\r\n\r\nDeliver two parts: one concise chat summary and one saved primary editable artifact containing the complete customer-only reply draft. The chat summary does not replace the saved artifact. When the user requests an email or CRM draft, use that saved native draft as the primary artifact rather than creating an additional Word file.\r\n\r\n### Chat summary\r\n\r\nIn chat, summarize the reply purpose, recommended message posture, the most important fact or commitment requiring validation, and the next review or send decision. Do not expose internal rationale, permission findings, or policy deliberation in the customer-ready text.\r\n\r\n### Artifact content\r\n\r\n- A reviewable subject or opening and message body.\r\n- Any evidence-dependent caveat that should remain visible.\r\n- Any factual, policy, privacy, or approval item that must be resolved before sending.\r\n\r\nA bounded acknowledgment or information request is useful when a full answer is not yet\r\nsupported. Do not present it as a complete resolution response.\r\n\r\nInclude only the customer-appropriate subject or opening and message body in the draft;\r\nrecipient, channel, purpose, and language may be represented as customer-safe document metadata\r\nwhen useful. Keep the evidence\r\ncutoff, unresolved approvals or fact checks, source references, and validation outcome in the\r\nchat run report or a separately identified internal note when requested; never mix them into the\r\ncustomer copy. Do not claim that the reply was sent.\r\n\r\n### Artifact selection\r\n\r\nChoose one format for the complete customer-only reply draft, respecting the user's requested format:\r\n\r\n- **Word (.docx):** Default for reviewing, editing and copying the subject or opening and full body into the intended channel.\r\n- **Markdown (.md):** When requested or Word creation or saving fails; keep the message customer-only and disclose fallback outside it.\r\n\r\nUse authorized, format-specific workflows. Keep content concise and styling simple. Plan changes together and apply them in as few supported batches as practical. Update authorized existing artifacts without creating duplicates or changing unrelated content. Follow Delivery and control for saving and reporting.\r\n\r\n### Delivery and control\r\n\r\nCreate and save the customer-only reply draft as the primary editable review artifact. When the user specifies an email or CRM draft, create or update it on that surface instead of substituting a separate file.\r\n\r\nVerify the save before reporting success and provide the actual link or location. If saving fails, disclose it outside the customer-only draft and provide clearly labeled unsaved reply text in chat. A saved draft is not a sent reply.\r\n\r\n## Guardrails\r\nCreating and saving the requested file artifact in an authorized location is permitted.\r\nDrafting does not require send approval because it sends no communication. Sending\r\nrequires applicable authorization and explicit approval of the final recipients,\r\nchannel\u002Fthread, subject, and body, plus a recheck — at the moment of sending — of the\r\nmessage's purpose and any applicable contact or communication policy for that recipient\r\nand channel. Operator approval to send is separate from the recipient's own contact\r\npermission: an unresolved required permission blocks sending, but a support reply does not\r\nneed marketing-style opt-in consent by default — apply whichever policy is actually in\r\nforce rather than inventing one. A substantive change after approval requires renewed\r\napproval. A drafted or saved message is not a sent message; when sending is not permitted\r\nor the applicable policy cannot be confirmed, keep the draft available for review rather\r\nthan withholding it.\r\n\r\n## When NOT to Use\r\n- Not for researching an unresolved policy or factual answer; use `answer-research`.\r\n- Not for closing the underlying issue.\r\n- Do not send automatically or imply delivery without confirmation.\r\n\r\n## Required information\r\n- **Baseline:** the customer need and enough issue evidence to support the intended\r\n  message.\r\n- **Broader scope:** fuller history, applicable policy, recipient\u002Fthread details, language\r\n  preference, and communication constraints improve precision without making a persisted\r\n  record a prerequisite.\r\n",{"name":5,"metadata":44,"description":7},{"displayname":45},"Draft Customer Reply","main","c739e95c35d12a999691ab076c3d4c3095bf8192","submissions\u002Fdraft-customer-reply",120,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-13 01:39:10",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add microsoft\u002Fcat-agent-skills --skill draft-customer-reply",{"tool":61,"command":62},"bunx","bunx skills add microsoft\u002Fcat-agent-skills --skill draft-customer-reply",{"tool":64,"command":65},"pnpm","pnpm dlx skills add microsoft\u002Fcat-agent-skills --skill draft-customer-reply","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fdraft-customer-reply\u002FSKILL.md",true,[69,75],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"metadata.json","REFERENCE","参考文档",413,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fdraft-customer-reply\u002Fmetadata.json",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"README.md",1311,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fdraft-customer-reply\u002FREADME.md",[80,104,129,167,185,201],{"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":39},"01M6X3P09R8SJH3QJGMTAA5N90","stakeholder-and-decision-map","Mines customer interactions to identify stakeholders, infer their likely roles and engagement, map the decision process, and highlight who or what may be missing. Use when asked to \"map a deal's buying group\", identify influential or missing stakeholders, \"assess who has gone quiet\", or \"explain how the customer will decide\". Do not use for phased engagement plans, contact sequences, choosing or drafting outreach to the single next contact, seller or team performance reviews, or contacting, scheduling, or changing records.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fstakeholder-and-decision-map\u002FSKILL.md",[],[87,88,89,90,91,20,92,93,94,35,95,96,97,98,99,100,101,102,24,103],"decision","map","decision map","stakeholder and decision map","performance","team","how","decide","next","infer","missing","records","assess","reviews","for","single","sequences",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":39},"01M6X3NRES2XSZQCH015WD4JN6","sales-progress-update","Creates or refreshes a sales progress update for a manager or team about work done, deal movement, pending outcomes, supported forecast position, and help needed. Use when asked to \"create my weekly sales update\", \"refresh my sales progress deck\", \"report my forecast position\", \"where do I stand against my quarter forecast\", or \"catch my manager up on committed deals\". Do NOT use for non-sales project updates, a since-date deal change digest, momentum or blocker analysis, meeting prep, or outreach drafting.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fsales-progress-update\u002FSKILL.md",[],[111,112,113,114,115,116,117,118,92,119,120,121,122,123,124,125,126,127,128,24],"update","sales","progress","sales progress update","change","create","meeting prep","analysis","work","up","done","digest","project","my","updates","manager","weekly","catch",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":148,"publishedAt":39},"01M6X3MSDTB1E5H6DQAFAY41YP","submission-assemble","Put the checked CSR or 510(k) sections together in template order with a reviewer-facing open-items register, as a draft package for human sign-off. Use when the user asks \"assemble the CSR draft\", \"put the module together for review\", \"build the review package with the open items on top\", \"compile the 510(k) sections in order\" or \"package this up for the submission lead\". Do NOT use for assembling an unchecked draft - use consistency-check instead. Do NOT use for loading protocol, SAP or TLF sources - use source-ingest instead. Do NOT use for compiling general documents or slide decks - use the built-in docx or pptx skill instead. Do NOT use for filing or submitting to a regulator - use the sponsor's validated gateway, operated by a human, instead. Guardrail: draft for human approval only (L1); status is draft_clean or draft_open_items, never submitted.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Freg-submission-authoring\u002Fsubmission-assemble\u002FSKILL.md",[135,140,143],{"categoryNo":136,"categoryName":137,"taxonomyType":138,"taxonomyTypeDesc":139},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":141,"categoryName":142,"taxonomyType":138,"taxonomyTypeDesc":139},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":144,"categoryName":145,"taxonomyType":146,"taxonomyTypeDesc":147},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[149,150,151,152,153,154,155,156,157,158,159,160,120,161,162,163,164,165,166,24],"assemble","submission","submission assemble","docx","pptx","writing","documents","healthcare","open","reviewer","never","only","clean","guardrail","slide decks","sources","filing","loading",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":39},"01M6X3MM9TVWDQ716QGNV4DS25","source-ingest","Pull every number, date and population definition out of a study's protocol, SAP, TLF tables, investigator brochure and prior approved text into one cited fact map, keyed per config\u002Ffield-dictionary.json, before any CSR or 510(k) section is written. Use when the user asks \"here's the locked TLF set and SAP, set up the CSR\", \"load the protocol and tables before we start drafting\", \"what figures do we have from the database lock?\", \"pull the disposition counts out of Table 14.1.1\" or \"ingest the IB for the 510(k)\". Do NOT use for drafting or assembling submission sections - use section-draft or submission-assemble instead. Do NOT use for reconciling a patient's medications - use the discharge-care-transition plugin instead. Guardrail: reads and cites sources only; never estimates, rounds or invents a fact.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Freg-submission-authoring\u002Fsource-ingest\u002FSKILL.md",[],[174,175,176,177,178,118,156,179,159,160,120,88,180,162,164,181,182,183,184,24],"source ingest","ingest","source","database","SET","text","patient","number","lock","definition","transition",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":192,"publishedAt":39},"01M6X3M7ZH5ZNEHP56BQ74HAJR","section-plan","Work out which sections a CSR or 510(k) requires, from the templates in config, check each one against the cited fact map, and name what is missing before a word is drafted. Use when the user asks \"what do we still need before we can draft the CSR?\", \"which sections are ready to start?\", \"what's blocking the performance data section?\", \"do we have everything for the synopsis?\" or \"map our tables to the E3 structure\". Do NOT use for writing section language - use section-draft instead. Do NOT use for cross-checking a finished draft - use consistency-check instead. Do NOT use for outlining general Word documents or business reports - use the built-in docx skill instead. Only structures with a template in config are supported. Guardrail: plans only; never marks a section ready on a missing fact and never invents a structure.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Freg-submission-authoring\u002Fsection-plan\u002FSKILL.md",[191],{"categoryNo":136,"categoryName":137,"taxonomyType":138,"taxonomyTypeDesc":139},[193,194,195,152,154,91,155,118,156,119,159,160,196,197,198,88,162,199,200,24],"plan","section","section plan","ready","reports","structure","word documents","which",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":207,"publishedAt":39},"01M6X3M0V1MJNCR653ES9XGVMS","section-draft","Write or revise the language for one planned CSR or 510(k) section - synopsis, efficacy, safety, discussion, device description - using only figures already in the cited fact map, each with its TLF or SAP citation. Use when the user asks \"draft the Synopsis from our locked tables\", \"write up safety from Table 14.3.1\", \"give me a first pass at the discussion\", \"draft the device description for the 510(k)\" or \"tighten the wording of the Discussion section\". Do NOT use for supplying a number not already in source_facts - use source-ingest instead. Do NOT use for verifying a draft's figures - use consistency-check instead. Do NOT use for appeal letters, clinical notes or discharge summaries - use the matching HLS plugin instead. Guardrail: drafts for human approval only (L1); never asserts an unsourced number or harmonises two figures.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Freg-submission-authoring\u002Fsection-draft\u002FSKILL.md",[],[22,194,208,154,209,156,210,159,160,120,211,88,212,213,214,162,215,181,216,24],"section draft","notes","write","me","human","life","clinical","drafts","at"]