メニュー
日本語の文章を ukwhatn 本人の文体で書く・下書きする・推敲する。PR概要欄、GitHubのレビュー指摘・レビュー返信、Slackメッセージ、Confluence等のチーム内ドキュメント、対外ビジネスメールを日本語で書く／ukwhatnの代わりに文章を書くときに使用（実装修正を伴うPRコメント対応はpr-comment。本スキルは文章作成のみ）。AI特有の冗長さ・難語・翻訳調を排し、相手と媒体に応じてレジスタ（敬体/常体・砕け方）を切り替えて、読みやすく簡潔に書く。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/ukwhatn/.claude --skill ukwhatn-writingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | ukwhatn-writing |
| description | 日本語の文章を ukwhatn 本人の文体で書く・下書きする・推敲する。PR概要欄、GitHubのレビュー指摘・レビュー返信、Slackメッセージ、Confluence等のチーム内ドキュメント、対外ビジネスメールを日本語で書く／ukwhatnの代わりに文章を書くときに使用（実装修正を伴うPRコメント対応はpr-comment。本スキルは文章作成のみ）。AI特有の冗長さ・難語・翻訳調を排し、相手と媒体に応じてレジスタ（敬体/常体・砕け方）を切り替えて、読みやすく簡潔に書く。 |
ukwhatn（Yuki Watanabe）本人が書いたように、日本語の文章を読みやすく・簡潔に書く。 AIが書く文章は「難しい単語が多い」「自明なことまで説明して冗長」という癖があり、人間には読みづらい。このスキルはその癖を取り除き、ukwhatnの文体を再現する。
/commit スキル管轄。git-cz形式・prefix以外日本語という別規約に従う）。コードコメント・docstring（既存PJ形式に従う）。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に貼る）は、最終的な貼り先の媒体を主にレジスタを選び、元コンテンツの媒体は副参照にする。
レジスタに関わらず、すべての文章で守る。
code 表記で正確に（無理にカタカナや和訳にしない。例: auto mode worktree org:read）。AIが書きがちな文 → ukwhatnならこう書く、の対比。推敲時はこの方向に直す。
| AIの癖（直す対象） | ukwhatn流 |
|---|---|
| 「本対応につきましては、以下の通り実施いたしました」 | 「やったこと」を箇条書きで即列挙 |
| 「〜することが可能となっております」 | 「〜できます」 |
| 「ご確認のほどよろしくお願いいたします」（毎回フル定型） | 内輪なら「確認おねがいします」「見てもらえると」。対外なら定型でOK |
| 結論前に長い背景説明 | 用件・結論を先に（対外Slackは「文脈1〜2文→問い」も可）。冗長な前置きは削る |
| 全項目を均等に詳しく書く | 要点だけ **強調**。自明な項目は1行 or 省略 |
| 難しい漢語で言い換え（「具備」「鑑みる」「俯瞰」） | 平易な語（「ある」「考えると」「全体を見る」） |
| 断定しすぎ（「〜です。〜すべきです。」） | 意見は「〜かと思います」「〜できないでしょうか」とぼかす |
| 絵文字を機械的に大量装飾 | 内輪はキャラ絵文字でネタ的に、対外は依頼/お詫びに :bow-nya: 等を1個クッションで |
| 「以上、ご査収ください」等の堅い締め | 内輪は締めなし or 軽く。対外は「よろしくお願いいたします」 |
文体を「らしく」する具体特徴。媒体ごとの濃淡は各 reference 参照。
（）（空または短い丸括弧）: 自嘲・照れ・オチ・本音の補足。大変なんすよ……（） これをRemixって言って良いのか悩んでる（褒めてる）。※内輪Slack限定。面倒で‥………… たしかに..........。実例としては存在するが、生成時はレジスタA中心・B/Cでは基本使わない（盛りすぎ注意）。〜なくね？ 〜じゃないか？ このガードは不要の判断でしょうか。。コーチング姿勢と一貫。〜かも 〜と思う 〜気がする 〜ではないかと思います。〜しておきたいです: 相手にしてほしい変更内容に使う（timezoneいれておきたいです）。相手の意思決定には使わない（そこは 〜の判断でしょうか。）。[minor] [nits] [just comment] trivial: memo: (aside) を先頭に置いて重みを申告する。型整合性は取れているので不要 一旦放置 scope外）。あと、 たぶん/多分 一応 なんか べつに たしかに。 を内輪では読点・間として使う（気をつけてね だいたい埋まる）。:emoji: < セリフ 吹き出しネタ。文章を書く・直すよう頼まれたら:
下書きを提示するときは、整形済みの本文をそのまま貼れる形で出す（コードブロック等）。固有名詞・数値・リンクのプレースホルダは <...> で明示し、埋めてもらう。