메뉴
ドキュメント作成・改善を支援するスキル。新規ドキュメントの作成、既存文章の改善・レビュー、ドキュメント構成の設計を行う際に使用する。トリガー条件: ドキュメントやテキストの作成・執筆を依頼されたとき、文章の改善・レビューを求められたとき、ドキュメントの構成設計を相談されたとき。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Codexの計画・実装内容・差分・検証結果をClaude Codeに渡して、読み取り中心のセカンドレビューを受けるスキル。トリガー: ユーザが「Claudeにレビューして」「Claude Codeに見てもらって」「セカンドオピニオンを得て」「計画や実装をレビューして」と依頼したとき、または大きめの変更前後に別モデルの観点で設計・バグ・テスト不足を確認したいとき。
Read academic papers from local raw/papers entries, arXiv/HTML/PDF sources, or provided URLs; create detailed Japanese Markdown explanations with formulas, figures, experimental results, limitations, and Obsidian/MathJax compatibility checks. Use when the user asks to read, explain, summarize, or turn a paper into an Obsidian-ready Markdown note.
漠然とした初期段階のアイデアを「発散→収束」の 2 サイクルで洗練するスキル。Double Diamond 思考フレームに沿って、対象ユーザ・成功条件の明確化、複数案の発散、批判的評価、HMW（How Might We）形式の問題定義への収束までを対話形式で進める。トリガー条件: ユーザが「アイデアを洗練したい」「ブレストしたい」「How Might We を作りたい」「アイデアを練りたい」「企画を考えたい」「サービスのアイデアを発散したい」と依頼したとき。
Kaggle コンペ参加期間中（序盤の戦略立案・中盤の追加実験・終盤の取捨選択いずれも）の実験投資判断スキル。次に試す仮説の発散と、優先度付けした実験バックログ生成を行う。Kaggle／コンペ／LB／CV／public notebook／discussion／submission／leaderboard／QWK／MAP@K／adversarial validation／pseudo labeling 等のキーワード、または『何から始めるべきか』『次に何の実験をやるべきか』『LB が伸びない』『仮説を整理したい』『リーク疑いがある』『submission 何回残してる時に何をやるべきか』のような発話で必ず使う。良い案を出すだけでなく『今やるべきでない仮説を殺す』ことも目的。一般的なブレスト・新規事業アイデア・プロダクト企画は対象外（その場合は idea-refinement を使う）。HPO（ハイパーパラ最適化の体系的探索）は対象外。
URLで指定されたWebページ（ブログ記事、X/Twitterポスト、技術記事、論文ページ等）の内容を調査・要約し、マークダウンファイルとしてまとめるスキル。記事内で引用・参照されている外部リンクの内容も追跡して含める。ページ内の画像も元URLから直接ダウンロードしてJPEG圧縮して保存する。トリガー: ユーザがURLを提示して「まとめて」「要約して」「内容を調査して」「ファイルに保存して」と依頼したとき。
作業中に行き詰まったとき、OpenAI Codex CLIをセカンドオピニオンとして呼び出すスキル。現在の問題・コード・エラーをCodexに渡し、別の視点からのアドバイスや解決策を得る。トリガー: ユーザが「Codexに聞いて」「セカンドオピニオンを得て」「Codexの意見を聞かせて」と依頼したとき。
| name | documentation |
| description | ドキュメント作成・改善を支援するスキル。新規ドキュメントの作成、既存文章の改善・レビュー、ドキュメント構成の設計を行う際に使用する。トリガー条件: ドキュメントやテキストの作成・執筆を依頼されたとき、文章の改善・レビューを求められたとき、ドキュメントの構成設計を相談されたとき。 |
ドキュメント作成・改善を段階的に支援するスキル。
ユーザの依頼内容に応じて、以下のいずれかのワークフローを選択する。
以下の手順でドキュメントを作成する。
ユーザに以下を質問し、ドキュメントの対象を絞り込む。
読み手とテーマが曖昧なままだと、ドキュメントが肥大化・複雑化するため、可能な限り絞り込む。
テーマを複数のサブテーマで構成される階層構造に分解する。
例: ある機能を説明するドキュメントの場合 → 概要、設定方法、利用方法、トラブルシューティング
階層構造の各要素を見出しとして構成する。見出しは「見出しの基本原則」に従って命名する。
各見出しの中に書く文章の構成を組む。
各topic sentenceに対して、読み手が納得できるよう理由や説明を書き足す。主な書き方として以下の3パターンがある。
執筆時は「文章品質基準」を遵守する。
タイトルや見出しの名前だけでは内容が把握しづらい場合、内容を補足するリード文を書く。前の見出しとの繋がりを改善する目的でもリード文を追加する。
既存の文章を読み込み、全体の構成と内容を把握する。
「文章品質基準」と「見出しの基本原則」に照らして改善点を特定する。改善点は以下の分類で整理する。
改善点ごとに以下の形式で提示する。
両ワークフローで共通して適用する基準。
情報に優先度をつけて、優先度が高いものから書く。伝えたいことをまず述べ、その理由や説明は後に続ける。
著者の視点ではなく、読み手が理解しやすい視点で書く。
1文には1つの情報のみ含める。文はできるだけ短くする。
否定形は意味が分かりづらくなることがある。肯定的な表現ができる場合は肯定形を使う。
