ukwhatn-writing

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

このスキルの目的

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

既存設定との関係

• 対象: 日本語の文章。特にPR概要欄 / GitHubレビュー（指摘・返信）/ Slackメッセージ / Confluence等のドキュメント / 対外ビジネスメール。
• 対象外: コミットメッセージ（/commit スキル管轄。git-cz形式・prefix以外日本語という別規約に従う）。コードコメント・docstring（既存PJ形式に従う）。画面に出る文言（ラベル・ボタン・見出し・空状態・エラー文。文章とは別の規約に従うため /writing-ui-text スキルを実行する）。
• Phase 0-5ワークフロー（@context/workflow-rules.md）やメモリ構造とは独立。文章を書く局面でいつでも併用できる。

---

STEP 1: まずレジスタを選ぶ（最重要）

ukwhatn文体の核は 相手・媒体・用途でレジスタ（敬体/常体・敬語の重さ・絵文字量）を瞬時に切り替えること。同一人物が、社外には完璧な敬語を、自チームには端的な敬体を書く。最初に「誰に・どの媒体で・何の用途で」を確定し、下表で文体と参照先を決める。

場面（媒体・用途）	相手	文体	詳細
Slack: 社内の目上・公的	他部署・上長・全社/事務局宛	完全敬語。お疲れ様です→〜でしょうか→よろしくお願いいたします。名乗らない	@references/slack.md
チャット（Teams・Slack Connect等）: 社外	顧客・取引先・ベンダー	完全敬語。続いているスレッドでは挨拶も名乗りも置かず、受けた内容への返答から入る。新しくスレッドを立てるときは「お世話になっております。」で始める。「お疲れ様です」は使わない	@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
フォーラム: コミュニティサイトの告知・スレッドのクローズ	サイト利用者	敬体で改まった定着語（移行・〜となります・〜に伴い）。役職つきで名乗り、変わること/変わらないことを親1文＋子項目で	@references/forum.md
運営チャット: 告知文面の合意形成	運営メンバー	成果物のラベル＋URL一覧 → -------- → 作業の宣言 → コードブロックの文面	@references/forum.md
長文文書: 記事・レポート・議事録・提案書	読み手による（上記から選ぶ）	レジスタは上記で決め、日本語としての書き方は @references/prose.mdの長文層と工程に従う	@references/prose.md

迷ったら、相手が社外なら社外向けの完全敬語（チャットはSlack D、メールはemail.md）、社内の目上・公的なら完全敬語（Slack B）、自チーム・対等な実務相手なら敬体の端的な文（Slack C）、自分用メモ・チーム内の思考整理なら常体を選ぶ。 複数媒体が絡むとき（例: GitHubのレビュー文をSlackに貼る）は、最終的な貼り先の媒体を主にレジスタを選び、元コンテンツの媒体は副参照にする。

---

STEP 2: 全場面共通のコア原則（AIの悪癖を消す7原則）

レジスタに関わらず、すべての文章で守る。

1. 短く。自明なことは書かない。 「説明しなくても伝わること」は削る。前置き・能書き・まとめの再説明をしない。一文に論点を詰め込みすぎない（日常メッセージは1行で切る）。
   • 相手が知っている用語の中身を言い直さない。 N+1 と書いたら「100件で101クエリ」のような括弧書きの言い換えも付けない
   • 見出しや箇条書きの直前に、導入文・まとめ文を置かない（「原因は2つある」「原因ごとに1案ずつある」の類）
   • 並ぶ事実・依頼が3つ以上なら、ネストした箇条書きにする。 第一階層は太字のラベル（**停止** **お願い**）にし、中身を子項目に置く。Slackのメッセージも同じ。長文では見出しの下にこの形で置く
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 と /yomiyasu スキルが定める（分担は次節）。prose.mdの適用する層は成果物の種別で決まる。

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

規則が衝突したときの優先順位: 事実性と安全 → 媒体固有のレジスタ（STEP 1のreference）→ prose.mdの共通層と /yomiyasu → prose.mdの長文層と整形。

自然な日本語への推敲は /yomiyasu に任せる

統語の復元（誰が・何を・どうした）、非生物主語と比喩動詞の書き換え、前置きフィラーの削除、ダッシュと和欧文間の空白の除去は /yomiyasu スキルが担う。下書きを書き終えたら /yomiyasu スキルを実行して推敲する。skills/yomiyasu/ は外部リポジトリの無改変コピーなので、本スキルと食い違う規則はここで上書きする（コピー側は編集しない）。

/yomiyasu の規則	本スキルから呼ぶときの扱い
「類似スキルを無効化する」注意書き	適用しない。併用時の優先順位は上の段落で決まっている
出力フォーマット（「書き直した本文」「変えたところ」「残したAIっぽいところ」「書き手に確かめたい点」）	使わない。本スキルの下書き提示形式（ワークフロー末尾）で出す
絵文字・補足カッコの排除	Unicode絵文字（GitHubの 🙇 など）はレジスタに従って残す。Slackのカスタム絵文字は使わない（ワークスペースによって存在しない）。補足カッコのうち、指す内容を特定する同格挿入（prose.md §3-3）は情報を足すので残す
言い切りの強さの保持（推量・可能性の語尾をそのまま残す）	意見と推測のぼかし語尾（STEP 2の原則4）は残す。根拠を持たない緩和は prose.md §2-1 に従って削る
主語と目的語の明確化（前後にある語の補完）	補うのは、文単体で動作主や対象を取り違えられる箇所だけ。見出し・前の文・親の箇条書きから分かる主語は補わない。推敲後に原文より長くなった文は、補った語が誤読を防いでいるかを見直し、防いでいない語は削る（原則1「短く」が優先する）
箇条書きを地の文に統合、箇条書き比率の上限（tech domainの15%、lintの比率警告）	適用しない。構造を持つ内容（3項目以上の並列、手順、条件と例外、親子関係）は箇条書きにし、階層はネストで示して1項目を1〜2文に収める。地の文で書くのは、前の文を受けて一方向に進む論証だけ。媒体テンプレが定める構造（PR概要欄の見出しと箇条書き、作業報告の表）もそのまま残す
文書の立場と文末（勧め・決まり・説明による文末の整理）	敬体／常体はレジスタに合わせる。文末の働きの判定は /yomiyasu に従う
ドメイン判定（tech / business / essay）	長文文書に限って行う。記事・設計書・手順はtech、PR概要欄・レポート・議事録・提案書はbusiness、個人の記事・雑記はessay
Step 3のlint（scripts/yomiyasu_lint.py）とStep 4の差分検査（scripts/yomiyasu_diff.py）	長文文書をファイルに書いたときだけ実行する。Slack・レビュー返信などの短文では実行しない

slop-catalog.md §3の語（「突き合わせる」「既定」「照合」など）は、比喩として使われているときだけ直す。字義どおりの用法は書き換えない。

---

STEP 3: AIアンチパターン → ukwhatn流

AIが書きがちな文 → ukwhatnならこう書く、の対比。推敲時はこの方向に直す。

AIの癖（直す対象）	ukwhatn流
「本対応につきましては、以下の通り実施いたしました」	「やったこと」を箇条書きで即列挙
「〜することが可能となっております」	「〜できます」
「ご確認のほどよろしくお願いいたします」（毎回フル定型）	自チームなら「ご確認お願いします」。対外なら定型でOK
結論前に長い背景説明	用件・結論を先に（対外Slackは「文脈1〜2文→問い」も可）。冗長な前置きは削る
全項目を均等に詳しく書く	要点だけ **強調**。自明な項目は1行 or 省略
難しい漢語で言い換え（「具備」「鑑みる」「俯瞰」）	平易な語（「ある」「考えると」「全体を見る」）
断定しすぎ（「〜です。〜すべきです。」）	意見は「〜かと思います」「〜できないでしょうか」とぼかす
結論を言い切ってから理由を別文で後置き（「〜にしておきたいです。〜が見つからないので。」）	理由を前に畳んで一文にする（「〜が見つからないので、〜にしておきたいです」）
絵文字を機械的に大量装飾	付けない。GitHubのお詫びにだけ 🙇 を1個添えてよい。Slackのカスタム絵文字（:bow-nya: 等）はワークスペースによって存在しないので使わない
「以上、ご査収ください」等の堅い締め	自チームは「よろしくお願いします」、対外は「よろしくお願いいたします」

---

STEP 4: ukwhatnの署名的な癖（早見）

文体を「らしく」する具体特徴。媒体ごとの濃淡は各reference参照。

• 問いで投げる: 答えを出さず問いを渡す。このガードは不要の判断でしょうか。。コーチング姿勢と一貫。
• ぼかし語尾: 〜かも 〜と思う 〜気がする 〜ではないかと思います。
• 要望語尾 〜しておきたいです: 相手にしてほしい変更内容に使う（timezoneいれておきたいです）。相手の意思決定には使わない（そこは 〜の判断でしょうか。）。
• 軽さのラベル前置: [minor] [nits] [just comment] trivial: memo: (aside) を先頭に置いて重みを申告する。
• 常体・体言止めの裁定: 自分のPRで指摘を却下するときだけ敬体を落とす（型整合性は取れているので不要 一旦放置 scope外）。
• 正確さ志向: 規約・仕様違反は即指摘、件数や設定値は具体、根拠リンクを添える。
• フィラー: あと、 たぶん/多分 一応。
• 全角スペース 　 をGitHubのレビュー指摘・裁定メモで読点の代わりに使う（やりすぎな気がする　時間がかかる処理でもないので不要判断）。
• 絵文字は控えめ（特にGitHub/レビュー指摘はほぼ無し）。

---

ワークフロー

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

1. STEP 1 で「相手・媒体・用途・最終的な貼り先」を確定し、文体と参照先referenceを決める。貼り先に既存のやり取り（同じスレッド・同じ相手との直近の投稿）があれば、その形式を型にする（媒体の一般則より、そこで実際に使われている形が優先。取得済みで手元にあるものを見ずに書き始めない）。情報が足りなければ確認する。複数媒体が絡むときは貼り先の媒体を優先する。
2. 該当referenceを読み、その場面のテンプレ・実例に沿って書く。長文文書なら @references/prose.mdも読み、設計（読み手と主メッセージ・見出しスケルトン・濃淡）を先に済ませてから本文に入る。
3. STEP 2の7原則で全体を点検（特に「短く」「難語排除」「ぼかしと断定の使い分け」）。
4. STEP 3 の方向に推敲し、AIっぽさを削る。/yomiyasu スキルを実行して推敲し（扱いはSTEP 2「自然な日本語への推敲は /yomiyasu に任せる」の表）、@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/forum.md — コミュニティのフォーラム告知とクローズの投稿、運営チャットで文面の合意を取る投稿の型
• @references/prose.md — 日本語としての書き方のうち /yomiyasu に無い規則（共通層: LLM口調の語彙カタログ / 論証の厳密さ / 演出の抑制 / 冗長の排除。長文層: 整形 / 段落と論証 / 読み手の負荷 / 視点と語り / 見出し。長文文書の工程と完成時の外部レビュー）
• /yomiyasu スキル — 統語の復元・比喩動詞・前置きフィラー・装飾記号の推敲（外部リポジトリの無改変コピー。出典と取り込みcommitは リポジトリ直下の NOTICE.md）