health-docs

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Healthcare System Documentation

医疗保健系统文档

Overview

概述

Healthcare engineering systems require documentation that serves multiple audiences simultaneously — developers, operators, auditors, AI agents, and regulators. That documentation rarely exists in a usable state: it's scattered across README files, inline comments, AGENTS.md, and external wikis, with critical regulatory-required content simply absent.

This skill audits what exists, maps it to what's required given the system's regulatory context, and consolidates it into a structured, maintainable hierarchy.

医疗保健工程系统需要同时面向多类受众的文档——开发人员、运维人员、审计人员、AI Agent和监管机构。但这类文档通常都不具备可用状态：分散在README文件、行内注释、AGENTS.md、外部维基中，监管要求的关键内容甚至直接缺失。

本Skill可以审计现有文档，结合系统的监管背景映射所需内容，将其整合为结构化、可维护的层级结构。

Modes

模式

Mode: analyze

模式：分析

Scan the repository, detect applicable regulatory regimes, assess documentation coverage across seven dimensions, and produce a structured handoff artifact. No repository files are modified — only
.health-docs/analysis.md
is written.

扫描代码仓库，检测适用的监管体系，评估七个维度的文档覆盖率，生成结构化交接工件。不会修改仓库中的任何文件，仅写入
.health-docs/analysis.md
。

Mode: document

模式：文档生成

Read the handoff artifact from analyze mode, conduct an evidence-informed interview to confirm requirements, then consolidate existing documentation into the target hierarchy and draft new content for required gaps. Confirms before writing.

读取分析模式生成的交接工件，开展基于证据的访谈确认需求，之后将现有文档整合到目标层级结构中，并为缺失的必填内容撰写草稿。写入前会先确认。

Operating Rules

操作规则

Never modify code, tests, configurations, or infrastructure files.
Never silently resolve conflicts between documentation sources — always flag for human resolution.
Always mark documents in
```
comply/
```
directories with
```
⚠ REQUIRES HUMAN REVIEW
```
regardless of operation type (consolidate, merge, or draft new) — the skill can transcribe and draft from evidence, but cannot certify compliance.
If a relevant subagent is unavailable, fall back to direct analysis for that dimension; note reduced confidence in the artifact.
Treat external links (Confluence, Notion, GDrive) as "unverifiable — content not assessed" — mark coverage as partial, not covered.
The
```
.health-docs/
```
directory is the skill's work directory in the target repo. Do not treat it as part of the documentation hierarchy.
Credential redaction: Before consolidating or copying any content, scan for secrets, API keys, tokens, passwords, private keys, and credentials. Do not reproduce secret material — replace with
```
[REDACTED — potential secret at <source-path>:<line>]
```
and note each redaction in the run record. If a file appears to be an environment file (
```
.env
```
,
```
.env.*
```
,
```
secrets.*
```
,
```
credentials.*
```
) or contains only key-value credential pairs, skip it entirely and note it in the run record rather than consolidating it.

永远不要修改代码、测试、配置或基础设施文件。
永远不要静默解决不同文档来源之间的冲突——始终标记出来供人工解决。
无论操作类型是整合、合并还是新起草，始终为
```
comply/
```
目录下的文档标记
```
⚠ 需要人工审核
```
——本Skill可以基于证据转录和起草内容，但无法证明合规性。
如果相关子代理不可用，回退到对该维度的直接分析，并在工件中注明置信度降低。
将外部链接（Confluence、Notion、GDrive）视为“不可验证——内容未评估”——标记为部分覆盖，而非未覆盖。
```
.health-docs/
```
目录是本Skill在目标仓库中的工作目录，不要将其视为文档层级结构的一部分。
凭证脱敏：在整合或复制任何内容前，扫描密钥、API密钥、令牌、密码、私钥和凭证信息。不要复制敏感内容，替换为
```
[已脱敏——潜在敏感内容位于 <源路径>:<行号>]
```
，并在运行记录中记录每一处脱敏。如果文件看起来是环境文件（
```
.env
```
、
```
.env.*
```
、
```
secrets.*
```
、
```
credentials.*
```
）或仅包含键值对形式的凭证，直接跳过该文件并在运行记录中注明，不要整合其内容。

Analyze Mode Workflow

分析模式工作流

Pass 1: Broad Scan and Regime Signal Detection

第1步：广泛扫描和监管体系信号检测

Inventory the repository without subagents:

Find all markdown files at every level (
```
**/*.md
```
)

Find all agent instruction files:

AGENTS.md

.github/copilot-instructions.md

.cursor/rules

.cursorrules

CLAUDE.md

Find CI/CD configs:

.github/workflows/

Jenkinsfile

.circleci/

Makefile

Detect existing documentation root: search for
```
docs/
```
,
```
documentation/
```
,
```
wiki/
```
,
```
doc/
```
in that precedence order. Select the first match by precedence (not filesystem order). If multiple directories exist, note the others in the artifact narrative. Record
```
null
```
in
```
doc_root_detected
```
if none are found.
Scan code and configuration for regime signals using
```
references/regime-signals.md
```
:
- PHI signals → HIPAA candidate (record confidence level and specific evidence)
- ONC/EHR API signals → ONC candidate
- SaMD/AI clinical signals → FDA SaMD candidate
Record all external links found in documentation (flag as unverifiable)

不使用子代理清点仓库内容：

查找所有层级的markdown文件（
```
**/*.md
```
）

查找所有Agent指令文件：

AGENTS.md

、

.github/copilot-instructions.md

、

.cursor/rules

、

.cursorrules

、

CLAUDE.md

查找CI/CD配置：

.github/workflows/

、

Jenkinsfile

、

.circleci/

、

Makefile

检测现有文档根目录：按优先级顺序搜索
```
docs/
```
、
```
documentation/
```
、
```
wiki/
```
、
```
doc/
```
，选择优先级最高的第一个匹配项（而非文件系统顺序）。如果存在多个目录，在工件描述中注明其他目录。如果未找到任何匹配，在
```
doc_root_detected
```
中记录
```
null
```
。
使用
```
references/regime-signals.md
```
扫描代码和配置中的监管体系信号：
- PHI信号 → 候选HIPAA合规（记录置信度和具体证据）
- ONC/EHR API信号 → 候选ONC合规
- SaMD/AI临床信号 → 候选FDA SaMD合规
记录文档中发现的所有外部链接（标记为不可验证）

Pass 2: Parallel Subagent Dispatch

第2步：并行调度子代理

Invoke available subagents in parallel against the Pass 1 file inventory. Dispatch only those relevant to detected signals:

Subagent	Condition	Invocation	Coverage dimensions fed
`$health-hipaa-review`	PHI signals found (see `references/regime-signals.md` )	"scoped review" + file list	`secure/` , `comply/hipaa/`
`$health-fhir-api-design`	FHIR or ONC signals found (FHIR resource types, SMART auth, EHR SDK imports, USCDI references)	"scoped review" + file list	`understand/integrations` , `comply/onc/`
`$health-human-factors`	UI source files found ( `.html` , `.tsx` , `.jsx` , `.vue` , `.erb` , or directories matching `app/views/` , `src/components/` , `templates/` )	"scoped review" + file list	`build/testing`

If a subagent is not installed: perform direct analysis for that dimension and note

confidence: reduced

in the artifact.

Translating subagent findings to coverage dimensions:

Each subagent returns a findings report. Translate to coverage dimensions using this mapping:

Subagent	Finding type	Coverage dimension
`$health-hipaa-review`	Access control / session management gaps	`secure/auth-model`
`$health-hipaa-review`	Audit log / retention gaps	`secure/audit-logs`
`$health-hipaa-review`	Encryption at-rest or in-transit gaps	`secure/encryption`
`$health-hipaa-review`	Risk analysis / risk management gaps	`comply/hipaa/risk-analysis` , `comply/hipaa/risk-management`
`$health-hipaa-review`	BAA / business associate documentation gaps	`comply/hipaa/baa-inventory`
`$health-fhir-api-design`	Integration / vendor API documentation gaps	`understand/integrations`
`$health-fhir-api-design`	SMART / bulk API access documentation gaps	`comply/onc/api-access`
`$health-human-factors`	Missing usability test docs / acceptance criteria	`build/testing`

For any finding that does not map to a row above, record the gap verbatim in the narrative and assign the closest matching dimension with

confidence: reduced

针对第1步清点的文件列表，并行调用可用的子代理。仅调度与检测到的信号相关的子代理：

子代理	触发条件	调用参数	覆盖维度
`$health-hipaa-review`	检测到PHI信号（参见 `references/regime-signals.md` ）	"范围审查" + 文件列表	`secure/` 、 `comply/hipaa/`
`$health-fhir-api-design`	检测到FHIR或ONC信号（FHIR资源类型、SMART认证、EHR SDK导入、USCDI引用）	"范围审查" + 文件列表	`understand/integrations` 、 `comply/onc/`
`$health-human-factors`	检测到UI源文件（ `.html` 、 `.tsx` 、 `.jsx` 、 `.vue` 、 `.erb` ，或匹配 `app/views/` 、 `src/components/` 、 `templates/` 的目录）	"范围审查" + 文件列表	`build/testing`

如果子代理未安装：对该维度执行直接分析，并在工件中注明

confidence: reduced

（置信度降低）。

将子代理的发现结果映射到覆盖维度：

每个子代理都会返回发现报告，使用如下映射关系转换为覆盖维度：

子代理	发现类型	覆盖维度
`$health-hipaa-review`	访问控制/会话管理缺口	`secure/auth-model`
`$health-hipaa-review`	审计日志/留存缺口	`secure/audit-logs`
`$health-hipaa-review`	静态加密/传输加密缺口	`secure/encryption`
`$health-hipaa-review`	风险分析/风险管理缺口	`comply/hipaa/risk-analysis` 、 `comply/hipaa/risk-management`
`$health-hipaa-review`	BAA/业务合作方文档缺口	`comply/hipaa/baa-inventory`
`$health-fhir-api-design`	集成/供应商API文档缺口	`understand/integrations`
`$health-fhir-api-design`	SMART/批量API访问文档缺口	`comply/onc/api-access`
`$health-human-factors`	缺失可用性测试文档/验收标准	`build/testing`

对于任何无法映射到上述条目的发现，在描述中逐字记录缺口，并分配最匹配的维度，同时标注

confidence: reduced

。

Pass 3: Synthesize Coverage Matrix

第3步：合成覆盖率矩阵

For each documentation dimension in

references/doc-hierarchy.md

, assign a coverage status:

Status	Meaning
`covered`	Exists, appears current and complete
`partial`	Exists but stale, thin, or incomplete — note what's missing
`conflict`	Multiple sources cover the topic with contradictory content
`absent`	No evidence found in the repository
`absent-required`	Absent and mandated by applicable regulation

Enumerate every dimension listed in

references/doc-hierarchy.md

in the coverage matrix — including

covered

dimensions. Do not omit covered entries. The complete matrix allows document mode to present an accurate inclusion/skip list to the user.

For each dimension, record:

dimension

: canonical ID matching the file path slug (e.g.,

secure/audit-logs

operate/runbooks/breach-notification

)

```
status
```
: one of the above
```
sources
```
: file paths and line ranges where related content was found (empty if absent)
```
regulatory
```
: applicable regulation and section (from
```
references/regulatory-mapping.md
```
), or
```
null
```
if none
```
required
```
:
```
null
```
— populated by document mode after the interview
```
confidence
```
:
```
high
```
,
```
medium
```
, or
```
reduced
```
(reduced if subagent was unavailable)

对于

references/doc-hierarchy.md

中的每个文档维度，分配覆盖状态：

状态	含义
`covered` （已覆盖）	内容存在，看起来是最新且完整的
`partial` （部分覆盖）	内容存在，但过时、单薄或不完整——注明缺失内容
`conflict` （冲突）	多个来源覆盖同一主题，但内容相互矛盾
`absent` （缺失）	在仓库中未找到相关证据
`absent-required` （必填缺失）	内容缺失且属于适用法规强制要求

在覆盖率矩阵中枚举

references/doc-hierarchy.md

中列出的所有维度——包括

covered

的维度，不要省略已覆盖的条目。完整的矩阵可以让文档模式向用户展示准确的包含/跳过列表。

每个维度需要记录：

dimension

：与文件路径slug匹配的标准ID（例如

secure/audit-logs

、

operate/runbooks/breach-notification

）

```
status
```
：上述状态之一
```
sources
```
：找到相关内容的文件路径和行范围（如果缺失则为空）
```
regulatory
```
：适用的法规和条款（来自
```
references/regulatory-mapping.md
```
），如果没有则为
```
null
```
```
required
```
：
```
null
```
——文档模式在访谈后填充
```
confidence
```
：
```
high
```
（高）、
```
medium
```
（中）或
```
reduced
```
（降低）（如果子代理不可用则为降低）

Write Handoff Artifact

写入交接工件

Write

.health-docs/analysis.md

with:

YAML frontmatter containing the structured coverage matrix (see Artifact Schema below)
Human-readable narrative body:
- Regime detection summary with evidence
- Coverage findings organized by dimension
- Conflicts and their sources
- External links flagged as unverifiable
- Priority gaps (absent-required items listed first)

写入

.health-docs/analysis.md

，包含以下内容：

YAML frontmatter，包含结构化覆盖率矩阵（参见下方工件 schema）
人类可读的描述正文：
- 监管体系检测摘要及证据
- 按维度组织的覆盖率发现结果
- 冲突及其来源
- 标记为不可验证的外部链接
- 优先级缺口（必填缺失项排在最前面）

Document Mode Workflow

文档模式工作流

Step 1: Read Handoff Artifact

第1步：读取交接工件

Read

.health-docs/analysis.md

. If it does not exist, tell the user to run analyze mode first.

Check the

generated_at

timestamp. If older than 90 days, warn the user that the analysis may be stale and recommend re-running analyze mode before proceeding.

If a

requirements

profile already exists in the artifact (from a previous document mode run), present it to the user and ask whether to use it or re-interview.

读取

.health-docs/analysis.md

，如果文件不存在，告知用户先运行分析模式。

检查

generated_at

时间戳，如果超过90天，警告用户分析可能已过时，建议先重新运行分析模式再继续。

如果工件中已经存在

requirements

配置文件（来自之前的文档模式运行），向用户展示并询问是使用该配置还是重新访谈。

Step 2: Evidence-Informed Interview (3 Confirmations)

第2步：基于证据的访谈（3项确认）

Present findings from the artifact and ask the user to confirm, not discover.

Confirmation 1 — Regime: Present the regime signals found with evidence and confidence levels. Example:

"I found these indicators: Patient model with MRN and DOB fields (src/models/patient.rb), FHIR R4 resources in src/fhir/, 'phi' in 14 variable names. I'm proposing HIPAA track. Correct?"

Confirmation 2 — Dimension inclusion: Show a fast-scan list of each dimension with proposed status (INCLUDE / SKIP / REVIEW). The user can override any entry. Mark regulatory-required dimensions that are absent as

INCLUDE ⚠ required

Confirmation 3 — Target directory:

If an existing documentation directory was detected in Pass 1, inform (no confirmation required): "Writing to
```
[detected-root]/
```
— your existing documentation root. Say otherwise to override." Do not wait for a response.
If no documentation directory was detected, require a response: "No documentation directory found. I'll create
```
docs/
```
. Use a different path?"

展示工件中的发现结果，要求用户确认，而非让用户自主发现。

确认1——监管体系： 展示检测到的监管体系信号、证据和置信度。示例：

"我发现了以下指标：包含MRN和DOB字段的患者模型（src/models/patient.rb）、src/fhir/目录下的FHIR R4资源、14个变量名中包含'phi'。我建议采用HIPAA跟踪，是否正确？"

确认2——维度包含： 展示每个维度的快速扫描列表及建议状态（包含/跳过/审核）。用户可以覆盖任何条目。将缺失的监管必填维度标记为

包含 ⚠ 必填

。

确认3——目标目录：

如果在第1步中检测到现有文档目录，告知用户（无需确认）："将写入
```
[检测到的根目录]/
```
——您的现有文档根目录。如需覆盖请说明。"无需等待响应。
如果未检测到文档目录，需要用户响应："未找到文档目录，我将创建
```
docs/
```
，是否需要使用其他路径？"

Step 3: Write Requirements Profile

第3步：写入需求配置文件

Write the confirmed

required: true/false

values for each dimension back into

.health-docs/analysis.md

frontmatter. This persists across sessions — future document mode runs skip the interview unless overridden.

将每个维度确认后的

required: true/false

值写回

.health-docs/analysis.md

的frontmatter中。该配置会跨会话保留——未来的文档模式运行会跳过访谈，除非用户覆盖。

Step 4: Pre-Flight Confirmation

第4步：前置确认

Before writing any files, show the full plan:

CONSOLIDATE (copying to target path — no rewrites; originals flagged in place):
  README.md:12-45      → docs/orient/README.md
  AGENTS.md:23-31      → docs/agent-context/phi-rules.md

MERGE (combining sources — conflicts flagged for your review):
  README.md:78-85  ⚠ CONFLICT  → docs/secure/auth-model.md
  AGENTS.md:23-31              (session timeout description differs)

DRAFT NEW (no existing source — requires human review where noted):
  docs/operate/runbooks/breach-notification.md    ← HIPAA §164.408 ⚠ REVIEW
  docs/comply/hipaa/risk-analysis.md              ← HIPAA §164.308 ⚠ REVIEW

SKIP (not required by your profile):
  docs/comply/onc/
  docs/comply/fda/

Proceed? [yes / no / edit plan]

Do not write any files until the user confirms.

在写入任何文件前，展示完整计划：

整合（复制到目标路径——不重写；原文件会被标记）：
  README.md:12-45      → docs/orient/README.md
  AGENTS.md:23-31      → docs/agent-context/phi-rules.md

合并（合并多个来源——冲突会标记供您审核）：
  README.md:78-85  ⚠ 冲突  → docs/secure/auth-model.md
  AGENTS.md:23-31              （会话超时描述不一致）

新起草（无现有来源——标注位置需要人工审核）：
  docs/operate/runbooks/breach-notification.md    ← HIPAA §164.408 ⚠ 需审核
  docs/comply/hipaa/risk-analysis.md              ← HIPAA §164.308 ⚠ 需审核

跳过（您的配置中未要求）：
  docs/comply/onc/
  docs/comply/fda/

是否继续？ [是 / 否 / 编辑计划]

用户确认前不要写入任何文件。

Step 5: Execute Plan

第5步：执行计划

Execute in strict order:

Consolidate — copy content from source locations to target paths. Do not rewrite — preserve substance, fix location. Do not delete the source file; the flag-originals step handles that. Add
```
⚠ REQUIRES HUMAN REVIEW
```
header to any
```
comply/
```
target file. Apply credential redaction before writing (see Operating Rules).

Merge — when multiple sources cover the same topic, merge them into the target file. Insert a visible conflict marker where descriptions differ:

<!-- ⚠ CONFLICT: session timeout described as 30min in README.md and 60min in AGENTS.md. Resolve before treating this document as authoritative. -->

Add

⚠ REQUIRES HUMAN REVIEW

header to any

comply/

target file.

Draft new — generate content for required dimensions with no source. Ground drafts in codebase evidence where possible. Add
```
⚠ REQUIRES HUMAN REVIEW
```
header to all
```
comply/
```
documents.
Flag originals — add a comment or note to original file locations indicating content was copied to the new path. Do not delete originals.

严格按顺序执行：

整合——将内容从源位置复制到目标路径。不要重写内容，保留实质，仅调整位置。不要删除源文件，标记原文件步骤会处理。为所有
```
comply/
```
目标文件添加
```
⚠ 需要人工审核
```
头部。写入前应用凭证脱敏规则（参见操作规则）。

合并——当多个来源覆盖同一主题时，将其合并到目标文件中。在描述不一致的位置插入可见的冲突标记：

<!-- ⚠ 冲突：README.md中描述会话超时为30分钟，AGENTS.md中描述为60分钟。将此文档作为权威版本前请先解决冲突。 -->

为所有

comply/

目标文件添加

⚠ 需要人工审核

头部。

新起草——为没有源内容的必填维度生成内容。尽可能基于代码库证据生成草稿。为所有
```
comply/
```
文档添加
```
⚠ 需要人工审核
```
头部。
标记原文件——在原文件位置添加评论或注释，说明内容已复制到新路径。不要删除原文件。

Step 6: Update Run Record

第6步：更新运行记录

Append a dated entry to

.health-docs/runs/YYYY-MM-DD.md

recording:

What was consolidated (source → target)
What was merged (sources → target, conflicts noted)
What was drafted (path, regulatory basis)
What was skipped
Any human review items outstanding

在

.health-docs/runs/YYYY-MM-DD.md

中追加带日期的条目，记录：

整合的内容（源→目标）
合并的内容（源→目标，注明冲突）
新起草的内容（路径、监管依据）
跳过的内容
所有待处理的人工审核项

Handoff Artifact Schema

交接工件Schema

The

.health-docs/analysis.md

file uses YAML frontmatter for structured data and a markdown body for human narrative.

yaml

---
generated_at: "2026-03-28T14:00:00Z"
schema_version: "1"

regime_detected:
  hipaa:
    proposed: true
    confidence: high
    evidence:
      - "Patient model with mrn, dob fields (src/models/patient.rb:12)"
      - "'phi' in 14 variable names"
  onc:
    proposed: true
    confidence: medium
    evidence:
      - "SMART on FHIR scopes in config/oauth.yml"
  fda_samd:
    proposed: false
    confidence: low
    evidence: []

doc_root_detected: "docs/"   # null if not found

coverage:
  - dimension: "understand/data-flows"
    status: "absent-required"
    sources: []
    regulatory: "HIPAA §164.308(a)(1)(ii)(A)"
    required: null          # populated by document mode
    confidence: high

  - dimension: "secure/audit-logs"
    status: "partial"
    sources:
      - path: "README.md"
        lines: "45-60"
        note: "mentions audit logging exists but no schema or retention policy"
    regulatory: "HIPAA §164.312(b)"
    required: null
    confidence: high

  - dimension: "comply/hipaa/baa-inventory"
    status: "absent-required"
    sources: []
    regulatory: "HIPAA §164.308(b)(1)"
    required: null
    confidence: high

requirements:               # populated after document mode interview
  interview_completed_at: null   # ISO 8601 timestamp, null until interview complete
  regime: []                     # confirmed regimes (e.g., ["hipaa", "onc"])
  dimensions: {}                 # dimension path → true/false
  human_review_required: []      # file paths requiring human sign-off

---

.health-docs/analysis.md

文件使用YAML frontmatter存储结构化数据，markdown正文存储人类可读的描述。

yaml

---
generated_at: "2026-03-28T14:00:00Z"
schema_version: "1"

regime_detected:
  hipaa:
    proposed: true
    confidence: high
    evidence:
      - "Patient model with mrn, dob fields (src/models/patient.rb:12)"
      - "'phi' in 14 variable names"
  onc:
    proposed: true
    confidence: medium
    evidence:
      - "SMART on FHIR scopes in config/oauth.yml"
  fda_samd:
    proposed: false
    confidence: low
    evidence: []

doc_root_detected: "docs/"   # 未找到则为null

coverage:
  - dimension: "understand/data-flows"
    status: "absent-required"
    sources: []
    regulatory: "HIPAA §164.308(a)(1)(ii)(A)"
    required: null          # 文档模式填充
    confidence: high

  - dimension: "secure/audit-logs"
    status: "partial"
    sources:
      - path: "README.md"
        lines: "45-60"
        note: "mentions audit logging exists but no schema or retention policy"
    regulatory: "HIPAA §164.312(b)"
    required: null
    confidence: high

  - dimension: "comply/hipaa/baa-inventory"
    status: "absent-required"
    sources: []
    regulatory: "HIPAA §164.308(b)(1)"
    required: null
    confidence: high

requirements:               # 文档模式访谈后填充
  interview_completed_at: null   # ISO 8601时间戳，访谈完成前为null
  regime: []                     # 确认的监管体系（例如["hipaa", "onc"]）
  dimensions: {}                 # 维度路径 → true/false
  human_review_required: []      # 需要人工签字确认的文件路径

---

Resources

资源

```
references/doc-hierarchy.md
```
: canonical seven-dimension documentation tree with target file paths, audience notes, and minimum required files
```
references/regime-signals.md
```
: PHI, ONC, and FDA SaMD signal patterns for Pass 1 detection
```
references/regulatory-mapping.md
```
: dimension → regulatory requirement mapping with classification (required / addressable / recommended)
```
examples/example-analysis.md
```
: sample analyze mode output narrative

examples/example-analysis-artifact.md

: sample

.health-docs/analysis.md

showing YAML structure pre- and post-interview

```
references/doc-hierarchy.md
```
：标准七维度文档树，包含目标文件路径、受众说明和最低要求文件
```
references/regime-signals.md
```
：第1步检测用的PHI、ONC和FDA SaMD信号模式
```
references/regulatory-mapping.md
```
：维度→监管要求映射，包含分类（必填/可寻址/推荐）
```
examples/example-analysis.md
```
：分析模式输出描述示例

examples/example-analysis-artifact.md

：

.health-docs/analysis.md

示例，展示访谈前后的YAML结构

Output Contract

输出契约

Analyze mode

分析模式

Writes
```
.health-docs/analysis.md
```
with YAML frontmatter (coverage matrix) and human narrative
No other files written

写入包含YAML frontmatter（覆盖率矩阵）和人类可读描述的
```
.health-docs/analysis.md
```
不写入其他任何文件

Document mode

文档模式

Writes or updates files within the target documentation directory
Updates
```
.health-docs/analysis.md
```
with requirements profile
Appends to
```
.health-docs/runs/YYYY-MM-DD.md
```
with run record
Does not modify code, tests, or configurations
Does not delete original files — flags them for human-reviewed cleanup

在目标文档目录内写入或更新文件
用需求配置文件更新
```
.health-docs/analysis.md
```
向
```
.health-docs/runs/YYYY-MM-DD.md
```
追加运行记录
不修改代码、测试或配置
不删除原文件——仅标记供人工审核后清理