skill-creator
スキルの新規作成・編集・改善を行うためのスキル。ユーザーがスキルを一から作りたい、既存のスキルを改善したい、スキルの書き方を知りたいときに使用する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
スキルの新規作成・編集・改善を行うためのスキル。ユーザーがスキルを一から作りたい、既存のスキルを改善したい、スキルの書き方を知りたいときに使用する。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 を作る」「プロジェクトを立ち上げる」「リポジトリの初期設定をする」ときに使用する。
| 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 を参照。
スキルのドラフトができたら:
改善のポイント: