jupytermind 0.3.0

package/.github/skills/tech-writer/assets/templates/technical-proposal.md

@@ -0,0 +1,112 @@
+# <提案名>
+
+<解決する課題、提案内容、期待する成果を3文以内で要約する。>
+
+- 提案者: <氏名・チーム>
+- 提案日: <YYYY-MM-DD>
+- 対象読者: <意思決定者・レビュー担当者>
+- ステータス: Draft / In Review / Approved / Rejected
+- 承認を求める事項: <承認・却下してほしい判断>
+
+## <この提案が必要な背景>
+
+<現在の状況、観測された問題、今対応する理由を事実ベースで記載する。>
+
+## 達成する目標と対象外
+
+### 目標
+
+- <測定可能な目標>
+- <利用者または事業にもたらす成果>
+
+### 対象外
+
+- <今回の提案では扱わない事項>
+
+## 提案する技術的アプローチ
+
+<採用する方式を最初の1文で明示し、その後に構成と処理の流れを説明する。>
+
+```mermaid
+flowchart LR
+    A[<入力>] --> B[<主要コンポーネント>]
+    B --> C[<出力>]
+```
+
+### 主要コンポーネント
+
+| コンポーネント | 役割 | 採用技術 | 選定理由 |
+|---|---|---|---|
+| <名称> | <役割> | <製品・サービス> | <理由> |
+
+### データとインターフェース
+
+- 入力データ: <形式・取得元>
+- 出力データ: <形式・保存先>
+- 外部連携: <API・プロトコル・認証方式>
+
+## セキュリティとコンプライアンス
+
+- 認証・認可: <方式と権限モデル>
+- データ保護: <暗号化・保持期間・削除方法>
+- 監査: <ログ・追跡方法>
+- 適用基準: <法令・社内規程・認証>
+
+## 実施計画
+
+| フェーズ | 作業 | 成果物 | 完了条件 | 期間 |
+|---|---|---|---|---|
+| <フェーズ名> | <作業内容> | <成果物> | <確認可能な条件> | <期間> |
+
+### ロールアウトとロールバック
+
+- ロールアウト: <段階導入・移行方法>
+- ロールバック条件: <中止を判断する指標>
+- ロールバック手順: <元の状態へ戻す方法>
+
+## 必要な費用と体制
+
+- TCO評価期間: <例: 導入から5年間>
+- 通貨・税区分: <通貨・税込/税別>
+
+| 項目 | 初期費用 | 年間継続費用 | 評価期間TCO | 前提条件 | 必要な担当・工数 |
+|---|---:|---:|---:|---|---|
+| <項目> | <金額> | <年額> | <金額> | <条件> | <役割・人日> |
+| **合計** | **<合計>** | **<合計>** | **<初期費用＋評価期間の継続費用>** |  |  |
+
+## 共通の評価軸で代替案を比較する
+
+| 選択肢 | 評価期間TCO | 導入期間 | 実装・運用工数 | リスク | 採否と理由 |
+|---|---:|---|---|---|---|
+| 現状維持 | <金額> | なし | <工数> | <継続する課題> | 不採用 / 採用: <理由> |
+| 提案方式 | <金額> | <期間> | <工数> | <リスク> | 採用 / 不採用: <理由> |
+| <代替案> | <金額> | <期間> | <工数> | <リスク> | 採用 / 不採用: <理由> |
+
+## リスクと対策
+
+| リスク | 影響 | 発生可能性 | 対策 | 所有者 |
+|---|---|---|---|---|
+| <リスク> | High / Medium / Low | High / Medium / Low | <予防・軽減策> | <担当> |
+
+## 成功を判断する指標
+
+| 指標 | 現状値 | 目標値 | 測定方法 | 判定時期 | 未達時の対応 |
+|---|---:|---:|---|---|---|
+| <指標> | <値> | <値> | <方法> | <日付・時点> | <改善・縮小・撤退判断> |
+
+## 意思決定事項と未解決事項
+
+### 承認条件の補足
+
+<ヘッダーの「承認を求める事項」は繰り返さず、条件付き承認に必要な補足だけを記載する。>
+
+### 未解決事項
+
+- <追加調査または合意が必要な事項>
+
+### 決定記録
+
+- 決定: Approved / Rejected / Deferred
+- 決定者: <氏名・会議体>
+- 決定日: <YYYY-MM-DD>
+- 条件・コメント: <承認条件または却下理由>

package/.github/skills/tech-writer/assets/templates/test-plan.md

@@ -0,0 +1,153 @@
+# <システム・プロジェクト名> テスト計画書
+
+<何を、どの品質リスクに対して、どの基準で検証する計画かを3文以内で要約する。>
+
+- 文書版: <例: 1.0>
+- 作成日: <YYYY-MM-DD>
+- 最終更新日: <YYYY-MM-DD>
+- 作成者: <氏名・チーム>
+- 承認者: <氏名・会議体>
+- ステータス: Draft / In Review / Approved
+- 対象リリース: <バージョン・時期>
+- 要件ベースライン: <要件定義書の文書名・版・URL>
+- 設計ベースライン: <設計書の文書名・版・URL>
+- セキュリティ設計ベースライン: <セキュリティ設計書の文書名・版・URL / N/A>
+
+## このテスト計画で合意する事項
+
+- テスト対象と対象外: <システム・機能・品質特性>
+- 合否判定基準: <リリース可否を決める基準>
+- 承認を求める事項: <範囲、環境、日程、体制、残余リスク>
+
+## テストの目的と品質目標
+
+| 目的ID | 品質目標 | 対応要件ID | 測定指標 | 合格値 |
+|---|---|---|---|---:|
+| T-OBJ-001 | <検証する品質> | FR-001 / NFR-001 | <指標> | <値> |
+
+## 対象範囲と対象外
+
+### 対象範囲
+
+- <対象機能・コンポーネント・インターフェース>
+- <対象ブラウザー・端末・OS・環境>
+
+### 対象外
+
+- <今回実施しない試験>
+- <別チーム・別フェーズが担当する試験>
+
+## 品質リスク
+
+| リスクID | 想定する障害・品質リスク | 影響 | 発生可能性 | 検出するテスト | 優先度 |
+|---|---|---|---|---|---|
+| QR-001 | <リスク> | High / Medium / Low | High / Medium / Low | <テスト種別> | <順位> |
+
+## テスト戦略
+
+| テストレベル・種別 | 目的 | 対象 | 実施者 | 自動化方針 | 完了条件 |
+|---|---|---|---|---|---|
+| 単体テスト | <目的> | <対象> | <担当> | <範囲・ツール> | <条件> |
+| 結合テスト | <目的> | <対象> | <担当> | <範囲・ツール> | <条件> |
+| システムテスト | <目的> | <対象> | <担当> | <範囲・ツール> | <条件> |
+| 受入テスト | <目的> | <対象> | <判定者> | <範囲・ツール> | <条件> |
+
+### 非機能テスト
+
+| 種別 | 対応要件ID | 条件・負荷 | 測定項目 | 合格基準 | 実施方法 |
+|---|---|---|---|---|---|
+| 性能・容量 | NFR-001 | <同時数・データ量> | <応答時間・TPS> | <値> | <方法・ツール> |
+| 可用性・復旧 | NFR-002 | <障害条件> | <RTO・RPO> | <値> | <方法> |
+| セキュリティ | NFR-003 | <脅威・権限> | <検証項目> | <基準> | <診断・試験> |
+
+## テスト環境
+
+| 環境 | 用途 | 構成 | 本番との差分 | 利用期間 | 管理者 |
+|---|---|---|---|---|---|
+| <環境名> | <用途> | <アプリ・基盤・外部接続> | <差分と影響> | <期間> | <担当> |
+
+### 環境の準備条件
+
+- ビルド・構成版: <バージョン・コミット>
+- 外部サービス: <実接続 / Stub / Mock>
+- 監視・ログ: <取得方法・保存先>
+- リセット方法: <初期化・再作成手順>
+
+## テストデータ
+
+| データセット | 用途 | 作成・取得方法 | 機密区分 | マスキング | 初期化・削除 |
+|---|---|---|---|---|---|
+| <名称> | <テスト目的> | <生成・複製> | <区分> | <方法> | <方法> |
+
+## 開始条件と終了条件
+
+### 開始条件
+
+- <対象ビルドが配置済み>
+- <環境・データ・アカウントが準備済み>
+- <重大な前工程不具合が解消済み>
+
+### 終了条件
+
+| 判定項目 | 合格条件 | 証跡 | 判定者 |
+|---|---|---|---|
+| テスト実行 | <必須ケース実行率など> | <レポート> | <役割> |
+| 不具合 | <重大度別の残存許容数> | <一覧> | <役割> |
+| 要件網羅 | <Must要件100%など> | <トレーサビリティ表> | <役割> |
+| 残余リスク | <受容条件> | <承認記録> | <役割> |
+
+### 中断条件と再開条件
+
+| 中断条件 | 判断者 | 必要な対応 | 再開条件 | 再開承認者 |
+|---|---|---|---|---|
+| <環境障害、重大不具合、前提崩れなど> | <役割> | <修正・再構築・影響分析> | <環境確認、修正版配置、再テスト範囲の合意> | <役割> |
+
+## テストケースと要件トレーサビリティ
+
+| テストID | 対応要件ID | 対応セキュリティ試験ID | 対応脅威ID | 対応制御ID | シナリオ | 事前条件 | 操作・入力 | 期待結果 | 優先度 | 自動化 |
+|---|---|---|---|---|---|---|---|---|---|---|
+| TC-001 | FR-001 / AC-001 | SEC-TC-001 / N/A | THR-001 / N/A | CTRL-001 / N/A | <シナリオ> | <条件> | <操作> | <観測可能な結果> | Must | Yes / No |
+
+## 不具合管理
+
+| 重大度 | 定義 | 初動期限 | 修正・判断期限 | リリース判定 |
+|---|---|---|---|---|
+| Critical | <サービス停止・情報漏えいなど> | <時間> | <期限> | 原則不可 |
+| High | <主要機能が利用不能など> | <時間> | <期限> | <例外承認条件> |
+| Medium / Low | <影響> | <時間> | <期限> | <許容条件> |
+
+- 登録先: <Issue tracker>
+- 必須情報: <再現手順、期待結果、実結果、環境、証跡>
+- 再テスト: <修正確認と回帰テストの範囲>
+- 重複・却下・延期: <判断権限と記録方法>
+
+## スケジュールと体制
+
+| フェーズ | 作業 | 期間 | 担当 | 入力 | 成果物 |
+|---|---|---|---|---|---|
+| <フェーズ> | <作業> | <期間> | <担当> | <入力> | <レポート・証跡> |
+
+## テスト結果と証跡
+
+- 実行結果の保存先: <URL・リポジトリ>
+- ログ・画面・計測値の保存方法: <方法>
+- テストサマリーの更新頻度: <日次・フェーズ終了時>
+- 最終報告の内容: <実行数、成功率、不具合、残余リスク>
+
+## リスクと未解決事項
+
+| ID | 内容 | 影響 | 対応・期限 | 所有者 | ステータス |
+|---|---|---|---|---|---|
+| T-RSK-001 | <環境遅延・データ不足など> | <影響> | <対応> | <担当> | Open |
+
+## 承認記録
+
+| 版 | 承認日 | 承認者 | 判断 | 残余リスク・条件 |
+|---|---|---|---|---|
+| <版> | <YYYY-MM-DD> | <氏名・会議体> | Approved / Rejected / Deferred | <条件> |
+
+## 変更履歴
+
+| 版 | 日付 | 変更内容 | 変更理由 | 作成者 |
+|---|---|---|---|---|
+| 0.1 | <YYYY-MM-DD> | 初版 | <理由> | <氏名> |

package/.github/skills/tech-writer/assets/templates/user-manual.md

@@ -0,0 +1,22 @@
+# <What this guide gets you>
+
+Target reader: <floor of prior knowledge assumed>
+
+## Prerequisites
+
+- <Required permissions, environment, pre-installs>
+
+## Steps
+
+1. <Action> — after running this, you'll see <state change>.
+2. <Action> — after running this, you'll see <state change>.
+
+## Completion check
+
+<What should be displayed/generated to confirm success>
+
+## Troubleshooting
+
+| Symptom | Cause | Fix |
+|---|---|---|
+| <...> | <...> | <...> |

package/.github/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> | 初版 | <氏名> | <氏名> |

package/.github/skills/tech-writer/references/doctypes/api-docs.md

@@ -0,0 +1,33 @@
+# API reference type
+
+The recommended skeleton and checklist for endpoint/function-level
+reference documentation, optimized for a developer who wants to get a
+first call working.
+
+## Target reader
+
+A developer who wants to call this API from their own code. The goal is
+"get the smallest request to succeed".
+
+## Recommended skeleton (per endpoint/function)
+
+1. **Signature**: the endpoint (method + path) or function signature first.
+2. **One-sentence description**: what it does. State side effects (state
+   changes, billing, async processing) if any.
+3. **Parameters**: a table (name, type, required/optional, default,
+   description). Include units (seconds/ms, bytes/KB) in the description.
+4. **Request example**: a minimal, runnable code example (curl or the
+   target language). Mark credentials clearly as placeholders.
+5. **Response example**: a real success example (actual sample values, not
+   just types).
+6. **Errors / status codes**: a table (code, meaning, whether to retry).
+7. **Rate limits / deprecation notices** (if applicable): don't omit.
+
+## Checklist
+
+- [ ] Does the request example run after just swapping in values (URL/token
+      fields clearly marked as placeholders)?
+- [ ] Does the parameter table have a required/optional column?
+- [ ] Does each error code say what the client should do about it?
+- [ ] Do deprecated parameters/endpoints point to a migration path?
+- [ ] Are units (time, size, currency) stated explicitly?

package/.github/skills/tech-writer/references/doctypes/blueprint.md

@@ -0,0 +1,81 @@
+# Blueprint type
+
+A Blueprint defines an agreed future state and the coordinated path from the
+current state to that future state. It can cover technology, business
+capabilities, operating models, governance, or a combination of them. It is
+broader and more directional than a system design, but more executable than a
+vision statement or strategy narrative.
+
+## Target reader
+
+Sponsors, architects, transformation leads, delivery owners, governance
+bodies, and affected teams who must align on the destination, sequence,
+decision rights, dependencies, and measures of progress.
+
+## Settle before writing
+
+- The outcome and planning horizon covered by the Blueprint
+- The current-state baseline and evidence supporting it
+- The target capabilities and principles that constrain the future state
+- The dimensions in scope: business, organization, process, data, technology,
+  security, governance, or operations
+- The authority that approves the Blueprint and owns subsequent changes
+- The level of detail needed for funding, portfolio planning, or delivery
+
+## Responsibility boundary
+
+A Blueprint establishes direction, boundaries, target capabilities, major
+building blocks, transformation workstreams, and sequencing. It does not
+replace implementation-level system designs, detailed requirements, project
+plans, operating procedures, or an investment approval proposal.
+
+Use `system-design` when teams need buildable component, interface, data, and
+deployment details. Use `technical-proposal` when the primary outcome is an
+approval of one investment or approach. Use `blueprint` when multiple
+initiatives or organizational and technical dimensions must converge on one
+future state over time.
+
+## Template
+
+Start from `assets/templates/blueprint.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Intended outcome, planning horizon, scope, and authority
+2. Drivers, principles, current-state baseline, and constraints
+3. Target capabilities and future-state operating and technical views
+4. Gap analysis, workstreams, dependencies, and transition states
+5. Phased roadmap with entry, exit, and decision criteria
+6. Governance, measures, risks, traceability, and change control
+
+## Checklist
+
+- [ ] Is the planning horizon and approval authority explicit?
+- [ ] Is `Analysis status: Completed / Incomplete / Not performed` recorded
+      separately from approval status, with `Evidence gaps` and the analysis
+      handoff location (or none)?
+- [ ] For `Incomplete`, are evidence gaps and confidence visible and every
+      affected conclusion or recommendation expressed with conditional wording,
+      or returned to consulting-analyst? For `Not performed`, are the scope and
+      reason explicit without implying completed analysis?
+- [ ] Is the current state supported by evidence rather than assumption?
+- [ ] Are target capabilities stated before products or implementation detail?
+- [ ] Are business, process, data, technology, security, governance, and
+      operations dimensions included or explicitly marked out of scope?
+- [ ] Does each gap map to a workstream, owner, dependency, and target state?
+- [ ] Do roadmap phases have entry conditions, exit conditions, and measurable
+      outcomes rather than dates alone?
+- [ ] Are transition states, coexistence, migration, and decommissioning
+      concerns visible?
+- [ ] Are decision rights, exception handling, and change control defined?
+- [ ] Can strategic drivers be traced through capabilities and workstreams to
+      measures?
+- [ ] Does traceability preserve relevant Q / HYP / FND / EVD and GAP / INT / CRT
+      IDs from the consulting handoff alongside driver, principle, capability,
+      gap, workstream, and KPI IDs? Are inapplicable links marked `N/A` with a
+      reason without forcing consulting IDs when no consulting handoff exists?
+- [ ] Are assumptions, risks, unresolved decisions, and superseded versions
+      recorded?
+- [ ] Does the header status match the approval outcome?

package/.github/skills/tech-writer/references/doctypes/code-comments.md

@@ -0,0 +1,39 @@
+# Code comments / docstrings type
+
+The principles and checklist for in-code documentation, where the same
+"why, not what" and completeness discipline applies at the scale of a
+single comment or docstring.
+
+## Target reader
+
+Whoever changes this code next (including your future self). The goal is
+to convey "why it's written this way" — the "what" should be conveyed by
+the code itself.
+
+## Principles
+
+1. **Write "why", not "what"**: don't repeat in a comment what the code
+   already shows. Explain why this implementation/ordering/exception
+   handling is necessary.
+2. **Write docstrings from the caller's perspective**: order arguments,
+   return values, exceptions, and side effects by what the *caller* wants
+   to know, not by internal implementation order.
+3. **Give `TODO`/`FIXME` a reason and, if possible, an issue link**:
+   `TODO: fix later` carries zero information. Write
+   `TODO(#123): running synchronously, async pending queue rollout`
+   instead.
+4. **Don't write comments that state the obvious**: delete comments like
+   `i += 1  # increment i by 1`.
+5. **Only comment on non-obvious choices**: implementations that look like
+   a detour, special code for performance reasons, or external constraints
+   (API quirks, past-bug workarounds) must always get a comment.
+
+## Checklist
+
+- [ ] Are there redundant comments left where the code's intent is clear
+      even without them?
+- [ ] Do non-obvious implementations have their reasoning explained?
+- [ ] Is docstring argument order driven by the caller's concerns rather
+      than internal variable order?
+- [ ] Do `TODO`/`FIXME` items have a reason or a tracking reference
+      (issue number, etc.)?

package/.github/skills/tech-writer/references/doctypes/design-doc.md

@@ -0,0 +1,42 @@
+# Design doc / ADR / RFC type
+
+The recommended skeleton and checklist for a design decision record: a
+document meant to earn a reviewer's agreement now and explain the "why" to
+someone reading it long after the decision was made.
+
+## Target reader
+
+Someone reviewing to reach a decision, or someone later tracing the history
+of that decision. The goal is "consensus" or "record", not a how-to guide
+for implementation.
+
+## Recommended skeleton (ADR format)
+
+1. **Title**: a noun phrase naming the decision (e.g. "Adopt Redis for the
+   async job queue").
+2. **Status**: Proposed / Accepted / Rejected / Superseded — state one.
+3. **Context**: why this decision is needed now. State the current
+   constraints as facts, separate from opinion.
+4. **Decision**: say what was chosen in one sentence first, then the
+   details.
+5. **Alternatives considered**: keep at least one, including why it was
+   rejected. Prevents future re-litigation of "why not A".
+6. **Consequences**: not just the upside — include the costs/constraints
+   accepted.
+7. **Open questions** (optional): leave unresolved points during review.
+
+## Design doc (RFC format, pre-implementation) specifics
+
+- Stating "what we will *not* build" (Non-Goals) before "what we will build"
+  keeps review discussion from drifting.
+- If there are diagrams (sequence/architecture), make the diagram carry the
+  primary information; keep the prose as supporting detail only.
+
+## Checklist
+
+- [ ] Is the decision stated in one sentence up front?
+- [ ] Are alternatives and their rejection reasons present (not written as
+      "the only option")?
+- [ ] Are trade-offs (what's given up) stated explicitly?
+- [ ] Are Non-Goals stated (for RFCs)?
+- [ ] Does the status reflect the current state?