[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69ADV9BTKPCEC4WGGESDBG8":3,"skill-same:01M69ADV9BTKPCEC4WGGESDBG8":75},{"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":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":6,"ownerHtmlUrl":39,"ownerBlogUrl":40,"ownerDescription":41,"updatedAt":42,"install":43,"resources":56},"01M69ADV9BTKPCEC4WGGESDBG8","whiteboard-to-infographic",null,"Convert a hand-drawn whiteboard photo (or sketched process\u002Fdiagram) from a discovery or working session into a polished, client-ready infographic as an editable PowerPoint slide (.pptx). Use this whenever someone uploads or references a photo of a whiteboard, a hand sketch of a process or system, or session-capture notes and wants it \"cleaned up\", \"made presentable\", \"turned into a diagram\u002Finfographic\", \"converted for the client\", or similar — even if they don't say the word \"infographic\". Covers two layout archetypes — linear process flows (left-to-right step rails) and network\u002Ftopology maps (locations, systems, or actors connected by labeled flows). Built for consulting\u002FERP discovery capture but works for any whiteboard-to-deliverable conversion. Do NOT use for charts\u002Fgraphs from numeric data, for editing an existing polished design, or for generating diagrams with no source sketch.","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\u002Fwhiteboard-to-infographic\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",[24,25,26,27,28],"whiteboard to infographic","pptx","design","notes","diagram","2026-11-10 10:12:30",false,"---\nname: whiteboard-to-infographic\ndescription: >-\n  Convert a hand-drawn whiteboard photo (or sketched process\u002Fdiagram) from a\n  discovery or working session into a polished, client-ready infographic as an\n  editable PowerPoint slide (.pptx). Use this whenever someone uploads or\n  references a photo of a whiteboard, a hand sketch of a process or system, or\n  session-capture notes and wants it \"cleaned up\", \"made presentable\", \"turned\n  into a diagram\u002Finfographic\", \"converted for the client\", or similar — even if\n  they don't say the word \"infographic\". Covers two layout archetypes — linear\n  process flows (left-to-right step rails) and network\u002Ftopology maps (locations,\n  systems, or actors connected by labeled flows). Built for consulting\u002FERP\n  discovery capture but works for any whiteboard-to-deliverable conversion. Do\n  NOT use for charts\u002Fgraphs from numeric data, for editing an existing polished\n  design, or for generating diagrams with no source sketch.\n---\n\n# Whiteboard to Infographic\n\nTurn a messy hand-drawn capture into a clean, branded one-page infographic —\ndelivered as a single **editable PowerPoint slide** — that a consultant can put\nin front of a client. The hard, non-delegable work is reading the handwriting\ncorrectly and choosing the right structure; the styling and layout are codified\nhere so every output looks consistent.\n\n## The discipline (do this in order — do not skip ahead to styling)\n\nThis is structure-first. Producing a polished deliverable from a misread sketch\nis the main failure mode, so confirm interpretation **before** building.\n\n1. **Read the source carefully.** The photo is the source of truth. Zoom and\n   crop aggressively — examine the image, then crop it into regions and\n   re-examine at 2–3x so the handwriting is legible. Transcribe every box,\n   label, arrow, annotation, and margin note. Do not silently drop anything you\n   can't read — list it as a question.\n\n2. **Confirm interpretation and lock structure.** Before building the slide,\n   send the user a compact transcription: the nodes\u002Fsteps, the\n   connections\u002Fflows, and any side notes or requirements. Explicitly flag:\n   ambiguous words, unexpanded acronyms, and anything you're inferring. Ask the\n   questions that change the build (see \"Questions to ask\"). Wait for\n   confirmation. Build only what's on the board — never invent steps, fields, or\n   connections to make it look complete. If a relationship isn't drawn, don't\n   draw it.\n\n3. **Get the color palette.** The palette is client-specific and is NOT baked\n   into this skill. If the user gave colors in the prompt or context, use them.\n   Otherwise, ask before building. You need hex values for these roles:\n   - **ink** — primary structure, dark text, node borders (e.g. a deep navy)\n   - **secondary** — sub-heads, connectors, region boundaries (e.g. steel blue)\n   - **accent** — sequence numbers, bullets, flags, emphasis (e.g. a signal red)\n   - **card** — light fill for callout cards \u002F cluster fills (e.g. pale blue-gray)\n   - **accent-tint** — light wash behind accent-flagged items (e.g. pale red)\n   Derive sensible text tints (e.g. a muted slate for sub-captions) from these.\n   Offer to suggest a palette if the user has no preference, but don't assume.\n\n4. **Choose the archetype** (state your choice and why):\n   - **Process rail** — the sketch is a sequence\u002Fflow with a clear order\n     (step 1 → step 2 → …). Read `references\u002Fprocess-rail.md`.\n   - **Network map** — the sketch is locations\u002Fsystems\u002Factors connected by\n     flows, with no single linear order (a topology). Read\n     `references\u002Fnetwork-map.md`.\n   If it's genuinely both, lead with the dominant reading and ask.\n\n5. **Build, verify, iterate.** Build the slide with `python-pptx` per the chosen\n   archetype's reference. The layout is deterministic — **code decides every\n   coordinate** — so verify structurally rather than by eye: every step\u002Fnode\n   present, columns\u002Fnodes evenly spaced, no shape overlapping another, every\n   label inside its box, drop-lines landing on their cards, edges approaching\n   nodes straight-on and not crossing through them. If your runtime can\n   rasterize the slide, optionally do a visual critique pass; if it can't, lean\n   entirely on the computed geometry. Fix in code and rebuild. Faithfulness \n   beats polish — never add a step, field, or connection that wasn't on the \n   board.\n\n## Building the slide (native python-pptx)\n\nBuild the infographic as a **single editable slide** with `python-pptx`, drawn\nnatively as shapes — no HTML, no image rendering, no external render step. It\nruns inside the agent's Python container and returns a `.pptx` the client can\nopen and edit.\n\nThe layout is **deterministic — code decides every coordinate.** Design on a\nfixed 1600×1000 grid mapped to a 13.333in slide (see each reference for the\n`PX()` scale helper), and compute every position from the step\u002Fnode count and\nthe canvas so the slide is correct by construction. Use the house-style system\nfonts (`Arial Narrow` for condensed display, `Arial` for body) so nothing\ndepends on font downloads. Turn off the default autoshape shadow\n(`shape.shadow.inherit = False`) for the flat house look. Save the deck and\nreturn the single `.pptx` as the deliverable — no PNG\u002FPDF\u002FHTML side-artifacts.\n\n**Revisions: never reuse a filename.** When the user asks for changes to an\ninfographic you have already delivered, build the revision as a **new file with\na new name** — `infographic-v1.pptx`, `infographic-v2.pptx`, `infographic-v3.pptx`,\nand so on — incrementing on every subsequent revision for the life of the\nconversation. Do not overwrite, re-save, or re-deliver an existing filename: a\nreused name can prevent the updated file from reaching the user, who then\nreceives the earlier version or no file at all. One revision, one new filename,\nevery time.\n\n## Conventions (shared by both archetypes)\n\nThese are the house style. Keep them consistent across a client engagement.\n\n- **Header band**: condensed uppercase title + a thin small-caps subtitle, a\n  full-width accent rule under it, and an optional right-aligned scope\u002Fcontext\n  note. A short eyebrow label (e.g. \"THE PROCESS\", \"SUPPLY NETWORK\") sits above\n  each major band.\n- **Accent flags** encode meaning — don't decorate with them:\n  - A solid **accent \"GAP\" pill** marks a gap between the standard system and the\n    client's process (a fit\u002Fgap item). Use only where the user confirms a gap.\n  - A hollow **\"need details\" tag** marks an open item to define in follow-up.\n  - Include a one-line legend explaining any flag you use.\n- **Faithfulness**: behaviors\u002Fnotes with no home in the visual go in a list, not\n  invented shapes. Keep the client's exact terms and acronyms; don't expand or\n  rename acronyms the client already knows unless asked.\n- **Restraint**: spend boldness on one signature device (the numbered chevron\n  rail, or the region cluster), keep everything else quiet. Whitespace where the\n  source is sparse is honest — don't pad it with invented detail.\n\n## Questions to ask before building\n\nAsk only the ones that actually change the build; don't interrogate.\n- Unreadable words \u002F unexpanded acronyms (transcribe what you can, ask the rest).\n- Archetype if ambiguous (rail vs. map).\n- For a rail: is there a meaningful sequence number\u002Fpriority on any step? What\n  goes in the bottom band — principles, requirements, or nothing?\n- For a map: which connections must be explicit vs. summarized in a legend;\n  what each node\u002Fedge label means; does anything apply across all nodes.\n- Whether a \"detailed\" companion version is wanted (dense capture of every\n  margin note) in addition to a clean executive version.\n- The color palette, if not already provided.\n\n## References\n\n- `references\u002Fprocess-rail.md` — linear flow archetype: deterministic banded\n  layout (header, numbered chevron rail with drop-lines, callout cards,\n  principles\u002Frequirements bottom band), as a `python-pptx` skeleton with color\n  placeholders.\n- `references\u002Fnetwork-map.md` — topology archetype: node\u002Fedge\u002Fcluster helpers\n  (labeled edges with arrowheads, dashed region clusters, edge-label chips, flow\n  legend, requirements band), as a `python-pptx` skeleton with color\n  placeholders.","# Whiteboard to Infographic\n\nTurn a messy hand-drawn capture into a clean, branded one-page infographic —\ndelivered as a single **editable PowerPoint slide** — that a consultant can put\nin front of a client. The hard, non-delegable work is reading the handwriting\ncorrectly and choosing the right structure; the styling and layout are codified\nhere so every output looks consistent.\n\n## The discipline (do this in order — do not skip ahead to styling)\n\nThis is structure-first. Producing a polished deliverable from a misread sketch\nis the main failure mode, so confirm interpretation **before** building.\n\n1. **Read the source carefully.** The photo is the source of truth. Zoom and\n   crop aggressively — examine the image, then crop it into regions and\n   re-examine at 2–3x so the handwriting is legible. Transcribe every box,\n   label, arrow, annotation, and margin note. Do not silently drop anything you\n   can't read — list it as a question.\n\n2. **Confirm interpretation and lock structure.** Before building the slide,\n   send the user a compact transcription: the nodes\u002Fsteps, the\n   connections\u002Fflows, and any side notes or requirements. Explicitly flag:\n   ambiguous words, unexpanded acronyms, and anything you're inferring. Ask the\n   questions that change the build (see \"Questions to ask\"). Wait for\n   confirmation. Build only what's on the board — never invent steps, fields, or\n   connections to make it look complete. If a relationship isn't drawn, don't\n   draw it.\n\n3. **Get the color palette.** The palette is client-specific and is NOT baked\n   into this skill. If the user gave colors in the prompt or context, use them.\n   Otherwise, ask before building. You need hex values for these roles:\n   - **ink** — primary structure, dark text, node borders (e.g. a deep navy)\n   - **secondary** — sub-heads, connectors, region boundaries (e.g. steel blue)\n   - **accent** — sequence numbers, bullets, flags, emphasis (e.g. a signal red)\n   - **card** — light fill for callout cards \u002F cluster fills (e.g. pale blue-gray)\n   - **accent-tint** — light wash behind accent-flagged items (e.g. pale red)\n   Derive sensible text tints (e.g. a muted slate for sub-captions) from these.\n   Offer to suggest a palette if the user has no preference, but don't assume.\n\n4. **Choose the archetype** (state your choice and why):\n   - **Process rail** — the sketch is a sequence\u002Fflow with a clear order\n     (step 1 → step 2 → …). Read `references\u002Fprocess-rail.md`.\n   - **Network map** — the sketch is locations\u002Fsystems\u002Factors connected by\n     flows, with no single linear order (a topology). Read\n     `references\u002Fnetwork-map.md`.\n   If it's genuinely both, lead with the dominant reading and ask.\n\n5. **Build, verify, iterate.** Build the slide with `python-pptx` per the chosen\n   archetype's reference. The layout is deterministic — **code decides every\n   coordinate** — so verify structurally rather than by eye: every step\u002Fnode\n   present, columns\u002Fnodes evenly spaced, no shape overlapping another, every\n   label inside its box, drop-lines landing on their cards, edges approaching\n   nodes straight-on and not crossing through them. If your runtime can\n   rasterize the slide, optionally do a visual critique pass; if it can't, lean\n   entirely on the computed geometry. Fix in code and rebuild. Faithfulness \n   beats polish — never add a step, field, or connection that wasn't on the \n   board.\n\n## Building the slide (native python-pptx)\n\nBuild the infographic as a **single editable slide** with `python-pptx`, drawn\nnatively as shapes — no HTML, no image rendering, no external render step. It\nruns inside the agent's Python container and returns a `.pptx` the client can\nopen and edit.\n\nThe layout is **deterministic — code decides every coordinate.** Design on a\nfixed 1600×1000 grid mapped to a 13.333in slide (see each reference for the\n`PX()` scale helper), and compute every position from the step\u002Fnode count and\nthe canvas so the slide is correct by construction. Use the house-style system\nfonts (`Arial Narrow` for condensed display, `Arial` for body) so nothing\ndepends on font downloads. Turn off the default autoshape shadow\n(`shape.shadow.inherit = False`) for the flat house look. Save the deck and\nreturn the single `.pptx` as the deliverable — no PNG\u002FPDF\u002FHTML side-artifacts.\n\n**Revisions: never reuse a filename.** When the user asks for changes to an\ninfographic you have already delivered, build the revision as a **new file with\na new name** — `infographic-v1.pptx`, `infographic-v2.pptx`, `infographic-v3.pptx`,\nand so on — incrementing on every subsequent revision for the life of the\nconversation. Do not overwrite, re-save, or re-deliver an existing filename: a\nreused name can prevent the updated file from reaching the user, who then\nreceives the earlier version or no file at all. One revision, one new filename,\nevery time.\n\n## Conventions (shared by both archetypes)\n\nThese are the house style. Keep them consistent across a client engagement.\n\n- **Header band**: condensed uppercase title + a thin small-caps subtitle, a\n  full-width accent rule under it, and an optional right-aligned scope\u002Fcontext\n  note. A short eyebrow label (e.g. \"THE PROCESS\", \"SUPPLY NETWORK\") sits above\n  each major band.\n- **Accent flags** encode meaning — don't decorate with them:\n  - A solid **accent \"GAP\" pill** marks a gap between the standard system and the\n    client's process (a fit\u002Fgap item). Use only where the user confirms a gap.\n  - A hollow **\"need details\" tag** marks an open item to define in follow-up.\n  - Include a one-line legend explaining any flag you use.\n- **Faithfulness**: behaviors\u002Fnotes with no home in the visual go in a list, not\n  invented shapes. Keep the client's exact terms and acronyms; don't expand or\n  rename acronyms the client already knows unless asked.\n- **Restraint**: spend boldness on one signature device (the numbered chevron\n  rail, or the region cluster), keep everything else quiet. Whitespace where the\n  source is sparse is honest — don't pad it with invented detail.\n\n## Questions to ask before building\n\nAsk only the ones that actually change the build; don't interrogate.\n- Unreadable words \u002F unexpanded acronyms (transcribe what you can, ask the rest).\n- Archetype if ambiguous (rail vs. map).\n- For a rail: is there a meaningful sequence number\u002Fpriority on any step? What\n  goes in the bottom band — principles, requirements, or nothing?\n- For a map: which connections must be explicit vs. summarized in a legend;\n  what each node\u002Fedge label means; does anything apply across all nodes.\n- Whether a \"detailed\" companion version is wanted (dense capture of every\n  margin note) in addition to a clean executive version.\n- The color palette, if not already provided.\n\n## References\n\n- `references\u002Fprocess-rail.md` — linear flow archetype: deterministic banded\n  layout (header, numbered chevron rail with drop-lines, callout cards,\n  principles\u002Frequirements bottom band), as a `python-pptx` skeleton with color\n  placeholders.\n- `references\u002Fnetwork-map.md` — topology archetype: node\u002Fedge\u002Fcluster helpers\n  (labeled edges with arrowheads, dashed region clusters, edge-label chips, flow\n  legend, requirements band), as a `python-pptx` skeleton with color\n  placeholders.",{"name":5,"description":7},"main","3678d23ad8fb8d098c428302a98044ac9514d5a1","submissions\u002Fwhiteboard-to-infographic",119,"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-12 02:57:14",{"source":8,"skillName":5,"commands":44,"prompt":54,"zipAvailable":55},[45,48,51],{"tool":46,"command":47},"npx","npx skills add microsoft\u002Fcat-agent-skills --skill whiteboard-to-infographic",{"tool":49,"command":50},"bunx","bunx skills add microsoft\u002Fcat-agent-skills --skill whiteboard-to-infographic",{"tool":52,"command":53},"pnpm","pnpm dlx skills add microsoft\u002Fcat-agent-skills --skill whiteboard-to-infographic","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fwhiteboard-to-infographic\u002FSKILL.md",true,[57,63,67,71],{"path":58,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":61,"sourceHtmlUrl":62},"metadata.json","REFERENCE","参考文档",564,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fwhiteboard-to-infographic\u002Fmetadata.json",{"path":64,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":65,"sourceHtmlUrl":66},"README.md",3032,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fwhiteboard-to-infographic\u002FREADME.md",{"path":68,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Fnetwork-map.md",7664,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fwhiteboard-to-infographic\u002Freferences\u002Fnetwork-map.md",{"path":72,"resourceType":59,"resourceTypeDesc":60,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fprocess-rail.md",8301,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fcat-agent-skills\u002Fblob\u002Fmain\u002Fsubmissions\u002Fwhiteboard-to-infographic\u002Freferences\u002Fprocess-rail.md",[76,103,128,161,179,195],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":29},"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",[],[83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102],"decision","map","decision map","stakeholder and decision map","performance","customer","team","how","decide","do","next","infer","missing","records","assess","reviews","for","single","when","sequences",{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":29},"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",[],[110,111,112,113,114,115,116,117,89,118,119,120,121,122,123,124,125,126,127,101],"update","sales","progress","sales progress update","change","create","meeting prep","analysis","work","up","done","digest","project","my","updates","manager","weekly","catch",{"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":143,"publishedAt":29},"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",[134,137,138],{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":139,"categoryName":140,"taxonomyType":141,"taxonomyTypeDesc":142},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[144,145,146,147,25,148,149,150,151,152,153,154,119,155,156,157,158,159,160,101],"assemble","submission","submission assemble","docx","writing","documents","healthcare","open","reviewer","never","only","clean","guardrail","slide decks","sources","filing","loading",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":29},"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",[],[168,169,170,171,172,117,150,173,153,154,119,84,174,156,158,175,176,177,178,101],"source ingest","ingest","source","database","SET","text","patient","number","lock","definition","transition",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":186,"publishedAt":29},"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",[185],{"categoryNo":135,"categoryName":136,"taxonomyType":21,"taxonomyTypeDesc":22},[187,188,189,147,148,87,149,117,150,118,153,154,190,191,192,84,156,193,194,101],"plan","section","section plan","ready","reports","structure","word documents","which",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":29},"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",[],[202,188,203,148,27,150,204,153,154,119,205,84,206,207,208,156,209,175,210,101],"draft","section draft","write","me","human","life","clinical","drafts","at"]