medharness

Inspect a given commit's web/classic changes and sync all features/fixes to web/default. Use when the user provides a commit ID and wants to audit whether web/default already has the same features as web/classic, port missing features, improve suboptimal implementations, fix bugs, and remove redundant code. Trigger phrases include: "/classic-to-default-sync <hash>", "classic-to-default-sync <hash>", "sync classic to default", "port from classic", "compare classic commit", "classic 和 default 对比", "把这次 classic 的修改同步到 default", "查看这次提交 classic 中的修改并同步", or any request supplying a commit hash together with classic/default comparison intent.

Complete and maintain frontend i18n translations for this project. Covers finding missing translation keys, detecting untranslated entries, and adding translations for all supported locales (en, zh, fr, ja, ru, vi). Use when the user asks to add translations, fix i18n, complete missing translations, or when new UI text needs to be internationalized.

Give the assistant project-aware shadcn/ui context: components.json, composition patterns, CLI, registries, theming, and MCP. Use when working on web/default UI, shadcn components, or presets. Overview aligns with https://ui.shadcn.com/docs/skills.md; full upstream skill text is vendored under vendor/shadcn/.

Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", or "switch to --preset".

Use this skill at the very start of every OpenSpec change (Step 0) for a medical-data SaaS / data platform repository. It classifies the data tier (L1-L4) the change will touch, enumerates the minimal required fields, and produces a signed COMPLIANCE_TAG.md plus a MODEL_ALLOWLIST.json that the mcp-model-router uses as a runtime gate. Always run before any PRD work, model invocation, or code generation that may touch patient / health data. Chinese trigger examples: "合规预检", "数据分级", "新需求合规", "字段清单合规", "PHI 风险评估", "Step 0", "模型 allowlist 生成". Do NOT use for non-medical changes, for pure infra refactors with no data exposure, or after a change has already entered Step 1. Success = signed COMPLIANCE_TAG.md, valid MODEL_ALLOWLIST.json injected into mcp-model-router, all "Yes" risks have mitigation, zero unsigned fields entering the prompt.

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.

Use this skill at Step μ5 of the 5-step micro SOP to produce a lightweight MICRO_AUDIT.json (vs the full AUDIT_BUNDLE.tar.gz). Records diff hash, test result, MICRO_TAG, and writes to mcp-audit-log under event_type `micro_change_seal`. Chinese trigger examples: "micro 归档", "Step μ5", "轻量审计冻结". Do NOT use for full changes (12-step SOP uses audit-snapshot). Success = MICRO_AUDIT.json written + mcp-audit-log receipt.

Use this skill at Step 12 of the v2 SOP, after a change has passed compliance review (Step 10) and any remediation (Step 11), to produce the AUDIT_BUNDLE.tar.gz that satisfies HIPAA / PIPL / 数据安全法 / 健康医疗数据 安全指南 6-year replayability requirements. Packages prompt history, code diff, compliance artifacts, test data, lineage graph, verification reports, model routing logs, and signatures into the canonical structure defined by AUDIT_BUNDLE.spec.md, computes the hash chain, and writes ROOT_SHA256 to the WORM-backed mcp-audit-log. Chinese trigger examples: "审计冻结", "归档审计 包", "Step 12", "AUDIT_BUNDLE 生成", "审计快照", "上链审计". Do NOT use for intermediate snapshots, partial archives, or any change still in Step 10 remediation. Success = AUDIT_BUNDLE.tar.gz exists, manifest passes schema validation, ROOT_SHA256 written to mcp-audit-log, LINEAGE_GRAPH invariants all true, bundle passes self-replay sanity check.

Use this skill at Step 10 of the v2 SOP, executed by the Compliance-Agent (whose backing model must be heterogeneous from the main orchestrator), to produce a COMPLIANCE_REPORT.md for a change that has passed functional Verify and code review. Audits PHI handling, prompt-injection surface, model-call conformance to MODEL_ALLOWLIST, and test-data lineage. Outputs risk-tiered findings (High / Medium / Low) with concrete remediation pointers. Chinese trigger examples: "合规审查 Gate", "Step 10", "合规扫描", "PHI 泄漏检查", "数据流图审查", "出 COMPLIANCE_REPORT". Do NOT use as a substitute for Step 8 code review, do NOT use before Step 7 Verify passes (functional bugs distort compliance signal). Success = signed COMPLIANCE_REPORT.md with high-risk = 0, every medium-risk has owner + remediation, no PHI leak found in logs / exceptions / cache layers.

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.

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.

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.

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.

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.

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.

ALIAS · 别名 Skill。v2.1 起合并到 `prd`。保留本文件仅用于兼容老 SOP 引用。

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.

ALIAS · 别名 Skill。本 Skill 在 v2.1 起被合并到 `prd-implementation-precheck`。 保留本文件仅用于兼容老 SOP 引用；新代码应改用主 Skill。

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.

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.

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.

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.

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.

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.