dotfiles

コードベース全体、特定分野、ブランチ差分の改善候補を監査し、根拠付きで優先順位を付け、改善バックログとして残すときに使う。ユーザーが「$improve」「/improve」「コードベースを監査して」「改善候補を優先順位付きで出して」「改善バックログを作って」「このブランチで増えた問題を調べて」「改善バックログを再照合して」「リポジトリの次の方向性を考えて」と依頼した場合に使う。既知のバグ修正、直接の実装、通常のコードレビュー、設計済み作業の計画書作成、実装結果の受け入れ検証には使わない。

設計済みの作業を別エージェントへ渡すため、実装計画書や handoff プロンプトの作成を求められたときに使う。未確定要件の壁打ちや自分で実装する依頼では使わない。

他エージェントへのレビュー依頼、実装結果の受け入れ検証、レビュー結果の妥当性確認を求められたときに使う。PRレビューコメント対応や通常のセルフレビューでは使わない。

別のtmux paneで動いているAIエージェント（Claude Code / Codex / opencode等）へ指示やレビュー依頼を送信する、応答の完了を待って回収する、他paneのエージェントの出力や作業ログを読む、レビュー往復ループを回すときに使う。「%Nのpaneに送って」「隣のpaneのCodexにレビューを依頼して」「あのpaneが終わったら続きをやって」「右のpaneの作業を読んでまとめて」のような依頼で発動する。送る文面の作成自体（レビュー依頼文・handoffプロンプト）では使わず、agent-review-request / agent-handoff-plan に任せる。tmuxを介さないsubagent起動や並列化にも使わない。

Claude Code の /compact 前に、セッション状態の checkpoint を手動で保存するときに使う。「/compact-state」「compact 前に状態を保存して」「checkpoint を保存して」と依頼されたときに発動する。圧縮後の復旧作業、通常の進捗報告、plan 作成では使わない。

調査・監査・技術選定比較・性能検証・実装結果について、ユーザーが「結果をHTMLで読みやすく整理して」「HTMLの説明資料・レポートとして残して」のように、後から読み返せる静的HTML成果物を求めたときに使う。説明を補助する表、限定的な図解・定量グラフ・折りたたみ・定型指摘フィルタにも対応する。内容の調査・整理を伴わないHTML断片への変換、UI案や配色の比較モック、スライド、単体の探索的グラフ、任意JavaScriptを要する対話ツールには使わない。

UI改善案、配色案、レイアウト案、情報密度の異なる案を、複数の静的HTMLモックとして比較・選択したいときに使う。「UI案をHTMLで比較して」「見た目を複数案出して」のような自然言語でも適用する。調査結果や技術比較を説明資料として残す依頼、単一案の実装、挙動・product logicだけの変更には使わない。

ユーザーが「コミットを分けたい」「変更を論理的に整理したい」「段階的にコミットしたい」「実行前に計画を確認したい」「commitして」と依頼するときに使う。

Use when the user explicitly asks Codex to work in ultracode style, use many agents, run parallel or staged subagents, perform adversarial verification, or handle a broad high-risk task with deep multi-agent review.

Discord への通知を送信する。ユーザーが「Discord通知も」「Discordにも通知」など明示的に要求したときに使う。

スマホに ntfy でプッシュ通知を送信する。ユーザーが「スマホ通知も」「スマホにも通知」など明示的に要求したときに使う。

similarity-ts を使って TypeScript/JavaScript の重複コードを検知し、優先度付きのリファクタリング計画を作成する。ユーザーが「重複を検出したい」「類似コードを整理したい」「リファクタリング計画を作りたい」と依頼したときに使う。

agent 向けの skill、slash command、AGENTS.md/CLAUDE.md 節、タスクプロンプト、コード生成プロンプトを実証的に改善する。新規作成または大幅改訂した指示の明瞭性、trigger と本文の整合、実行時の不明瞭点、裁量補完、成功率を検証したいときに使う。

ユーザーが「grill-me」「grillして」「設計を詰めたい」「要件を詰めたい」「実装前に質問して」「この方針を壁打ちして」のように、実装前の設計インタビューやストレステストを明示したときに使う。曖昧な新機能、設計判断が多い変更、影響範囲が広いリファクタに向く。単純なバグ修正、明確なレビュー指摘対応、コミット整理、既に実装方針が固まっている作業では使わない。

日本語の技術文書・書籍原稿の文章規範。整形（一文一行、引用ブロック、脚注、コラム記法）、段落と論証の構成（パラグラフライティング）、論証の厳密さ（ツッコミどころの除去）、読み手の負荷の管理、視点と語り、演出の抑制、LLM っぽい空句の禁止、冗長の排除を定める。日本語で技術書の章、草稿、記事、解説文を書くとき、または推敲・リライトするときに使用する。

GitHub リポジトリや既存 OSS の実装を調査するときに使う。

dotfiles の .agents/skills と npx skills/skills-lock.json による skill 導入・更新・削除・重複整理を行うときに使う。~/.codex/skills などへ分散させない。

vw エイリアス経由で vde-worktree を安全かつ一貫した手順で運用するためのスキル。worktree の作成・切替・確認・ロック・掃除・コマンド実行を行うときに使う。

commit 後に push、deploy、version bump、publish まで続けて依頼されたときに使う。commit 整理だけ、CI 修正、デプロイ基盤構築では使わない。

Set up and use portless for named local dev server URLs (e.g. https://myapp.localhost instead of http://localhost:3000). Use when integrating portless into a project, configuring dev server names, setting up the local proxy, working with .localhost domains, or troubleshooting port/proxy issues.

Draft, audit, or activate a compact /goal when the user asks for a persistent objective or wants Codex to work until a verifiable outcome is true. Defines Done, evidence, constraints, stop conditions, optional one-question-at-a-time clarification, and only necessary worker use. Not for ordinary implementation, Q&A, one-off edits, loose brainstorming, or subjective work with no rubric.