メニュー
スキルの新規作成・編集・改善を行うためのスキル。ユーザーがスキルを一から作りたい、既存のスキルを改善したい、スキルの書き方を知りたいときに使用する。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | skill-creator |
| description | スキルの新規作成・編集・改善を行うためのスキル。ユーザーがスキルを一から作りたい、既存のスキルを改善したい、スキルの書き方を知りたいときに使用する。 |
スキルの作成と改善を支援するスキル。
スキルは、Claudeの能力を拡張するためのモジュール。特定のドメインや作業に関する手続き的な知識・ワークフロー・ツール連携を提供する。
スキルが提供するもの:
skill-name/
├── SKILL.md（必須）
│ ├── YAML frontmatter（必須: name, description）
│ └── Markdown本文（必須）
└── バンドルリソース（任意）
├── scripts/ - 決定的・反復的な処理のスクリプト
├── references/ - 必要に応じて読み込むドキュメント
└── assets/ - 出力に使うファイル（テンプレート、画像等）
frontmatter:
name: スキル名description: トリガー条件と機能の説明。スキルの発動はこのフィールドで決まるため、具体的かつ網羅的に書く。「いつ使うか」の情報は全てここに含める（本文はトリガー後にしか読まれない）本文: スキルの使い方、手順、ガイドライン。命令形で書く。
scripts/: 毎回同じコードを書き直すような処理や、決定的な実行が必要な場合に使う。トークン効率が良く、コンテキストに読み込まずに実行できる。
references/: 作業中に参照するドキュメント。スキーマ、API仕様、ドメイン知識など。SKILL.mdをスリムに保ちつつ、必要なときだけ読み込む。大きなファイル（300行超）には目次をつける。
assets/: コンテキストに読み込まず、出力で使うファイル。テンプレート、画像、フォントなど。
README.md、CHANGELOG.md、インストールガイドなどの補助ドキュメントは不要。スキルはAIエージェントが仕事をするための情報だけを含める。
スキルは3段階でコンテキストに読み込まれる:
SKILL.md本文が500行に近づいたら、参照ファイルに分割する。分割時はSKILL.mdから明確に参照し、いつ読むべきかを記載する。
参照の深さは1段階まで。全ての参照ファイルはSKILL.mdから直接リンクする。
パターン例:
複数のドメインやフレームワークをサポートする場合、バリアントごとにファイルを分ける:
cloud-deploy/
├── SKILL.md（ワークフロー + 選択ガイド）
└── references/
├── aws.md
├── gcp.md
└── azure.md
ユーザーがAWSを選んだら、aws.mdだけ読む。
ユーザーの意図を理解する。会話の中にすでにワークフローがある場合（例: 「これをスキルにして」）は、そこから情報を抽出する。
確認すること:
質問は一度に多く聞きすぎない。重要なものから順に確認する。
具体例をもとに、再利用可能なリソースを洗い出す:
scripts/references/assets/descriptionは発動条件を左右する最重要フィールド。以下を含める:
詳細な書き方のパターンは references/patterns.md を参照。
スキルのドラフトができたら:
改善のポイント:
cmuxターミナル内での操作スキル。CMUX_*環境変数が存在する場合、cmuxのCLIコマンドを使う前に必ずこのスキルを読む。ペイン分割、コマンド送信、ブラウザ自動化、通知、Markdown/diffのプレビュー、cmux設定の変更など、cmux操作全般で使用する。「別ペインで開いて」「横に表示して」「ブラウザで確認して」「プレビューして」「diffを見せて」などのときにも使用する。
Preview generated Markdown (plans, design notes, reviews, research reports) in the user's browser. Use when sharing long, structured output — documents with headings, tables, code blocks, or Mermaid diagrams — that is hard to read in the terminal.
バグを場当たり修正せず、根本原因を特定してから直すためのデバッグ手順。再現→切り分け→根本原因→検証の順で進める。バグ・デバッグ・原因不明・落ちる・再現しない・CIが赤・flakyなテスト・想定外の挙動に遭遇したときに使用する。「デバッグして」「なぜ落ちる」「原因を調べて」などのときにも使用する。
「完了」「直した」と報告する前に、実際に実行・テスト・観察して根拠を確かめるための検証ルール。修正・実装・リファクタが終わって成功を報告しようとするとき、変更が意図どおり動くと主張する前に使用する。「できた」「直した」「実装した」「修正完了」と言おうとしているときに使用する。
日本語の技術文書を書いた後・公開前にレビューし、重要度つきの指摘レポートを出すスキル（ファイルは変更しない）。日本語の文章品質・AI Slop・表記の慣習・整合性・独自性・語り口を点検する。媒体非依存の汎用版で、ブログMDXなどプロジェクト固有のレビュースキルがあればそちらを優先・併用する。
新しい k8o プロジェクト/リポジトリを立ち上げる一連の手順。@k8o/create で雛形生成 → GitHub リポジトリ作成 → ブランチ保護 ruleset とマージ設定 → リリース用 secret(fnox経由) → npm 初回 publish と Renovate 有効化まで。「新しい repo を作る」「プロジェクトを立ち上げる」「リポジトリの初期設定をする」ときに使用する。