Ukwhatn Writing

---
name: ukwhatn-writing
description: 日本語の文章を ukwhatn 本人の文体で書く・下書きする・推敲する。PR概要欄、GitHubのレビュー指摘・レビュー返信、Slackメッセージ、Confluence等のチーム内ドキュメント、対外ビジネスメール、および記事・レポート・議事録・提案書といった長文文書を日本語で書く／ukwhatnの代わりに文章を書くときに使用（実装修正を伴うPRコメント対応はpr-comment。本スキルは文章作成のみ）。AI特有の冗長さ・難語・翻訳調を排し、相手と媒体に応じてレジスタ（敬体/常体・砕け方）を切り替えて、読みやすく簡潔に書く。日本語としての書き方（LLM口調の語彙・論証の厳密さ・演出の抑制・段落構成・整形）は references/prose.md が定め、成果物の種別で適用する層を切り替える。
---

# ukwhatn-writing

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

## このスキルの目的

1. **人間にとって読みやすい文章を書く**（AIの冗長さ・難語・翻訳調を消す）
2. **ukwhatnの代わりに文章を書き、執筆時間を減らす**

## 既存設定との関係

- **対象**: 日本語の文章。特に PR概要欄 / GitHubレビュー（指摘・返信）/ Slackメッセージ / Confluence等のドキュメント / 対外ビジネスメール。
- **対象外**: コミットメッセージ（`/commit` スキル管轄。git-cz形式・prefix以外日本語という別規約に従う）。コードコメント・docstring（既存PJ形式に従う）。画面に出る文言（ラベル・ボタン・見出し・空状態・エラー文。文章とは別の規約に従うため `context/ui-artifact-standards.md` を Read する）。
- 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 |
| 長文文書: 記事・レポート・議事録・提案書 | 読み手による（上記から選ぶ） | レジスタは上記で決め、**日本語としての書き方は @references/prose.md の長文層と工程に従う** | @references/prose.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）。

### 日本語としての書き方は @references/prose.md

上の7原則は「何を書くか・どう振る舞うか」を決める。**「日本語としてどう書くか」（LLM 口調の語彙・論証の厳密さ・演出の抑制・段落の作り方・整形）は @references/prose.md** が定める。適用する層は成果物の種別で決まる。

| 成果物 | prose.md で適用する層 |
|---|---|
| Slack、GitHub のレビュー指摘と返信 | 共通層のみ |
| PR概要欄、負債メモ、リサーチメモ | 共通層 + 原則6（スコープの明示） |
| 設計書・手順・告知・記事・レポート・議事録・提案書 | 共通層 + 長文層 + 工程 + 完成時の外部レビュー |

**規則が衝突したときの優先順位**: 事実性と安全 → 媒体固有のレジスタ（STEP 1 の reference）→ prose.md の共通層 → prose.md の長文層と整形。内輪の Slack 文体（`（）`・三点リーダ・フィラー・体言止め）はレジスタ側に属するので、共通層の規則を理由に削らない。

---

## 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 を読み、その場面のテンプレ・実例に沿って書く。**長文文書なら @references/prose.md も読み、設計（読み手と主メッセージ・見出しスケルトン・濃淡）を先に済ませてから本文に入る。**
3. **STEP 2 の7原則**で全体を点検（特に「短く」「難語排除」「ぼかしと断定の使い分け」）。
4. **STEP 3** の方向に推敲し、AIっぽさを削る。**@references/prose.md の共通層（LLM 口調の語彙カタログ）で本文を検索して潰す。**
5. PR概要・ドキュメント等の構造物は、reference のテンプレ見出しを踏襲する。
6. **人に共有・公開する長文は、書き上げたら外部レビューに出す**（対象・Severity・ラウンド上限は @references/prose.md「完成時の外部レビュー」、実行手順は `~/.claude/context/agent-cli-guide.md`）。自分で読み直すだけでは、書いたときと同じ判断が再生されるだけで前提の抜けが見えない。

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

## 参照

- @references/slack.md — Slack（雑談 / 対外・公的 / 業務の依頼・確認・報告）の書き分け
- @references/github.md — PR概要テンプレ / レビュー指摘 / レビュー返信
- @references/confluence.md — 設計書 / 手順 / 告知 / 相談 / 負債メモ / リサーチ
- @references/email.md — 対外ビジネスメール（宛名・名乗り・構成・お礼/詫び・依頼・締めの型、AIが外しやすい5ポイント）
- @references/prose.md — 日本語としての書き方（共通層: LLM 口調の語彙カタログ / 論証の厳密さ / 演出の抑制 / 冗長の排除。長文層: 整形 / 段落と論証 / 読み手の負荷 / 視点と語り / 見出し。長文文書の工程と完成時の外部レビュー）