kotonoha 0.2.0 → 0.3.0

package/skills/consulting-analyst/references/handoff-contract.md

@@ -0,0 +1,90 @@
+# Analysis handoff contract
+
+The handoff transfers reasoning and evidence without transferring ownership
+of final prose or presentation design.
+
+## Required fields
+
+`synthesis-handoff.md` must include:
+
+- Decision-maker and decision question
+- Intended outcome and deadline
+- Recommended answer and confidence
+- Supporting issue, hypothesis, finding, source, and evidence IDs
+- Assumptions and estimates
+- Counterevidence and alternative interpretations
+- Options, criteria, weights, and sensitivity when applicable
+- Current, target, gap, intervention, and action IDs when applicable
+- Risks, unresolved questions, and evidence-gathering actions
+- Required destination and target doctype or presentation purpose
+- Frozen items the receiving skill must preserve
+
+## ID semantics and traceability
+
+- `Q` identifies an issue; `HYP` a hypothesis; `FND` a synthesized finding.
+- `SRC` identifies a source record; `EVD` an analysis evidence record linked
+  to its source. Never rename a source record to `EVD` or overwrite analysis
+  evidence with a source citation.
+- `GAP` identifies a current-to-target gap; `INT` an intervention defined in
+  Current–Target–Gap; `CRT` an option criterion; `ACT` a recommended action.
+- Findings preserve their Q / HYP and EVD links and reference relevant
+  GAP / INT / CRT IDs. Actions link to supporting FND IDs, related Q / HYP
+  IDs, and applicable GAP / INT / CRT IDs. Transition risks reference the
+  affected GAP / INT IDs.
+- Preserve this chain in destination documents. Blueprint traceability keeps
+  relevant Q / HYP / FND / EVD and GAP / INT / CRT alongside its driver,
+  principle, capability, workstream, and KPI IDs. White Paper claims link
+  relevant HYP / FND / EVD IDs, while source records remain SRC IDs.
+- Use only defined, relevant IDs. Mark inapplicable links `N/A` with a reason;
+  do not require consulting IDs when no consulting handoff exists.
+
+If `Analysis status` is `Incomplete`, the receiving skill must either return
+the decision-critical gaps for further analysis or visibly preserve the
+incomplete status, evidence gaps, confidence, and conditional nature of every
+affected conclusion. It must not convert an incomplete handoff into an
+unqualified recommendation.
+
+## Handoff to tech-writer
+
+`tech-writer` owns document structure, doctype completeness, Markdown, and
+reader-facing prose. It may:
+
+- Reorder analysis to fit the doctype
+- Rename headings
+- Condense repeated evidence
+- Add doctype-required metadata and controls
+
+It must not:
+
+- Change evidence IDs or source meaning
+- Present assumptions as facts
+- Remove counterevidence that affects the conclusion
+- Change criteria, weights, scores, confidence, or recommendation without
+  returning the change to analysis
+
+## Handoff to presentation-planner
+
+`presentation-planner` owns audience reasoning, scenario, slide order, and
+visual handoff. It may:
+
+- Select the shortest evidence set that supports the audience decision
+- Split findings across slides
+- Adapt the order for the audience's prior knowledge
+
+It must preserve:
+
+- The decision question and requested action
+- Evidence status and confidence
+- Material caveats and counterevidence
+- Option-comparison logic
+- Conditions that would change the recommendation
+
+## Return conditions
+
+Return the handoff to `consulting-analyst` when:
+
+- A new conclusion is required
+- New evidence changes confidence or ranking
+- The audience asks a different decision question
+- Criteria or target-state dimensions change
+- Communication edits expose a contradiction in the analysis

package/skills/japanese-prose/SKILL.md

@@ -87,7 +87,10 @@ converge and list the unresolved items.
 When strong emphasis touches surrounding prose, put half-width spaces outside
 the delimiters: `これは **重要** です`, not `これは**重要**です`. Spaces are
 unnecessary at line boundaries or next to punctuation, and must not be placed
-inside `**`.
+inside `**`. Use ASCII spaces (`U+0020`), never full-width spaces (`U+3000`),
+tabs, or non-breaking spaces, immediately before and after emphasis embedded
+in prose. Write `これは **「重要」** と説明する`, not
+`これは　**「重要」**　と説明する`.
 
 ## Diagnostic interpretation
 

package/skills/presentation-planner/SKILL.md

@@ -36,6 +36,20 @@ Read `references/responsibility-boundary.md` before acting. This skill owns:
 - Selection and adaptation of a packaged design specification
 - A deterministic handoff contract for the host's PPTX skill
 
+When a presentation request still lacks a defined decision question,
+evidence-backed findings, or option analysis, load kotonoha's sibling
+`consulting-analyst` skill first. Consume its `synthesis-handoff.md` rather
+than inventing business conclusions during storyline design. Preserve its
+evidence IDs, confidence, counterevidence, decision criteria, and conditions
+that would change the recommendation. If the sibling skill is absent, ask for
+the decision question and evidence or label conclusions as unverified.
+
+If the handoff status is `Incomplete`, either return decision-critical gaps
+for further analysis or show the incomplete status, evidence gaps, confidence,
+and conditional wording in the presentation plan. Return to analysis when
+new evidence, a different audience decision, changed criteria, or a
+contradiction would change the conclusion.
+
 This skill must not:
 
 - Create, edit, unzip, or inspect `.pptx` binaries

package/skills/tech-writer/SKILL.md

@@ -6,19 +6,21 @@ description: >-
   notes/CHANGELOG, user manuals/how-to guides, code comments/docstrings,
   requirements definitions, system designs, test plans, operations runbooks,
   migration plans, security designs/threat models, technical proposals,
-  RFI/RFP procurement documents, and Qiita/Zenn articles. Use for requests
+  Blueprints, White Papers, RFI/RFP procurement documents, and Qiita/Zenn
+  articles. Use for requests
   like "write a README", "draft a design doc", "define system requirements",
   "write a system design", "create a test plan", "write an operations
   runbook", "plan a migration", "create a threat model", "write a technical
-  proposal", "draft an RFI", "create an RFP", "write this PR description",
-  "clean up my commit
+  proposal", "create a Blueprint", "write a White Paper", "draft an RFI",
+  "create an RFP", "write this PR description", "clean up my commit
   message", "make this how-to guide clearer", "write API docs", "summarize
   the release notes", "write a Zenn article", "write this up for Qiita", as
   well as
   Japanese-language equivalents (「READMEを書いて」「設計ドキュメントを作って」
   「要件定義書を作って」「システム設計書を書いて」「テスト計画書を作って」
   「運用設計書を書いて」「移行計画を作って」「脅威モデルを作って」
-  「技術提案書を書いて」「RFIを作って」「RFPを作って」「PRの説明文を書いて」
+  「技術提案書を書いて」「Blueprintを作って」「ホワイトペーパーを書いて」
+  「RFIを作って」「RFPを作って」「PRの説明文を書いて」
   「コミットメッセージを整えて」「手順書を分かりやすくして」
   「APIドキュメントを整備して」「リリースノートをまとめて」
   「Zennの記事を書いて」「Qiitaに投稿する記事を書いて」). Especially useful when
@@ -41,8 +43,8 @@ with the shortest path. Covers README, design docs/ADRs, API reference, PR
 descriptions/commit messages/issue reports, release notes/CHANGELOG, user
 manuals/how-to guides, code comments/docstrings, requirements definitions,
 system designs, test plans, operations runbooks, migration plans, security
-designs/threat models, technical proposals, RFI/RFP procurement documents,
-and Qiita/Zenn articles.
+designs/threat models, technical proposals, Blueprints, White Papers,
+RFI/RFP procurement documents, and Qiita/Zenn articles.
 
 Default format: Markdown for every doctype in this skill, except a git
 commit message body (plain text by convention — light "-" bullets are
@@ -54,18 +56,35 @@ reference files.
 
 ## Division of labor
 
-Document quality splits into two layers: "is the structure right" and "is
-the prose natural and readable". This skill owns the first layer (structure,
-document type conventions, completeness, reader fit). The bundled
-`japanese-prose` skill owns the second layer (sentence-level naturalness,
-reading load, terminology, and repeated-pattern analysis). Kotonoha packages
-both layers: tech-writer locks down the structure and orchestrates the §5
-handoff to japanese-prose during `write` mode before the final rubber-duck
-review.
+Document creation can span three layers: "is the reasoning defensible", "is
+the structure right", and "is the prose natural and readable". The bundled
+`consulting-analyst` skill owns problem decomposition, hypotheses, evidence,
+option evaluation, and synthesis when those are not yet settled. This skill
+owns structure, document type conventions, completeness, and reader fit. The
+bundled `japanese-prose` skill owns sentence-level naturalness, reading load,
+terminology, and repeated-pattern analysis.
+
+When a request for a Blueprint, White Paper, proposal, or decision document
+still lacks a defensible analysis, load the sibling `consulting-analyst`
+skill first and consume its `synthesis-handoff.md`. Do not silently invent
+the missing analysis inside document prose. If the sibling skill is absent,
+ask for the decision question and evidence or label analytical conclusions as
+unverified. Preserve issue, hypothesis, source, evidence, criterion, weight,
+score, confidence, counterevidence, and uncertainty records. Return the work
+to analysis when new evidence, a new decision question, changed criteria, or
+a contradictory conclusion requires analytical judgment.
+
+If the handoff status is `Incomplete`, either return the decision-critical
+gaps to `consulting-analyst` or preserve that status, the evidence gaps, the
+confidence, and conditional wording visibly in the document. Never turn an
+incomplete handoff into an unqualified recommendation. Tech-writer then locks
+down the document structure and orchestrates the §5 handoff to
+japanese-prose during `write` mode before the final rubber-duck review.
 
 - Rule of thumb: "does removing a heading still make sense?" tests structure
-  (this skill's job). "Does rereading a single sentence change its meaning?"
-  tests prose (not this skill's job).
+  (this skill's job). "Does the recommendation follow from evidence?" tests
+  analysis (`consulting-analyst`). "Does rereading a single sentence change
+  its meaning?" tests prose (`japanese-prose`).
 - Code comments/docstrings document code itself, but the same
   structure-and-completeness framing still applies.
 
@@ -110,7 +129,13 @@ hand the user a checklist to fill in. Instead:
    For a supplier response, structure the document against the supplied
    RFP's requirement IDs, requested proposal contents, pricing format, and
    contract deviations, then apply the general principles in
-   `references/style-constitution.md`.
+   `references/style-constitution.md`. For a bare "Blueprint" request, ask
+   whether the reader needs an integrated future state and transformation
+   path (`blueprint`), implementation-level system detail (`system-design`),
+   or approval for one investment (`technical-proposal`). For a bare "White
+   Paper" request, ask whether the goal is an evidence-led publication
+   (`white-paper`) or an internal approval request (`technical-proposal`);
+   do not treat a sales brochure as an evidence-led White Paper.
 2. Open the matching reference file and note its target reader and any
    "settle before writing" items. Combined with the general musts below,
    this is your information checklist — but never show it to the user as a
@@ -129,7 +154,10 @@ hand the user a checklist to fill in. Instead:
    approved requirements baseline for a system design, exit criteria for a
    test plan, RTO/RPO for an operations runbook, rollback conditions for a
    migration plan, assets and trust boundaries for a threat model, market
-   unknowns for an RFI, or evaluation rules for an RFP).
+   unknowns for an RFI, evaluation rules for an RFP, planning horizon,
+   approval authority, and baseline evidence for a Blueprint, or the central
+   claim, evidence standard, and publisher or sponsor conflicts for a White
+   Paper).
 5. **A "don't know" / "not applicable" / "no ticket for this" answer
    satisfies a must — it is not a reason to keep asking.** Ask that must
    at most once; if the answer is a non-answer, record it as a stated
@@ -162,6 +190,8 @@ hand the user a checklist to fill in. Instead:
 | Migration plan / 移行計画書 | migration-plan | `references/doctypes/migration-plan.md` |
 | Security design / Threat model / セキュリティ設計書 | security-design | `references/doctypes/security-design.md` |
 | Internal technical proposal | technical-proposal | `references/doctypes/technical-proposal.md` |
+| Blueprint / 将来構想・変革設計図 | blueprint | `references/doctypes/blueprint.md` |
+| White Paper / ホワイトペーパー | white-paper | `references/doctypes/white-paper.md` |
 | Request for information / RFI | rfi | `references/doctypes/rfi.md` |
 | Request for proposal / RFP | rfp | `references/doctypes/rfp.md` |
 | Zenn article | zenn | `references/doctypes/zenn.md` |
@@ -176,8 +206,8 @@ one-question-at-a-time intake for reader and outcome.
 For documents likely to run long — design docs/ADRs, user manuals with
 multiple steps, API references covering several endpoints, requirements
 definitions, system designs, test plans, operations runbooks, migration
-plans, security designs, technical proposals, RFI/RFP documents, or anything
-the user calls
+plans, security designs, technical proposals, Blueprints, White Papers,
+RFI/RFP documents, or anything the user calls
 "long"/"detailed"/"comprehensive" — draft a table of contents (heading
 outline) before writing any body prose.
 
@@ -207,7 +237,8 @@ document and needs the outline step below.
 For living, multi-section documents (README, design doc, API reference,
 release notes, user manual, requirements definition, system design, test
 plan, operations runbook, migration plan, security design, technical
-proposal, RFI/RFP, Zenn/Qiita article), write under the 8 rules
+proposal, Blueprint, White Paper, RFI/RFP, Zenn/Qiita article), write under
+the 8 rules
 in `references/style-constitution.md`. Summary: state "what this is" and
 "the outcome for the reader" in the first three lines; make headings
 labels that preview content (not "Overview", but "Overview of what");
@@ -225,7 +256,10 @@ For every Markdown doctype, surround `**strong emphasis**` with half-width
 spaces when the delimiters would otherwise touch prose. For example, write
 `これは **強調** になる`, not `これは**強調**にならない`. Spaces are not
 required at line boundaries or next to punctuation, and must not be placed
-inside the `**` delimiters.
+inside the `**` delimiters. Use ASCII spaces (`U+0020`), never full-width
+spaces (`U+3000`), tabs, or non-breaking spaces, immediately before and after
+emphasis embedded in prose. Write `これは **「重要」** と説明する`, not
+`これは　**「重要」**　と説明する`.
 
 For atomic artifacts (commit messages, PR descriptions, issue reports,
 code comments/docstrings, a single entry appended to an existing
@@ -373,8 +407,8 @@ for `write` mode; do not run it for `review` or `score` mode.
 See each reference file for detail. The items below are for living,
 multi-section documents (README, design doc, API reference, release notes,
 user manual, requirements definition, system design, test plan, operations
-runbook, migration plan, security design, technical proposal, RFI/RFP,
-Zenn/Qiita article). Atomic
+runbook, migration plan, security design, technical proposal, Blueprint,
+White Paper, RFI/RFP, Zenn/Qiita article). Atomic
 artifacts (commit message, PR
 description, issue report, code comment/docstring, a single appended
 release-notes entry) are already covered by their own doctype checklist

package/skills/tech-writer/assets/templates/blueprint.md

@@ -0,0 +1,187 @@
+# <Blueprint名>
+
+<対象読者、実現する将来像、この文書を使って合意する事項を3文以内で記載する。>
+
+- オーナー: <組織・役割>
+- 作成日: <YYYY-MM-DD>
+- 最終更新日: <YYYY-MM-DD>
+- 対象期間: <YYYY-MM-DD〜YYYY-MM-DD、または3年間など>
+- 対象範囲: <事業・組織・業務・データ・技術など>
+- ステータス: Draft / In Review / Approved / Rejected / Deferred / Superseded
+- 承認者・会議体: <名称>
+- 現行版: <版番号>
+- 置き換える文書: <文書名・版、または該当なし>
+- Analysis status: Completed / Incomplete / Not performed
+- Evidence gaps: <不足する証拠、影響する判断、収集担当・期限、またはなし>
+- 分析ハンドオフ: <synthesis-handoff.mdの所在、またはなし>
+
+`Analysis status`は文書の承認ステータスとは別に記録する。`Incomplete`の場合は、不足する証拠と確からしさを明示し、影響する結論・推奨事項を条件付きで記載する。判断を妨げる不足は`consulting-analyst`へ戻すか、この文書に残す。`Not performed`の場合は、分析未実施の範囲と理由を記載し、分析済みとして扱わない。
+
+## <このBlueprintで実現する成果>
+
+<対象期間の終了時に、誰が何を実現できる状態になるかを記載する。>
+
+| 成果ID | 期待する成果 | 現状値 | 目標値 | 測定方法 | 判定時期 | オーナー |
+|---|---|---:|---:|---|---|---|
+| OUT-001 | <成果> | <値> | <値> | <方法> | <時期> | <役割> |
+
+## 対象範囲と対象外
+
+### 対象範囲
+
+- <対象となる組織、能力、業務、データ、システム、地域>
+
+### 対象外
+
+- <このBlueprintでは扱わない事項と、その扱い先>
+
+### 前提条件と制約
+
+| ID | 種別 | 内容 | 根拠 | 変更時の影響 |
+|---|---|---|---|---|
+| CON-001 | 前提 / 制約 | <内容> | <資料・決定> | <影響> |
+
+## 変革を必要とする背景
+
+<外部環境、利用者ニーズ、経営課題、技術的負債、規制など、将来像が必要な理由を事実と解釈に分けて記載する。>
+
+| ドライバーID | ドライバー | 根拠 | 対応しない場合の影響 |
+|---|---|---|---|
+| DRV-001 | <変化・課題> | <データ・資料> | <影響> |
+
+## 設計原則
+
+| 原則ID | 原則 | 判断への適用方法 | 例外を認める条件 |
+|---|---|---|---|
+| PRN-001 | <原則> | <選択・優先順位への反映> | <条件と承認者> |
+
+## 現在地を示すベースライン
+
+### 現在の能力と成熟度
+
+| 能力ID | 能力 | 現状 | 成熟度 | 根拠 | 主な課題 |
+|---|---|---|---|---|---|
+| CAP-001 | <能力> | <現在の状態> | 1〜5 | <評価資料> | <課題> |
+
+### 現在の構成
+
+<業務、組織、データ、アプリケーション、基盤、セキュリティ、運用のうち、対象範囲に必要な現在の構成を示す。>
+
+```mermaid
+flowchart LR
+    A[<現在の利用者・業務>] --> B[<現在の能力・システム>]
+    B --> C[<現在の成果・制約>]
+```
+
+## 目標とする能力と将来像
+
+### 目標能力
+
+| 能力ID | 目標能力 | 提供する価値 | 対象者 | 成熟度目標 | 成功条件 |
+|---|---|---|---|---|---|
+| CAP-001 | <能力> | <価値> | <対象者> | 1〜5 | <測定可能な条件> |
+
+### 将来のOperating Model
+
+| 観点 | 将来の状態 | 主な変更 | 意思決定者 |
+|---|---|---|---|
+| 組織・役割 | <状態> | <変更> | <役割> |
+| 業務プロセス | <状態> | <変更> | <役割> |
+| ガバナンス | <状態> | <変更> | <役割> |
+| 人材・スキル | <状態> | <変更> | <役割> |
+
+### 将来のデータ・技術構成
+
+<技術が対象外の場合は、その理由と別文書を記載する。>
+
+```mermaid
+flowchart LR
+    A[<利用者・チャネル>] --> B[<目標能力>]
+    B --> C[<データ・サービス・基盤>]
+    C --> D[<測定可能な成果>]
+```
+
+| 構成要素 | 責任 | 原則・標準 | 詳細設計の所在 |
+|---|---|---|---|
+| <要素> | <責任> | <適用する原則> | <文書・未作成> |
+
+### セキュリティ・リスク・運用の将来像
+
+- セキュリティ: <信頼境界、責任分担、主要統制>
+- リスク管理: <識別、受容、軽減、報告の方法>
+- 運用: <所有権、監視、継続性、改善サイクル>
+
+## 現在地と将来像の差分
+
+| Gap ID | 関連能力 | 現在地 | 将来像 | 必要な変更 | 優先度 |
+|---|---|---|---|---|---|
+| GAP-001 | CAP-001 | <状態> | <状態> | <変更> | High / Medium / Low |
+
+## 変革ワークストリーム
+
+| WS ID | ワークストリーム | 解消するGap | 成果物 | オーナー | 依存関係 | 完了条件 |
+|---|---|---|---|---|---|---|
+| WS-001 | <名称> | GAP-001 | <成果物> | <役割> | <WS・外部条件> | <条件> |
+
+## 移行段階とロードマップ
+
+<日付だけでなく、各段階へ進む条件と完了条件を記載する。>
+
+| フェーズ | 目的 | 対象ワークストリーム | 開始条件 | 完了条件 | 目標時期 |
+|---|---|---|---|---|---|
+| Phase 1 | <目的> | WS-001 | <条件> | <測定可能な条件> | <時期> |
+
+### 移行中の共存と廃止
+
+- 共存が必要な状態: <旧新の併存、データ同期、二重運用>
+- 切り替え条件: <判断指標・承認者>
+- 廃止対象と条件: <業務・システム・契約・データ>
+- ロールバックまたは方針見直し条件: <条件>
+
+## ガバナンスと意思決定
+
+| 判断事項 | 決定者 | 提案者 | 相談先 | 報告先 | 判断時期 |
+|---|---|---|---|---|---|
+| <判断事項> | <役割> | <役割> | <役割> | <役割> | <時期> |
+
+### 例外と変更管理
+
+- 原則の例外申請: <手順・承認者>
+- Blueprint変更: <提案、影響分析、承認、版管理>
+- 下位文書との不整合: <検出・解消方法>
+
+## 成果の測定とレビュー
+
+| 指標ID | 関連成果 | 指標 | 目標 | データ源 | 頻度 | 未達時の対応 |
+|---|---|---|---:|---|---|---|
+| KPI-001 | OUT-001 | <指標> | <値> | <データ源> | <頻度> | <見直し・是正> |
+
+## リスクと未解決事項
+
+| ID | 種別 | 内容 | 影響 | 対応 | オーナー | 期限 |
+|---|---|---|---|---|---|---|
+| RSK-001 | リスク / 未解決事項 | <内容> | <影響> | <対応> | <役割> | <日付> |
+
+## トレーサビリティ
+
+分析ハンドオフがある場合は、関連するQ / HYP / FND / EVD / GAP / INT / CRT IDsを保持する。INTは介入、CRTは選択肢の評価基準を表す。該当しないリンクは理由付き`N/A`とし、ハンドオフがない場合は分析IDを無理に作らない。
+
+| 論点 Q IDs | 仮説 HYP IDs | 発見 FND IDs | 証拠 EVD IDs | ドライバー | 設計原則 | 目標能力 | Gap | 介入 INT IDs | 評価基準 CRT IDs | ワークストリーム | 指標 |
+|---|---|---|---|---|---|---|---|---|---|---|---|
+| <関連Q IDs、またはN/A> | <関連HYP IDs、またはN/A> | <関連FND IDs、またはN/A> | <関連EVD IDs、またはN/A> | DRV-001 | PRN-001 | CAP-001 | GAP-001 | <関連INT IDs、またはN/A> | <関連CRT IDs、またはN/A> | WS-001 | KPI-001 |
+
+## 承認と変更履歴
+
+### 承認
+
+ヘッダーのステータスと、次の承認結果を一致させる。承認結果が`Rejected`または`Deferred`の場合、ステータスを`Approved`にしない。
+
+| 役割 | 氏名・会議体 | 判断 | 日付 | 条件 |
+|---|---|---|---|---|
+| <役割> | <名称> | Approved / Rejected / Deferred | <YYYY-MM-DD> | <条件> |
+
+### 変更履歴
+
+| 版 | 日付 | 変更内容 | 変更者 | 承認者 |
+|---|---|---|---|---|
+| 0.1 | <YYYY-MM-DD> | 初版 | <氏名> | <氏名・会議体> |

package/skills/tech-writer/assets/templates/white-paper.md

@@ -0,0 +1,192 @@
+# <White Paperタイトル>
+
+<対象読者が抱える問題、本書の中心的な結論、読後に判断できることを3文以内で記載する。>
+
+- 発行者: <組織名>
+- 著者・監修者: <氏名・役割>
+- 発行日: <YYYY-MM-DD>
+- 最終更新日: <YYYY-MM-DD>
+- 版: <版番号>
+- ステータス: Draft / In Review / Approved for Publication / Withdrawn
+- 公開承認者: <氏名・役割・会議体>
+- 法務・コンプライアンス・主張レビュー: <レビュー者・該当なし>
+- 対象読者: <読者>
+- 対象地域・業界: <範囲>
+- 調査対象期間: <YYYY-MM-DD〜YYYY-MM-DD>
+- 公開区分: Public / Limited / Confidential
+- Analysis status: Completed / Incomplete / Not performed
+- Evidence gaps: <不足する証拠、影響する判断、収集担当・期限、またはなし>
+- 分析ハンドオフ: <synthesis-handoff.mdの所在、またはなし>
+
+`Analysis status`は公開承認ステータスとは別に記録する。`Incomplete`の場合は、不足する証拠と確からしさを明示し、影響する結論・推奨事項を条件付きで記載する。判断を妨げる不足は`consulting-analyst`へ戻すか、この文書に残す。`Not performed`の場合は、分析未実施の範囲と理由を記載し、分析済みとして扱わない。
+
+## 要旨
+
+<問題、調査・分析の範囲、主要な発見、結論、読者への示唆を300〜500字で記載する。本文を読まなくても中心的な判断が分かるようにする。>
+
+## 本書が答える問い
+
+- 中心的な問い: <読者が判断したい問い>
+- 中心的な主張: <証拠で支持または反証できる具体的な主張>
+- 読者に求める次の行動: <検討、評価、実証、導入判断など>
+
+## 対象範囲と用語
+
+### 対象範囲
+
+- 含む: <地域、業界、組織規模、技術、期間>
+- 含まない: <対象外と、その理由>
+- 情報の基準日: <YYYY-MM-DD>
+
+### 主要用語
+
+| 用語 | 本書での定義 | 類似語との違い |
+|---|---|---|
+| <用語> | <定義> | <違い> |
+
+## 調査・分析方法
+
+<どの情報を、どの基準で収集・評価・統合したかを記載する。>
+
+| 方法 | 対象・件数 | 選定基準 | 分析方法 | 主な制約 |
+|---|---:|---|---|---|
+| 文献調査 / インタビュー / データ分析 / 実証 | <対象> | <基準> | <方法> | <制約> |
+
+### 証拠の評価基準
+
+- 一次情報を優先する条件: <条件>
+- 情報の新しさを判断する基準: <基準>
+- 利害関係のある情報の扱い: <検証・注記方法>
+- 不一致または反証となる情報の扱い: <方法>
+
+## <問題が重要になる背景>
+
+<市場、制度、利用者、技術、運用などの変化を、出典付きの事実と分析者の解釈に分けて説明する。>
+
+## 調査から得られた主要な発見
+
+### <発見1を結論として表す見出し>
+
+<発見を最初に記載し、その後に証拠、解釈、適用範囲を説明する。>
+
+| 項目 | 内容 |
+|---|---|
+| 主張ID | CLM-001 |
+| 主張 | <具体的な主張> |
+| 関連仮説 HYP IDs | <関連HYP IDs、または理由付きN/A> |
+| 分析上の発見 FND IDs | <関連FND IDs、または理由付きN/A> |
+| 根拠 | EVD-001、EVD-002 |
+| 確からしさ | High / Medium / Low |
+| 適用範囲 | <どこまで当てはまるか> |
+| 制約・反証 | <弱める条件、矛盾する証拠> |
+
+### <発見2を結論として表す見出し>
+
+<必要な数だけ同じ構造で記載する。>
+
+## 選択肢と評価
+
+| 選択肢 | 適する状況 | 期待効果 | 費用・負担 | リスク | 根拠 |
+|---|---|---|---|---|---|
+| 現状維持 | <状況> | <効果> | <負担> | <リスク> | <証拠ID> |
+| <選択肢> | <状況> | <効果> | <負担> | <リスク> | <証拠ID> |
+
+## 推奨する考え方またはソリューションパターン
+
+<推奨事項を、適用条件とともに記載する。製品やサービスを例示する場合は、一般的な結論と製品固有の主張を分ける。>
+
+```mermaid
+flowchart LR
+    A[<課題・入力>] --> B[<推奨する能力・方式>]
+    B --> C[<期待する成果>]
+```
+
+### 適用条件
+
+- 適する条件: <条件>
+- 適さない条件: <条件>
+- 事前に検証する事項: <PoC・評価・法務確認など>
+
+## 導入・適用時に検討する事項
+
+| 観点 | 確認事項 | 判断材料 | 主なリスク |
+|---|---|---|---|
+| 組織・人材 | <確認事項> | <証拠・測定> | <リスク> |
+| 業務・ガバナンス | <確認事項> | <証拠・測定> | <リスク> |
+| データ・技術 | <確認事項> | <証拠・測定> | <リスク> |
+| セキュリティ・法令 | <確認事項> | <証拠・測定> | <リスク> |
+| 費用・運用 | <確認事項> | <証拠・測定> | <リスク> |
+
+## 事例または検証結果
+
+<事例、実証、シミュレーションのどれかを明示する。代表性を保証しない場合は、その制約を記載する。>
+
+| 項目 | 内容 |
+|---|---|
+| 対象 | <組織・環境・条件> |
+| 実施内容 | <方法> |
+| 結果 | <測定値> |
+| 比較基準 | <導入前・対照・目標> |
+| 制約 | <一般化できない理由> |
+| 出典 | <証拠ID・URL> |
+| 顧客名・数値・事例の掲載許諾 | <許諾者・許諾日・条件、または匿名化の方法> |
+
+## 反対意見・代替解釈・限界
+
+- 反対意見: <有力な異論と、その根拠>
+- 代替解釈: <同じ証拠から導ける別の結論>
+- データの限界: <欠損、偏り、サンプル、期間>
+- 将来変化する可能性: <技術、制度、市場など>
+- 結論を見直す条件: <新しい証拠・閾値>
+
+## 結論と次の判断
+
+<中心的な問いへの回答を簡潔に示し、対象読者が次に行う評価・合意・実証・意思決定を記載する。新しい主張は追加しない。>
+
+## 利害関係と開示
+
+- 発行者と対象製品・サービスの関係: <関係・該当なし>
+- 資金提供・協賛: <提供者・該当なし>
+- 著者の利害関係: <内容・該当なし>
+- データ提供者の関与: <収集、分析、レビューへの関与>
+- AI利用: <調査・執筆・翻訳・校正での利用範囲>
+
+## 証拠台帳
+
+SRCは出典の記録、EVDは分析上の証拠の記録を表す。分析ハンドオフがある場合は、関連するHYP / FND / EVD IDsを主張・発見に紐付け、元のIDと意味を保持する。出典をEVDに置き換えない。該当しないリンクは理由付き`N/A`とし、ハンドオフがない場合はHYP / FND IDsを無理に作らない。
+
+### 出典の記録
+
+| 出典ID | 出典 | 種別 | 発行日 | 参照日 | 関連する証拠ID | 品質・制約 |
+|---|---|---|---|---|---|---|
+| SRC-001 | <著者、資料名、URL> | 一次 / 二次 | <YYYY-MM-DD> | <YYYY-MM-DD> | EVD-001 | <評価> |
+
+### 分析上の証拠の記録
+
+| 証拠ID | 出典ID | 記述の種別 | 証拠または解釈 | 関連仮説 HYP IDs | 関連発見 FND IDs | 関連主張 | 品質・制約 |
+|---|---|---|---|---|---|---|---|
+| EVD-001 | SRC-001 | Fact / Estimate / Interpretation | <証拠、または解釈とその根拠EVD IDs> | <関連HYP IDs、またはN/A> | <関連FND IDs、またはN/A> | CLM-001 | <評価> |
+
+Interpretationは解釈として保持し、仮説を支持する証拠には数えない。`Supported`の仮説には、その仮説を支持するFact / EstimateのEVDが必要となる。
+
+## 参考文献
+
+1. <著者・組織>『<資料名>』<発行年>、<URL>（参照日: <YYYY-MM-DD>）
+
+## 公開承認とレビュー記録
+
+ステータスを`Approved for Publication`にするには、公開承認と、必須レビューの`Approved`または理由付き`N/A`が揃っていることを確認する。`Withdrawn`の場合は、撤回日と理由を記録する。
+
+| 種別 | レビュー者・承認者 | 対象 | 判断 | 日付 | 条件・N/Aの理由 |
+|---|---|---|---|---|---|
+| 公開承認 | <氏名・役割・会議体> | 文書全体 | Approved / Rejected | <YYYY-MM-DD> | <条件> |
+| 法務レビュー | <氏名・役割> | <対象箇所・文書全体> | Approved / Rejected / N/A | <YYYY-MM-DD> | <条件・N/Aの理由> |
+| コンプライアンスレビュー | <氏名・役割> | <対象箇所・文書全体> | Approved / Rejected / N/A | <YYYY-MM-DD> | <条件・N/Aの理由> |
+| 主張・数値検証 | <氏名・役割> | <CLM・EVD・事例ID> | Approved / Rejected / N/A | <YYYY-MM-DD> | <条件・N/Aの理由> |
+| 顧客名・事例掲載許諾 | <許諾者・確認者> | <事例・顧客名・数値> | Approved / Rejected / N/A | <YYYY-MM-DD> | <条件・匿名化・N/Aの理由> |
+
+## 変更履歴
+
+| 版 | 日付 | 変更内容 | 変更者 | レビュー者 |
+|---|---|---|---|---|
+| 0.1 | <YYYY-MM-DD> | 初版 | <氏名> | <氏名> |