kotonoha 0.1.2 → 0.1.4

package/skills/tech-writer/assets/templates/system-design.md

@@ -0,0 +1,220 @@
+# <システム名> システム設計書
+
+<承認済み要件をどの構成と方式で実現するか、設計の要点と主要な判断を3文以内で要約する。>
+
+- 文書版: <例: 1.0>
+- 作成日: <YYYY-MM-DD>
+- 最終更新日: <YYYY-MM-DD>
+- 作成者: <氏名・チーム>
+- レビュー担当: <アーキテクト・開発・運用・セキュリティ担当>
+- ステータス: Draft / In Review / Approved
+- 対象リリース: <バージョン・時期>
+- 対応する要件定義書: <文書名・版・URL>
+
+## この設計で合意する事項
+
+- 設計対象: <システム・サブシステム・機能>
+- 主要な設計判断: <採用する方式>
+- レビューで確認する事項: <構成、品質属性、運用可能性など>
+
+## 設計の前提と対象範囲
+
+### 対象範囲
+
+- <設計対象のコンポーネント・データ・インターフェース>
+
+### 対象外
+
+- <別文書・別フェーズで設計する事項>
+
+### 前提条件と制約
+
+| ID | 区分 | 内容 | 設計への影響 |
+|---|---|---|---|
+| DC-001 | 要件 / 技術 / 予算 / 納期 / 法令 | <条件> | <影響> |
+
+## 設計ドライバーと対応要件
+
+| 設計ドライバー | 対応要件ID | 優先順位 | 設計上の対応 |
+|---|---|---:|---|
+| <性能・可用性・セキュリティなど> | NFR-001 | 1 | <方式> |
+
+## システム全体構成
+
+### システムコンテキスト
+
+```mermaid
+flowchart LR
+    U[<利用者>] --> S[<対象システム>]
+    S --> E[<外部システム>]
+```
+
+### コンテナ・実行単位
+
+```mermaid
+flowchart LR
+    UI[<フロントエンド>] --> API[<API・サービス>]
+    API --> DB[(<データストア>)]
+    API --> EXT[<外部サービス>]
+```
+
+| コンポーネント | 責務 | 採用技術 | 実行環境 | 依存先 | 対応要件ID |
+|---|---|---|---|---|---|
+| <名称> | <単一の責務> | <製品・フレームワーク> | <環境> | <依存先> | FR-001 |
+
+## コンポーネント設計
+
+### <コンポーネント名>
+
+- 責務: <担当する処理>
+- 公開インターフェース: <API・イベント・画面>
+- 依存関係: <他コンポーネント・外部サービス>
+- 状態管理: <保持する状態・整合性>
+- エラー処理: <失敗の通知・再試行・補償>
+- 対応要件ID: <FR-001, NFR-001>
+
+## 主要な処理フロー
+
+### <ユースケース・処理名>
+
+```mermaid
+sequenceDiagram
+    actor User as <利用者>
+    participant App as <アプリケーション>
+    participant Store as <データストア>
+    User->>App: <要求>
+    App->>Store: <読み書き>
+    Store-->>App: <結果>
+    App-->>User: <応答>
+```
+
+| ステップ | 処理 | 入出力 | 失敗時の動作 | 対応要件ID |
+|---:|---|---|---|---|
+| 1 | <処理> | <入出力> | <再試行・中断・補償> | FR-001 |
+
+## データ設計
+
+### データモデル
+
+```mermaid
+erDiagram
+    ENTITY_A ||--o{ ENTITY_B : has
+    ENTITY_A {
+        string id PK
+        datetime created_at
+    }
+```
+
+| エンティティ・データ | 用途 | 主キー | 整合性ルール | 機密区分 | 保持・削除 | 対応要件ID |
+|---|---|---|---|---|---|---|
+| <名称> | <用途> | <キー> | <制約> | <区分> | <期間・方法> | DATA-001 |
+
+### トランザクションと整合性
+
+- トランザクション境界: <開始・確定・取消の単位>
+- 同時実行制御: <ロック・楽観制御・冪等性>
+- 結果整合性: <許容する不整合時間・補正方法>
+
+## インターフェース設計
+
+| IF-ID | 提供側 / 利用側 | 方式 | エンドポイント・イベント | 入出力 | 認証・認可 | タイムアウト・再試行 | バージョニング |
+|---|---|---|---|---|---|---|---|
+| IF-001 | <提供 / 利用> | REST / Event / File | <名称> | <スキーマ参照> | <方式> | <値・条件> | <方針> |
+
+### エラー契約
+
+| エラーコード | 発生条件 | 呼び出し元への応答 | 再試行可否 | 運用通知 |
+|---|---|---|---|---|
+| <コード> | <条件> | <ステータス・メッセージ> | Yes / No | <通知条件> |
+
+## セキュリティ設計
+
+| 項目 | 設計 | 対応する脅威・要件 | 検証方法 |
+|---|---|---|---|
+| 認証 | <方式> | <脅威・NFR-ID> | <試験・監査> |
+| 認可 | <ロール・権限モデル> | <脅威・NFR-ID> | <試験・監査> |
+| データ保護 | <転送時・保存時暗号化、鍵管理> | <データ区分・NFR-ID> | <確認方法> |
+| シークレット管理 | <保管、配布、ローテーション、失効> | <脅威・NFR-ID> | <確認方法> |
+| 監査 | <記録対象、保存期間、改ざん対策> | <規程・NFR-ID> | <確認方法> |
+
+## 性能と容量の設計
+
+| 指標 | 想定負荷 | 設計目標 | 実現方式 | 限界・スケール条件 | 検証方法 |
+|---|---:|---:|---|---|---|
+| <応答時間・TPSなど> | <値> | <値> | <キャッシュ・並列化など> | <閾値> | <負荷試験> |
+
+## 可用性と信頼性の設計
+
+- 可用性目標: <SLO・対象時間帯>
+- 障害分離: <冗長化・障害ドメイン>
+- タイムアウトと再試行: <値・バックオフ・上限>
+- 冪等性と重複排除: <方式>
+- RTO / RPO: <値>
+- バックアップ: <対象・頻度・保持期間・復元試験>
+- 災害復旧: <切替方式・責任者・訓練頻度>
+
+## 配置とネットワーク設計
+
+```mermaid
+flowchart TB
+    Client[<クライアント>] --> Edge[<入口・LB・Gateway>]
+    Edge --> App[<アプリケーション実行環境>]
+    App --> Data[(<データストア>)]
+```
+
+| 環境 | リージョン・場所 | ネットワーク境界 | 配置物 | スケール方式 | 構成管理 |
+|---|---|---|---|---|---|
+| Development / Staging / Production | <場所> | <VNet・Subnet・FW> | <構成> | <方式> | <IaC・設定管理> |
+
+## 監視と運用の設計
+
+| 種別 | 対象 | シグナル | 閾値・条件 | 通知先 | 初動手順 |
+|---|---|---|---|---|---|
+| メトリクス / ログ / トレース | <対象> | <指標> | <条件> | <担当> | <Runbook> |
+
+- SLI / SLO: <測定式・目標>
+- ログ方針: <構造、機密情報のマスキング、保持期間>
+- リリース方式: <段階展開、Feature Flag、承認>
+- 定常作業: <バックアップ確認、パッチ、証明書更新>
+- 障害対応: <検知、切り分け、連絡、事後レビュー>
+
+## 移行・リリース・ロールバック設計
+
+| フェーズ | 作業 | 入力 | 完了条件 | 検証 | ロールバック条件 |
+|---|---|---|---|---|---|
+| <フェーズ> | <作業> | <データ・成果物> | <判定可能な条件> | <方法> | <条件> |
+
+- データ移行方式: <全件・差分・二重書きなど>
+- 互換性維持: <API・スキーマ・クライアント>
+- 切替手順: <順序・責任者・所要時間>
+- ロールバック手順: <復旧先・データ整合性の扱い>
+
+## テスト方針と要件トレーサビリティ
+
+| 要件ID | 設計箇所 | テストレベル | テスト内容 | 合格基準 | 証跡 |
+|---|---|---|---|---|---|
+| FR-001 | <節・コンポーネント> | Unit / Integration / System / Acceptance | <内容> | <基準> | <成果物> |
+
+## 採用しなかった方式とトレードオフ
+
+| 選択肢 | 評価軸 | 採否 | 理由 | 受け入れる影響 |
+|---|---|---|---|---|
+| <方式> | コスト / 性能 / 運用性 / リスク | 採用 / 不採用 | <理由> | <制約・負債> |
+
+## リスクと未解決事項
+
+| ID | 区分 | 内容 | 影響 | 対応・決定期限 | 所有者 | ステータス |
+|---|---|---|---|---|---|---|
+| RSK-001 | リスク / 未解決事項 | <内容> | <影響> | <対応・期限> | <担当> | Open |
+
+## レビューと承認記録
+
+| 版 | レビュー・承認日 | 担当 | 判断 | 条件・コメント |
+|---|---|---|---|---|
+| <版> | <YYYY-MM-DD> | <氏名・会議体> | Approved / Rejected / Deferred | <条件> |
+
+## 変更履歴
+
+| 版 | 日付 | 変更内容 | 変更理由 | 作成者 |
+|---|---|---|---|---|
+| 0.1 | <YYYY-MM-DD> | 初版 | <理由> | <氏名> |

package/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/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/skills/tech-writer/references/doctypes/migration-plan.md

@@ -0,0 +1,63 @@
+# Migration plan type
+
+A migration plan defines how data, users, integrations, and business
+processes move from a current state to a target state with measurable
+validation, controlled downtime, and a tested rollback path.
+
+## Target reader
+
+Migration leads, application and data engineers, business owners, operators,
+support teams, security reviewers, and Go/No-Go approvers.
+
+## Settle before writing
+
+- The current and target states and complete migration inventory
+- Allowed downtime, data-loss tolerance, and business continuity needs
+- Migration approach, waves, dependencies, and change-freeze conditions
+- Reconciliation and business-acceptance criteria
+- Go/No-Go and rollback authority, triggers, and deadlines
+- Rehearsal evidence, communication needs, and post-migration support
+
+## Responsibility boundary
+
+Own the executable transition plan and its decisions. Link to implementation
+scripts rather than embedding large programs. Do not claim rollback is
+possible unless the plan states how post-cutover writes and data consistency
+will be handled.
+
+The migration section in `system-design` is sufficient for describing the
+chosen transition architecture. Use a standalone `migration-plan` when the
+cutover needs rehearsals, a timed procedure, business communications,
+Go/No-Go gates, reconciliation evidence, or separate approval. When both
+exist, the migration plan is authoritative for execution and the system
+design summarizes the strategy and links to it.
+
+## Template
+
+Start from `assets/templates/migration-plan.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Agreement target, current and target states, scope, and constraints
+2. Inventory, dependencies, mappings, transformation, and migration method
+3. Roles, rehearsals, readiness, and timed production procedure
+4. Reconciliation, Go/No-Go gates, rollback, and business continuity
+5. Security, communication, stabilization, decommissioning, and approval
+
+## Checklist
+
+- [ ] Are all data, configuration, identities, integrations, and business
+      processes inventoried with owners and dependencies?
+- [ ] Are mapping, transformation, default, rejection, retry, and idempotency
+      rules explicit?
+- [ ] Have full-scale timing, validation, and rollback been rehearsed?
+- [ ] Are start, cutover, reopen, Go/No-Go, and rollback conditions objective?
+- [ ] Do reconciliation checks cover counts, aggregates, referential
+      integrity, and business scenarios?
+- [ ] Does rollback address writes made after cutover and its last safe time?
+- [ ] Are downtime communications, alternative operations, support, security,
+      temporary access, and evidence covered?
+- [ ] Are stabilization, cleanup, old-system retention, and decommissioning
+      conditions defined?

package/skills/tech-writer/references/doctypes/operations-runbook.md

@@ -0,0 +1,63 @@
+# Operations design and runbook type
+
+An operations design and runbook makes a production service observable,
+changeable, recoverable, and supportable. It combines stable operating
+policies with executable procedures for routine work and incidents.
+
+## Target reader
+
+Service owners, on-call engineers, operators, support staff, security teams,
+change approvers, and incident commanders.
+
+## Settle before writing
+
+- The service boundary, owners, dependencies, and operating hours
+- SLI, SLO, alert, capacity, backup, RTO, and RPO targets
+- On-call, escalation, change, and incident authority
+- Access requirements and safety constraints for operational actions
+- The symptoms and failure scenarios that require executable runbooks
+- Review, exercise, and expiration frequency
+
+## Responsibility boundary
+
+Write steps that an authorized operator can execute and verify. Link to
+automation where it exists, but preserve preconditions, safety checks,
+expected results, escalation, and recovery behavior. Never include secret
+values or bypass access and change controls.
+
+The operations section in `system-design` is sufficient for architectural
+operability decisions. Use a standalone `operations-runbook` when on-call
+staff need executable procedures, alerts, escalation, exercises, or a review
+cycle independent of the system design. When both exist, the runbook is
+authoritative for live operations and the system design links to its current
+approved version.
+
+## Template
+
+Start from `assets/templates/operations-runbook.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Service scope, dependencies, levels, owners, and escalation
+2. Observability, alerts, routine work, and capacity management
+3. Incident severity, common initial response, and symptom runbooks
+4. Start, stop, restore, security, change, and rollback procedures
+5. Disaster recovery, business continuity, risks, exercises, and review
+
+## Checklist
+
+- [ ] Can an unfamiliar authorized operator identify the service, owner,
+      dependencies, dashboards, communication channels, and impact?
+- [ ] Are SLI/SLO calculations, alert conditions, suppression, and test
+      frequency specified?
+- [ ] Does every procedure state preconditions, safety limits, steps,
+      expected results, evidence, escalation, and recovery?
+- [ ] Are backup restoration, RTO/RPO, disaster recovery, and exercises
+      executable and owned?
+- [ ] Are access, secret, certificate, vulnerability, audit, and security
+      incident operations covered without exposing secret values?
+- [ ] Are releases, emergency changes, rollback, and post-change checks clear?
+- [ ] Are capacity, cost, routine maintenance, review dates, and stale
+      runbook detection addressed?

package/skills/tech-writer/references/doctypes/requirements-definition.md

@@ -0,0 +1,61 @@
+# Requirements definition type
+
+A requirements definition establishes agreement on what outcomes, scope,
+capabilities, quality levels, and acceptance conditions a system must
+satisfy. It describes the required behavior and measurable constraints
+without prematurely prescribing the implementation architecture.
+
+## Target reader
+
+Business owners, product owners, users, architects, delivery teams,
+operators, security reviewers, and approvers who must agree on what will be
+built and how acceptance will be judged.
+
+## Settle before writing
+
+- The business problem, target users, and measurable outcome
+- In-scope and out-of-scope business processes, systems, and data
+- Requirement priorities and the authority that resolves conflicts
+- Constraints covering budget, schedule, law, policy, and existing systems
+- Measurable acceptance conditions for functional and non-functional needs
+- The identifier or naming convention used for traceability
+
+## Responsibility boundary
+
+State what the system must achieve and the constraints it must meet. Do not
+turn preferred products, component layouts, database schemas, or deployment
+topologies into requirements unless they are genuine externally imposed
+constraints. Put implementation choices in a system design document and
+link them back to requirement IDs.
+
+## Template
+
+Start from `assets/templates/requirements-definition.md`.
+The template is the Japanese-language skeleton; translate its headings when
+the target document is English.
+
+## Recommended skeleton
+
+1. Agreement target, background, problem, purpose, and success measures
+2. Scope, stakeholders, assumptions, and constraints
+3. Business flow, business rules, and prioritized functional requirements
+4. Measurable non-functional, data, and external-interface requirements
+5. Migration, operation, acceptance, and traceability
+6. Risks, open questions, approval, and change history
+
+## Checklist
+
+- [ ] Are purpose, scope, exclusions, stakeholders, assumptions, and
+      constraints explicit?
+- [ ] Does every requirement have a stable ID, priority, and independently
+      verifiable acceptance condition?
+- [ ] Are non-functional requirements measurable under stated conditions?
+- [ ] Are data ownership, classification, retention, quality, and deletion
+      requirements covered?
+- [ ] Are external interfaces, migration, operations, and failure handling
+      included where applicable?
+- [ ] Can each requirement be traced to a problem or objective and forward
+      to an acceptance test and design or implementation artifact?
+- [ ] Are implementation preferences separated from actual constraints?
+- [ ] Are unresolved items owned and time-bound, with approval and change
+      history recorded?