メニュー
日本語の文章を ukwhatn 本人の文体で書く・下書きする・推敲する。PR概要欄、GitHubのレビュー指摘・レビュー返信、Slackメッセージ、Confluence等の社内ドキュメントを日本語で書く／ukwhatnの代わりに文章を書くときに使用（実装修正を伴うPRコメント対応はpr-comment。本スキルは文章作成のみ）。AI特有の冗長さ・難語・翻訳調を排し、相手と媒体に応じてレジスタ（敬体/常体・砕け方）を切り替えて、読みやすく簡潔に書く。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
コードベース包括的レビュー。6観点（perf/sec/test/arch/cq/docs）を並列サブエージェントで実行し、優先度付きissueファイルをメモリディレクトリに生成。使用タイミング: コードベース全体の監査・定期レビュー・リリース前品質確認の依頼時、/codebase-review実行時。境界: PR単位のレビュー→pr-review、自ブランチの提出前確認→self-review、ローカル未コミット変更→/code-review、ドキュメントのレビュー→doc-review。
既存設定と整合したスキルを新規作成。「スキルを作って」「この手順をスキル化して」等の依頼時、/create-skill実行時に使用。~/.claude/AGENTS.md（CLAUDE.mdは互換symlink）、context/*.md、既存スキルを自動参照し、重複・競合を避けたスキルを生成。境界: 既存スキル・指示ファイルの修正→update-inst、指示ファイル全体の監査→instructions-audit。
抽象的な要件・Biz 要求から要求を深掘りし、コードベース SSoT で既存実装整合性を確認した上で「実装マスタ（01_requirements_skeleton.md）」と「システム要件書（02_system_requirements.md）」を作成する。使用タイミング (1)「○○って機能を作りたい」「このBiz要求を満たす機能を設計して」等の抽象要件提示時、(2) 既存機能の拡張・Phase 分割等の要件定義開始時、(3) `/design-feature ...` 実行時。
Agent Teamsによる多角的ドキュメントレビュー。設計書・仕様書・計画書等のドキュメントを6 Agent（通常4 + Devil's Advocate + agent CLI）で並列レビュー。使用タイミング: (1) /doc-review 明示実行時、(2) 「チームでレビューして」「多角的にレビューして」等の明示依頼時（Agent Teams発動条件(c)相当）。通常の「レビューして」だけの依頼では発火しない（単独レビューまたはagent CLIで対応し、必要なら本スキルを提案する）。
既存の計画・設計・アイデアを徹底的に尋問し、共有理解に至るまでストレステストする対話スキル。使用タイミング: (1) 「グリルして」「grillして」「この計画を詰めて」「計画の穴を突いて」「ストレステストして」等の依頼時、(2) 実装着手前に計画・設計の前提や未決定事項を洗い出したい時。境界: ゼロからの要件定義・要件書作成→design-feature、完成した文書の多角的レビュー→doc-review。本スキルは既に存在する計画・アイデアの対話的な検証を行う。要件書等の成果物は生成せず、確定した重要決定のみADRとして.local/docs/に記録する。
現在のセッション内容を、別セッションのエージェントが引き継げるハンドオフ文書に圧縮し、メモリディレクトリに書き出す。セッションを切り替えたい時・作業を中断して後日再開したい時に /handoff で実行。
| 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作者 | ドライ。事実は断定・提案/推測はぼかす＋一次ソースURL＋代替案 | @references/github.md |
| GitHub: レビュー返信/作業報告 | レビュアー | 「ありがとうございます！」＋対応報告 | @references/github.md |
| GitHub: PR概要欄 | レビュアー全般 | 固定見出しテンプレ。「やらなかったこと」を立てる | @references/github.md |
| Confluence: 設計書・思考整理・負債メモ・リサーチ | 自分・チーム内 | 常体。代替案＋採用理由をセットで | @references/confluence.md |
| Confluence: 対外告知・手順・相談 | 他チーム・Biz | 敬体。目的提示＋各ステップに理由 | @references/confluence.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では基本使わない（盛りすぎ注意）。〜なくね？ 〜じゃないか？ このガードは不要の判断でしょうか。。コーチング姿勢と一貫。〜かも 〜と思う 〜気がする 〜ではないかと思います。あと、 たぶん/多分 一応 なんか べつに たしかに。 を内輪では読点・間として使う（気をつけてね だいたい埋まる）。:emoji: < セリフ 吹き出しネタ。文章を書く・直すよう頼まれたら:
下書きを提示するときは、整形済みの本文をそのまま貼れる形で出す（コードブロック等）。固有名詞・数値・リンクのプレースホルダは <...> で明示し、埋めてもらう。