[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6X2MS2WYYC6KATSXRCFAQ2N":3,"skill-same:01M6X2MS2WYYC6KATSXRCFAQ2N":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},"01M6X2MS2WYYC6KATSXRCFAQ2N","deal-catchup",null,"Summarizes what changed and why across a scoped deal set, separating genuine customer movement from record housekeeping. Use to report what changed and why across a scoped set of deals since a stated baseline, such as \"which deals slipped\", \"what moved on my top deals\", or \"what changed while I was out\". Needs a defined scope and current deal evidence; a baseline improves the comparison, but a current-state result is available without one. DO NOT use for ranking what to work on next or a single deal's full standing review.","microsoft\u002Fcat-agent-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69A1AHE1MABT7GVP5143M5Z",103,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fdeal-catchup\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"deal catchup","catchup","deal","scope","result","catch","my","which","top","ranking","review","full","across","next","up","work","work on","why","SET","customer","2026-11-10 10:12:30",false,"---\r\nname: deal-catchup\r\ndescription: Summarizes what changed and why across a scoped deal set, separating genuine customer movement from record housekeeping. Use to report what changed and why across a scoped set of deals since a stated baseline, such as \"which deals slipped\", \"what moved on my top deals\", or \"what changed while I was out\". Needs a defined scope and current deal evidence; a baseline improves the comparison, but a current-state result is available without one. DO NOT use for ranking what to work on next or a single deal's full standing review.\r\nmetadata:\r\n  displayname: Deal Catch-up\r\n---\r\n\r\n# Deal Catch-up\r\n\r\nFollow this skill's evidence, artifact, privacy, action-control, and outcome-reporting rules below.\r\n\r\nDomain: Sales.\r\n## Evidence and connectivity\r\n\r\nBegin with authorized user-provided material and accessible work sources. Discover optional CRM 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 to begin when the minimum semantic evidence is otherwise available.\r\n\r\nIf CRM 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\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- Record Snapshots & Exports for scoped membership, dated baselines, current state and authoritative change events.\r\n- Email for substantive customer explanations of timing, value or decision changes.\r\n- Meeting Transcripts & Notes for dated commitments and the reasons behind material movement.\r\n- Internal Messaging for evidenced alignment needs, dependencies and seller-reported context.\r\n- Knowledge & Files for prior reviews and proposals that establish a comparable baseline.\r\n\r\nRetain provenance, freshness limits and the existing evidence, privacy and authorization rules.\r\n\r\n## Purpose\r\nReport what changed on a scoped set of deals since a stated point in time, distinguish genuine\r\ncustomer or deal movement from record housekeeping, and attach a substantiated reason to each\r\nmaterial change.\r\n\r\n## Applicability\r\nUse when an account or a scoped set of deals is identifiable from the request, accessible work\r\ncontext, or supplied material. Establish the requested comparison window and any available\r\nbaseline. Current structured deal state is optional enrichment, not a prerequisite. Two related\r\nasks share this procedure:\r\n- which deals in scope slipped, and why;\r\n- what changed across a bounded top set of deals (by value or another stated basis) since a\r\n  point in time.\r\n\r\nA missing baseline or authoritative opportunity snapshot still supports a result: reconstruct\r\nthe dated visible-evidence chronology, label current structured state and period-over-period\r\nmovement unknown where unsupported, and do not invent a prior state. Disambiguate an opportunity\r\nonly when several plausible deals would materially change the result.\r\n\r\n## Usage situations\r\n- \"Which of my deals slipped this week, and why?\"\r\n- \"What changed on my top deals since last Monday?\"\r\n- \"What moved on this account's deals while I was out?\"\r\n- Non-trigger: \"Which deals should I work next\" (ranking — use `pipeline-prioritizer`); \"give me\r\n  the full picture on this one deal\" (a single deal's standing review).\r\n\r\n## Procedure\r\n1. Establish the account or deal scope and the baseline or window from the ask. Discover the\r\n   account from available context before asking \"Which account?\" Resolve a relative period\r\n   (\"last week\", \"since I was out\") to a concrete date\r\n   range with timezone and state it. If the period is ambiguous, ask when material or state\r\n   a provisional interpretation. Do not invent a prior state when a baseline is unavailable.\r\n   For a bounded top set, name the selection basis and presentation cap; honor a supplied\r\n   cap, otherwise state a practical cap for this result, not a universal priority threshold.\r\n2. Use available current state for each in-scope deal: name, value, stage\u002Fstatus, close date,\r\n   last record-modification time, owner, account, and stakeholders. Mark missing fields unknown.\r\n3. Establish what changed:\r\n   - Prefer a genuinely dated, authoritative history of the record when one exists.\r\n   - Where a computed or narrative \"what changed since\" summary is available, treat it as a\r\n     lead pointing at what to check, not a verified fact — it is generated, not a sourced\r\n     quote.\r\n   - Compare dated prior and current evidence, or use an authoritative dated change event.\r\n     A modification timestamp establishes record recency only, not a specific deal change,\r\n     direction, magnitude, or cause.\r\n   - Report an in-window slip only when dated evidence places a postponement or a newly\r\n     crossed close deadline while the deal remained open inside that window. Already\r\n     overdue before the baseline is a separate current overdue status, not a new slip.\r\n     Apply the same timing test to stage regression, likelihood\u002Fvalue decline, and won\u002Flost\r\n     transitions. If evidence brackets only a broader interval, state it and leave change\r\n     inside the requested window unknown.\r\n4. Establish why each material change happened from actual evidence — supplied notes, messages,\r\n   meeting records, or other communication — read at the content level, not inferred from a\r\n   status field alone. Attribute the reason to its source and, where known, the person. A\r\n   change with no available evidence for its reason is still reported, with the reason marked\r\n   unknown; an unconfirmed reason on one deal does not block reporting the rest of the digest.\r\n5. Compare a source-attributed signal with established current record state before flagging\r\n   it as not reflected in the record. Without that comparison, label it an unverified update\r\n   candidate. Do not apply an update.\r\n6. Compose per deal: what changed, the substantiated (or marked-unknown) reason, any\r\n   record-update flag, and a suggested next action. When the evidence surfaces an\r\n   internal alignment need or dependency that changes the next step, name it as an\r\n   optional field distinguishing a known dependency, a decision still needed, and a\r\n   suggested seller action — never a guessed colleague or area of expertise. Order by\r\n   the stated impact basis (slip severity, value, or another stated criterion).\r\n\r\n## Judgment\r\n- A record-modification timestamp establishes recency only. Use dated change evidence to\r\n  establish movement and substantive evidence to establish its cause.\r\n- A generated \"what changed\" narrative is a lead to verify, not a verified source fact; cite\r\n  the actual evidence, not the narrative, for the reason.\r\n- An absent reason is a per-deal gap, not grounds to withhold the rest of the digest. Report\r\n  the change and mark the reason unknown.\r\n- Do not claim \"no changes\" or \"all signals reviewed\" unless the evaluated coverage actually\r\n  supports it — state what was checked.\r\n- A missing baseline yields a current-state, dated observation, with movement explicitly\r\n  marked unknown — never a fabricated prior state or an invented \"no change\" result.\r\n- State the selection basis, presentation cap, and comparison period used. A cap controls\r\n  presentation, not business importance; a different cap, named list, or window is valid.\r\n- A stated \"top\" set reflects the deals actually evaluated. When the underlying evidence pull\r\n  is itself bounded or paged, say so — a partial read is not the genuine top of the full book.\r\n\r\n## Output\r\n\r\nDeliver both a concise chat summary and one saved primary editable artifact, following the\r\nsections below. The artifact must explain what changed and why across a scoped deal set, marking unsupported movement or\r\ncauses unknown.\r\n\r\n### Chat summary\r\n\r\nIn chat, summarize the largest evidenced movement, its best-supported reason, the most material\r\nregression or unknown, and the next action. State the examined scope and window so the summary\r\ncannot be mistaken for a complete portfolio view.\r\n\r\n### Artifact content\r\n\r\nIdentify the ownership or membership evidence that establishes the requested deal set. Separate verified members from unresolved candidates; correspondence alone does not establish ownership. Preserve supported observations for candidates without including them in unqualified portfolio claims or asserting movement outside the verified baseline and period.\r\n\r\nState scope, requested window, available baseline (or its absence), selection basis\u002Fcap,\r\nevaluated deal count, and coverage. Then, per deal: verified movement and its dates, or\r\ncurrent state with change unknown; the substantiated reason (or \"unconfirmed\" with what\r\nwas checked); any record-update flag or unverified candidate; an optional internal\r\ndependency field when the evidence supports one; and a proposed next action. Keep\r\nexisting overdue status separate from verified in-window slips.\r\n\r\n## Artifact selection\r\n\r\nChoose one format for the complete internal deal catch-up, respecting the user's requested format:\r\n\r\n- **Word (.docx):** Default for explaining what changed, why and what to do next.\r\n- **Excel (.xlsx):** Instead for filtering a scoped multi-deal chronology or action handoff, with takeaways and causal explanations retained.\r\n- **Markdown (.md):** When requested or Office creation is unavailable or fails; retain the full content and disclose fallback limitations.\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\nVerify the save before reporting success and provide the actual link or location. If saving fails, disclose it and provide clearly labeled unsaved catch-up in chat.\r\n\r\n## Guardrails\r\nThis report is read-only except for creating and saving the requested file artifact in an\r\nauthorized location. It does not update records, send messages, or take any other action on a\r\ncustomer's or seller's behalf. A record-update flag is a proposal for the user to apply, not an\r\napplied change.\r\n\r\n## When NOT to Use\r\n- Not for choosing which deals to work next; use `pipeline-prioritizer`.\r\n- Not for one deal's complete standing review; that requires a separate review procedure outside this catalog.\r\n- Do not report a change as confirmed from a record-modification timestamp alone, and do not\r\n  claim complete coverage from a partial or capped evidence pull.\r\n\r\n## Required information\r\n- **Minimum:** an identifiable account or deal scope. Accessible correspondence, meetings,\r\n  notes, proposals, or supplied material can support a visible-evidence reconstruction without\r\n  a current CRM opportunity snapshot.\r\n- **Structured-state enrichment:** current opportunity evidence improves current-state and\r\n  field-level comparisons but is not required for the baseline catch-up.\r\n- **Comparison evidence:** a resolved comparison period plus dated prior\u002Fcurrent evidence\r\n  or a dated change event establishes movement within that period. Without it, report\r\n  current state and dated observations, with change unknown.\r\n- **Reason evidence:** substantive notes, messages, meeting records, or other evidence.\r\n  Its absence leaves the reason unknown for that deal, not the whole result unavailable.\r\n- **Missing-input question:** \"Which account or deal set should I catch up on?\"\r\n","# Deal Catch-up\r\n\r\nFollow this skill's evidence, artifact, privacy, action-control, and outcome-reporting rules below.\r\n\r\nDomain: Sales.\r\n## Evidence and connectivity\r\n\r\nBegin with authorized user-provided material and accessible work sources. Discover optional CRM 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 to begin when the minimum semantic evidence is otherwise available.\r\n\r\nIf CRM 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\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- Record Snapshots & Exports for scoped membership, dated baselines, current state and authoritative change events.\r\n- Email for substantive customer explanations of timing, value or decision changes.\r\n- Meeting Transcripts & Notes for dated commitments and the reasons behind material movement.\r\n- Internal Messaging for evidenced alignment needs, dependencies and seller-reported context.\r\n- Knowledge & Files for prior reviews and proposals that establish a comparable baseline.\r\n\r\nRetain provenance, freshness limits and the existing evidence, privacy and authorization rules.\r\n\r\n## Purpose\r\nReport what changed on a scoped set of deals since a stated point in time, distinguish genuine\r\ncustomer or deal movement from record housekeeping, and attach a substantiated reason to each\r\nmaterial change.\r\n\r\n## Applicability\r\nUse when an account or a scoped set of deals is identifiable from the request, accessible work\r\ncontext, or supplied material. Establish the requested comparison window and any available\r\nbaseline. Current structured deal state is optional enrichment, not a prerequisite. Two related\r\nasks share this procedure:\r\n- which deals in scope slipped, and why;\r\n- what changed across a bounded top set of deals (by value or another stated basis) since a\r\n  point in time.\r\n\r\nA missing baseline or authoritative opportunity snapshot still supports a result: reconstruct\r\nthe dated visible-evidence chronology, label current structured state and period-over-period\r\nmovement unknown where unsupported, and do not invent a prior state. Disambiguate an opportunity\r\nonly when several plausible deals would materially change the result.\r\n\r\n## Usage situations\r\n- \"Which of my deals slipped this week, and why?\"\r\n- \"What changed on my top deals since last Monday?\"\r\n- \"What moved on this account's deals while I was out?\"\r\n- Non-trigger: \"Which deals should I work next\" (ranking — use `pipeline-prioritizer`); \"give me\r\n  the full picture on this one deal\" (a single deal's standing review).\r\n\r\n## Procedure\r\n1. Establish the account or deal scope and the baseline or window from the ask. Discover the\r\n   account from available context before asking \"Which account?\" Resolve a relative period\r\n   (\"last week\", \"since I was out\") to a concrete date\r\n   range with timezone and state it. If the period is ambiguous, ask when material or state\r\n   a provisional interpretation. Do not invent a prior state when a baseline is unavailable.\r\n   For a bounded top set, name the selection basis and presentation cap; honor a supplied\r\n   cap, otherwise state a practical cap for this result, not a universal priority threshold.\r\n2. Use available current state for each in-scope deal: name, value, stage\u002Fstatus, close date,\r\n   last record-modification time, owner, account, and stakeholders. Mark missing fields unknown.\r\n3. Establish what changed:\r\n   - Prefer a genuinely dated, authoritative history of the record when one exists.\r\n   - Where a computed or narrative \"what changed since\" summary is available, treat it as a\r\n     lead pointing at what to check, not a verified fact — it is generated, not a sourced\r\n     quote.\r\n   - Compare dated prior and current evidence, or use an authoritative dated change event.\r\n     A modification timestamp establishes record recency only, not a specific deal change,\r\n     direction, magnitude, or cause.\r\n   - Report an in-window slip only when dated evidence places a postponement or a newly\r\n     crossed close deadline while the deal remained open inside that window. Already\r\n     overdue before the baseline is a separate current overdue status, not a new slip.\r\n     Apply the same timing test to stage regression, likelihood\u002Fvalue decline, and won\u002Flost\r\n     transitions. If evidence brackets only a broader interval, state it and leave change\r\n     inside the requested window unknown.\r\n4. Establish why each material change happened from actual evidence — supplied notes, messages,\r\n   meeting records, or other communication — read at the content level, not inferred from a\r\n   status field alone. Attribute the reason to its source and, where known, the person. A\r\n   change with no available evidence for its reason is still reported, with the reason marked\r\n   unknown; an unconfirmed reason on one deal does not block reporting the rest of the digest.\r\n5. Compare a source-attributed signal with established current record state before flagging\r\n   it as not reflected in the record. Without that comparison, label it an unverified update\r\n   candidate. Do not apply an update.\r\n6. Compose per deal: what changed, the substantiated (or marked-unknown) reason, any\r\n   record-update flag, and a suggested next action. When the evidence surfaces an\r\n   internal alignment need or dependency that changes the next step, name it as an\r\n   optional field distinguishing a known dependency, a decision still needed, and a\r\n   suggested seller action — never a guessed colleague or area of expertise. Order by\r\n   the stated impact basis (slip severity, value, or another stated criterion).\r\n\r\n## Judgment\r\n- A record-modification timestamp establishes recency only. Use dated change evidence to\r\n  establish movement and substantive evidence to establish its cause.\r\n- A generated \"what changed\" narrative is a lead to verify, not a verified source fact; cite\r\n  the actual evidence, not the narrative, for the reason.\r\n- An absent reason is a per-deal gap, not grounds to withhold the rest of the digest. Report\r\n  the change and mark the reason unknown.\r\n- Do not claim \"no changes\" or \"all signals reviewed\" unless the evaluated coverage actually\r\n  supports it — state what was checked.\r\n- A missing baseline yields a current-state, dated observation, with movement explicitly\r\n  marked unknown — never a fabricated prior state or an invented \"no change\" result.\r\n- State the selection basis, presentation cap, and comparison period used. A cap controls\r\n  presentation, not business importance; a different cap, named list, or window is valid.\r\n- A stated \"top\" set reflects the deals actually evaluated. When the underlying evidence pull\r\n  is itself bounded or paged, say so — a partial read is not the genuine top of the full book.\r\n\r\n## Output\r\n\r\nDeliver both a concise chat summary and one saved primary editable artifact, following the\r\nsections below. The artifact must explain what changed and why across a scoped deal set, marking unsupported movement or\r\ncauses unknown.\r\n\r\n### Chat summary\r\n\r\nIn chat, summarize the largest evidenced movement, its best-supported reason, the most material\r\nregression or unknown, and the next action. State the examined scope and window so the summary\r\ncannot be mistaken for a complete portfolio view.\r\n\r\n### Artifact content\r\n\r\nIdentify the ownership or membership evidence that establishes the requested deal set. Separate verified members from unresolved candidates; correspondence alone does not establish ownership. Preserve supported observations for candidates without including them in unqualified portfolio claims or asserting movement outside the verified baseline and period.\r\n\r\nState scope, requested window, available baseline (or its absence), selection basis\u002Fcap,\r\nevaluated deal count, and coverage. Then, per deal: verified movement and its dates, or\r\ncurrent state with change unknown; the substantiated reason (or \"unconfirmed\" with what\r\nwas checked); any record-update flag or unverified candidate; an optional internal\r\ndependency field when the evidence supports one; and a proposed next action. Keep\r\nexisting overdue status separate from verified in-window slips.\r\n\r\n## Artifact selection\r\n\r\nChoose one format for the complete internal deal catch-up, respecting the user's requested format:\r\n\r\n- **Word (.docx):** Default for explaining what changed, why and what to do next.\r\n- **Excel (.xlsx):** Instead for filtering a scoped multi-deal chronology or action handoff, with takeaways and causal explanations retained.\r\n- **Markdown (.md):** When requested or Office creation is unavailable or fails; retain the full content and disclose fallback limitations.\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\nVerify the save before reporting success and provide the actual link or location. If saving fails, disclose it and provide clearly labeled unsaved catch-up in chat.\r\n\r\n## Guardrails\r\nThis report is read-only except for creating and saving the requested file artifact in an\r\nauthorized location. It does not update records, send messages, or take any other action on a\r\ncustomer's or seller's behalf. A record-update flag is a proposal for the user to apply, not an\r\napplied change.\r\n\r\n## When NOT to Use\r\n- Not for choosing which deals to work next; use `pipeline-prioritizer`.\r\n- Not for one deal's complete standing review; that requires a separate review procedure outside this catalog.\r\n- Do not report a change as confirmed from a record-modification timestamp alone, and do not\r\n  claim complete coverage from a partial or capped evidence pull.\r\n\r\n## Required information\r\n- **Minimum:** an identifiable account or deal scope. Accessible correspondence, meetings,\r\n  notes, proposals, or supplied material can support a visible-evidence reconstruction without\r\n  a current CRM opportunity snapshot.\r\n- **Structured-state enrichment:** current opportunity evidence improves current-state and\r\n  field-level comparisons but is not required for the baseline catch-up.\r\n- **Comparison evidence:** a resolved comparison period plus dated prior\u002Fcurrent evidence\r\n  or a dated change event establishes movement within that period. Without it, report\r\n  current state and dated observations, with change unknown.\r\n- **Reason evidence:** substantive notes, messages, meeting records, or other evidence.\r\n  Its absence leaves the reason unknown for that deal, not the whole result unavailable.\r\n- **Missing-input question:** \"Which account or deal set should I catch up on?\"\r\n",{"name":5,"metadata":44,"description":7},{"displayname":45},"Deal Catch-up","main","c739e95c35d12a999691ab076c3d4c3095bf8192","submissions\u002Fdeal-catchup",118,"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-07 09:09:13",{"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 deal-catchup",{"tool":61,"command":62},"bunx","bunx skills add microsoft\u002Fcat-agent-skills --skill deal-catchup",{"tool":64,"command":65},"pnpm","pnpm dlx skills add microsoft\u002Fcat-agent-skills --skill deal-catchup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fdeal-catchup\u002FSKILL.md",true,[69,75],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"metadata.json","REFERENCE","参考文档",386,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fdeal-catchup\u002Fmetadata.json",{"path":76,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":77,"sourceHtmlUrl":78},"README.md",1248,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fdeal-catchup\u002FREADME.md",[80,105,126,164,181,196],{"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,38,92,93,94,95,32,96,97,98,99,100,101,102,103,104],"decision","map","decision map","stakeholder and decision map","performance","team","how","decide","do","infer","missing","records","assess","reviews","for","single","when","sequences",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"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",[],[112,113,114,115,116,117,118,119,92,34,33,120,121,122,25,123,124,125,24,103],"update","sales","progress","sales progress update","change","create","meeting prep","analysis","done","digest","project","updates","manager","weekly",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":145,"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",[132,137,140],{"categoryNo":133,"categoryName":134,"taxonomyType":135,"taxonomyTypeDesc":136},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":138,"categoryName":139,"taxonomyType":135,"taxonomyTypeDesc":136},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":141,"categoryName":142,"taxonomyType":143,"taxonomyTypeDesc":144},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[146,147,148,149,150,151,152,153,154,155,156,157,33,158,159,160,161,162,163,103],"assemble","submission","submission assemble","docx","pptx","writing","documents","healthcare","open","reviewer","never","only","clean","guardrail","slide decks","sources","filing","loading",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":170,"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",[],[171,172,173,174,37,119,153,175,156,157,33,88,176,159,161,177,178,179,180,103],"source ingest","ingest","source","database","text","patient","number","lock","definition","transition",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":188,"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",[187],{"categoryNo":133,"categoryName":134,"taxonomyType":135,"taxonomyTypeDesc":136},[189,190,191,149,151,91,152,119,153,34,156,157,192,193,194,88,159,195,26,103],"plan","section","section plan","ready","reports","structure","word documents",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":202,"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",[],[203,190,204,151,205,153,206,156,157,33,207,88,208,209,210,159,211,177,212,103],"draft","section draft","notes","write","me","human","life","clinical","drafts","at"]