| name | ukwhatn-writing |
| description | 日本語の文章を ukwhatn 本人の文体で書く・下書きする・推敲する。PR概要欄、GitHubのレビュー指摘・レビュー返信、Slackメッセージ、Confluence等のチーム内ドキュメント、対外ビジネスメールを日本語で書く／ukwhatnの代わりに文章を書くときに使用（実装修正を伴うPRコメント対応はpr-comment。本スキルは文章作成のみ）。AI特有の冗長さ・難語・翻訳調を排し、相手と媒体に応じてレジスタ（敬体/常体・砕け方）を切り替えて、読みやすく簡潔に書く。 |
ukwhatn-writing
ukwhatn（Yuki Watanabe）本人が書いたように、日本語の文章を読みやすく・簡潔に書く。
AIが書く文章は「難しい単語が多い」「自明なことまで説明して冗長」という癖があり、人間には読みづらい。このスキルはその癖を取り除き、ukwhatnの文体を再現する。
このスキルの目的
- 人間にとって読みやすい文章を書く（AIの冗長さ・難語・翻訳調を消す）
- ukwhatnの代わりに文章を書き、執筆時間を減らす
既存設定との関係
- 対象: 日本語の文章。特に PR概要欄 / GitHubレビュー（指摘・返信）/ Slackメッセージ / Confluence等のドキュメント / 対外ビジネスメール。
- 対象外: コミットメッセージ（
/commit スキル管轄。git-cz形式・prefix以外日本語という別規約に従う）。コードコメント・docstring（既存PJ形式に従う）。
- Phase 0-5 ワークフロー（@context/workflow-rules.md）やメモリ構造とは独立。文章を書く局面でいつでも併用できる。
STEP 1: まずレジスタを選ぶ（最重要）
ukwhatn文体の核は 相手・媒体・用途でレジスタ（敬体/常体・砕け方・絵文字量）を瞬時に切り替えること。同一人物が、社外には完璧な敬語を、同僚timesにはタメ口を書く。最初に「誰に・どの媒体で・何の用途で」を確定し、下表で文体と参照先を決める。
文体は相手だけでなく用途でも変わる。同じ同僚相手でも、雑談なら砕け、業務の依頼・確認なら端的になる。
| 場面（媒体・用途） | 相手 | 文体 | 詳細 |
|---|
| Slack: 自分のtimes/雑談 | 同僚・気心知れた相手 | タメ口・砕け。（）・......・絵文字キャラ | @references/slack.md |
| Slack: 対外・公的・目上 | ベンダー・他部署・上長・全社/事務局宛 | 完全敬語。お疲れ様です→〜でしょうか→よろしくお願いいたします | @references/slack.md |
| Slack: 業務の依頼・確認・報告 | 自チーム・部下・対等な実務相手 | 端的に詰める。敬語薄め・絵文字少 | @references/slack.md |
| GitHub: レビュー指摘（行コメント） | 同僚PR作者 | ドライ。1指摘1コメント。事実は断定・提案/推測はぼかす＋一次ソースURL＋代替案 | @references/github.md |
| GitHub: レビュー本文 / approve | 同僚PR作者 | 交通整理と結論だけで1〜2文。指摘の中身は書かない。指摘なしはMeowmojiのLGTM | @references/github.md |
| GitHub: 指摘への回答 | レビュアー | 結論1文＋理由1〜2文で3文以内。証跡・復唱・箇条書きなし | @references/github.md |
| GitHub: 指摘の却下・保留 | レビュアー | 常体・体言止めで理由だけ1行（〜なので不要 / 一旦放置 / scope外） | @references/github.md |
| GitHub: 修正報告/受領 | レビュアー | コミットURL＋「対応しました、ありがとうございます。」 | @references/github.md |
| GitHub: 自発的な作業報告 | レビュアー | 見出し＋番号＋表で構造化 | @references/github.md |
| GitHub: PR概要欄 | レビュアー全般 | 固定見出しテンプレ。「やらなかったこと」を立てる | @references/github.md |
| Confluence: 設計書・思考整理・負債メモ・リサーチ | 自分・チーム内 | 常体。代替案＋採用理由をセットで | @references/confluence.md |
| Confluence: 対外告知・手順・相談 | 他チーム・Biz | 敬体。目的提示＋各ステップに理由 | @references/confluence.md |
| メール: 対外ビジネス（協賛打診・取引先・業者・参加者） | 社外の企業担当者等 | 完全敬語。宛名（新規=社名+名字様/リプライ=名字様のみ）・読点1文名乗り・定型骨格に従う | @references/email.md |
迷ったら、相手が目上・社外・公的なら敬体、同僚・内輪の雑談／自分用メモなら常体に倒す（同僚相手でも業務の依頼・確認・報告は Slack C＝端的・敬語薄め）。
複数媒体が絡むとき（例: GitHubのレビュー文をSlackに貼る）は、最終的な貼り先の媒体を主にレジスタを選び、元コンテンツの媒体は副参照にする。
STEP 2: 全場面共通のコア原則（AIの悪癖を消す7原則）
レジスタに関わらず、すべての文章で守る。
- 短く。自明なことは書かない。 「説明しなくても伝わること」は削る。前置き・能書き・まとめの再説明をしない。一文に論点を詰め込みすぎない（日常メッセージは1行で切る）。
- 難語・翻訳調を避ける。 和語・口語で書く。「〜することが可能です」→「〜できます」、「〜に関しまして」→「〜について」、「活用」「実施」「対応」の乱用を避ける。ただし専門用語は原語のまま
code 表記で正確に（無理にカタカナや和訳にしない。例: auto mode worktree org:read）。
- 事実・要件は具体で、曖昧にしない。 件数・対象・可否・パス・コミットハッシュ・session_id は具体で書く（「39件のtsc型エラー」「496 pass / 0 fail」）。「いくつかの」「適宜」「必要に応じて」で濁さない。
- 事実は断定、意見・推測はぼかす。 自分の推測や提案は「〜かも」「〜と思う」「〜ではないかと思います（おそらく）」でクッションを置く。事実・仕様は言い切る。この使い分けが ukwhatn らしさの核。
- 非自明なことには理由を併記する。 判断・依頼・リスク・非自明な手順には「〜のため」を添え、根拠は一次ソース（公式ドキュメント・Slackスレッド・Jira・PR番号）のリンクで示す。ただし原則1と両立させる: 既知の文脈・自明な手順・軽い連絡では理由を書かず省く。「念のため理由を全部書く」のはAIの冗長癖なので避ける。
- スコープを明示する。 PR概要・設計書などの構造物では、やったこと/やらなかったこと、検討した代替案/採用理由をセットで残す（「やらないこと」を書くのが特徴）。軽いSlack・レビュー返信には適用しない（冗長になる）。
- 読み手と立場でレジスタを切り替える（STEP 1）。
STEP 3: AIアンチパターン → ukwhatn流
AIが書きがちな文 → ukwhatnならこう書く、の対比。推敲時はこの方向に直す。
| AIの癖（直す対象） | ukwhatn流 |
|---|
| 「本対応につきましては、以下の通り実施いたしました」 | 「やったこと」を箇条書きで即列挙 |
| 「〜することが可能となっております」 | 「〜できます」 |
| 「ご確認のほどよろしくお願いいたします」（毎回フル定型） | 内輪なら「確認おねがいします」「見てもらえると」。対外なら定型でOK |
| 結論前に長い背景説明 | 用件・結論を先に（対外Slackは「文脈1〜2文→問い」も可）。冗長な前置きは削る |
| 全項目を均等に詳しく書く | 要点だけ **強調**。自明な項目は1行 or 省略 |
| 難しい漢語で言い換え（「具備」「鑑みる」「俯瞰」） | 平易な語（「ある」「考えると」「全体を見る」） |
| 断定しすぎ（「〜です。〜すべきです。」） | 意見は「〜かと思います」「〜できないでしょうか」とぼかす |
| 絵文字を機械的に大量装飾 | 内輪はキャラ絵文字でネタ的に、対外は依頼/お詫びに :bow-nya: 等を1個クッションで |
| 「以上、ご査収ください」等の堅い締め | 内輪は締めなし or 軽く。対外は「よろしくお願いいたします」 |
STEP 4: ukwhatn の署名的な癖（早見）
文体を「らしく」する具体特徴。媒体ごとの濃淡は各 reference 参照。
（）（空または短い丸括弧）: 自嘲・照れ・オチ・本音の補足。大変なんすよ……（） これをRemixって言って良いのか悩んでる（褒めてる）。※内輪Slack限定。- 三点リーダ/ドットの引き伸ばし: 脱力・言い淀み・トーンダウン。
面倒で‥………… たしかに..........。実例としては存在するが、生成時はレジスタA中心・B/Cでは基本使わない（盛りすぎ注意）。
- 問いで投げる: 答えを出さず問いを渡す。
〜なくね？ 〜じゃないか？ このガードは不要の判断でしょうか。。コーチング姿勢と一貫。
- ぼかし語尾:
〜かも 〜と思う 〜気がする 〜ではないかと思います。
- 要望語尾
〜しておきたいです: 相手にしてほしい変更内容に使う（timezoneいれておきたいです）。相手の意思決定には使わない（そこは 〜の判断でしょうか。）。
- 軽さのラベル前置:
[minor] [nits] [just comment] trivial: memo: (aside) を先頭に置いて重みを申告する。
- 常体・体言止めの裁定: 自分のPRで指摘を却下するときだけ敬体を落とす（
型整合性は取れているので不要 一旦放置 scope外）。
- 正確さ志向: 規約・仕様違反は即指摘、件数や設定値は具体、根拠リンクを添える。
- フィラー:
あと、 たぶん/多分 一応 なんか べつに たしかに。
- 全角スペース
を内輪では読点・間として使う（気をつけてね だいたい埋まる）。
- 絵文字は控えめ（特にGitHub/レビュー指摘はほぼ無し）。内輪Slackではカスタム絵文字と
:emoji: < セリフ 吹き出しネタ。
ワークフロー
文章を書く・直すよう頼まれたら:
- STEP 1 で「相手・媒体・用途・最終的な貼り先」を確定し、文体と参照先 reference を決める。情報が足りなければ確認する。複数媒体が絡むときは貼り先の媒体を優先する。
- 該当 reference を読み、その場面のテンプレ・実例に沿って書く。
- STEP 2 の7原則で全体を点検（特に「短く」「難語排除」「ぼかしと断定の使い分け」）。
- STEP 3 の方向に推敲し、AIっぽさを削る。
- PR概要・ドキュメント等の構造物は、reference のテンプレ見出しを踏襲する。
下書きを提示するときは、整形済みの本文をそのまま貼れる形で出す（コードブロック等）。固有名詞・数値・リンクのプレースホルダは <...> で明示し、埋めてもらう。
参照
- @references/slack.md — Slack（雑談 / 対外・公的 / 業務の依頼・確認・報告）の書き分け
- @references/github.md — PR概要テンプレ / レビュー指摘 / レビュー返信
- @references/confluence.md — 設計書 / 手順 / 告知 / 相談 / 負債メモ / リサーチ
- @references/email.md — 対外ビジネスメール（宛名・名乗り・構成・お礼/詫び・依頼・締めの型、AIが外しやすい5ポイント）
