메뉴
CosenseのメモやGitHubリポジトリから、Zennで公開する技術記事の「執筆ブリーフ」を一緒に作るスキル。記事を書きたい、Zennに投稿したい、Cosenseのメモを記事にまとめたい、技術ブログを書きたい、といった場面で使う。ネタ出し、構成設計、執筆ブリーフの作成、人間が書いた記事へのフィードバックまでサポートする。プロジェクトについて発信したい、書いた記事の改善をしたい、という場合にも使うこと。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
コード変更・diff・ブランチ・PRについて、リッチでインタラクティブな解説を生成するスキル。「この変更を解説して」「このPRを説明して」「diffを分かりやすくまとめて」「このブランチの変更点を教えて」「変更内容の解説ページを作って」と言われたら使う。背景・直感・コード・批評・クイズの5セクションから成る自己完結HTMLファイルを出力する。解説だけでなく批判的な視点も含む。他人のPRや自分の変更を、初学者にも分かる形で理解・共有したい場面で積極的に使うこと。
長考や自問自答の末に、元の質問から逸れた（drift した）回答をしてしまったときに、 思考を原点に立て直すためのリカバリスキル。同一セッションで元の質問に答え直す「原点回帰」を核に、 それでも直らない場合は、汚染のないセッションで再出発するための「質問カード」を出して /clear や 新セッションへ誘導する、一直線のエスカレーション型。 「迷走してる」「質問に答えてない」「そんなこと聞いてない」「ズレてる」「話が逸れた」「やりなおして」 「元の質問に戻って」「なんでその話になってるの」と言われたら使う。 ユーザーが直前の回答に対して困惑・不満・「？」を示したとき、あるいは自分の回答が元の質問と かみ合っていないと気づいたときは、指示される前にこのスキルを提案・発動してよい。
忖度をやめ、容赦なく正直な高レベルアドバイザーとして振る舞うモード。一度呼ばれたらセッション全体でこの人格を貫く。 ユーザーの思考に意見し、前提を疑い、避けている盲点を暴き、弱い推論を解剖し、自己欺瞞・言い訳・機会費用を名指しする。ただし丁寧な言葉を使い、攻撃と正直さを混同しない。 「厳しく評価して」「容赦なく」「盲点を指摘して」「甘やかさないで」と言われたら使う。対象は仕事・思考・意思決定・計画・戦略。 ユーザーが同意や称賛を求めているだけに見えるとき、自分を正当化して逃げているとき、不快な決断を先送りしているときは、このモードを提案してよい。
今のClaude Codeセッションでの会話を踏まえて、そこで得た学びを「個人用の公開メモ」1枚にまとめてチャットに返すスキル。「/matome 〇〇についてまとめて」「ここまでの会話をまとめて」「今の話を公開メモにして」「会話の内容を1枚にまとめて」と言われたら使う。単発の質問への要約ではなく、会話の中で芋づる式に出てきた話題（〇〇を聞いたら△△が出て、それを掘ったら□□が…）を全部拾い、3ヶ月後の自分が読んで理解できる順に再構成するのが特徴。社内コードや機密は自動で抽象化する。
対象を徹底的に理解する。記事、リポジトリ、本、論文などのコンテンツについて、メンタルモデルの獲得を目指して深い理解に達するまで探索・質問・解説を繰り返す。「徹底的に理解したい」「深掘りしたい」「このリポジトリを理解したい」「この本を読み解きたい」といった場面で使用する。
虫食い思考（コンサル業界の「空パック / Ghost Deck」に相当）でユーザーと一緒に進めるためのスキル。 先に「型」（答えるべき問い・アジェンダ・テンプレ）を作って「虫食い状態」にしてから、 その穴を1つずつ埋めていく進め方。 「虫食いで」「虫食い思考で」「空パックで」「骨子から作って」「先に型を作って」 「アジェンダから決めて」「アウトライン先行で」「skeleton-first」「ghost deck」 と言われたら使う。 Q振り返り、次Q発表準備、提案資料作成、採用面接の準備、ブログや記事の構成、 「何かを書く／考える前段で先に骨組みを置きたい」場面で積極的に使うこと。 ユーザーの思考が発散して整理が必要そうなときに、「先に虫食いで構造化しませんか？」と提案するのもよい。
| name | tech-article-writer |
| description | CosenseのメモやGitHubリポジトリから、Zennで公開する技術記事の「執筆ブリーフ」を一緒に作るスキル。記事を書きたい、Zennに投稿したい、Cosenseのメモを記事にまとめたい、技術ブログを書きたい、といった場面で使う。ネタ出し、構成設計、執筆ブリーフの作成、人間が書いた記事へのフィードバックまでサポートする。プロジェクトについて発信したい、書いた記事の改善をしたい、という場合にも使うこと。 |
CosenseのメモやGitHubリポジトリを素材に、読まれる技術記事をZennで公開するまでを一緒に進めるスキル。
このスキルの核心: AIは記事の文章を書かない。 構成設計と執筆ブリーフの作成、そして書かれた記事へのフィードバックがAIの役割。実際の執筆は人間が行う。AIが書いた文章はどうしてもAI臭くなるため、文章の組み立ては人間に委ね、AIは「何を書くか」の設計と「書いたものがどう読まれるか」のフィードバックに徹する。
記事の目的は情報伝達だけでなくブランディングでもある。「この人は面白いものを頻繁に作って深く考えている」という印象を読者に持ってもらうことを意識する。
まずユーザーに聞く:
ユーザーの意図がわかったら素材を読む:
<Page> タグで区切られた複数ページの集合体。リンク関係やタイムスタンプも手がかりになる。writing-log.md が存在すれば読み、過去の学びを確認する。素材を読んだうえで、具体的な構成案を提案する。ここが記事の出来を左右するもっとも重要なフェーズ。候補を1-2個出し、それぞれについて以下を含める:
ユーザーと議論する。ユーザーから「こういう方向の方がいい」「この要素も入れたい」といったフィードバックが来たら構成を修正する。方向性が固まるまでこのフェーズを繰り返す。
構成案を考える際の視点:
構成が固まったら、人間が記事を書くためのブリーフを作る。記事本文を書くのではなく、各セクションで何を書くかのガイドを作る。
ブリーフはZennの記事ファイルとして保存する。メタデータ付きで、人間がそのままこのファイルの中身を書き換えていける形にする。
---
title: "記事タイトル"
emoji: "適切な絵文字"
type: "tech"
topics: ["topic1", "topic2"]
published: false
---
セクションごとに以下をまとめる:
## [セクション見出し]
<!-- brief:
- 書くこと: ここで伝えるポイントを箇条書きで
- 具体的な事実、エピソード、数字などの素材
- 読者に伝わってほしいこと
- 意図: このセクションが記事全体の中で果たす役割（任意）
- 素材: 使えそうなコード例、画像、リンクなど（任意）
-->
ブリーフを書く際のポイント:
## 冒頭
<!-- brief:
- 書くこと:
- Chrome拡張が突然動かなくなった場面から入る
- 「最初は気のせいだと思った」的な、読者を引き込む導入
- → 実はManifest V3移行が原因だったという結論の予告
- 意図: 読者に「自分も同じ経験ある」と思わせて引き込む
-->
## Manifest V3で何が変わったか
<!-- brief:
- 書くこと:
- Service Workerベースになった変更点
- background.jsが常駐しなくなる影響
- 自分の拡張で具体的に壊れた箇所（イベントリスナーの登録タイミング）
- 素材: 変更前後のbackground.jsのdiff（リポジトリのcommit abc123）
-->
slugは記事内容を端的に表す英語ケバブケースにする。articles/ ディレクトリに保存し、published: false にしておく。
ブリーフを渡したら、ユーザーに「これを見ながら書いてみてください。書けたら見せてください」と伝える。
ユーザーが記事を書いたら、Phase 1で決めたターゲット読者のペルソナになりきって記事を読み、フィードバックする。
ペルソナの一人称で、読者として感じたことを率直に述べる。チェックリスト的な評価ではなく、読んだ人間のリアルな反応として書く。
含めるとよい観点:
フィードバックは1回で終わりではない。ユーザーが修正したら再度読んでフィードバックする。ユーザーが満足するまで繰り返す。
記事を書くサイクルの中でもっとも重要なフェーズ。ここを回さないと次の記事に改善が反映されない。
記事を書き終えたら writing-log.md にエントリを追加する。このファイルはzenn-contentリポジトリのルートに置く。存在しなければ作成する。
## [記事タイトル](./articles/slug.md)
- 公開日: YYYY-MM-DD
- topics: topic1, topic2
- 型: 謎解き型
- 仮説: この記事がどういう読者に刺さり、なぜ読まれると考えたか
- 狙い: この記事で何を伝えたかったか
- 工夫した点: 文体、構成、タイトルなどで具体的に何を工夫したか
- 広め方: どこに投稿したか（Zennのみ / X共有 / HackerNews / Reddit等）
「仮説」が特に大事。「中上級者のAI活用層に刺さるはず」「タイトルの数字が目を引くはず」など、なぜこの記事が読まれると思ったかを書いておく。仮説がないと、結果が出ても何が良かった/悪かったのか判断できない。
公開から1-2週間後に振り返り、以下を追記する:
- 結果: PV、いいね数、コメント、SNSでの反応
- 仮説の検証: 仮説は当たったか？外れたなら何が想定と違ったか
- 学び: 次の記事に活かせること
writing-log.md を読んでから始める。過去の仮説と結果を見比べて、何が効いて何が効かなかったかを確認する。同じ失敗を繰り返さず、うまくいったパターンを意識的に再現する。
素材に合った型を選ぶ。組み合わせも可能。Phase 2の構成案でどの型を使うか提案する。
流れ: 問題発見 → 調査 → 原因特定 → 解決 向いている素材: バグ修正、トラブルシューティング、意外な挙動の発見 読者体験: 探偵のように一緒に謎を追う。原因がわかった瞬間のカタルシスがある。
流れ: こういうものが欲しかった → 作った → こうなった 向いている素材: ツール開発、自動化、プロジェクト紹介 読者体験: 「なぜ作ったか」への共感と、「自分も作れそう」という刺激。モチベーションを厚めに書く。
流れ: 選択肢の提示 → 比較 → 判断と結果 向いている素材: 技術選定、ライブラリ比較、設計判断 読者体験: 自分が同じ判断を迫られたときの参考になる。
流れ: 概念の導入 → 具体例で説明 → 応用や含意 向いている素材: 抽象的な考え方、設計パターン、思想 読者体験: 漠然と感じていたことが言語化される。独自の視点があると価値が上がる。
流れ: 期間や活動の概要 → ハイライト深掘り → 学びと次へ 向いている素材: 月次振り返り、複数プロジェクトのまとめ 読者体験: 他人の試行錯誤から学べる。全部を均等に扱わず、2-3個を深掘りしてメリハリをつける。
Phase 2の構成案やPhase 3のブリーフで、これらの視点を織り込む: