[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M713BFGZP6AH2GSN8JCC6G5D":3,"skill-same:01M713BFGZP6AH2GSN8JCC6G5D":68},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":6,"ownerHtmlUrl":40,"ownerBlogUrl":41,"ownerDescription":42,"updatedAt":43,"install":44,"resources":57},"01M713BFGZP6AH2GSN8JCC6G5D","yq-doc-maintenance",null,"文档出现腐化、冲突、重复、导航或归档混乱时使用。","EthanYoQ\u002FSkill-hub","EthanYoQ","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257484394?v=4","01M70C9QKWR1YS0S7V26DNB18H","Ethan","01M70C9QMER047R5ANZZA6KC2P",11,"MIT","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F08-writing-marketing\u002Fyq-doc-maintenance\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29],"doc maintenance","doc","maintenance","yq","yq doc maintenance","文档","2026-11-10 10:12:30",false,"---\nname: yq-doc-maintenance\ndescription: 文档出现腐化、冲突、重复、导航或归档混乱时使用。\n---\n\n# Documentation Governance\n\nMaintain a coherent documentation system whose claims have clear owners and can be checked against the project. Start with ownership and structure; edit prose only after the source of truth is known. This skill covers Markdown, READMEs, tutorials, runbooks, reference docs, decision records, postmortems, JSDoc, and code comments. Use [yq-technical-writing](..\u002Fyq-technical-writing\u002FSKILL.md) for sentence-level coverage and clarity, and [yq-remove-reasoning-leaks](..\u002Fyq-remove-reasoning-leaks\u002FSKILL.md) for authoring-session residue. If the audit exposes implementation, test, or gate complexity rather than a documentation-ownership problem, invoke `$yq-simplify-code` for that candidate instead of hiding a behavior change inside documentation cleanup.\n\nThis is guidance, not a universal folder layout. Discover and preserve the repository's own documentation contract.\n\n## Establish the documentation contract\n\n1. Confirm the requested scope and whether the task is an audit, a proposal, or an authorized edit. Use the narrowest defensible scope from the request and current diff; do not silently expand a focused task into a repository-wide rewrite.\n2. Snapshot the audit identity: repository, checkout or worktree, branch, revision, dirty state, and applicable instructions. Recheck it before reporting. If the worktree changes during the audit, stop combining observations, anchor completed findings to the captured revision, and list later changes as uninspected.\n3. Read applicable `AGENTS.md`, `CLAUDE.md`, `CONTEXT.md`, root and package READMEs, documentation indexes, architecture\u002Fdecision records, contribution guides, and CI or package scripts that validate docs.\n4. Identify excluded or derivative areas: third-party sources, generated catalogs, build output, recorded fixtures, snapshots, vendored documentation, and frozen archives. Edit an owner before regenerating a derivative artifact.\n5. Record how this repository expresses intended behavior, observed behavior, rationale, and process. Code or runtime evidence can establish what happens; it does not automatically overrule a current product specification. When those disagree, label the mismatch instead of silently choosing one.\n\nTreat dates, file size, link count, and directory location as discovery clues, not proof that a document is authoritative or obsolete.\n\nFor a long-lived repository, multiple documentation roots, or reports of widespread rot and conflict, read [the large-repository audit playbook](references\u002Flarge-repository-audit.md) before changing files.\n\n## Map the corpus before restructuring it\n\nInventory tracked documentation and relevant untracked files without traversing dependency stores, build caches, or unrelated large artifacts. Include ignored-but-relevant documents or evidence only through bounded, known roots. Prefer the Git index and constrained `rg --files` queries over a whole-drive scan. Audit each relevant worktree against its own revision and status; never merge conflicting observations from different worktrees into one unlabeled fact set.\n\nFor each document in scope, determine:\n\n- its subject and intended reader;\n- its form: orientation, tutorial, runbook, reference, decision record, postmortem, generated\u002Frecorded artifact, or archive;\n- the canonical owner of each important claim;\n- its authority tier and lifecycle: canonical, summary, derivative, historical, task-state, or external evidence; active, frozen, generated, or local-only;\n- its freshness contract: owner, as-of point, invalidation event, and explicit supersession relation when one exists;\n- its direct children and inbound links;\n- the code, config, schema, command, runtime evidence, or decision that can verify it;\n- any referenced spreadsheet, PDF, JSON, screenshot, bundle, or external artifact needed to verify a claim, without treating that evidence as ordinary prose to rewrite;\n- whether it is current, partially stale, fully superseded, duplicated, conflicting, misplaced, or intentionally historical.\n\nA document can be structurally misplaced while every sentence is correct. Fix information architecture before polishing those sentences.\n\n## Review structure before prose\n\nApply this order to each human-facing document:\n\n1. State the document's own subject and keep full detail about that subject.\n2. Summarize direct children by purpose and responsibility; link deeper mechanisms to their owning documents.\n3. Classify the document by intended use rather than filename. A tutorial leads ordered work to an observable result. A runbook supports an operational procedure and recovery. A reference supports lookup without sequential reading. A decision record preserves rationale and alternatives. A postmortem preserves incident evidence and causality.\n4. Trace tutorial prerequisites and move optional or advanced material out of the critical path.\n5. Split substantial mixed forms. Keep a small secondary form only when a clearly labeled section is easier to use than another file.\n\nDo not impose a new taxonomy when the repository already has a coherent one. Propose a taxonomy only when missing ownership is itself causing duplication or conflict.\n\n## Treat documentation budgets as routing signals\n\nWhen the repository enforces word, line, section, or file-count budgets, inspect the gate's report before editing and apply this order:\n\n1. **Relocate** detail owned by a child component, advanced guide, decision record, postmortem, generated reference, or historical artifact.\n2. **Condense** duplication, narration, obsolete status, and implementation walkthroughs while preserving every load-bearing proposition.\n3. **Raise or refine the budget** only when the remaining material belongs on that surface and the repository permits an explicit, justified exception.\n\nDo not optimize prose to an arbitrary number, delete contracts to make a gate green, or treat an unbudgeted large file as automatically defective. When the project tracks documentation size, report the measured delta and any deliberately long exception.\n\n## Reconcile stale, duplicated, and conflicting claims\n\nWork at the claim level rather than declaring whole files \"good\" or \"bad.\"\n\n1. Build a conflict set containing the claim, every location that states it, the evidence available now, the intended owner, and the unresolved question.\n2. Choose the owner by responsibility and audience, not by whichever copy is newest or longest. Preserve a concise consumer-facing contract locally when readers need it; link to the owner for rationale, algorithms, history, and extended examples.\n3. Repair the owner first, then update summaries, translations, generated references, examples, and navigation. A generated catalog is changed through its source or generator.\n4. Replace redundant explanations with links. Keep necessary local facts such as preconditions, failures, ownership, and consequences even when their rationale lives elsewhere.\n5. Classify supersession precisely. Partial supersession keeps surviving contracts and cross-links. Full supersession requires that no current behavior, compatibility obligation, schema, migration, supported workflow, or unique rationale remains solely in the older document.\n6. Archive or delete only within the task's authority and the repository's retention rules. Frozen history remains frozen; repair active inbound links rather than modernizing an archive.\n\nAn outdated command, renamed path, missing target, contradictory default, or unsupported status claim is evidence of rot. Age alone is not. If documentation describes intended behavior that implementation does not satisfy, report or fix the product mismatch under the appropriate task instead of rewriting the promise to match the bug.\n\nBefore moving or renaming a document, find inbound links, path references, and heading fragments. Treat the move as one atomic change: new home, old-home removal or redirect if the project supports one, navigation update, and every resolvable inbound reference repaired.\n\n## Classify decision records by future value\n\nJudge proposals, ADRs, design notes, and implementation records by the decisions they can still inform. Age, size, and completion status are discovery clues, not archive criteria.\n\n- **Proposed:** keep an active proposal available while the decision remains open. Reject it honestly when it is no longer worth pursuing; do not archive an unresolved proposal as if it were settled.\n- **Implemented — keep active:** retain rationale, alternatives, negative guarantees, ownership boundaries, compatibility rules, security constraints, or reintroduction conditions that can guide a future change.\n- **Implemented — archive:** archive a completed record when current behavior is owned elsewhere and its remaining content is one-off implementation or process history with little future decision value.\n- **Rejected — keep as a guardrail:** retain a rejection when the losing option remains a plausible, tempting mistake and the record explains why it loses.\n- **Rejected — remove:** remove it when the idea is obsolete, superseded, no longer plausible, and unlikely to prevent repeated debate. Repair or remove inbound links at the same time.\n\nWhen a new record supersedes an older one, inspect the related active records in the same scope. Cross-link partial supersession; for full supersession, transfer unique rationale, alternatives, obligations, and reintroduction conditions to the current owner before archiving or deleting the older record. Follow the repository's existing retention format. This classification does not require a new archive layout, manifest, hash, or validation gate.\n\n## Keep durable evidence, remove sediment\n\nKeep non-obvious contracts, rationale, alternatives, consequences, operational recovery, compatibility obligations, verification evidence, and named coverage gaps. Remove or relocate:\n\n- duplicated explanations and hand-written inventories owned by code or generators;\n- completed migration checklists presented as current work;\n- temporary status reports that claim to be evergreen reference;\n- authoring-session narration, review choreography, and dead citations;\n- implementation walkthroughs that add no contract beyond the code;\n- stale examples whose commands or outputs no longer reproduce.\n\nIf removing prose would change a promised behavior rather than its explanation, treat it as a product or architecture decision. Use the repository's existing ADR, RFC, issue, proposal, or decision-note mechanism; do not hide that decision inside a documentation cleanup.\n\n## Validate against this repository\n\nDiscover the actual validators from package manifests, task runners, CI, contribution docs, and `--help` output. Classify their side effects before execution. In a read-only audit, run only checks proven not to rewrite docs, generate output, mutate databases, or create runtime state; otherwise inspect the check and report it as unrun. Select checks for the surfaces touched and do not transplant commands from another project. If no validator exists, use the bounded fallback checks in the large-repository playbook.\n\nAt minimum when applicable:\n\n- run the repository's documentation generator or sync check;\n- run link and anchor validation, including code references to documentation paths;\n- execute or smoke-test changed commands and examples through their real entry path;\n- update paired\u002Flocalized documents according to the repository's own policy;\n- run tests or snapshots for model-, CLI-, or UI-visible wording;\n- run `git diff --check` and search for old paths or distinctive superseded claims;\n- inspect the final diff for derivative, archive, vendor, or out-of-scope changes.\n\nReport the corpus boundary, audit revision and status stability, documents and claim families inspected, canonical owners chosen, conflicts resolved or deferred, files moved\u002Farchived\u002Fdeleted, deliberate keeps, and checks actually run. A successful link checker is structural evidence, not proof that the prose is true.\n","# Documentation Governance\n\nMaintain a coherent documentation system whose claims have clear owners and can be checked against the project. Start with ownership and structure; edit prose only after the source of truth is known. This skill covers Markdown, READMEs, tutorials, runbooks, reference docs, decision records, postmortems, JSDoc, and code comments. Use [yq-technical-writing](..\u002Fyq-technical-writing\u002FSKILL.md) for sentence-level coverage and clarity, and [yq-remove-reasoning-leaks](..\u002Fyq-remove-reasoning-leaks\u002FSKILL.md) for authoring-session residue. If the audit exposes implementation, test, or gate complexity rather than a documentation-ownership problem, invoke `$yq-simplify-code` for that candidate instead of hiding a behavior change inside documentation cleanup.\n\nThis is guidance, not a universal folder layout. Discover and preserve the repository's own documentation contract.\n\n## Establish the documentation contract\n\n1. Confirm the requested scope and whether the task is an audit, a proposal, or an authorized edit. Use the narrowest defensible scope from the request and current diff; do not silently expand a focused task into a repository-wide rewrite.\n2. Snapshot the audit identity: repository, checkout or worktree, branch, revision, dirty state, and applicable instructions. Recheck it before reporting. If the worktree changes during the audit, stop combining observations, anchor completed findings to the captured revision, and list later changes as uninspected.\n3. Read applicable `AGENTS.md`, `CLAUDE.md`, `CONTEXT.md`, root and package READMEs, documentation indexes, architecture\u002Fdecision records, contribution guides, and CI or package scripts that validate docs.\n4. Identify excluded or derivative areas: third-party sources, generated catalogs, build output, recorded fixtures, snapshots, vendored documentation, and frozen archives. Edit an owner before regenerating a derivative artifact.\n5. Record how this repository expresses intended behavior, observed behavior, rationale, and process. Code or runtime evidence can establish what happens; it does not automatically overrule a current product specification. When those disagree, label the mismatch instead of silently choosing one.\n\nTreat dates, file size, link count, and directory location as discovery clues, not proof that a document is authoritative or obsolete.\n\nFor a long-lived repository, multiple documentation roots, or reports of widespread rot and conflict, read [the large-repository audit playbook](references\u002Flarge-repository-audit.md) before changing files.\n\n## Map the corpus before restructuring it\n\nInventory tracked documentation and relevant untracked files without traversing dependency stores, build caches, or unrelated large artifacts. Include ignored-but-relevant documents or evidence only through bounded, known roots. Prefer the Git index and constrained `rg --files` queries over a whole-drive scan. Audit each relevant worktree against its own revision and status; never merge conflicting observations from different worktrees into one unlabeled fact set.\n\nFor each document in scope, determine:\n\n- its subject and intended reader;\n- its form: orientation, tutorial, runbook, reference, decision record, postmortem, generated\u002Frecorded artifact, or archive;\n- the canonical owner of each important claim;\n- its authority tier and lifecycle: canonical, summary, derivative, historical, task-state, or external evidence; active, frozen, generated, or local-only;\n- its freshness contract: owner, as-of point, invalidation event, and explicit supersession relation when one exists;\n- its direct children and inbound links;\n- the code, config, schema, command, runtime evidence, or decision that can verify it;\n- any referenced spreadsheet, PDF, JSON, screenshot, bundle, or external artifact needed to verify a claim, without treating that evidence as ordinary prose to rewrite;\n- whether it is current, partially stale, fully superseded, duplicated, conflicting, misplaced, or intentionally historical.\n\nA document can be structurally misplaced while every sentence is correct. Fix information architecture before polishing those sentences.\n\n## Review structure before prose\n\nApply this order to each human-facing document:\n\n1. State the document's own subject and keep full detail about that subject.\n2. Summarize direct children by purpose and responsibility; link deeper mechanisms to their owning documents.\n3. Classify the document by intended use rather than filename. A tutorial leads ordered work to an observable result. A runbook supports an operational procedure and recovery. A reference supports lookup without sequential reading. A decision record preserves rationale and alternatives. A postmortem preserves incident evidence and causality.\n4. Trace tutorial prerequisites and move optional or advanced material out of the critical path.\n5. Split substantial mixed forms. Keep a small secondary form only when a clearly labeled section is easier to use than another file.\n\nDo not impose a new taxonomy when the repository already has a coherent one. Propose a taxonomy only when missing ownership is itself causing duplication or conflict.\n\n## Treat documentation budgets as routing signals\n\nWhen the repository enforces word, line, section, or file-count budgets, inspect the gate's report before editing and apply this order:\n\n1. **Relocate** detail owned by a child component, advanced guide, decision record, postmortem, generated reference, or historical artifact.\n2. **Condense** duplication, narration, obsolete status, and implementation walkthroughs while preserving every load-bearing proposition.\n3. **Raise or refine the budget** only when the remaining material belongs on that surface and the repository permits an explicit, justified exception.\n\nDo not optimize prose to an arbitrary number, delete contracts to make a gate green, or treat an unbudgeted large file as automatically defective. When the project tracks documentation size, report the measured delta and any deliberately long exception.\n\n## Reconcile stale, duplicated, and conflicting claims\n\nWork at the claim level rather than declaring whole files \"good\" or \"bad.\"\n\n1. Build a conflict set containing the claim, every location that states it, the evidence available now, the intended owner, and the unresolved question.\n2. Choose the owner by responsibility and audience, not by whichever copy is newest or longest. Preserve a concise consumer-facing contract locally when readers need it; link to the owner for rationale, algorithms, history, and extended examples.\n3. Repair the owner first, then update summaries, translations, generated references, examples, and navigation. A generated catalog is changed through its source or generator.\n4. Replace redundant explanations with links. Keep necessary local facts such as preconditions, failures, ownership, and consequences even when their rationale lives elsewhere.\n5. Classify supersession precisely. Partial supersession keeps surviving contracts and cross-links. Full supersession requires that no current behavior, compatibility obligation, schema, migration, supported workflow, or unique rationale remains solely in the older document.\n6. Archive or delete only within the task's authority and the repository's retention rules. Frozen history remains frozen; repair active inbound links rather than modernizing an archive.\n\nAn outdated command, renamed path, missing target, contradictory default, or unsupported status claim is evidence of rot. Age alone is not. If documentation describes intended behavior that implementation does not satisfy, report or fix the product mismatch under the appropriate task instead of rewriting the promise to match the bug.\n\nBefore moving or renaming a document, find inbound links, path references, and heading fragments. Treat the move as one atomic change: new home, old-home removal or redirect if the project supports one, navigation update, and every resolvable inbound reference repaired.\n\n## Classify decision records by future value\n\nJudge proposals, ADRs, design notes, and implementation records by the decisions they can still inform. Age, size, and completion status are discovery clues, not archive criteria.\n\n- **Proposed:** keep an active proposal available while the decision remains open. Reject it honestly when it is no longer worth pursuing; do not archive an unresolved proposal as if it were settled.\n- **Implemented — keep active:** retain rationale, alternatives, negative guarantees, ownership boundaries, compatibility rules, security constraints, or reintroduction conditions that can guide a future change.\n- **Implemented — archive:** archive a completed record when current behavior is owned elsewhere and its remaining content is one-off implementation or process history with little future decision value.\n- **Rejected — keep as a guardrail:** retain a rejection when the losing option remains a plausible, tempting mistake and the record explains why it loses.\n- **Rejected — remove:** remove it when the idea is obsolete, superseded, no longer plausible, and unlikely to prevent repeated debate. Repair or remove inbound links at the same time.\n\nWhen a new record supersedes an older one, inspect the related active records in the same scope. Cross-link partial supersession; for full supersession, transfer unique rationale, alternatives, obligations, and reintroduction conditions to the current owner before archiving or deleting the older record. Follow the repository's existing retention format. This classification does not require a new archive layout, manifest, hash, or validation gate.\n\n## Keep durable evidence, remove sediment\n\nKeep non-obvious contracts, rationale, alternatives, consequences, operational recovery, compatibility obligations, verification evidence, and named coverage gaps. Remove or relocate:\n\n- duplicated explanations and hand-written inventories owned by code or generators;\n- completed migration checklists presented as current work;\n- temporary status reports that claim to be evergreen reference;\n- authoring-session narration, review choreography, and dead citations;\n- implementation walkthroughs that add no contract beyond the code;\n- stale examples whose commands or outputs no longer reproduce.\n\nIf removing prose would change a promised behavior rather than its explanation, treat it as a product or architecture decision. Use the repository's existing ADR, RFC, issue, proposal, or decision-note mechanism; do not hide that decision inside a documentation cleanup.\n\n## Validate against this repository\n\nDiscover the actual validators from package manifests, task runners, CI, contribution docs, and `--help` output. Classify their side effects before execution. In a read-only audit, run only checks proven not to rewrite docs, generate output, mutate databases, or create runtime state; otherwise inspect the check and report it as unrun. Select checks for the surfaces touched and do not transplant commands from another project. If no validator exists, use the bounded fallback checks in the large-repository playbook.\n\nAt minimum when applicable:\n\n- run the repository's documentation generator or sync check;\n- run link and anchor validation, including code references to documentation paths;\n- execute or smoke-test changed commands and examples through their real entry path;\n- update paired\u002Flocalized documents according to the repository's own policy;\n- run tests or snapshots for model-, CLI-, or UI-visible wording;\n- run `git diff --check` and search for old paths or distinctive superseded claims;\n- inspect the final diff for derivative, archive, vendor, or out-of-scope changes.\n\nReport the corpus boundary, audit revision and status stability, documents and claim families inspected, canonical owners chosen, conflicts resolved or deferred, files moved\u002Farchived\u002Fdeleted, deliberate keeps, and checks actually run. A successful link checker is structural evidence, not proof that the prose is true.\n",{"name":5,"description":7},"mine","1e7390741dffd3d5041fca4ebc056071ee3ba137","skills\u002F08-writing-marketing\u002Fyq-doc-maintenance",5,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub","https:\u002F\u002Fgithub.com\u002FEthanYoQ","www.orz.md","Part Marketer, Part AI Explorer.","2026-11-07 14:52:29",{"source":8,"skillName":5,"commands":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add EthanYoQ\u002FSkill-hub --skill yq-doc-maintenance",{"tool":50,"command":51},"bunx","bunx skills add EthanYoQ\u002FSkill-hub --skill yq-doc-maintenance",{"tool":53,"command":54},"pnpm","pnpm dlx skills add EthanYoQ\u002FSkill-hub --skill yq-doc-maintenance","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F08-writing-marketing\u002Fyq-doc-maintenance\u002FSKILL.md",true,[58,64],{"path":59,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":62,"sourceHtmlUrl":63},"agents\u002Fopenai.yaml","REFERENCE","参考文档",243,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F08-writing-marketing\u002Fyq-doc-maintenance\u002Fagents\u002Fopenai.yaml",{"path":65,"resourceType":60,"resourceTypeDesc":61,"sizeBytes":66,"sourceHtmlUrl":67},"references\u002Flarge-repository-audit.md",7898,"https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F08-writing-marketing\u002Fyq-doc-maintenance\u002Freferences\u002Flarge-repository-audit.md",[69,97,128,152,170,185],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":76,"publishedAt":30},"01M713CBDSYARG4PXFXK2R2NNN","xhs-pharma-social-listening","Run evidence-disciplined Xiaohongshu social listening for foreign pharma employee pain points. Use when the user asks to collect and analyze notes\u002Fcomments about pharma companies, aliases, roles, compliance, medical affairs, or AI topics, then produce a cited and scored sampled-insight report. Includes independent-evidence counting, MediaCrawler batch collection, and CAPTCHA\u002F461 fallback to Agent Reach\u002FOpenCLI.","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fxhs-pharma-social-listening\u002FSKILL.md",[75],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96],"social","xhs pharma social listening","social listening","xhs","medical","counting","when","collection","batch","analyze","notes","run","opencli","fallback","captcha","agent reach","evidence","for","collect","produce",{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":109,"publishedAt":30},"01M713C8Q76ZP0WXXBRAFKS6EE","healthcare-phi-compliance","Protected Health Information (PHI) and Personally Identifiable Information (PII) compliance patterns for healthcare applications. Covers data classification, access control, audit trails, encryption, and common leak vectors. Use when code touches PHI or PII in a healthcare system, or when auditing access control, audit trails, or leak vectors.","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fhealthcare-phi-compliance\u002FSKILL.md",[103,104],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[110,111,112,113,114,115,116,117,83,118,119,120,121,122,123,124,94,125,126,127],"healthcare","phi","compliance","healthcare phi compliance","pii","compliance patterns","information","access","encryption","code","common","audit","data","patterns","Access Control","system","applications","Auditing Access Control",{"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":135,"publishedAt":30},"01M713C5R2GE43X45T2K75TB76","healthcare-eval-harness","Patient safety evaluation harness for healthcare application deployments. Automated test suites for CDSS accuracy, PHI exposure, clinical workflow integrity, and integration compliance. Blocks deployments on safety failures. Use when a healthcare deployment must be gated on patient-safety tests for CDSS accuracy, PHI exposure, and workflow integrity.","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fhealthcare-eval-harness\u002FSKILL.md",[134],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[110,136,137,138,139,140,141,83,142,143,144,145,111,94,146,147,148,149,150,151],"eval","harness","healthcare eval harness","eval harness","clinical","patient","workflow","Evaluation","Safety","integrity","deployment","accuracy","tests","deployments","use","super",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":30},"01M713C2J17S91VYR7A8M696VR","healthcare-emr-patterns","EMR\u002FEHR development patterns for healthcare applications. Clinical safety, encounter workflows, prescription generation, clinical decision support integration, and accessibility-first UI for medical data entry. Use when building EMR or EHR features such as encounter workflows, prescription generation, or clinical data entry UI.","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fhealthcare-emr-patterns\u002FSKILL.md",[158],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[110,160,123,161,162,81,140,163,83,164,165,166,144,122,167,168,169,94,126,150],"EMR","healthcare emr patterns","decision","workflows","support","clinical decision support","features","ui","as","development",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":177,"publishedAt":30},"01M713BZERTXV0N8X6SW9DDVWZ","healthcare-cdss-patterns","Clinical Decision Support System (CDSS) development patterns. Drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), alert severity classification, and integration into EMR workflows. Use when building clinical decision support — drug interaction checks, dose validation, clinical scoring, or alert severity.","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fhealthcare-cdss-patterns\u002FSKILL.md",[176],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[110,123,178,162,140,160,163,83,179,180,164,165,181,169,125,182,150,183,151,184],"healthcare cdss patterns","scoring","interaction","severity","classification","alert","decision support",{"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":30},"01M713BVK3PQR7V4ZKYGMWMXJD","dxy-task-clarify","用户的请求含糊、缺背景、缺资料说明、缺读者或用途时使用。先用少量带选项的追问把任务问清楚，写成任务卡，用户确认后再执行。尤其适用于医生、科研人员和药企各岗位的工作，例如「帮我分析一下这些数据」「帮我准备明天的拜访」「写个总结」「做个 PPT」「回一下这封邮件」「整理一下会议纪要」「整理一下这些文献」「帮我准备下周的讲课」「写个病例汇报」「帮我写个提示词」。用户说「先问我」「帮我理清需求」「我不知道怎么描述」「我不会问 AI」时也使用。用途、资料、读者都已说清的请求，纯翻译，以及写代码、改代码，不使用。","https:\u002F\u002Fgithub.com\u002FEthanYoQ\u002FSkill-hub\u002Fblob\u002Fmine\u002Fskills\u002F10-business-industry\u002Fdxy-task-clarify\u002FSKILL.md",[191],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[193,194,195,196,197,198,199,200],"clarify","dxy task clarify","task","pptx","整理","翻译","数据","总结"]