kotonoha 0.1.2 → 0.1.5-dev.0

package/skills/tech-writer/SKILL.md

@@ -3,25 +3,34 @@ 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
-  English documents, with Japanese as the primary target for polished,
-  natural phrasing (pairing well with https://github.com/coji/natural-japanese
-  for sentence-level Japanese refinement). Does NOT handle sentence-level
-  naturalness, word choice, or rhythm ("AI smell" removal) — that is the
-  domain of natural-japanese and similar prose-polishing skills. This skill
-  is specific to a document's structure, information completeness, and
-  reader fit.
+  English documents, with Japanese as the primary target. Owns document
+  structure, information completeness, and reader fit; for living Japanese
+  documents, it orchestrates a registered prose-polishing skill such as
+  https://github.com/coji/natural-japanese for sentence-level naturalness,
+  word choice, rhythm, and "AI smell" removal without reimplementing that
+  skill.
 license: MIT
 argument-hint: "[write|review|score] [doctype] <target file or request>"
 ---
@@ -31,7 +40,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
@@ -45,11 +57,13 @@ reference files.
 
 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 second layer
-(sentence-level naturalness, removing "AI smell", rhythm) is out of scope and
-belongs to a prose-polishing skill such as [natural-japanese](https://github.com/coji/natural-japanese).
-When both skills are installed, use this skill to lock down the structure
-first, then hand Japanese prose to natural-japanese for polish.
+document type conventions, completeness, reader fit). A prose-polishing skill
+such as [natural-japanese](https://github.com/coji/natural-japanese) owns the
+second layer (sentence-level naturalness, removing "AI smell", rhythm);
+tech-writer orchestrates that skill without duplicating its rules or scripts.
+When both skills are installed, this skill locks down the structure and
+orchestrates the §5 handoff to natural-japanese 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?"
@@ -62,12 +76,14 @@ 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–§5 workflow, starting with the intake loop in §1 and ending only after
+  §1–§6 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 status required by §6 instead of claiming a clean review. For a
+  in-scope Japanese living document, also return the §5 Japanese prose
+  optimization status.
 - `review`: structural review of an existing document. Does not rewrite;
-  reports the gap against the doctype checklist (§6).
+  reports the gap against the doctype checklist (§7).
 - `score`: structure-only quick diagnostic. Runs
   `scripts/lint.py --json <file>` and summarizes the findings (no rewrite).
 
@@ -90,7 +106,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
@@ -104,7 +126,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
@@ -113,7 +140,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–§5 in the same turn to produce the
+   and immediately continue into §2–§6 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.
@@ -130,6 +157,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` |
 
@@ -140,9 +176,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).
@@ -168,7 +207,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");
@@ -191,11 +232,11 @@ or `references/doctypes/release-notes.md` instead — see the scope note in
 verbatim there.
 
 Sentence-level concerns — keeping individual sentences concise, avoiding
-double negatives, not dropping the subject, and general naturalness — are
-out of this skill's scope regardless of doctype. When natural-japanese (or
-an equivalent prose-polishing skill) is available, hand Japanese prose to
-it for that pass; otherwise apply ordinary careful-writing judgment, but
-don't treat it as this skill's responsibility to enforce.
+double negatives, not dropping the subject, and general naturalness — belong
+to a prose-polishing skill. In `write` mode for a Japanese document, perform
+the explicit handoff in §5 after the structure is complete. If no compatible
+optimizer is available, still apply ordinary careful-writing judgment and
+report the missing optimization pass explicitly.
 
 
 ## 4. Review — structural check
@@ -224,9 +265,60 @@ 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. Rubber-duck review loop — write mode only
-
-After the structural review in §4, use the host's subagent mechanism to
+## 5. Optimize Japanese prose without changing the structure — write mode only
+
+For a living, multi-section document whose requested final language is
+Japanese, read
+`references/japanese-prose-optimization.md` and hand the completed draft to a
+registered `natural-japanese` or equivalent Japanese prose-polishing skill.
+This pass is mandatory when such a skill is available.
+
+Treat the optimizer as available when the host's registered skill list
+contains `natural-japanese` or a compatible Japanese prose-polishing skill.
+Invoke it through the host's skill-loading mechanism; when only installed
+skill files are exposed, check
+`.github/skills/natural-japanese/SKILL.md`,
+`.copilot/skills/natural-japanese/SKILL.md`, and
+`$HOME/.copilot/skills/natural-japanese/SKILL.md`, then load the discovered
+`SKILL.md` and follow that workflow. Treat the pass as unavailable only when
+no compatible registration or readable skill installation exists, or when
+the optimizer cannot start.
+
+Freeze heading hierarchy, section order, identifiers, numeric facts,
+citations, normative language, tables, code, commands, acceptance criteria,
+and explicit risks before handoff. Require sentence-level optimization and
+request AI-pattern diagnostics, reading-load review, and terminology checks
+when their scripts are runnable, without changing those invariants. Missing
+optional diagnostics are a reported limitation, not proof that the prose pass
+did not run. After the prose pass, repeat the doctype checklist and structural
+lint from §4.
+
+For an in-scope Japanese document in `write` mode, report one explicit status.
+Do not run this pass or report a status for atomic artifacts such as commit
+messages, PR descriptions, issue reports, single release-note entries, or
+code comments/docstrings unless the user explicitly requests prose polishing
+and supplies the prose in a standalone file:
+
+- `Japanese prose optimization completed`
+- `Japanese prose optimization not performed`
+- `Japanese prose optimization did not converge`
+
+Across the complete write workflow, allow at most 15 optimizer handoffs,
+including reruns after rubber-duck edits. If no compatible optimizer can be
+loaded, use
+`Japanese prose optimization not performed` and state the reason. If the
+optimizer starts but fails, or an edit violates a frozen invariant, revert
+the invalid edit and retry within the three-round limit; unresolved failures
+or invariant violations use
+`Japanese prose optimization did not converge`. Do not claim this
+optimization from kotonoha's structural lint alone. Documents that are not
+within the Japanese final-language scope defined above require no optimization
+status.
+
+## 6. Rubber-duck review loop — write mode only
+
+After the structural review in §4 and any Japanese prose optimization in §5,
+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;
@@ -244,9 +336,14 @@ for `write` mode; do not run it for `review` or `score` mode.
 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.
+3. **Re-run the relevant checks after each edit round**: if a fix changed
+   Japanese prose, repeat the §5 optimization over the changed prose before
+   reporting its final status. Then 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 or leave the final Japanese
+   prose outside the completed optimization pass. If a required rerun cannot
+   start because all 15 handoffs were already used, or cannot complete,
+   report `Japanese prose optimization did not converge`, not `completed`.
 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
@@ -268,11 +365,14 @@ for `write` mode; do not run it for `review` or `score` mode.
    contradictory requirements, label it `review did not converge` and
    include the latest unresolved findings and fixes already attempted.
 
-## 6. Doctype checklist summary
+## 7. 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
@@ -292,5 +392,6 @@ The idea of separating structure from prose comes from
 [natural-japanese](https://github.com/coji/natural-japanese) (MIT License)
 and its design principle "machines detect, humans (or agents) judge" and
 "prevent at generation time rather than fix afterward". This skill extends
-that separation to the structural side of technical documents, deliberately
-leaving prose naturalness out of scope.
+that separation by owning technical-document structure while orchestrating,
+but not reimplementing, the registered prose-polishing skill responsible for
+sentence-level naturalness.

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> | 初版 | <理由> | <氏名> |