charliehzm
User让医疗机构所有大模型流量：PHI 不外泄 · 模型走白名单 · 全量可审计 · 成本可控。
Categories
Indexed Skills (15)
memory-curate
Use this skill on a weekly cadence and at every change archive to keep the project's tiered memory (MEMORY.md index + per-topic memory files + workspace artifacts under .memory/) coherent and fresh. Detects stale entries, merges duplicates, prunes superseded facts, refreshes the inference layer from the latest verified facts, and produces a weekly curation report. Counteracts the "stale memory commands decisions" failure mode that silently degrades long-running AI Coding sessions. Chinese trigger examples: "记忆刷新", "memory 整理", "刷新 MEMORY.md", "记忆失效检测", "记忆周报", "整理 .memory/". Do NOT use to write new factual memory (let domain skills do that), do NOT use as a substitute for an actual audit (this is hygiene, not compliance). Success = no duplicates remain, every fact has a `last_verified` ≤ 14 days, the inference layer matches the fact layer, weekly report saved with curation actions logged.
phi-desensitize
Use this skill before any prompt, log message, error trace, test fixture, or external API call that may include patient health information (PHI) or personal identifying information (PII) in a medical-data SaaS context. Replaces sensitive tokens with reversible synthetic substitutes, emits a desensitize map (encrypted), and produces a residual-risk report. Mandatory pre-stage before any L3/L4 data ever enters a model context window. Chinese trigger examples: "脱敏", "PHI 脱敏", "数据脱敏", "去标识化", "patient_id 替换", "把这段日志脱敏", "把样例匿名化". Do NOT use as a one-way redactor when the workflow needs round-trip mapping; do NOT use for fully synthetic data that contains no real source values (use test-data-generation instead). Success = every L3/L4 token in input is replaced, output passes mcp-phi-detector with zero hits, reversal map is encrypted with KMS-managed key, and residual-risk report is empty or explicitly approved.
prd-implementation-precheck
Use this skill at Step 1 (PRD pre-check) and Step 2 (TDD alignment) of the v2 12-step SOP to find blockers and warnings in PRD / TDD before any implementation work begins. Produces a structured gap list pointing to missing scope boundaries, undefined acceptance criteria, unresolved cross-team dependencies, vague metrics, and stage breakdown gaps. Chinese trigger examples: "PRD 预检", "PRD 检查", "TDD 对齐检查", "需求文档审查", "PRD 缺口扫描", "Step 1", "Step 2". Do NOT use to write the PRD itself (use `prd` Skill), do NOT use as substitute for compliance precheck (Step 0 is separate). Success = zero blockers, zero warnings, stage breakdown present, every acceptance criterion has a measurable test hook, every dependency has a named owner.
tdd-alignment
Use this skill at SOP Step 2 to verify and align a Technical Design Document (TDD) with the final PRD: checks every PRD-stated acceptance criterion has a corresponding test/verification approach, every named stage in PRD has a TDD validation strategy, and every L3/L4 data field has a desensitization / audit step planned. Produces an alignment report and inserts patches into TDD where gaps exist. Chinese trigger examples: "TDD 对齐", "TDD 验收对齐", "测试设计对齐 PRD", "Step 2". Do NOT use for unit-test writing (use during Step 9), code-level design review (Step 8), or when TDD is missing entirely (escalate to author). Success = TDD covers 100% of PRD acceptance criteria with named test strategies; PHI handling addressed; staging tests defined.
prd-precheck
ALIAS · 别名 Skill。本 Skill 在 v2.1 起被合并到 `prd-implementation-precheck`。 保留本文件仅用于兼容老 SOP 引用；新代码应改用主 Skill。
ask-questions-if-underspecified
Use this skill when scope ambiguity blocks progress in any SOP step (PRD, TDD, design, task decomposition). Produces a tight set of clarifying questions (max 5) that, once answered, unblock the next step. Avoids the failure mode where Agents proceed on assumption and produce wrong work. Chinese trigger examples: "需求不清", "需要澄清", "提问澄清", "范围不明", "信息不足要澄清", "ask the user". Do NOT use for exploration (use research), do NOT use to delay obvious work. Success = ≤ 5 questions, each decision-shaping, each tied to a specific PRD section.
mocking-stubbing
Use this skill at Step 9 of the v2 SOP to run the change's tests against the stage-isolated synthetic mock data produced at Step 5. Handles fixture loading, mock service stand-up (DB / external APIs / LLM endpoints), runs the test pyramid (unit + integration + e2e where applicable), and produces a test result report. On failure, hand off to systematic-debugging. Chinese trigger examples: "mock 测试", "Step 9", "跑测试用 mock", "联调 mock", "存根服务测试". Do NOT use to test against production data, do NOT use without verified mock fingerprints. Success = all tests green against stage mock, test result XML produced, no real service contacted.
openspec-apply-change
Use this skill at Step 6 of the v2 SOP to implement one task from the change's tasks/ directory at a time. Each invocation should produce a code diff for exactly one task document, touching ≤ 2 files, with prompts pre-routed through mcp-model-router and any L3/L4 text pre-desensitized via phi-desensitize. Updates the task document checkbox upon completion. Chinese trigger examples: "执行任务", "OpenSpec apply", "Step 6", "实现 任务", "应用变更". Do NOT use to implement multiple tasks at once, do NOT use without an active MODEL_ALLOWLIST, do NOT use bypassing phi-desensitize for L3/L4 text. Success = one task's diff produced, ≤ 2 files touched, task checkbox flipped, all model calls routed through mcp-model-router.
openspec-continue-change
Use this skill at Step 3 (after openspec-new-change) to expand proposal / design / specs into implementation-ready content. Iteratively fills out the technical approach, data model, contract specs, test strategy, and risk table. Stop when the change is "implementation-ready": every spec has acceptance criteria, design covers all PRD scope items, and the Compliance Design section is fully populated. Chinese trigger examples: "继续 OpenSpec", "OpenSpec 续写", "完善 design.md", "specs 填充". Do NOT use for task decomposition (next step), do NOT use to write code. Success = design.md covers 100% of in-scope PRD items, every spec has acceptance criteria, openspec validate passes.
openspec-verify-change
Use this skill at Step 7 of the v2 SOP to verify that all tasks in the active OpenSpec change are implemented and align with their specs. Cross-checks tasks.md checkboxes against actual code presence, runs per-spec acceptance criteria as smoke tests where possible, and surfaces unimplemented artifacts. Verify is a HARD GATE: failure routes back to Step 6 (openspec-apply-change) until clear. Chinese trigger examples: "OpenSpec verify", "Step 7", "核验变更", "检查未实现工件". Do NOT use to judge code quality (that's Step 8 review), do NOT use to verify compliance (that's Step 10). Success = every task checked, every spec has evidence, unimplemented-artifact list is empty.
prompt-injection-scan
Use this skill (typically inside Reviewer-Agent or Compliance-Agent) to scan RAG retrieval results, external document content, tool call outputs, and user-provided text for prompt-injection patterns before they reach the main model context. Outputs a classification report and quarantines suspicious content. Chinese trigger examples: "Prompt 注入扫描", "RAG 内容审查", "外部文档注入检测", "指令注入检查". Do NOT use as PHI detector (use phi-detect), do NOT use as content moderation (separate concern). Success = scanned text either passes or is quarantined with reason; zero suspicious patterns reach the main context unflagged.
quick-fix
Use this skill for micro-changes (bugfix / docs / 小配置) that satisfy: ≤2 files changed, no L3/L4 PHI field touched, no new LLM call, no spec/design modification. This skill routes to the 5-step micro SOP instead of the full 12-step SOP. Auto-checks via scripts/sop_router.py; if any check fails, redirects to full SOP. Chinese trigger examples: "改个小 bug", "修 typo", "更新配置", "改一行", "quick fix", "微改动". Do NOT use for feature development, multi-stage work, or anything touching patient data / model allowlist / spec. Success = sop_router returns "micro" + 5 步流程 跑完 + MICRO_AUDIT.json 入 mcp-audit-log.
requesting-code-review
Use this skill at Step 8 of the v2 SOP after Verify passes, to request and receive a code review from a Reviewer-Agent (or human reviewer). Packages the diff with context (task documents, specs, COMPLIANCE_TAG, design rationale), invokes the review, and iterates with systematic-debugging until all feedback is closed. Chinese trigger examples: "请求 review", "Step 8", "代码审查", "请人 review", "review 这个 change". Do NOT use as substitute for Step 10 compliance review, do NOT skip when reviewer feedback contains High items. Success = all reviewer feedback closed, review thread archived.
systematic-debugging
Use this skill whenever a test fails, a code review surfaces a defect, or a bug is reported, to perform structured root-cause analysis rather than trial-and-error patches. Walks symptom → narrow → reproduce → minimal repro → root cause → fix → regression test. Outputs a debug log entry that feeds into Memory and AUDIT_BUNDLE. Chinese trigger examples: "调试", "找 bug 根因", "系统化调试", "Bug 定位", "test failure 调试", "review 反馈 修复". Do NOT use for stylistic feedback (just fix), do NOT use for known one-line fixes. Success = root cause identified with evidence, fix applied at root cause level, regression test added.
task-decomposition
Use this skill at Step 4 of the v2 SOP to decompose an OpenSpec change's tasks.md into atomic, prioritized, single-document, ≤2-file-change tasks. Enforces strict separation of frontend vs backend tracks, Chinese naming for task documents, and explicit dependency order. Each task gets its own task document under tasks/, referenced from tasks.md. Chinese trigger examples: "任务拆解", "Step 4", "拆任务", "task 拆分", "前后端分离任务". Do NOT use before openspec-continue-change finalizes specs, do NOT bundle ≥3 files per task. Success = every task ≤ 2 files, every task has its own document, ordering reflects priority + dependency, frontend / backend tracks are separated.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.