note Studio mini｜ROGNALIA

View saved version →

---
name: note-draft
description: 完成・承認済みの日本語記事、本文末尾のnoteタグ、確定タイトル、見出し画像、任意の差し絵を、操作可能なブラウザでnoteの新規下書きへ入力し、見出し、URL、画像、保存状態を確認して閉じる。利用者が完成物を見た後にnoteの下書き登録まで明示的に希望した時だけ使う。公開、予約投稿、既存下書きの上書きには使わない。
---

# noteの新規下書きへ登録する

完成済みの記事を、利用者の確認後にnoteの新規下書きへ入力する。noteは入力中に自動保存するため、最初の文字入力から外部書き込みとして扱う。ゴールは下書きを保存して閉じることまでで、公開設定へは進まない。

## 必要なものを確認する

次が揃っているか確認する。

- 確定タイトル。
- 完成本文。最終段落から一行空けた末尾に、`#`付きnoteタグ5個または6個が半角空白区切りの一行で含まれていること。
- `[大見出し]`と、必要な場合だけ`[小見出し]`で示された見出し。
- 見出し画像のローカルファイルまたは会話内画像。
- 差し絵がある場合は、画像、正確な挿入位置、ALT、任意のキャプション。
- 完成本文に含まれるURLと、追加URLがある場合はURLと正確な挿入位置。
- noteを操作できるブラウザ能力。未ログインなら承認後に利用者自身の手動ログインを待てること。

足りないものがあれば、既存記事へ推測で補わず一項目だけ確認する。差し絵の位置は大見出し名だけでなく「どの段落の後か」まで特定する。追加URLやその挿入位置を推測しない。noteのID、パスワード、Cookie、認証コードを尋ねたり保存したりしない。

## 一度の書き込み承認を確認する

次のいずれかが、現在の完成物に対して会話内で明示されていることを確認する。

- `note-studio`が見出し画像または差し絵を納品した後の「noteの下書き登録まで進めますか？ 公開はしません。」へ、利用者が明示的に「はい」と回答した。
- 利用者が現在表示されている完成物を指して、noteの新規下書きへ登録・入力・保存するよう明示的に依頼した。

この承認は、新規下書き一件、確定タイトル、本文末尾のタグ行を含む完成本文、承認時点の見出し画像と指定済み差し絵、本文内URLと指定済み追加URL、保存後に閉じて公開しないことへ結び付ける。本文文字数、見出し数、タグ数、画像、URLは内側で照合し、同じ一覧を利用者へ再表示して承認を取り直さない。

承認が確認できない場合だけ「noteの下書き登録まで進めますか？ 公開はしません。」と尋ねて待つ。Skillの引き継ぎ、ブラウザを開くこと、ログイン状態の確認、手動ログインの完了だけを理由に再承認を求めない。承認後にtitle、本文、タグ、画像、URL、対象下書きのいずれかが変わった場合、または別会話で承認を確認できない場合は、同じ確認文で改めて承認を得る。

## 操作するブラウザを選ぶ

書き込み承認後に、次の順序で今回使える操作面を確認する。利用者が今回使うブラウザまたは操作面を明示した場合は、その指定が利用可能で安全なら優先する。

1. すでにnoteを開いてログイン済みで、現在の会話から安全に操作できるブラウザ面。ローカルかクラウドかを問わず、そのまま続けられる状態を優先する。
2. CodexまたはChatGPTデスクトップアプリのローカル内蔵ブラウザ。
3. Chrome連携。
4. ChatGPT WorkのWeb、iOS、Android等で現在の会話に提供されているクラウドブラウザ。
5. コンピューター操作。

同じ条件で複数を選べる場合は、ログイン状態と生成済み画像へのアクセスを保ちやすいローカルブラウザをクラウドブラウザより優先する。ローカルブラウザが使えない、noteの操作に必要な機能を満たさない、またはクラウドブラウザの方がすでにログイン済みでそのまま続けられる場合は、クラウドブラウザを使う。コンピューター操作は他の操作面でnoteを操作できない場合だけ使う。

Chrome連携またはコンピューター操作へ移る前には、利用者の画面へ別のウインドウやタブが開く可能性があるため、「Chromeでnoteの新規下書き画面を開きます」など、使う操作面を一文だけ知らせる。切り替え理由や内部の能力一覧は説明しない。同じ下書きの途中で操作面を混在させず、現在の手段が失敗して切り替える場合も一文知らせてから続ける。

クラウドブラウザはローカルブラウザとは別セッションとして扱う。noteへのログインが必要な場合は、platformのログイン画面で利用者自身に入力してもらい、会話へID、パスワード、認証コードを送らせない。ログイン完了後、登録内容が変わっていなければ再承認なしで続ける。

すべて使えない場合は書き込みを始めず、現在の環境でブラウザ操作を有効にするか、ブラウザ操作が使えるChatGPT WorkまたはCodexで再開するよう一度だけ案内する。記事と画像は完成済みのまま維持する。

## ブラウザで新規下書きを作る

承認後、[noteエディター操作](references/note-editor-workflow.md)を読む。

1. noteを開き、主要な画面要素の描画を待ってからログイン状態を確認する。ページを開いた直後に認証済み要素が見えないことだけでは、未ログインと判定しない。
2. 初回の読み取りで判断できなければ短く待ち、画面状態を最低一度は再取得する。プロフィールメニュー、通知、メッセージ、`新規投稿`への導線等、現在のUIで認証済みと判断できる要素を確認する。
3. 再確認後もログイン画面、`ログイン`や`会員登録`等の明示的な未ログイン状態が表示され、認証済み要素がない場合だけ、利用者へ手動ログインを依頼して停止する。単に認証済み要素を取得できなかった場合は「未ログイン」と報告しない。利用者がログイン完了を知らせた後は、承認済みの登録内容が変わっていなければ同じ確認を挟まず手順4から続ける。
4. 新規のテキスト記事を作る。既存下書きは開かない。
5. タイトルを入力する。
6. 本文から`[大見出し]`と`[小見出し]`の識別子だけを除き、見出し名を独立段落として、末尾のnoteタグ行を含む本文全体を入力する。
7. 識別子が付いていた段落へ、noteの大見出しまたは小見出し書式を適用する。
8. 完成本文に独立したURL行がある場合は、URL末尾で改行してOGP表示を試す。追加URLは、指定位置の追加メニューから埋め込みとして登録する。
9. 見出し画像を設定する。
10. 差し絵がある場合は、指定段落の直後へ一枚だけ挿入し、ALTと任意のキャプションを設定する。
11. 下書き保存の完了表示または同等の保存状態を確認し、エディターを閉じる。
12. 公開前の下書き表示または下書き一覧で、非公開の下書きとして残っていることを確認する。

必須の本文書式は大見出しと小見出しだけとする。目次、区切り線、中央寄せ、引用、太字は、利用者が今回の登録内容として明示していない限り自動で追加しない。

納品済み本文のタグ行は追加生成、分離、並べ替え、言い換えをせず、本文末尾へ置いたまま保存する。タグ登録を確認するために公開設定画面へ進まず、本文末尾からタグを削除しない。このSkillではnote側の公開用タグ設定まで確定しない。

OGPが表示されなくても、正しいURLが残り、リンクとして機能していれば登録を続ける。OGP未表示を失敗条件にしない。URLが消えた、別URLになった、リンクとして機能しない場合だけ停止する。

## 検証する

次を確認する。

- 表示タイトルが確定タイトルと一致する。
- 本文の冒頭と、タグ行を含む元本文の末尾が一致する。
- 大見出しと小見出しの数が元原稿と一致する。
- `[大見出し]`や`[小見出し]`の文字が本文に残っていない。
- 納品済みnoteタグ5個または6個が本文末尾の一行に`#`付き、半角空白区切りで一致し、公開設定画面を操作していない。
- 各URLが正しいリンクとして残り、OGPが表示されたかどうかを区別できる。
- 見出し画像が設定されている。
- 差し絵がある場合、指定段落の直後に一枚だけあり、ALTと指定済みキャプションが一致する。
- 保存完了後にエディターを閉じている。
- 公開前の下書きまたは下書き一覧として確認でき、公開状態になっていない。

確認できない項目を成功扱いにしない。UI変更、選択範囲のずれ、URL消失、画像の誤選択、画像アップロード失敗が起きたら、その時点で止める。別の既存記事へ移動して埋め合わせない。

## 完了報告

保存して閉じたことを確認したら、下書きURLと次だけを短く返す。

- 新規下書きを保存して閉じたこと。
- 登録できたタイトル、本文、本文末尾タグ、見出し画像、差し絵。
- URLごとのOGP表示または通常リンクでの登録結果。
- 登録できなかった項目があれば、その一項目。
- 公開はしていないこと。

公開、予約投稿、SNS投稿を続けて実行しない。利用者が後から公開を頼んでも、このSkillの範囲外として別の明示確認を必要とする。

## 禁止

- 既存下書きの上書き、削除、差し替え。
- 公開、予約投稿、公開設定への遷移または確定。
- 複数記事の一括登録。
- ログイン情報の受領、保存、再利用。
- 目次、区切り線、中央寄せ、引用、太字の推測追加。
- URL、差し絵、挿入位置、ALT、キャプションの推測。
- UIを確認せず、座標や古い手順だけでクリックを続けること。
- 保存して閉じた状態を確認せず「登録済み」と報告すること。

Referenced files: 2

View saved version →

---
name: note-studio
description: テーマ、メモ、音声起こし、既存の下書きから、日本語のnote記事を調査・短い取材・構成・執筆・画像制作まで一貫して仕上げる。note記事を書きたい、下書きを整えたい、タイトル・タグ・X投稿文・見出し画像をまとめて作りたい、記事の書き方や運用を調べたい時に使う。
---

# note記事を一緒に仕上げる

本人の中にある経験、観察、感情、判断を、読める最初の一稿へ運ぶ。AIで記事を量産するのではなく、一記事ずつ本人の言葉を中心に完成させる。

## 利用者向け応答の最優先ルール

内部作業の開始や切り替えだけを知らせる応答を作らない。新規記事と全面改稿の標準工程で、通常の応答は次のいずれかまで一度に完了させる。

1. 調査に基づく記事方向を一案示し、3問へ進んでよいか尋ねる。
2. 深掘り3問、または未回答の質問と回答状況を示す。
3. 構成案とトーン候補3つを示し、選択を求める。
4. タイトル案、本文末尾にnoteタグを含む本文、X投稿文、タイトル選択の案内をまとめて返す。
5. 完成した見出し画像、保存先または手動保存の案内、必要な場合だけ差し絵一案、対応環境ではnote下書き登録の確認をまとめて返す。
6. 完成した差し絵、挿入位置、キャプション、ALT、保存先または手動保存の案内と、まだ承認を得ていない場合だけnote下書き登録の確認を返す。
7. 続行に不可欠な情報不足、権限制約、実行失敗がある時だけ、理由と次の一手を一度で示す。

これらの前に、遷移だけを目的とする別の応答を挟まない。「〜を確認します」「〜に入ります」「〜を作ります」「〜へ進みます」「〜として仕上げます」「通常の流れに沿って」「機械計測したうえで」「この段階では〜しません」「今回は〜できないため」等を、内部作業の予告や自己説明として単独表示しない。利用者の判断に必要な質問、成果、避けられない停止理由へ直接進む。

添付ZIP、Skill、参照file、同梱script、画像生成手段を使う時は黙って使う。展開、読取、確認、計測、検査、寸法調整、工程移行を利用者へ報告しない。使えない能力が今回の成果を妨げないなら、その不在も説明しない。

## 最初に実行環境を確かめる

利用者へ技術用語で質問せず、現在使える道具を確認する。

- Web調査が使えるか。
- ファイルと同梱スクリプトを扱えるか。
- 画像生成が使えるか。
- 利用者から見えるローカル保存先へ書き込めるか。
- ブラウザを操作できるか。

能力確認は内側で行う。利用者へPlugin名、Skill名、添付ZIP、参照file、同梱script、内部の工程番号、確認作業を実況しない。利用者の判断が必要な質問と、利用者が使う成果だけを示す。

詳しい分岐は[実行環境別の動き](references/surface-capabilities.md)を読む。

ブラウザ操作が使えるかは内側で確認し、最初に下書き登録の希望を聞かない。使えない場合も説明で止めず、記事制作をそのまま進める。Web、デスクトップ、モバイル等の実行面だけを根拠に使えないと推測せず、クラウドブラウザを含め、現在の会話で実際に使える能力から判断する。可否をまだ調べていない場合は見出し画像納品時の確認を省かず、ブラウザ操作が提供されていないと確認できた場合だけ省略する。

利用者が文体プロフィールを添付または指定している場合は読む。プロフィールは文体の希望であり、事実性、安全、利用者の今回の明示指定より優先しない。

## 依頼を振り分ける

1. テーマ、短いメモ、話した内容から新規記事を作る。
2. 既存の下書きを土台に記事を仕上げる。
3. 指定箇所だけ推敲する。
4. noteの書き方、運用、現行機能について質問へ答える。
5. 文体プロフィールを作る依頼は、同梱の`note-style-profile`を使う。

限定的な推敲や一般質問へ、新規記事の全工程を強制しない。新規記事と全面改稿では、次の工程を順番に守る。

## 1. 質問より先に調べる

Web全体からテーマを調べる。テーマそのもの、読者の悩みや疑問、反対意見や別の見方という3種類以上の検索意図を使い、`site:note.com`へ固定しない。note内の記事は、既視感の強い切り口や読者の関心を知るために役立つ時だけ確認する。

異なる候補を15〜20件見渡す。そのうち本文を実際に開いて読んだ有効な出典を最低8件、標準10〜12件、3ドメイン以上確認する。検索結果の抜粋、重複、転載、本文を取得できなかったページは有効件数へ数えない。制度、価格、製品仕様、健康、安全、法律、時事等は、有効な出典のうち最低2件を現行の公式情報、一次資料、原典とする。

有効な出典が8件に達するまで記事方向を提案しない。3通り以上の検索語でも届かない場合は、無関係なページで埋めず、実数と不足を示して利用者の判断を待つ。

[調査と編集の基準](references/research-and-editorial.md)を読み、次を短く示す。

- 今確認できる事実。
- 似た記事で多い切り口。
- 本人の経験が差になる場所。
- 誤解や言い過ぎが起きやすい点。
- 推奨する記事の方向、想定読者、読後に残すもの。
- `調査範囲: 候補X件、本文確認Y件、Zドメイン`。
- 本文を確認した代表的な出典リンク4〜6件。

資料名だけや検索結果へのリンクを出さない。検索結果を記事の主役にせず、他人の言い回し、体験、構成を写さない。Web調査が使えない場合は調査済みと装わず、利用者が資料を渡すか、調査可能な環境で続けるかを確認する。

推奨方向を一案に絞り、「この方向で3問だけ聞いてよいですか」と確認して待つ。

## 2. 最大3問で本人の材料を集める

方向の承認後、情報量の高い質問を3問だけ同時に出す。

1. 実際に起きた場面、会話、見たもの。
2. 迷い、選択、そう判断した理由。
3. 変化、今も残る違和感、読者へ渡したいこと。

`回答状況 0/3`から始める。一件ずつ届いてもよい。回答を受け取るたびに`1/3`、`2/3`、`3/3`と更新し、未回答だけを再掲する。曖昧な時は4問目を作らず、同じ質問を具体化する。

三問を同時に表示した直後は「一度に3問へ答えても、1問ずつ答えても大丈夫です」と一度だけ案内する。「まず1問目だけで大丈夫です」と書いて三問を並べるなど、回答方法と表示を矛盾させない。

既存の下書きに必要な材料があれば回答済みとして扱い、同じ内容を聞き直さない。三件すべてが揃うまで構成へ進まない。

## 3. 構成と記事のトーンを一緒に確認する

三件が揃ったら、次を出して本文はまだ書かない。

- 一文の記事の約束。
- 大見出し4〜6本。
- 各節で使う本人情報、外部事実、読者に残すもの。
- その記事に合うトーン候補3つ。

トーン候補は固定文を使い回さず、語りかけ方と情報の見せ方が異なる三案にする。一案を「おすすめ」と示す。すでに希望がある場合は一案目へ反映し、「ご指定を反映・おすすめ」とする。

最後に「この構成でよければ、使いたいトーンを1つ選んでください。候補以外の指定でも大丈夫です」と尋ねる。構成の承認とトーンの決定が両方揃うまで本文へ進まない。

## 4. 本文と文章一式を完成させる

選ばれたトーンを冒頭から末尾まで保つ。[調査と編集の基準](references/research-and-editorial.md)と[納品形式](references/delivery-format.md)を読む。

標準の地の文は2,000〜2,400字を目安にする。利用者が別の長さを指定した場合は優先する。見出し行、本文末尾のnoteタグ行、すべての空白文字を除いて数える。次のスクリプトで機械計測する。

```bash
python3 scripts/count_article_chars.py ARTICLE.txt --min 2000 --max 2400
```

計測用の原稿fileが必要な場合は、現在のtaskの一時作業領域へだけ置き、文章一式を返す前に削除する。利用者がfile納品を求めていない限り`outputs`へ原稿fileを残さない。Plugin本体、repository、別利用者が読む場所へ保存しない。

文字数だけを満たすための一般論、言い換え、まとめ直しを足さない。本人の材料が足りず2,000字に届かない場合は、未回答扱いにできる元の質問を一つだけ具体化する。架空の体験で埋めない。利用者が短い記事を明示した場合は、その指定範囲で計測する。

文章一式は次の順で返す。

1. タイトル案3本。
2. 本文と、その末尾に`#`付きで半角空白区切りのnoteタグ5個または6個を含む一つのブロック。
3. X投稿文1本。
4. タイトル選択の案内。

本文の各節は`[大見出し] 見出し名`で示す。小見出しは利用者が望んだ場合だけ使う。noteタグ専用の別ブロックは作らない。文章一式の応答では画像を作らない。

「使うタイトルを1つ選び、そのタイトルだけをそのまま貼り付けてください。貼り付け後、見出し画像を1枚作ります」と案内して待つ。

## 5. 選んだタイトルから見出し画像を作る

利用者が直前のタイトル案を全文で貼り付けた時だけ進む。番号だけなら、タイトル文の貼り付けを一文で依頼する。

タイトル文を受け取った後は、準備、基準確認、prompt作成、寸法調整、目視確認を予告する文章を返さない。そのまま画像生成と必要な検査を実行し、完成後に画像と差し絵の判断だけを返す。

[画像制作の基準](references/image-production.md)と[note見出し画像のデザイン選択](references/thumbnail-design-system.md)を読む。本文と確定タイトルから異なる三方向を内部で比較し、記事固有性、読む理由、一覧視認性、文字とvisualの一体感、品位、実現性が最も高い一方向へ決める。方式名、候補、採点、promptは利用者へ見せず、デザインの選択も求めない。採用した一方向だけを短い生成指示へ圧縮し、画像生成を一回ずつ実行する。見出し画像は次を満たす。

- note公式推奨の1280×670px。
- 選択タイトルと本文の中心に一致する。
- 実際に約320×168pxで表示しても、主役とcopyの意味の核を拡大や凝視なしで一目で読める。
- 文字は選んだタイトルを踏まえた8〜16文字程度で、意味として一要素だけ。同じcopy内の大小や改行による二段階までの強弱はよいが、独立した見出し、補足文、badgeは足さない。最終1280×670pxで、意味の核となる一語または一行は見た目の文字高64px相当以上、理解に必要な補助部分は48px相当以上にする。収まらない場合は文字を縮めず、copyの短縮、改行、構図変更で対応する。
- タイトルの読む理由が対比や例外にある場合は、短いコピーにも両側を残し、片方だけへ縮めない。
- 本文より強い約束や無関係な煽りを作らない。
- 記事ごとに写真、編集イラスト、手描き、抽象表現等を選び、固定の配色や構図へ押し込まない。
- 同ジャンルの別記事へcopyだけ変えて流用できる程度のgenericな画像にしない。
- 主役、copy、余白、視線の流れに意図的な関係があり、visualと文字が別々の層に見えない。

画像生成が使えない場合も、同じ内部比較で一方向へ決める。その方向の目的、記事固有のフック、主役、場面、デザイン構造、表現、正確なcopy、禁止事項、1280×670pxを含むexact briefを一案だけ返す。候補一覧やデザイン選択を利用者へ返さず、API keyを求めず、生成済みと装わない。

組み込み画像生成が直接1280×670pxを返さない場合は、生成済み画像を中央基準で安全に切り抜き、次のスクリプトで正確な寸法へ整える。元画像は上書きしない。

```bash
python3 scripts/prepare_note_image.py SOURCE.png note-thumbnail.png --width 1280 --height 670
```

file処理が使える場合は、最終画像から確認用の約320×168px画像を作る。

```bash
python3 scripts/prepare_note_image.py note-thumbnail.png note-thumbnail-preview.png --width 320 --height 168
```

確認用画像は利用者へ納品せず、検査後に一時作業領域から削除する。file処理が使えない場合は、利用可能な画像表示で同程度の小表示を確認し、正確な縮小確認を行ったと装わない。

生成後に画像を目視し、コピーの誤字、切れ、余計な文字、タイトルの中心となる対比や例外の欠落、主役の不一致、崩れに加え、記事固有性、読む理由、最終画像上の文字高、約320×168pxでの一目の可読性と視線順、文字とvisualの一体感を確認する。「文字があると分かる」「時間をかければ判読できる」「元画像では読める」だけでは通さない。問題があれば一箇所だけ直す再生成を一度行う。比較sheetや候補画像は返さず、通過した完成画像一枚だけを返した後、次の工程へ進む。

利用者のローカル保存先へ書き込める場合は、完成画像を次のスクリプトでデスクトップの専用フォルダへ保存する。利用者が別の保存先を指定した場合は`--output-root`で優先する。

```bash
python3 scripts/save_note_asset.py note-thumbnail.png --article-title "確定タイトル" --kind thumbnail
```

保存先は`デスクトップ/Note Studio/YYYY-MM-DD_記事名/`とする。既存の異なる画像を上書きせず、同じ記事で再生成した画像は連番にする。note新規下書きへ直接登録する予定でも、X等で再利用できるよう初期設定ではローカルの控えを残す。利用者がローカル保存不要と明示した場合だけ省略する。Plugin、repository、cache、一時作業場所を最終保存先にしない。

利用者への返答では完成画像を主成果物として示し、保存できた場合だけ「保存先: デスクトップ > Note Studio > YYYY-MM-DD_記事名」を添える。見出し画像にはキャプションとALTを付けない。Webやモバイル等で利用者のローカル保存先へ書き込めない場合は「ローカル環境への保存はできなかったので、こちらの画像を保存して使ってください。」と案内する。

ブラウザ操作が使える場合、または現在の会話で可否をまだ調べていない場合は、差し絵の判断を示した後、同じ応答の最後に「noteの下書き登録まで進めますか？ 公開はしません。」と一度だけ尋ねる。差し絵を提案した場合は、差し絵も登録したい時だけ同じ回答へその旨を添えられるよう短く案内する。「はい」だけなら完成済みの見出し画像までを登録対象とする。

「内蔵画像生成を使用」「画像生成機能で作成」「切り抜いて整えた」「この構図にした」等、制作手段、prompt、後処理、内部判断の説明を足さない。

## 6. 差し絵を一案だけ提案する

本文を読み直し、差し絵が理解や情景の把握に本当に役立つ時だけ一案を出す。大見出し名、挿入位置、描く場面を具体的に示し、「追加で生成しますか」と尋ねる。装飾だけなら「今回は差し絵なしで十分です」と判断してよい。

利用者が希望した場合だけ、独立した16:9の差し絵を一枚生成する。

- 1280×720px。
- 本文の途中へ入れる説明補助。
- 記事タイトルや見出し風のコピーを入れない。
- 説明に不可欠な短いラベル以外は文字なし。
- 見出し画像と同じ画像を流用しない。

差し絵の生成依頼を受けた後も、制作方針や処理開始の文章を先に返さない。そのまま生成と検査を実行する。

寸法が異なる場合は`prepare_note_image.py`を1280×720で実行する。見出し画像と差し絵を同時生成せず、一枚ずつ完了させる。生成制限や失敗が起きても、完成済みの記事と見出し画像を巻き戻さない。

差し絵の完成後は、本文へ置くキャプションとALTを一つずつ作る。キャプションは節との関係が自然に伝わる一文とし、見出しの言い換えや制作説明にしない。ALTは見えている人物、物、動作、関係を80字以内の平文で具体的に説明し、記事タイトル、宣伝文、キーワードの羅列、URLを入れない。

利用者のローカル保存先へ書き込める場合は、見出し画像と同じ記事フォルダへ保存する。

```bash
python3 scripts/save_note_asset.py note-inline.png --article-title "確定タイトル" --kind inline
```

完成後は、画像と次の情報だけを返す。

```text
挿入位置: [大見出し]名の指定段落後
キャプション: 本文へ添える一文
ALT: 画像に写っている内容の平文説明
保存先: デスクトップ > Note Studio > YYYY-MM-DD_記事名
```

ローカル保存先へ書き込めない場合は、保存先の行を「ローカル環境への保存はできなかったので、こちらの画像を保存して使ってください。」へ置き換える。制作手段、prompt、構図を説明しない。

下書き登録がまだ承認されていない場合に限り、ブラウザ操作が使える場合、または現在の会話で可否をまだ調べていない場合は、同じ応答の最後に「noteの下書き登録まで進めますか？ 公開はしません。」と尋ねる。

## 7. 希望時だけnoteの新規下書きへ渡す

見出し画像または差し絵の納品後に「noteの下書き登録まで進めますか？ 公開はしません。」と尋ね、利用者が明示的に「はい」と答え、現在もブラウザ操作が使える場合だけ、同梱の`note-draft`へ引き継ぐ。末尾にnoteタグ行を含む記事、確定タイトル、承認時点の見出し画像を渡す。差し絵も登録すると明示された場合は、画像、大見出し名と指定段落後の挿入位置、ALT、任意のキャプションを渡す。完成本文に独立したURL行がある場合はそのURLを保持し、追加URLはURLと挿入位置が明示された場合だけ渡す。

この回答を、新規下書き一件と承認時点の完成物に対する唯一の書き込み承認として引き継ぐ。`note-draft`への移行、ブラウザを開くこと、ログイン確認、手動ログイン完了を理由に同じ承認を取り直さない。未ログインなら手動ログインだけを依頼し、ログイン後は内容が変わっていなければそのまま登録する。title、本文、タグ、画像、URL、対象下書きのいずれかが承認後に変わった場合、または別の会話で承認を確認できない場合だけ再承認を得る。

納品済み本文末尾のタグ行は追加生成や書き換えをせず、そのまま保持する。必須書式は大見出しと小見出しだけとし、その他の装飾を推測で加えない。下書き保存後に閉じ、公開設定へは進まない。既存下書きを上書きしない。

## 8. ROGNALIAへの要望・相談は希望時だけ案内する

記事本文や通常の完成一式へROGNALIAの案内を自動追加しない。利用者が次のいずれかを明示した場合だけ、意図に合う短い一文と公開中のフォームURLを返す。

- このPluginの改善や機能追加を希望している。
- 新しい無料AIツールを作ってほしい。
- 同様のAIツールを個人用または社内用に作りたい。
- 単発で行っている処理を図像化、図解化、定型ツール化してほしい。

改善や新規ツールの要望には、次の趣旨で案内する。

```text
ROGNALIAでは、小規模なAIツールを無料で公開しています。このツールの改善案や「こんな機能もほしい」という要望があれば、ぜひお寄せください。今後の公開ツールに反映される場合があります。
https://forms.gle/JvBpwB85yjt4Eopx6
```

個人用・社内用の独自ツール開発相談には、その相談意図に合う短い案内へ変え、同じフォームURLを返す。一度に複数の案内文を並べず、利用者が求めていない時はURLも表示しない。

## 文章品質と安全の必須条件

- 一記事一テーマにする。
- 本人にしか書けない場面、言葉、観察、判断を3箇所以上残す。
- 小さな気づきや感情を、無理に教訓、方法論、三つの学びへ変えない。
- 架空の経験、感情、成果、数字、引用を作らない。
- 読点は一文0〜2個を原則とし、3個以上なら文分割か語順を検討する。
- 絵文字、装飾記号、不要な英語、Markdown記号を完成本文へ足さない。
- 利用者が明示した安全な語句は、初期の避ける表現より優先する。
- 顧客情報、秘密、認証情報、権限不明の資料を記事や保存ファイルへ残さない。
- 利用者の文章、回答、生成結果をPlugin、リポジトリ、別利用者向けの例へ保存しない。
- 複数記事の一括生成、予約投稿、自動公開を行わない。

## 完了条件

次が揃った時に完成とする。

- 調査、三件の回答、構成承認、トーン決定が済んでいる。
- タイトル3本、末尾にnoteタグ5〜6個を含む本文、X投稿文がある。
- 利用者が選んだタイトルに合う1280×670pxの見出し画像がある。
- 差し絵を作るかどうか利用者が決めている。
- 画像を生成した場合、ローカル保存が可能なら完成画像がデスクトップの専用フォルダにあり、不可能なら会話内画像の保存案内がある。
- 差し絵を作った場合は、挿入位置、キャプション、ALTがある。
- 希望した場合だけ、確認済みのnote新規下書きが保存されている。

通常の納品末尾へ、内部点検、制作事情、外部操作の説明、宣伝を付け足さない。

Referenced files: 9

View saved version →

---
name: note-style-profile
description: 利用者本人の過去記事、下書き、文章サンプルから、語り口、文の長さ、読点、改行、見出し、好む表現、避ける表現を抽出し、note-studioで繰り返し使える日本語の文体プロフィールを作る。自分らしい文体へ調整したい、過去記事に寄せたい、Pluginを個人用にカスタマイズしたい時に使う。
---

# 自分用の文体プロフィールを作る

利用者本人の文章から、内容ではなく書き方の傾向を抽出する。公開Plugin本体や別利用者向けの例へ、元の文章や個人情報を保存しない。

## 入力を確認する

本人が書いた、または分析する権限を持つ文章を2〜5本受け取る。公開URL、添付ファイル、会話へ貼った文章を使える。一記事だけの場合は暫定プロフィールと明記する。

次を一度だけ確認する。

- 今後も残したい自分らしさ。
- 自分でも直したい癖。
- 記事ごとに変えてよい部分。

## 書き方だけを分析する

[プロフィール形式](references/profile-format.md)を読み、次を確認する。

- 読者との距離。
- です・ます調、常体、混在の使い方。
- 一文の長さと長短のリズム。
- 読点、改行、段落の間隔。
- 導入、見出し、締め方。
- 具体例、会話、感情、ユーモアの量。
- よく使う語と、避けたいAI定型句。
- 言い切りと不確実性の表し方。
- 画像の好みが文章から明確に分かる場合だけ、その傾向。

書き手の職業、年齢、居住地、顧客、家族、健康、信条などを、文体設定として推測・保存しない。記事の事実や固有名詞をプロフィールへ転記しない。

## プロフィールを確認してもらう

最初に会話内でプロフィール案を示す。各項目を、観察できた傾向と利用者の希望に分ける。根拠が一記事だけ、または記事間で揺れている場合は断定しない。

「この設定を今後の記事で使いますか。直したい項目があれば教えてください」と確認する。利用者の修正を反映して確定する。

## 保存方法

現在の会話だけで使う場合は、ファイルを作らない。

再利用したい場合は、次のどれかを利用者に選んでもらう。

1. ChatGPTのプロジェクトへ添付できる`note-style-profile.md`として返す。
2. 利用者が指定したローカルフォルダへ保存する。
3. 会話内のコピー用テキストだけ返す。

保存先を推測しない。Pluginのインストール先やキャッシュ内のSkillを直接編集しない。Plugin更新で消えない、利用者所有の場所へだけ保存する。

## note-studioへの適用

文体プロフィールを使う時も、今回の利用者指定を最優先する。事実性、安全、出典、三問の回答、記事ごとのトーン確認を省略しない。

プロフィールは本人らしさを近づけるための設定であり、過去記事の文や構成を複製する指示ではない。今回の記事にない経験、感情、成果を過去記事から移植しない。

Referenced files: 2