| name | write-grimodex-copy |
| description | docs/communication-style-guide.md を正本として、Grimodex の公開向け文章を 事実ベースで作成・改稿し、特に日本語／英語のリリースノートの意味、深刻度、 対応方法を一致させる。「リリースノートを書いて／直して」「日英の更新記録」 「リリース告知」「延期・障害・保守告知」「広報文」「SNS告知」 「README冒頭」「公式サイト見出し」「開発状況報告」で使用する。 Issue、PR、コミットメッセージ、UI文言、エラーメッセージと復旧手順、 API・IPC・MCP・CLI仕様、開発者向けセットアップ、法務文書、 セキュリティアドバイザリの技術詳細には使用しない。
|
Write Grimodex Copy
公開向け文面を作る前に、事実、影響、公開状態を固定する。世界観の演出で製品用語や重大情報を曖昧にしない。
1. 適用範囲を判定する
- リリースノート、リリース／延期／障害／保守告知、SNS告知、README冒頭、公式サイト見出し、紹介文、開発状況報告に使用する。
- Issue、PR、コミットメッセージ、アプリ内UI、エラーメッセージ、復旧手順、API／IPC／MCP／CLI仕様、開発者向けセットアップ、法務文書、セキュリティアドバイザリの技術詳細には端末文体を適用しない。
- 公開文と技術手順が混在する場合は分離し、公開文だけを本スキルで作る。復旧や移行の手順は平易な通常文で書く。
- version更新を含む場合は
/bump-version を主フローとし、本スキルは文章作成だけを担当する。
2. 正本を読む
毎回 docs/communication-style-guide.md を全文読む。このファイルだけを恒常的な呼称、語彙、テンプレート、適用除外、公開前チェックリストの正本とする。規則を本スキルへ複製して独立運用しない。
3. Fact ledgerを作る
文章を書く前に、根拠から次を列挙する。
- 対象version、channel、現在のlifecycle状態（開発中、Draft、公開済み、延期、障害対応中）
- 前回リリース以降の変更と、各変更のユーザー向け効果
- 対象OS／環境、影響範囲、検証状態、既知制約
- 必要な操作、移行、backup、回避策、期限
- 根拠となるcommit、diff、issue、test、artifact、URL
確認できない事実は補わない。STATUS、CHANNEL、DISTRIBUTIONは実状態を確認できる場合だけ使う。
4. 重大情報を先に分類する
データ消失、データ破損、脆弱性、起動不能、互換性断絶、自動移行失敗の可能性を最初に確認する。解消済み、封鎖済み、既知を原因と現在状態に基づいて区別し、重大度、対象範囲、回避策を演出語で隠さない。
5. 通常文を完成させてから文体を適用する
- Fact ledgerから平易な技術文として本文を完成させる。
- 機能名、AI、Codex、MCP、Electronなどの製品・技術用語を実名のまま保つ。
- 最後にタイトル、見出し、冒頭の呼びかけと冒頭1〜2文へガイドの端末文体を適用する。
- 空の節、placeholder、裏付けのない最上級表現を削除する。
6. 日英リリースノートを揃える
public/RELEASE_NOTES/v<version>.ja.md と public/RELEASE_NOTES/v<version>.en.md を同じFact ledgerから作る。- 日英で変更、分類、深刻度、対象範囲、必要操作、期限、backup、workaround、リンクを一致させる。別々に要約して情報を落とさない。
- Draft Release用の文面は公開可能な完成度まで書くが、Draftを公開済みと報告しない。状態を断定できないmetadataは省略する。
- 公開前チェックリストを両言語へ適用し、version、日付、リンク、固有名詞を照合する。
7. 権限境界を守る
本スキルは文章を作成・改稿するだけで、version、commit、PR、tag、GitHub Releaseを作成または公開しない。gh release edit --draft=falseなどの公開操作は実行しない。公開は別の明示指示と、その公開フローの確認を必要とする。
完了時は、変更した文面、参照した事実、Draft／公開状態、未確認事項を報告する。
