zh-ebn-report

台湾看護実証レポート作成コーチ（台湾向けエビデンスに基づく看護レポート作成コーチ）

このスキルは、台湾の看護師が台湾看護学会および台湾実証看護学会の審査基準に沿った実証レポートを作成できるよう支援します。実証読書レポートと実証事例分析の2種類を扱います。最終的な目的は、看護師が N2/N3/N4 の上級審査に合格する、または投稿可能な学術成果を作成することです。

このスキルが扱うレポートの種類

台湾の実証看護分野では、主に次の2種類が入門編として扱われています。

種類	違い	対応レベル	分量
実証読書レポート（EBR）	複数の文献を評価したうえで論理的に統合します。事例への適用はありません	主に N1、N2	約 8～15 ページ
実証事例分析（EBP case analysis）	実証結果を実在する患者1名に適用し、効果を評価します	N3 以上	約 15～25 ページ

N4 以上では、多くの場合、システマティックレビューまたは看護プロジェクト研究に進むため、このスキルでは扱いません。

執筆前の状況確認

執筆を始める前に、使用するテンプレートと詳しさを決めるため、次の4点をユーザーに確認してください。

1. どの種類のレポートを作成しますか？（読書レポート／事例分析）
2. どの段階の上級審査ですか？（N1～N4、または投稿コンテスト）
3. 病棟の種類と事例の条件は何ですか？（テーマの妥当性と実現可能性を判断します）
4. 病院指定の書式テンプレートはありますか？（ある場合は病院のテンプレートを優先し、このスキルで内容を補います）

これらがまだ決まっていない場合は、すぐに草稿を書き始めず、まず ask_user_input_v0 ツールで質問してください。

中核となるワークフロー：実証 5A ステップ

すべての実証レポートは、次の5つのステップを軸に進めます。どれも欠かせません（読書レポートは Appraise まででよく、事例分析では5つすべてを実施する必要があります）。

1. Ask — 回答可能な臨床疑問を形成します（PICO）
2. Acquire — 最良の文献エビデンスを検索します
3. Appraise — エビデンスを厳密に評価します（CASP + Oxford エビデンスレベル）
4. Apply — 事例に臨床適用します（事例分析のみ）
5. Audit — 結果を評価します（事例分析のみ）

各ステップの詳しい進め方、よくある誤り、文例については、対応する reference ファイルを参照してください。

自動化 Pipeline と HITL 審査者の役割分担

このスキルでは、プロジェクトのルートにある src/zh_ebn_report/ の Python CLI zh-ebn-report と連携し、10名の名前付き subagent が分担してレポートの草稿を作成します。ユーザーの役割は「執筆者」から「HITL 審査者」へと変わります。9つの checkpoint で判断、承認、または書き直しの依頼を行いますが、最終的な文章は学術倫理に従い、自分の言葉で書き直して提出する必要があります。

Subagent の分担（詳しくは references/subagent-roles.md を参照してください）：

#	役割	並行？
1	テーマゲートキーパー	いいえ
2	PICO 構築担当	いいえ
3	検索ストラテジスト	いいえ
4	CASP 評価担当 × N	はい
5	統合担当	いいえ
6	セクション執筆担当 × 4–6	はい
7	文体ゲートキーパー	8と並行
8	APA 7 フォーマット担当	7と並行
9	事例ナラティブ担当 (事例分析)	10と並行
10	適用監査担当 (事例分析)	9と並行

dispatch の原則：互いの入力に依存しない agent は、必ず並行して呼び出してください（Phase 4 の複数文献の CASP、Phase 6 の各セクション、Phase 7 の文体+APA、Phase 5.5 の事例+適用）。Claude が対話形式で支援する場合も、同じロジックに従ってください。

CLI インターフェース：

zh-ebn-report init --type reading|case --topic "..."
zh-ebn-report run  --resume <run-id>              # end-to-end
zh-ebn-report topic|pico|search|appraise|synthesise|write|check|render
zh-ebn-report render --final                        # 去 DRAFT 後綴（需已 review）
zh-ebn-report status <run-id>

LLM バックエンド（v0.6+）：pipeline はデフォルトで Claude Code CLI（お使いの Claude サブスクリプション）を利用するため、ANTHROPIC_API_KEY は必須ではありません。LLM_BACKEND 環境変数で切り替えます。

• LLM_BACKEND=claude_code（デフォルト）— subprocess で claude -p を呼び出し、サブスクリプションを利用します。PATH 上に claude CLI が必要です
• LLM_BACKEND=anthropic — Anthropic SDK を直接利用します。ANTHROPIC_API_KEY（または LLM_API_KEY）が必要で、CI やサブスクリプションのない環境に適しています
• LLM_BACKEND=auto — claude CLI の有無を検出して選択します

実装については clients/llm.py（Protocol + factory）、clients/claude_code_cli.py（CLI バックエンド）、clients/anthropic.py（SDK バックエンド）を参照してください。どちらのバックエンドも外部インターフェースは共通で、complete() / complete_json() を相互に利用できます。並行処理では、複数の LLM 呼び出しに対して複数の claude subprocess を起動し、max_parallel_casp などの config で実行数を制限します。

ガードレールの構造（v0.2+）：pipeline は LLM の自主性だけに頼ることはありません。prompt に記載された「必須条件」のうち、機械的に検証できるものには、それぞれ対応する Python ガードレールがあります。orchestrator 内で LLM の自己評価結果を上書きするか、compliance.check_sections で処理を止めます。

• pipeline/evidence_guard.py — Oxford Level が study_design の OCEBM 2011 上限を超えないようにします（コホート研究のメタ分析は Level I にできません）
• pipeline/synthesis_guard.py — CASP levels + 矛盾点から overall_evidence_strength を機械的に導出します
• pipeline/voice_scan.py — regex で禁止語をスキャンし、pass_threshold_met を再計算します
• pipeline/apa_guard.py — DOI 検証 + citation の存在確認 + LLM の format_issues に基づいて apa_pass を導出します
• pipeline/compliance.py — 文型、文字数、引用、匿名性、privacy、断定表現、citation の捏造を防ぐチェックを行います

回帰検証ツール：ガードレールを追加または変更するたびに実行してください。

python scripts/retro_validate.py

output/<run-id>/state.json の過去のデータをすべて読み込み、現行のガードレールを適用して、「当時これらのガードレールがあれば何を検出できたか」を報告します。(a) ガードレールが実際の違反を検出することの確認、(b) リグレッションの防止に使用します。CI 向けに --json を追加して出力し、--strict を追加すると、ガードレールによる検出が1件でもあれば終了コード 1 を返します。

台湾看護向け強化（v0.8+）：台湾の看護実践における3つの主要なニーズを対象とした専用サポートです。

1. 華藝 Airiti のインポート：RIS に加えて、CSV（Airiti の書誌エクスポートのデフォルト形式）に対応しました。

   • zh-ebn-report search <run-id> --airiti-csv <file.csv> — タイトル／著者／年／雑誌／DOI／抄録／種類を読み込みます
   • 「学位論文」を自動検出し、StudyDesign.OTHER + OxfordLevel.IV に固定します（学位論文は査読を経ていないため、レベルを引き上げてはいけません）
   • 中国語の著者名（張小明 などの CJK 文字のみの文字列）では、引用キーの姓として先頭2文字を自動的に使用し、元の split() による誤分割を解消します
   • エクスポート手順：Airiti Library にアクセス → 文献を選択 → 書誌管理 → CSV エクスポートを選択 → ダウンロード
   • 実装については clients/manual_import.py:_airiti_csv_to_records を参照してください

2. Gordon の11項目の機能的健康パターン：TWNA の事例報告／看護プロジェクトにおける 護理評估 セクションの標準的な構成です。

   • 参照：references/gordon-11-patterns.md（11項目の定義 + 主観的／客観的データのテンプレート + NANDA 診断との対応）
   • 執筆 role：prompts/section_writer_護理評估.md。LLM に各項目の S/O + 評価所見を順に出力するよう指示します
   • Compliance：_check_gordon_11_coverage が 護理評估 セクションをスキャンし、重要語が11項目中9項目以上含まれているかを確認します（柔軟な基準で、第9項目の性・生殖は急性期／幼児の状況では省略できます）
   • twna_case / twna_project タイプにのみ適用し、reading/case タイプでは必須にしません

3. AI 關鍵字調整（keyword tuner）：PubMed 初次檢索若落在 100–1000「甜蜜區」之外，可選啟用一輪 LLM 調整。

   • 啟用：ENABLE_KEYWORD_TUNER=1（預設關）
   • 觸發條件：初輪 hits < 50（太窄）或 > 5000（太寬）
   • 調整員：prompts/keyword_tuner.md（Haiku 等級，只改 Boolean 字串）
   • 決策：pipeline/keyword_tuner.pick_better 挑離甜蜜區較近的那一版；SearchHistoryRow.note 兩輪都記錄，審計可見
   • 上限 1 輪；第二輪仍超出就接受現況、不再呼叫 tuner（控成本）

Audit Artifact Store（v0.7+）：每個 run 在 output/<run-id>/artifacts/ 留一整組中間產物供日後審查：

artifacts/
  _index.jsonl                  # append-only 所有 artifact 的紀錄（timestamp, category, path, meta）
  blobs/<sha256>.txt            # 內容定址儲存（system prompt 60KB × 30 次只存 1 份）
  llm/<ISO>_<caller>_<tier>_<id>.json  # 每次 LLM 呼叫的完整記錄
  guardrails/<name>/<ISO>_{before,after,summary}.json  # 每道 guardrail 的 before/after/summary

LLM record 含：呼叫者函式名（自動偵測 stack）、tier、model、backend（anthropic / claude_code）、duration_ms、system prompt hashes、user msg hash、response raw hash、response_parsed。Guardrail 紀錄讓「LLM 原始判讀 vs Python 覆寫後」兩個版本都保留。

實作見 pipeline/audit.py（ArtifactStore）與 clients/audited.py（AuditedLLMClient）。Orchestrator 在每個 phase 入口呼叫 _bind_to_run(state) 建立對應 run 的 store，LLM 與 guardrail 呼叫透明落檔。

Pipeline 最終輸出 <報告>-DRAFT.docx（Quarto → pandoc → DOCX，APA 7 CSL 引文排版），含搜尋歷程表、CASP 評讀表、PRISMA 風格流程圖、AI 協作聲明頁。若 templates/reference.docx（可選）存在，將做為樣式母本套用院內字型與樣式；否則以 pandoc 預設樣式輸出。

倫理守則（依 2026 年台灣護理學會與台灣實證護理學會規範；詳見 references/ai-disclosure.md）：

• AI 可以完全生成草稿，但使用者必須 audit、揭露、承擔責任
• CLI 啟動必須傳 --i-accept-audit-responsibility flag；未傳不執行
• Pipeline 自動附三份必要文件：AI 使用揭露段落（研究方法/致謝）、Audit 責任聲明（封面或末頁）、Subagent 執行紀錄（補充資料）
• 檔名預設帶 -DRAFT；使用者完成審稿並明確勾選「已審閱」後以 render --final 去除後綴
• AI 不得列為作者；揭露段落須載明工具名稱、模型、版本、具體使用方式

使用這份技能的流程

根據使用者所處的階段，以下列次序提供協助：

情境 A：使用者還在選題

先讀 references/topic-selection.md，幫使用者判斷題目可不可行。避免五大地雷主題（文獻極少、爭議太大、倫理敏感、無法操作、不是護理專業範疇）。

本階段 dispatch：題目守門員（Subagent 1）→ CP1。

情境 B：使用者已有題目，要設 PICO

讀 references/pico-and-search.md，套用 PICO 結構，注意：

• 中英並列（審查者要看英文關鍵字）
• 標明問題型態（治療型 Therapy / 傷害型 Harm / 診斷型 Diagnosis / 預後型 Prognosis）
• Outcome 盡量量化、可觀察

本階段 dispatch：PICO 建構員（Subagent 2）→ CP2。

情境 C：要做文獻搜尋與評讀

讀 references/pico-and-search.md（搜尋策略）與 references/appraisal-tools.md（評讀工具與證據等級）。

關鍵提醒：

• 搜尋歷程要可重現：資料庫、關鍵字、布林邏輯、欄位碼、Limits、起始篇數、去重後篇數、排除條件、納入篇數全部要交代
• 六件套搜尋策略：主詞 / 同義字 / MeSH / CINAHL Heading / Boolean / 欄位碼
• 初始篇數以 100–1000 為甜蜜區，不在此範圍記錄迭代調整
• 引文追蹤：正向（Google Scholar「Cited by」）+ 反向（reference list）皆做過
• DOI 逐篇驗證（pipeline 自動走 CrossRef；手動可 https://doi.org/<DOI>）
• 評讀工具對應研究設計：RCT 用 CASP RCT、系統性回顧用 CASP SR、質性研究用 JBI
• 證據等級依 Oxford 2011 準則

本階段 dispatch：搜尋策略師（3）→ CP3 → CP4 → CASP 評讀員 × N 並行（4）→ CP5。

情境 D：要把實證結果用到個案（案例分析核心）

讀 references/case-report-template.md。注意護理報告獨有的要求：

• 要有護理師原話的直接引語
• 要有個案/家屬原話的直接引語（用引號）
• 要有具體時間點的評估紀錄
• 結果要客觀可測量 + 主觀感受並陳
• 個案資料必須已去識別化（姓名、病歷號、身分證字號全去除）才能進入此階段

本階段 dispatch：綜整整合員（5）→ CP6 → 個案敘事員 + 應用審計員（9、10）並行 → 分節撰寫員 × 6 並行（6）→ CP7。

情境 E：要寫結論與討論

讀 references/phrasing-bank.md。結論段的標準動作：

1. 回應 PICO 的結論
2. 承認研究限制
3. 本地脈絡考量（不能貿然全面推翻護理常規）
4. 對未來臨床與教育的建議

本階段 dispatch：分節撰寫員（6，結論節）→ 語氣守門員 + APA 7 格式員（7、8）並行 → CP8 → Quarto render → CP9。

寫作風格的核心守則

台灣實證護理報告有一套非常固定的「腔調」，不符合會被當成外行。核心原則：

自稱用「筆者」，不用「我」。

個案不叫「病人」，叫「個案」或「案○」（案母、案父、案兄等）。

動詞偏書面語：

• 不寫「我找了幾篇文章」→ 寫「運用實證方法檢索相關文獻」
• 不寫「病人說他不想躺」→ 寫「個案主訴無法配合長時間平躺」
• 不寫「我覺得應該這樣做」→ 寫「綜整實證結果，建議⋯⋯」

引用文獻中文在前、英文在後，依 APA 第 7 版格式。中文依姓氏筆劃、英文依字母排序。

盡量引用近 5 年文獻，除非是重要的經典研究。

更多句型範例見 references/phrasing-bank.md。

審查通過率最高的寫作策略

根據歷年通過的範本歸納，以下做法最能提升通過率：

1. 題目要具體而不宏大。「如何減少術後感染」會被退，「在腹部手術後成人，嚼口香糖與一般照護對恢復腸蠕動之效果比較」才會過。

2. 搜尋歷程越透明越好。表格呈現：資料庫 / 關鍵字 / 初始篇數 / 排除條件 / 納入篇數。

3. 至少納入 2–4 篇高證據等級文獻。Oxford Level I–II（RCT、SR、MA）為主。若文獻極少，可放寬到觀察型研究，但要在討論段說明。

4. CASP 評讀表要完整附上，不能只寫「本文獻效度尚可」這種含糊語言。

5. 案例分析要有真實的應用記錄。審查者最討厭看到「計畫要做但沒做」或「應用結果與文獻完全一致」這種過度完美的敘述。有偏差才合理，偏差要能解釋。

6. 討論段要體現反思。不要只說「實證結果很棒，以後都這樣做」。要承認在地限制、機構文化、個別差異。

7. AI 協作的新規範（2026 版）：台灣護理學會與台灣實證護理學會已明文允許使用生成式 AI 輔助寫作，條件是：

   • AI 不得列為作者
   • 必須在研究方法或致謝段主動揭露 AI 工具名稱、版本、具體使用方式
   • 作者必須逐節審閱與修訂 AI 產出之內容
   • 作者必須聲明「已審閱並修訂 GenAI 產出之內容，並對本文內容的真實性與準確性承擔全部責任」
   • 建議將 AI 輔助生成的部分作為補充資料一併提交

   換句話說：AI 可以幫你把糊的題目變好題目、生成完整草稿，但你必須讀過、改過、簽名負責。這份技能的目標就是提供符合此規範的 AI 協作 pipeline（詳見 references/ai-disclosure.md）。

常見陷阱與錯誤

• PICO 的 Comparison 寫錯。Comparison 不是「無介入」，而是「現行照護標準」或「另一種介入」。
• 把實證讀書報告寫成一般文獻回顧。讀書報告要評讀、要綜整、要有結論建議，不是單純摘要文獻。
• 證據等級亂標。Oxford 2011 版是目前主流，不要用舊版 1–4 級。
• CASP 表直接打勾沒說明。每題都要寫簡短說明，特別是「不清楚」的項目。
• 個案資料暴露。姓名、病歷號、具體身分特徵一定要去識別化。
• 參考文獻沒用 APA 第 7 版。2020 年後一律用 APA 7，不要用 APA 6。

參考文件索引

本技能附帶以下 reference 檔案，視需要載入：

• references/case-report-template.md — 實證案例分析完整模板（最常用）
• references/reading-report-template.md — 實證讀書報告模板
• references/pico-and-search.md — PICO 設定與文獻搜尋策略（含六件套、欄位碼、100–1000 校準、引文追蹤、DOI 驗證）
• references/appraisal-tools.md — CASP 評讀表與 Oxford 證據等級
• references/phrasing-bank.md — 台灣護理報告標準句型庫
• references/topic-selection.md — 選題指引與地雷主題
• references/subagent-roles.md — 10 個 subagent 分工與輸入/輸出契約（Python pipeline 對應）
• references/ai-disclosure.md — 2026 版台灣護理 AI 使用規範與揭露/Audit/Subagent 紀錄的三份模板
• references/gordon-11-patterns.md — Gordon 11 項功能性健康型態（TWNA 護理評估節標準骨架）

看到使用者的需求後，先決定要讀哪幾份 reference，不要全部塞進脈絡。

最終輸出

完成草稿後，提供：

1. 完整的報告文件（建議用 .docx 格式，因為醫院多半要求紙本交件）
2. 獨立的參考文獻清單（方便檢查 APA 格式）
3. 搜尋歷程的表格（方便附錄）
4. CASP 評讀表（方便附錄）

如果使用者還需要投影片版本（口頭報告用），提供 15 分鐘簡報的綱要：臨床情境 2 min → PICO 與搜尋 3 min → 證據摘要 5 min → 應用結果 4 min → 結論建議 1 min。

---

記住：這份技能的價值在於讓 AI 與人類護理師合作產出可通過審查的實證報告。依 2026 年台灣護理學會與台灣實證護理學會規範，AI 可協助生成完整草稿；人類護理師以 HITL checkpoint 逐節 audit、修訂、加入個人臨床觀察、簽名負責。最終送審文件需附 AI 使用揭露段落與 Audit 責任聲明（詳見 references/ai-disclosure.md）。