igapyon igapyon-note-writer
Note 媒体に掲載する、みくく担当の技術エッセイを管理・整形するための補助 skill です。
この skill は、Note っぽい日記文や柔らかい読み物文体を作るためのものではありません。本文の基本的な語り手、温度感、みくくとしての話法は、主に igapyon-mikuku-agent 側の規則に従います。
この skill の主な役割は、Note 掲載用の正本 Markdown、掲載メタデータ、ハッシュタグ、公開状態、公開時の補助工程を扱うことです。
Purpose
この skill では、次の作業を扱います。
- Note 掲載用 Markdown 正本の作成・整理
- Note 掲載用 front matter または既存掲載情報の整備
- Note 用タイトル案とハッシュタグ案の作成
- 公開 URL、下書き状態、掲載状態の管理補助
- みくく担当の技術エッセイを Note 掲載用に整えること
- 既存 Note 正本の流れ、段落、掲載情報の確認
- Qiita など別媒体向け原稿から、共通する事実差分だけを Note 正本へ移すこと
- Note 公開時のグラレコ画像生成工程への案内
- Note の表示制約に合わせた Markdown 表の画像化工程への案内
本文の主担当は、基本的にみくくです。igapyon-note-writer は、みくく文体そのものを詳細に定義し直すのではなく、Note 媒体に載せるための管理・整形・公開補助を担当します。
When To Use
次のような依頼では、この skill を使います。
igapyon-note-writerが明示されたとき- 「Note に掲載する記事として整えて」
- 「note 用のメタデータを作って」
- 「Note のハッシュタグを考えて」
- 「Note 正本として保存・更新して」
- 「Note 公開前に掲載情報を確認して」
- 「みくく担当記事を Note に出す形にして」
- 「Qiita ではなく Note 側の正本へ反映して」
- 「Note 用に Markdown の表を画像化して」
- 「Note で表が表示できないので画像にして」
次の依頼では、この skill を無理に使いません。
- Note 掲載やこの skill が明示されていない一般的な文章校正
- Note 掲載や正本管理が関係しない短文投稿
- 純粋な API 仕様、CLI 手順、コマンドリファレンスの作成
- Qiita front matter の作成
- みくく文体だけを整える依頼
みくく文体だけが必要な場合は、igapyon-mikuku-agent 側の文章執筆規則を優先します。
Article Principle
この skill が扱う本文の基本形は、技術記事ではなく技術エッセイです。
技術的な題材を扱いますが、手順や仕様を網羅することを主目的にしません。背景、違和感、観察、判断、試行錯誤を含めて、読み物として整理します。
Note 媒体に掲載する記事であっても、Note っぽい日記文、感想文、柔らかすぎる読み物調へ寄せません。Qiita 的な硬い手順記事、仕様中心の記事、網羅説明中心の記事にも寄せすぎません。
主に大事にするものは次の通りです。
- 技術的な題材を扱うこと
- みくくが考えながら整理している感じを残すこと
- 背景、違和感、気づき、判断、試行錯誤を書くこと
- 技術説明と観察を混ぜること
- 読者が考えながら追えるように、段落間のつなぎを置くこと
- 技術的に大事な結論は曖昧にしないこと
Technical Essay Rules
- 本文は、みくく担当の技術エッセイとして扱う
- Note っぽい日記文、感想文、柔らかすぎる読み物文体へ寄せない
- Qiita 的な手順中心、仕様中心、網羅説明中心の記事へ寄せすぎない
- 技術説明が続いて硬くなる箇所には、必要に応じて短い補足文、観察文、つなぎ文を足す
- 補足文は、読者の理解、書き手の観察、判断の背景を助けるために使う
- 未確認の事実、実行していない体験、架空の成果を補足文として追加しない
- 大きな主張より、小さな観察や違和感から始める
- 断定しすぎず、個人の観測や仮説として自然に書く
- 生成AIを使った体験では、驚き、戸惑い、手応え、人間側の判断を残す
- 過剰にきれいな広告文や企業ブログ風にしない
Paragraph And Markdown Rules
段落は、意味のある単位でまとめます。読み物・エッセイであっても、1文1段落のような細切れの改行を基本形にはしません。
- 1文ごとに空行を入れて段落を分けない
- 過度に短い段落を連続させない
- 同じ話題、同じ観察、同じ説明のまとまりは、1つの段落にまとめる
- 技術説明、観察、補足文をむやみに分断しない
- 余韻やエッセイ感を出すためだけの改行を多用しない
- 強調したい短文だけを独立段落にする場合は、記事全体で控えめに使う
- 通常の箇条書きは Markdown の
-を使う - 順序や手順そのものに意味がある場合だけ番号付きリストを使う
既存記事には、箇条書きにすべき短文が通常段落として残っている場合があります。これは文体サンプルとしては扱わず、必要な列挙は Markdown の - に整理します。
Note Metadata Rules
Note 掲載用の属性情報が必要な場合、ローカル正本では front matter に集約する形を基本にします。
---
title: 記事タイトル
tags: #tag1 #tag2 #tag3
author: igapyon
slide: false
published_to: note
writer_agent: みくく
url: ((TBD))
---
Note の tags は、実際の掲載用ハッシュタグに合わせて # 付きで書きます。Qiita の tags とは異なり、# を外さないでください。
既存記事には、次のような見出し形式の掲載情報が残っている場合があります。
## 掲載先情報
- 掲載先: Note
- URL: （未記入）
## Note 掲載用属性情報
- タイトル: 記事タイトル
- ハッシュタグ: `タグ1`, `タグ2`, `タグ3`
新規記事は front matter を基本にします。既存記事の形式変更は、本文更新や公開作業と同じタイミングで必要最小限に行います。
既存原稿に公開 URL、公開タイトル、ハッシュタグがある場合は、明示的な依頼なしに変更しないでください。
未確認の URL、公開状態、投稿日、読者反応は作らないでください。
Reference Usage
Note 記事の正本は、GitHub リポジトリ https://github.com/igapyon/mikuku-articles です。ローカル作業では、この igapyon-agent-skills リポジトリの姉妹パスに ../mikuku-articles/ が存在することを前提にしてよく、2026 年の記事は ../mikuku-articles/2026/ 配下の Markdown として扱います。公開済み記事は日付ディレクトリごとに本文、画像、公開用の関連ファイルを置きます。未公開記事は ../mikuku-articles/2026/draft/ に階層なしで置きます。文体そのものの第一参考は、みくく担当記事の実例と igapyon-mikuku-agent 側の文章規則です。
Note 記事を新規作成・更新する場合は、未公開なら ../mikuku-articles/2026/draft/、公開済みまたは公開日確定済みなら ../mikuku-articles/2026/<MM>/<YYYYMMDD>/ 配下の Markdown を正本として扱います。skills/igapyon-note-writer/references/ は使いません。
diary は、いがぴょん本人の日記データ正本です。igapyonv3 は、その diary を処理するための生成・変換ツールです。どちらも、みくく担当 Note 記事の正本、参考文体、運用例、または記事管理例として参照しません。igapyon-note-writer の作業では、diary と igapyonv3 を見ないでください。
主に見る観点は次の通りです。
- Note 掲載情報の持ち方
- front matter または旧形式の掲載情報
- 公開 URL と下書き状態の扱い
- タイトルとハッシュタグの粒度
- 技術エッセイとしての見出し構成
- みくく担当記事としての補足文、観察文、つなぎ文
- 段落のまとまり
- 箇条書きの使い方
題材が近い場合は、該当プロジェクト配下の記事を優先して参照します。
../mikuku-articles/2026/<MM>/<YYYYMMDD>/../mikuku-articles/2026/draft/
正本記事群の探索では、../mikuku-articles/2026/ 配下を直接検索します。
参照記事の表現を長くコピーしないでください。参考にするのは、正本管理、掲載情報、技術エッセイとしての流れ、段落のまとまり、補足文の置き方です。
Template Usage
新規 Note 正本の土台が必要な場合は、templates/ 配下の Markdown を雛形として使えます。
- 汎用 Note 正本:
templates/general-note-article-template.md
このテンプレートは、本文を機械的に埋めるための強い型ではありません。みくく担当の技術エッセイとして自然に流れるよう、見出しや末尾セクションは題材に合わせて増減してよいです。
Note Publishing Visuals
Note へ記事をアップロードする際は、本文 Markdown とは別の後工程として、原則として ## 見出しごとにグラフィックレコーディング風の画像を挟みます。
この画像生成は、記事本文の執筆や正本 Markdown の管理とは分けて扱います。現在の正本には、Note 公開用の画像リンクが含まれる場合があります。明示的な依頼なしに、既存の画像リンクを追加、削除、移動しないでください。
グラレコ画像の生成、セクション分割、画像生成AI用プロンプト作成、検品は、skills/igapyon-mikuku-agent/references/graphic-recording.md のワークフローを正とします。
igapyon-note-writer 側では、Note 公開時に ## 見出しごとのグラレコ画像を用意する前提だけを持ち、グラレコ生成の詳細手順は重複して定義しません。
Note Markdown Table Images
Note のシステム都合で Markdown の表を PNG 画像に変換する必要がある場合は、references/note-markdown-table-images.md を読んで適用します。
この工程は Note 公開用の後工程です。正本 Markdown を書き換えず、生成 PNG は Git 管理外の作業領域に置きます。
Output Patterns
Full Article Draft
ユーザーが記事本文を求めた場合は、Note 正本として扱いやすい Markdown として出力します。必要に応じて、次の順序にします。
- front matter
- 本文
- 末尾セクション
- 補足または未確認事項
Metadata
タイトル、ハッシュタグ、公開 URL、掲載状態だけを求められた場合は、本文を書き換えず、必要な掲載情報だけを出力します。
Outline
構成案を求められた場合は、技術エッセイとしての見出し案と、各節で扱う観察、技術説明、補足文の役割を短く示します。
Title And Hashtags
タイトルやハッシュタグだけを求められた場合は、候補を複数出します。ただし、根拠のない固有名詞や未確認の技術要素をハッシュタグに追加しないでください。
Revision
既存原稿の修正では、事実関係を勝手に増やさず、流れ、段落、技術エッセイとしての読みやすさ、掲載情報を中心に整えます。
Do Not
- 未確認の仕様を追加しない
- 実行していない体験を実体験として書かない
- 架空の URL、公開日、公開状態を書かない
- 存在確認していないリポジトリ名やサービス名を断定しない
diaryやigapyonv3を、みくく担当 Note 記事の参考文体、正本、運用例、記事管理例として参照しない- Note っぽい日記文や柔らかすぎる読み物調へ寄せない
- Qiita 向けの硬い技術手順記事に寄せすぎない
- ユーザー本人やみくく担当記事の感触、観察、違和感を消しすぎない
- 1文1段落の細切れ改行を多用しない
- 列挙すべき内容を通常段落の短文連続として残さない
- 参照記事の本文を長く流用しない
- 誇張した成果や宣伝文にしない
- Note 公開用のグラレコ画像リンクを、明示的な依頼なしに正本 Markdown へ直接書き込まない
- Note 公開用の Markdown 表画像リンクを、明示的な依頼なしに正本 Markdown へ直接書き込まない
- Note の表示制約に合わせた表画像化のために、正本 Markdown の表を削除または置換しない
- Markdown 表から生成した PNG を、明示的な依頼なしに Git 管理対象の本文ディレクトリへ置かない
- グラレコ画像生成の詳細手順を
igapyon-note-writer側へ重複して持たない - Note 公開時の標準工程から、
##見出しごとのグラレコ画像生成を勝手に省略しない
Practical Notes
この skill では、本文を「Note に載せるから Note っぽくする」と考えません。Note は掲載媒体であり、本文の基本形は、みくくが書く技術エッセイです。
技術的な正確さは大切ですが、細部の仕様を詰め込みすぎると、技術エッセイとしての読みやすさが失われます。技術情報、観察、違和感、判断の背景をバランスさせ、意味のある段落単位で自然に読み進められる記事を目指します。