kotonoha 0.1.1 → 0.1.4

package/skills/presentation-planner/references/handoff-contract.md

@@ -0,0 +1,49 @@
+# PPTX handoff contract
+
+Use this structure for
+`.presentation/<deck-slug>/pptx-handoff.md`.
+
+## Inputs
+
+- Brief: `<path>/presentation-brief.md`
+- Scenario: `<path>/presentation-scenario.md`
+- Slide outline: `<path>/slide-outline.md`
+- Design specification: `<path>/design-spec.yaml`
+- Source materials: `<paths>`
+
+## Output
+
+- PPTX path: `<path>/<filename>.pptx`
+- Aspect ratio: `<16:9 / 4:3 / custom>`
+- Expected slide count: `<count or range>`
+
+## Rendering requirements
+
+- Preserve slide order and assertion titles.
+- Preserve the approved scenario stages and audience reasoning journey.
+- Require every slide to map to at least one scenario stage; preserve
+  multi-stage mappings recorded with ` / ` in the outline.
+- Treat evidence and citation fields as content requirements.
+- Apply semantic design tokens from `design-spec.yaml`.
+- Add speaker notes where specified.
+- Add alt text or an equivalent description for informative visuals.
+- Do not invent quantitative claims or citations.
+
+## Required visual QA
+
+- Render every slide to an image or thumbnail.
+- Check clipping, overlap, off-canvas objects, font substitution, and
+  unreadable contrast.
+- Check charts for legible labels, units, legends, and source notes.
+- Check diagrams for readable flow direction and connector attachment.
+- Report every deviation from the outline or design specification.
+
+## Completion report
+
+Return:
+
+1. Output path and final slide count
+2. Visual QA result
+3. Missing or substituted assets/fonts
+4. Deviations from the scenario, outline, or design and their reasons
+5. Remaining manual-review items

package/skills/presentation-planner/references/responsibility-boundary.md

@@ -0,0 +1,32 @@
+# Responsibility boundary with the PPTX creation skill
+
+`presentation-planner` and the host's PPTX skill are complementary.
+
+| Concern | presentation-planner | PPTX creation skill |
+|---|---:|---:|
+| Audience, outcome, and decision | Owns | Consumes |
+| Scenario and audience reasoning journey | Owns | Preserves |
+| Storyline and slide sequence | Owns | Preserves |
+| Assertion titles and evidence mapping | Owns | Renders |
+| Design tokens and layout intent | Owns | Implements |
+| `.pptx` binary creation and editing | Never | Owns |
+| python-pptx/PptxGenJS/COM code | Never | Owns |
+| Theme/layout extraction from an existing PPTX | Requests and consumes summary | Owns |
+| Rendering and thumbnails | Never | Owns |
+| Overlap, clipping, and font checks | Defines acceptance criteria | Executes |
+| Speaker notes insertion | Specifies content | Implements |
+
+## Conflict rule
+
+If both skills could act, `presentation-planner` runs first and creates the
+handoff package. The PPTX skill starts only after the planning artifacts are
+complete. For a simple mechanical edit to an existing presentation where
+the storyline and design are unchanged, skip `presentation-planner` and use
+the PPTX skill directly.
+
+## Failure rule
+
+If the PPTX skill cannot implement a requested visual instruction, it must
+report the constraint and proposed fallback. The planning skill may update
+the design spec or slide outline, but it must not work around the constraint
+by manipulating the PPTX binary itself.

package/skills/presentation-planner/references/scenario-templates.md

@@ -0,0 +1,55 @@
+# Presentation scenario templates
+
+A presentation scenario defines the audience's reasoning journey between the
+brief and the slide-by-slide outline. It is not a script and does not repeat
+all slide content. It records the assertions, evidence, transitions,
+objections, and final action that make the deck persuasive and coherent.
+
+## Artifact boundary
+
+| Artifact | Question it answers |
+|---|---|
+| `presentation-brief.md` | Who is the audience, and what outcome is required? |
+| `presentation-scenario.md` | What reasoning journey moves them to that outcome? |
+| `slide-outline.md` | Which slides deliver each assertion and piece of evidence? |
+| `design-spec.yaml` | Which visual system expresses the content? |
+| `pptx-handoff.md` | How must the PPTX skill generate and validate the deck? |
+
+Do not use the scenario as a second slide outline. A scenario stage may span
+several slides, or two stages may share one slide when the argument remains
+clear.
+
+## Choose a template
+
+| Template | Use when | Avoid when |
+|---|---|---|
+| `executive-decision.md` | The audience must approve an option, investment, roadmap, or policy | The goal is purely educational |
+| `technical-briefing.md` | The audience must understand or review architecture and technical behavior | The deck is primarily KPI analysis |
+| `data-report.md` | Findings, trends, research, or experiments must support an action | Credible data is unavailable |
+
+Copy the closest template to
+`.presentation/<deck-slug>/presentation-scenario.md`, then remove stages that
+do not advance the required outcome. Do not add stages or slides merely to
+match the template.
+
+If none fits, create `presentation-scenario.md` from the generic fallback in
+`SKILL.md`, preserving the same stage, audience-question, assertion, evidence,
+transition, and suggested-slide-range fields used by packaged templates.
+
+## Adaptation rules
+
+- Express each stage as an assertion the audience must accept.
+- Record the audience question answered by each stage.
+- Map factual claims to sources or mark them as assumptions.
+- State the transition: why accepting one stage makes the next relevant.
+- Include objections, uncertainty, and trade-offs before the final action.
+- Keep the final decision or call to action singular and testable.
+- Set suggested slide counts only as planning ranges, never quotas.
+
+## Validation
+
+- Reading only stage assertions reconstructs the argument.
+- Every stage changes what the audience knows, believes, or is ready to do.
+- Evidence strength matches the certainty of the assertion.
+- The slide outline maps every slide to a scenario stage.
+- No slide introduces a new conclusion absent from the approved scenario.

package/skills/tech-writer/SKILL.md

@@ -3,15 +3,25 @@ name: tech-writer
 description: >-
   Helps structure and polish technical documents: README, design docs/ADRs,
   API reference, PR descriptions/commit messages/issue reports, release
-  notes/CHANGELOG, user manuals/how-to guides, code comments/docstrings, and
-  Qiita/Zenn articles. Use for requests like "write a README", "draft a
-  design doc", "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
+  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
+  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
+  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を書いて」「設計ドキュメントを作って」
-  「PRの説明文を書いて」「コミットメッセージを整えて」「手順書を分かりやすくして」
-  「APIドキュメントを整備して」「リリースノートをまとめて」「Zennの記事を書いて」
-  「Qiitaに投稿する記事を書いて」). Especially useful when
+  「要件定義書を作って」「システム設計書を書いて」「テスト計画書を作って」
+  「運用設計書を書いて」「移行計画を作って」「脅威モデルを作って」
+  「技術提案書を書いて」「RFIを作って」「RFPを作って」「PRの説明文を書いて」
+  「コミットメッセージを整えて」「手順書を分かりやすくして」
+  「APIドキュメントを整備して」「リリースノートをまとめて」
+  「Zennの記事を書いて」「Qiitaに投稿する記事を書いて」). Especially useful when
   the request is a bare goal without enough context to start (e.g. "I want
   to write a README" / "○○を書きたい"), since this skill drives a one
   question-at-a-time intake before writing. Supports both Japanese and
@@ -31,7 +41,10 @@ argument-hint: "[write|review|score] [doctype] <target file or request>"
 Structures technical documents so readers reach the information they need
 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, and Qiita/Zenn articles.
+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.
 
 Default format: Markdown for every doctype in this skill, except a git
 commit message body (plain text by convention — light "-" bullets are
@@ -62,9 +75,12 @@ first, then hand Japanese prose to natural-japanese for polish.
 Infer the mode from the argument or the request:
 
 - `write` (default): new document, or restructuring a draft. Runs the full
-  §1–§4 workflow, starting with the intake loop in §1.
+  §1–§5 workflow, starting with the intake loop in §1 and ending only after
+  the rubber-duck review loop has no remaining actionable findings. If an
+  independent review cannot run or cannot converge, returns the explicit
+  review status required by §5 instead of claiming a clean review.
 - `review`: structural review of an existing document. Does not rewrite;
-  reports the gap against the doctype checklist (§5).
+  reports the gap against the doctype checklist (§6).
 - `score`: structure-only quick diagnostic. Runs
   `scripts/lint.py --json <file>` and summarizes the findings (no rewrite).
 
@@ -87,7 +103,13 @@ hand the user a checklist to fill in. Instead:
    past this doctype without knowing which one applies. Similarly, a bare
    "write a tech blog post" request doesn't by itself say Qiita, Zenn, or
    neither — ask which platform (or "no platform, just a plain document")
-   as part of this same first question.
+   as part of this same first question. For a "technical proposal", ask
+   whether it is an internal approval proposal or a supplier response to an
+   RFP; only the internal approval proposal maps to `technical-proposal`.
+   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`.
 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
@@ -101,7 +123,12 @@ hand the user a checklist to fill in. Instead:
    doctype (and subtype, for `pr-commit`), and (d) any doctype-specific
    musts (e.g. the decision and alternatives for a design doc, the
    prior-knowledge floor for a user manual, breaking-change status for
-   release notes, the related issue for a PR description or bug report).
+   release notes, the related issue for a PR description or bug report,
+   measurable acceptance conditions for a requirements definition, the
+   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).
 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
@@ -110,7 +137,7 @@ hand the user a checklist to fill in. Instead:
    one-line note) and move on.
 6. **Once complete, do not ask the user to compose anything.** Synthesize
    the gathered answers into the best possible generation approach yourself
-   and immediately continue into §2–§4 in the same turn to produce the
+   and immediately continue into §2–§5 in the same turn to produce the
    document. Skip further confirmation unless the doctype is release-facing
    and consequential (e.g. a public release note with breaking changes) or
    the user explicitly asked to see a plan first.
@@ -127,6 +154,15 @@ hand the user a checklist to fill in. Instead:
 | Release notes / CHANGELOG | release-notes | `references/doctypes/release-notes.md` |
 | User manual / how-to guide / tutorial | user-manual | `references/doctypes/user-manual.md` |
 | Code comments / docstrings | code-comments | `references/doctypes/code-comments.md` |
+| Requirements definition / 要件定義書 | requirements-definition | `references/doctypes/requirements-definition.md` |
+| System design / システム設計書 | system-design | `references/doctypes/system-design.md` |
+| Test plan / テスト計画書 | test-plan | `references/doctypes/test-plan.md` |
+| Operations design / Runbook / 運用設計書 | operations-runbook | `references/doctypes/operations-runbook.md` |
+| 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` |
+| 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` |
 | Qiita article | qiita | `references/doctypes/qiita.md` |
 
@@ -137,9 +173,12 @@ one-question-at-a-time intake for reader and outcome.
 ## 2. Outline first for long documents
 
 For documents likely to run long — design docs/ADRs, user manuals with
-multiple steps, API references covering several endpoints, or anything the
-user calls "long"/"detailed"/"comprehensive" — draft a table of contents
-(heading outline) before writing any body prose.
+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
+"long"/"detailed"/"comprehensive" — draft a table of contents (heading
+outline) before writing any body prose.
 
 1. Build the heading outline from the reader and outcome gathered in §1 and
    the doctype's recommended skeleton (in its reference file).
@@ -165,7 +204,9 @@ document and needs the outline step below.
 ## 3. Write — under the structure constitution
 
 For living, multi-section documents (README, design doc, API reference,
-release notes, user manual, Zenn/Qiita article), write under the 8 rules
+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
 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");
@@ -221,11 +262,58 @@ step 2 as the primary check for those.
 4. **Reader-goal recheck**: confirm the "what the reader can do after
    reading" outcome from §1 is actually achievable from this document alone.
 
-## 5. Doctype checklist summary
+## 5. Rubber-duck review loop — write mode only
+
+After the structural review in §4, use the host's subagent mechanism to
+launch an independent reviewer in the `rubber-duck` role to challenge the
+completed document for meaningful problems that the authoring pass may have
+missed. Prefer a registered `rubber-duck` agent when the host provides one;
+otherwise use an independent general-purpose or critic-style subagent with
+the same review prompt. Treat the reviewer as unavailable only when the host
+has no independent subagent mechanism. Do not substitute the author's own
+self-review: independence is the point of this pass. This loop is mandatory
+for `write` mode; do not run it for `review` or `score` mode.
+
+1. **Start the review with full context**: give the reviewer the target file,
+   doctype, intended reader, one-sentence reader outcome from §1, and any
+   explicit constraints or assumptions. Ask it to report concrete,
+   actionable problems in correctness, logic, missing information, reader
+   flow, examples, and stated limitations — not cosmetic preferences.
+2. **Resolve every valid finding**: edit the document rather than merely
+   listing proposed fixes. If a finding conflicts with a stated requirement
+   or is factually inapplicable, record a one-line reason for declining it.
+3. **Re-run the relevant checks after each edit round**: repeat the doctype
+   checklist and structural lint from §4 before asking for another
+   rubber-duck review. A fix must not introduce a new structural defect.
+4. **Review again with the prior decisions**: reuse the same reviewer context
+   when supported. Otherwise, include the previous findings, applied fixes,
+   and declined findings with their reasons in every new review prompt. Ask
+   specifically for unresolved or newly introduced actionable findings.
+5. **Use a bounded convergence rule**: allow at most five rubber-duck rounds
+   for a living, multi-section document. For an atomic artifact, run one
+   round and finish immediately if it is clean; only continue after an
+   actionable finding, with a maximum of three rounds. A round is clean only
+   when no unaddressed actionable correctness, logic, completeness,
+   reader-flow, example, or limitation findings remain. A finding declined
+   with a recorded requirement-based or factual reason is a resolved
+   exception rather than an open finding. If another round runs, supply that
+   exception back to the reviewer under step 4. Purely cosmetic preferences
+   are not actionable.
+6. **Report non-clean outcomes precisely**: if the host has no independent
+   reviewer, label the result `review not performed` and do not claim the
+   rubber-duck pass completed. If the round limit is reached with
+   unaddressed actionable findings, or findings oscillate between
+   contradictory requirements, label it `review did not converge` and
+   include the latest unresolved findings and fixes already attempted.
+
+## 6. Doctype checklist summary
 
 See each reference file for detail. The items below are for living,
 multi-section documents (README, design doc, API reference, release notes,
-user manual, Zenn/Qiita article). Atomic artifacts (commit message, PR
+user manual, requirements definition, system design, test plan, operations
+runbook, migration plan, security design, technical proposal, 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
 via step 2 in §4 — these common items don't add extra requirements on top

package/skills/tech-writer/assets/templates/migration-plan.md

@@ -0,0 +1,173 @@
+# <システム・データ名> 移行計画書
+
+<何をどこからどこへ、どの停止許容時間と品質基準で安全に移行するかを3文以内で要約する。>
+
+- 文書版: <例: 1.0>
+- 作成日: <YYYY-MM-DD>
+- 最終更新日: <YYYY-MM-DD>
+- 移行責任者: <氏名・チーム>
+- Go / No-Go判断者: <氏名・会議体>
+- ステータス: Draft / In Review / Approved
+- 本番移行予定: <YYYY-MM-DD HH:mm–HH:mm TZ>
+- 関連要件・設計: <文書名・版・URL>
+
+## この移行計画で合意する事項
+
+- 移行対象: <データ、利用者、機能、外部接続>
+- 移行方式: <一括、段階、並行稼働など>
+- 許容停止時間と品質基準: <値>
+- 承認を求める事項: <日程、体制、判定、ロールバック>
+
+## 現行と移行後の状態
+
+| 項目 | 現行 | 移行後 | 主な変更 | 利用者への影響 |
+|---|---|---|---|---|
+| システム | <現行> | <移行先> | <変更> | <影響> |
+| データ | <形式・量> | <形式・量> | <変換> | <影響> |
+| 業務 | <手順> | <手順> | <変更> | <教育・周知> |
+
+## 対象範囲と対象外
+
+### 対象範囲
+
+- <移行するデータ・設定・利用者・接続先>
+
+### 対象外
+
+- <廃止しないもの・後続フェーズへ送るもの>
+
+## 前提条件と制約
+
+| ID | 条件・制約 | 確認方法 | 期限 | 所有者 |
+|---|---|---|---|---|
+| MIG-CON-001 | <停止時間・契約・技術制約> | <確認> | <期限> | <担当> |
+
+## 移行対象の棚卸し
+
+| 対象ID | 対象 | 移行元 | 移行先 | 件数・容量 | 所有者 | 依存関係 | 移行要否 |
+|---|---|---|---|---:|---|---|---|
+| MIG-001 | <データ・設定> | <場所> | <場所> | <値> | <担当> | <依存先> | Yes / No |
+
+## データマッピングと変換
+
+| 移行元項目 | 移行先項目 | 変換ルール | 必須・既定値 | 検証ルール | エラー時の扱い |
+|---|---|---|---|---|---|
+| <項目> | <項目> | <変換> | <条件> | <型・範囲・参照整合性> | <除外・補正・中止> |
+
+## 移行方式と移行単位
+
+- 方式: 一括 / 段階 / 並行稼働 / Blue-Green / <その他>
+- 選定理由: <停止時間、整合性、ロールバックとの関係>
+- 差分同期: <CDC、二重書き、再実行など>
+- 冪等性: <再実行しても重複・欠損しない仕組み>
+
+| Wave | 対象 | 実施日時 | 完了条件 | 次Waveへの判定 |
+|---|---|---|---|---|
+| 1 | <対象> | <日時> | <条件> | <条件> |
+
+## 体制と役割
+
+| 役割 | 担当 | 責任 | 当日の連絡方法 | 代行者 |
+|---|---|---|---|---|
+| 移行指揮 | <担当> | Go / No-Go、進行 | <方法> | <担当> |
+| データ移行 | <担当> | 抽出・変換・投入 | <方法> | <担当> |
+| 業務確認 | <担当> | 業務受入 | <方法> | <担当> |
+| 運用・監視 | <担当> | 監視・障害対応 | <方法> | <担当> |
+
+## リハーサル計画
+
+| 回 | 目的 | 対象・データ量 | 実施日 | 目標時間 | 合格条件 | 改善事項 |
+|---|---|---|---|---:|---|---|
+| 1 | <手順・性能・復旧の検証> | <範囲> | <日付> | <時間> | <条件> | <記録> |
+
+## 移行開始条件
+
+- <リハーサルが合格している>
+- <対象版が承認され、変更凍結されている>
+- <バックアップとリストア試験が完了している>
+- <監視、連絡網、ロールバック環境が準備されている>
+- <利用者通知と業務側の準備が完了している>
+
+## 本番移行タイムライン
+
+| 時刻 | 手順ID | 作業 | 実行者 | 想定時間 | 完了条件 | 証跡 |
+|---|---|---|---|---:|---|---|
+| <HH:mm> | STEP-001 | <作業> | <担当> | <分> | <確認可能な条件> | <ログ・画面> |
+
+## 検証と照合
+
+| 検証ID | 対象 | 検証方法 | 移行前値 | 移行後値 | 許容差 | 判定者 |
+|---|---|---|---:|---:|---:|---|
+| VAL-001 | 件数 | <SQL・レポート> | <値> | <値> | 0 | <担当> |
+| VAL-002 | 金額・集計 | <照合方法> | <値> | <値> | <値> | <担当> |
+| VAL-003 | 参照整合性 | <孤立・重複・外部キー検査> | <値> | <値> | 0 | <担当> |
+| VAL-004 | 業務シナリオ | <操作> | <期待> | <実結果> | なし | <担当> |
+
+## Go / No-Go判定
+
+| 判定時点 | Go条件 | No-Go条件 | 必要な証跡 | 判断者 |
+|---|---|---|---|---|
+| 移行開始前 | <条件> | <条件> | <チェックリスト> | <担当> |
+| 切替前 | <条件> | <条件> | <移行・照合結果> | <担当> |
+| サービス再開前 | <条件> | <条件> | <業務確認・監視> | <担当> |
+
+## ロールバック計画
+
+- ロールバック可能期限: <時刻・条件>
+- ロールバック判断条件: <時間超過、欠損、重大障害など>
+- 判断者: <役割>
+- データ整合性方針: <移行後更新の扱い>
+
+| 手順 | 作業 | 実行者 | 想定時間 | 完了条件 |
+|---:|---|---|---:|---|
+| 1 | <新環境への書き込みを停止する> | <担当> | <分> | <条件> |
+| 2 | <切替後に新環境へ書き込まれた差分を退避し、再適用・補償対象を確定する> | <担当> | <分> | <差分が固定され証跡がある> |
+| 3 | <旧環境を復旧し、必要な差分を再適用または補償する> | <担当> | <分> | <整合性基準を満たす> |
+| 4 | <データと業務を確認して旧環境を再開する> | <担当> | <分> | <再開条件を満たす> |
+
+## 業務継続と利用者コミュニケーション
+
+| 対象 | 通知内容 | 通知時期 | 手段 | 担当 |
+|---|---|---|---|---|
+| 利用者 | <停止・変更・再開> | <時期> | <メール・画面> | <担当> |
+| 問い合わせ窓口 | <FAQ・既知問題> | <時期> | <手段> | <担当> |
+| 経営・顧客 | <進捗・障害> | <条件> | <手段> | <担当> |
+
+- 停止中の代替業務: <手作業・受付停止など>
+- 再開後の問い合わせ増加対応: <増員・期間>
+
+## セキュリティと監査
+
+- 移行データの暗号化: <転送時・保存時>
+- 一時ファイル: <保管場所・アクセス・削除期限>
+- 特権アクセス: <申請・有効期限・監査>
+- 個人情報・機密情報: <マスキング・取扱い>
+- 操作証跡: <記録内容・保存期間>
+
+## 移行後の安定化
+
+| 期間 | 監視強化項目 | 判定基準 | 担当 | 通常運用への移行条件 |
+|---|---|---|---|---|
+| <期間> | <エラー率・照合・問い合わせ> | <閾値> | <担当> | <条件> |
+
+- 旧環境の扱い: <参照専用、保持期間、廃止日>
+- 一時データ・権限の削除: <期限・証跡>
+- 未移行・エラーデータの処理: <方法・期限>
+
+## リスクと未解決事項
+
+| ID | 内容 | 影響 | 発生可能性 | 対策・期限 | 所有者 | ステータス |
+|---|---|---|---|---|---|---|
+| MIG-RSK-001 | <内容> | High / Medium / Low | High / Medium / Low | <対策> | <担当> | Open |
+
+## 承認記録
+
+| 版 | 承認日 | 承認者 | 判断 | 条件・コメント |
+|---|---|---|---|---|
+| <版> | <YYYY-MM-DD> | <氏名・会議体> | Approved / Rejected / Deferred | <条件> |
+
+## 変更履歴
+
+| 版 | 日付 | 変更内容 | 変更理由 | 作成者 |
+|---|---|---|---|---|
+| 0.1 | <YYYY-MM-DD> | 初版 | <理由> | <氏名> |