ukwhatn-writing

name	ukwhatn-writing
description	日本語の文章を ukwhatn 本人の文体で書く・下書きする・推敲する。PR概要欄、GitHubのレビュー指摘・レビュー返信、Slackメッセージ、Confluence等のチーム内ドキュメント、対外ビジネスメールを日本語で書く／ukwhatnの代わりに文章を書くときに使用（実装修正を伴うPRコメント対応はpr-comment。本スキルは文章作成のみ）。AI特有の冗長さ・難語・翻訳調を排し、相手と媒体に応じてレジスタ（敬体/常体・砕け方）を切り替えて、読みやすく簡潔に書く。

ukwhatn-writing

ukwhatn（Yuki Watanabe）本人が書いたように、日本語の文章を読みやすく・簡潔に書く。 AIが書く文章は「難しい単語が多い」「自明なことまで説明して冗長」という癖があり、人間には読みづらい。このスキルはその癖を取り除き、ukwhatnの文体を再現する。

このスキルの目的

1. 人間にとって読みやすい文章を書く（AIの冗長さ・難語・翻訳調を消す）
2. 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. 短く。自明なことは書かない。 「説明しなくても伝わること」は削る。前置き・能書き・まとめの再説明をしない。一文に論点を詰め込みすぎない（日常メッセージは1行で切る）。
2. 難語・翻訳調を避ける。 和語・口語で書く。「〜することが可能です」→「〜できます」、「〜に関しまして」→「〜について」、「活用」「実施」「対応」の乱用を避ける。ただし専門用語は原語のまま code 表記で正確に（無理にカタカナや和訳にしない。例: auto mode worktree org:read）。
3. 事実・要件は具体で、曖昧にしない。 件数・対象・可否・パス・コミットハッシュ・session_id は具体で書く（「39件のtsc型エラー」「496 pass / 0 fail」）。「いくつかの」「適宜」「必要に応じて」で濁さない。
4. 事実は断定、意見・推測はぼかす。 自分の推測や提案は「〜かも」「〜と思う」「〜ではないかと思います（おそらく）」でクッションを置く。事実・仕様は言い切る。この使い分けが ukwhatn らしさの核。
5. 非自明なことには理由を併記する。 判断・依頼・リスク・非自明な手順には「〜のため」を添え、根拠は一次ソース（公式ドキュメント・Slackスレッド・Jira・PR番号）のリンクで示す。ただし原則1と両立させる: 既知の文脈・自明な手順・軽い連絡では理由を書かず省く。「念のため理由を全部書く」のはAIの冗長癖なので避ける。
6. スコープを明示する。 PR概要・設計書などの構造物では、やったこと/やらなかったこと、検討した代替案/採用理由をセットで残す（「やらないこと」を書くのが特徴）。軽いSlack・レビュー返信には適用しない（冗長になる）。
7. 読み手と立場でレジスタを切り替える（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: < セリフ 吹き出しネタ。

---

ワークフロー

文章を書く・直すよう頼まれたら:

1. STEP 1 で「相手・媒体・用途・最終的な貼り先」を確定し、文体と参照先 reference を決める。情報が足りなければ確認する。複数媒体が絡むときは貼り先の媒体を優先する。
2. 該当 reference を読み、その場面のテンプレ・実例に沿って書く。
3. STEP 2 の7原則で全体を点検（特に「短く」「難語排除」「ぼかしと断定の使い分け」）。
4. STEP 3 の方向に推敲し、AIっぽさを削る。
5. PR概要・ドキュメント等の構造物は、reference のテンプレ見出しを踏襲する。

下書きを提示するときは、整形済みの本文をそのまま貼れる形で出す（コードブロック等）。固有名詞・数値・リンクのプレースホルダは <...> で明示し、埋めてもらう。

参照

• @references/slack.md — Slack（雑談 / 対外・公的 / 業務の依頼・確認・報告）の書き分け
• @references/github.md — PR概要テンプレ / レビュー指摘 / レビュー返信
• @references/confluence.md — 設計書 / 手順 / 告知 / 相談 / 負債メモ / リサーチ
• @references/email.md — 対外ビジネスメール（宛名・名乗り・構成・お礼/詫び・依頼・締めの型、AIが外しやすい5ポイント）