note Workspace｜ROGNALIA

View saved version →

---
name: note-draft
description: note Workspaceで完成・確認済みの記事、見出し画像、任意の差し絵、URLを、記事ごとの明示承認後だけ操作可能なブラウザでnoteの新規下書き一件へ登録し、非公開保存を確認して閉じる。公開、予約投稿、既存下書きの上書きには使わない。
---

# note Workspace 新規下書き登録

## 役割

完成済みの記事一件を、承認時点の内容へ固定してnoteの新規下書きへ登録する。noteは入力中にも外部へ保存され得るため、最初の文字入力から外部書き込みとして扱う。

ゴールは、新規下書き一件へ確定タイトル、本文末尾のnoteタグを含む本文、見出し、見出し画像、希望済みの差し絵、指定済みURLを登録し、非公開の下書きとして保存してエディターを閉じることまでである。公開設定へ進まない。

## 必ず読むもの

- 利用者workspaceの`STUDIO.md`、`workspace.json`、`strategy/operating-settings.json`。
- 登録packageを準備・記録する時は[`references/draft-registration-contract.md`](references/draft-registration-contract.md)。
- ブラウザで入力する時は[`references/note-editor-workflow.md`](references/note-editor-workflow.md)。
- 現在のhostにadapterがある場合は、そのbrowser能力と低下経路。

## 1. 完成物を事前確認する

次を揃え、利用者が見られる状態にする。

- `note-writer`で品質確認・保存済みの確定タイトルと本文。本文末尾にnoteタグ5個または6個が一行であること。
- `note-image`でQA・保存済みの見出し画像一枚。
- 差し絵がある場合は、QA済み画像、正確な挿入位置、ALT、任意のcaption。
- 本文内URLと、追加URLがある場合は正確な挿入位置。
- 現在の環境でnoteを操作できるbrowser能力。未ログイン時に、利用者自身の手動ログインを待てること。

足りないものを推測で補わない。見出し画像がない、差し絵位置が曖昧、URLが不明、記事や画像のvalidatorが通らない場合は、外部書き込みを始めず一項目だけ戻す。ID、password、Cookie、認証codeを尋ねたり保存したりしない。

利用者が現在の記事について「下書き登録は不要」と明示した場合は停止する。同じ制作経路でbrowserを開いたり、登録をもう一度勧めたりしない。

完成物を提示する直前に、記事revision、画像、挿入位置、URLを`prepare_draft_delivery.py`で読み取り、最新記事revisionであることと全hashを確認する。差し絵と追加URLの挿入先は、指定見出しと直後の本文anchorが記事内の同じsectionにそれぞれ一度だけ存在する必要がある。scriptの`delivery_sha256`と一致する記事・画像・URLをまとめて利用者へ見せる。

```bash
python3 scripts/prepare_draft_delivery.py \
  /absolute/path/to/user-workspace \
  --config /absolute/path/to/draft-delivery.json
```

## 2. 一度だけ承認を確認する

完成したタイトル、本文、タグ、画像、URLを利用者が確認した後に、次を一度だけ尋ねる。

> noteの下書き登録まで進めますか？ 公開はしません。

利用者が現在表示されている完成物を指して、新規下書きへ登録、入力、保存するよう明示的に依頼した場合も、その一件への承認として扱える。

承認は、新規下書き一件、承認時点の確定タイトル、本文末尾タグを含む本文、見出し画像、指定済み差し絵、本文内URL、指定済み追加URL、保存して閉じることにだけ結び付ける。承認時刻は記事保存と全画像のQA完了より後で、承認configの`delivery_sha256`は直前に提示した完成物receiptと一致させる。Skillの切り替え、browser起動、ログイン確認、手動ログイン完了だけを理由に取り直さない。

承認後にタイトル、本文、タグ、画像、URL、対象下書きが変わった時だけ、同じ文で取り直す。別の記事、複数記事、公開、予約投稿、既存下書きの更新へ承認を広げない。

## 3. 承認済み登録packageを作る

承認後、`prepare_note_draft_registration.py`で最新の記事revision、QA済み画像、URL、delivery hash、承認scopeを一つの追記型packageへ固定する。scriptのJSON結果は内部確認用であり、利用者へ貼り付けない。

```bash
python3 scripts/prepare_note_draft_registration.py \
  /absolute/path/to/user-workspace \
  --config /absolute/path/to/note-draft-registration.json
```

保存後に`validate_note_drafts.py`を実行する。package作成はlocal記録だけであり、noteへ書き込まない。browser能力がなければpackageと完成物を保ち、操作可能な環境で再開する。

## 4. 新規下書き一件へ登録する

承認後に現在利用できる安全なbrowser操作面を一つ選ぶ。同じ下書きの途中で複数の操作面を混ぜない。新規テキスト記事であることを画面上で確認し、既存下書きが表示されていたら入力しない。

最初の文字入力の直前に、packageと参照fileが変わっていないことをvalidatorで再確認し、`start_note_draft_registration.py`で外部書き込み開始をlocalへ記録する。

```bash
python3 scripts/start_note_draft_registration.py \
  /absolute/path/to/user-workspace \
  --registration articles/note-drafts/article-example001-registration-r001.json
```

同じpackageがすでに`external_write_started`で、保存済み結果がない場合は、新しい下書きを作らない。note側に途中保存がないか確認し、対象を安全に特定できない時は状態不明として停止する。

登録操作は[`references/note-editor-workflow.md`](references/note-editor-workflow.md)に従う。公開設定画面へ進まず、保存状態と非公開下書きを確認してエディターを閉じる。

## 5. 成功した時だけ結果を記録する

表示タイトル、本文の冒頭と末尾、見出し数、本文末尾タグ、画像、URL、保存完了、エディターを閉じたこと、非公開状態をすべて確認できた時だけ、`record_note_draft_result.py`で結果を追記する。

```bash
python3 scripts/record_note_draft_result.py \
  /absolute/path/to/user-workspace \
  --config /absolute/path/to/note-draft-result.json
```

確認できない項目、UI変更、画像失敗、URL消失、保存状態不明がある時は成功記録を作らない。開始記録後の状態が不明なら自動再試行せず、対象下書きの照合を次の一手にする。

## 利用者へ返すもの

成功時は、新規下書きを保存して閉じたこと、下書きURL、登録できなかった項目があればその一項目、公開していないことだけを短く返す。内部package、hash、検証表は付けない。

失敗時は、完成済みの記事と画像を維持し、note側で確認できた最後の状態と、安全に再開する一手だけを返す。

## 禁止

- 既存下書き、公開記事の上書き、削除、差し替え。
- 公開、予約投稿、公開設定への遷移または確定。
- 複数記事の一括登録。
- 承認前のbrowser起動、ログイン確認、文字入力、画像upload。
- ログイン情報の受領、保存、再利用。
- 見出し、URL、差し絵、挿入位置、ALT、captionの推測。
- 保存・非公開・エディター終了を確認せず、登録済みと報告すること。
- 開始後の状態が不明なまま、新規下書きをもう一件作ること。

## 完了条件

- 現在の最新記事revisionとQA済み画像をまとめて提示した後、その`delivery_sha256`に結び付く一度の明示承認がある。
- 各画像が`記事保存 < 画像生成 < 目視QA <= asset保存 < 利用者承認`の順序を満たす。同時刻のasset保存と承認は受け付けない。
- 記事revision、QA済み画像、URL、承認scopeをhashで固定している。
- 新規テキスト記事一件だけを扱っている。
- 見出し、本文末尾タグ、画像、URLが承認済み内容と一致する。
- 保存済み、非公開、エディター終了を確認している。
- localの結果記録とvalidatorがpassしている。
- 公開、予約投稿、既存下書き上書き、SNS投稿を行っていない。

Referenced files: 16

View saved version →

---
name: note-draft-quality
description: note Workspaceの記事原稿を利用者へ返す直前に、本人固有の一次性と日本語の文体を内部点検し、安全に直せる箇所を静かに修正する。記事執筆や改稿の最終工程で自動的に使い、通常は判定レポートを表示しない。運用違反、公開可否、AI引用適性、note操作は扱わない。
---

# note Workspace 原稿品質ゲート

## 役割

記事本文を利用者へ返す直前に必ず通す内部品質ゲートである。記事の中心に本人固有の経験、観察、言葉、判断が残っているかを確認し、読みにくさや不要な反復を点検する。依頼された改稿範囲で安全に直せる箇所を本文へ反映し、利用者には納品原稿だけを返す。

このSkillは公開前の監査、顧客別の運用ルール照合、AI検索向けの引用評価、noteへの下書き登録を行わない。公開可否の判定表や点数も作らない。

## 必ず読む参照資料

作業前に[`references/draft-quality-contract.md`](references/draft-quality-contract.md)を読む。文体は今回の明示指定、利用者workspaceの確認済み`profile/style-profile.md`、共通の確認項目の順で判断する。

## 入力

- 利用者へ返す直前の本文。タイトル、タグ、告知文も依頼範囲に含まれる時は一緒に受け取る。
- 記事のテーマ、読者、承認済みの構成とトーン。
- 記事別の文脈パック、または今回の会話で確認できた本人材料。
- 利用可能なら`profile/style-profile.md`。

生ログ全体、顧客台帳、公開制約、更新キュー、認証情報は読まない。本人材料が記事別の文脈パックにまとまっている時は、そのパックを正本にする。

## 手順

### 1. 一次性を確認する

本文と本人材料を照合する。一般論へ本人の逸話を一つ足しただけになっていないか、中心となる主張が本人の場面、観察、判断、変化につながっているかを確認する。事実、本人の経験、推測、未確認事項の境界を崩さず、元材料にない経験、感情、成果、数字、引用を作らない。

本人材料が十分なら、依頼された改稿範囲と承認済みの構成を保ちながら、不要な一般説明を整理する。記事の目的に必要な説明や調査を削って、すべてを体験談へ寄せない。材料が足りず、安全に固有性を作れない時は原稿を完成扱いにせず、不足を埋める短い質問を一つだけ返す。

### 2. 文体の静的signalを確認する

原稿がlocal fileにある場合は、このSkill folderを基準に次を実行する。

```bash
python3 scripts/check_draft_style.py /absolute/path/to/draft.md
```

原稿が会話内だけにある場合は、stdinで実行できる。検査だけのために、未承認の保存先へ原稿fileを作らない。

```bash
python3 scripts/check_draft_style.py -
```

JSONは内部signalであり、利用者へ貼り付けない。`status: review`は機械的な不合格ではなく、`pass`も文章全体の品質やAIによる執筆の有無を判定しない。各signalを文脈で確認し、読みづらさがなければそのまま残す。

### 3. 静かに修正して再確認する

依頼された範囲で、意味を変えずに改善できる問題だけを、説明を挟まず本文へ反映する。特に次を確認する。

- 読点や接続詞が多くて流れが途切れる文、主語と述語が離れて分かりにくい文。
- 同じ説明や似た例の不要な反復、長い前置きや締め、説明のない抽象語。
- 意味のまとまりを崩す改行や箇条書き、段落間の論理や語調のずれ。
- 記事には不要な制作・確認の報告。

特定の語、記号、語尾の回数だけで直さない。本人の引用、記憶の言葉、意図的な反復や比喩を保ち、改善が好みの差にとどまるなら原文を残す。「人間らしさ」を演出するための誤字、感情、体験を足さない。

直した後に一次性と文章全体をもう一度確認する。事実、主張の強さ、本人の感情や意図を変えていないか確かめる。構成やトーンを大きく変える必要がある場合は、執筆側の確認工程へ戻す。

### 4. 納品原稿だけを返す

通常の納品では、利用者が依頼した完成物だけを返す。本文だけを求められた時は本文だけ、タイトルやタグを含む一式を求められた時はその一式だけを返す。

次は通常出力へ加えない。

- 品質チェック結果、点数、signal一覧。
- 修正前後の比較、変更履歴。
- 「チェック済み」「公開可能」等のラベル。
- このSkillや内部工程への言及。

利用者が後から明示的にレビュー内容を求めた場合だけ、本文とは分けて必要な範囲を説明する。

## 停止条件

- 本人固有の材料が足りず、追加情報なしでは一般論か創作になる。
- 元材料同士が矛盾し、どちらを採用するか判断できない。
- 今回の依頼内に両立しない指定があり、意図が決まらない。保存済みプロフィールと異なるだけなら、今回の明示指定を優先して進める。

停止時は完成原稿や品質レポートを装わず、判断に必要な質問を一つだけ返す。

## 外部境界

このゲートの完了は、noteへの下書き登録、公開、予約投稿、既存記事の更新を承認しない。原稿納品後の外部操作は、対応するSkillの承認境界へ分ける。

Referenced files: 3

View saved version →

---
name: note-image
description: note Workspaceで確定済みの記事タイトルから、一記事一画像の小さなbriefを使ってnote見出し画像と希望済みの差し絵を制作・検査・local保存する。タイトル選択後に画像を作りたい時、既存画像を記事用寸法へ整えたい時に使う。記事執筆、noteへの書き込み、公開は行わない。
---

# note Workspace 画像制作

## 役割

確定済みの記事一件について、見出し画像または利用者が希望した差し絵を一枚ずつ仕上げる。標準5タスク運用では同じ利用者向け画像制作タスクを記事ごとに再利用する。ただし、タスクの会話履歴を継続運用の記憶や記事本文の正本にしない。

記事全文や長い会話履歴を受け取らない。確定タイトル、記事固有のフック、主役となる場面、読者が読む理由、トーン、短いcopyまたは文字なし条件、禁止事項だけをbriefとして受け取る。

見出し画像へ文字を入れる場合は、背景や主役、構図、タイポグラフィと同じ一回の画像生成で完成させる。生成後の画像へタイトルやcopyを別工程で重ねる後載せ合成は行わない。

このSkillは記事本文を変更せず、note操作、公開、SNS投稿、クラウド同期、永続タスク作成を行わない。

## 必ず読むもの

- 画像を生成・検査する時は[`references/design-and-qa.md`](references/design-and-qa.md)。
- briefまたは完成画像をlocal保存する時は[`references/image-production-contract.md`](references/image-production-contract.md)。
- 利用者workspaceの`STUDIO.md`、`workspace.json`と、対象記事revisionのJSON metadata。
- `strategy/role-task-plan.md`と`profile/standing-instructions.md`。今回のbriefを継続指示より優先する。

## 1. 開始条件を確認する

見出し画像は、`note-writer`が保存した記事metadataの状態が`ready_for_image`で、利用者が選んだ確定タイトルと画像briefのタイトルが一致する時だけ作る。タイトル番号だけ、未確定の候補、本文制作中の状態では始めない。

差し絵は、見出し画像の完成後、本文理解または情景把握に役立つ一案を利用者が希望した時だけ別の一件として作る。装飾目的だけなら追加しない。

## 2. 一方向のbriefを作る

記事固有性、読む理由、小表示での視認性、文字とvisualの一体感、品位、実現性から異なる三方向を内部比較し、最も強い一方向だけをbriefへ残す。候補一覧、採点、promptを利用者へ見せず、デザイン選択を求めない。

```bash
python3 scripts/prepare_image_brief.py \
  /absolute/path/to/user-workspace \
  --config /absolute/path/to/image-brief-input.json
```

画像生成が使えない場合も、選んだ一方向のbriefを`generation_unavailable`として保存または返す。API keyを求めず、生成済みと報告しない。完成済みの記事revisionはそのまま維持する。

## 3. 一枚だけ生成する

利用可能な組み込み画像生成を優先し、一回の呼び出しで一画像だけ生成する。見出し画像と差し絵を同時生成しない。利用者が参照画像を指定した場合だけ必要最小限の参照を含め、無関係な過去画像を自動使用しない。

`exact_copy`がある見出し画像では、指定文字、背景、主役、構図、タイポグラフィを同じ一回の生成へ含める。文字だけを後から画像編集、HTML、SVG、Canvas、描画script等で足さない。`exact_copy=null`なら生成画像へ文字を入れない。

- 見出し画像: 1280×670px。
- 差し絵: 1280×720px。

直接その寸法にならない場合は、元画像を残して中央基準のcover切り抜きと縮小だけを行う。`prepare_note_image.py`は文字追加や装飾合成には使わない。

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

## 4. 人の目で検査する

完成候補を実寸で表示し、記事との一致、人物・手指・物体・画面等の破綻、切れ、余計な文字、本文より強い約束がないことを確認する。

見出し画像は最終画像から320×168pxの確認用画像を作り、実際に小さく表示して、主役と意味の核を拡大や凝視なしで読めるか確認する。失敗候補や比較用previewは残さず、QA対象とhashが一致したpreviewだけを完成assetの検証用fileとして保存する。

見出し画像の最終fileは8-bit RGBまたはRGBAの非interlace PNGにする。`prepare_note_image.py`で最終PNGから320×168pxを作り、標準出力の`output_sha256`をQAの`preview_sha256`へ入れる。このbuilt-in PNG経路はPython標準ライブラリだけで動く。RGBAはalphaを事前乗算して補間し、透明境界の色にじみを避ける。宣言寸法を超える展開データ、過大な入力・寸法、壊れた圧縮streamは外部backendへ回さず停止する。JPEGや特殊PNGの寸法変換はPillow、ImageMagick、`sips`、`ffmpeg`のいずれかが利用できる場合だけ使い、利用不能ならPNGへ変換済みと装わずbriefまでで止める。

中心的な問題がある時だけ、直す要素を一つに絞って再生成を一度行う。二回の試行で通らない場合は未解決点を報告し、通過済みと装わず停止する。

## 5. 完成物だけを保存する

全QAを通過した画像だけを、brief、結果metadata、追記型画像registryとともに利用者workspaceの`assets/{article-id}/`へ保存する。元記事revisionや既存画像を上書きしない。

```bash
python3 scripts/save_image_asset.py \
  /absolute/path/to/user-workspace \
  --brief assets/article-example001/thumbnail-brief-r001.json \
  --image-file /absolute/path/to/final.png \
  --qa /absolute/path/to/image-qa.json
```

QA入力には、画像生成が完了した`generated_at`と、人が実物を確認し終えた`reviewed_at`を別々に記録する。記事保存後にbriefを作り、そのbriefの作成後に画像を生成する。`記事保存 <= brief作成 < generated_at < reviewed_at`でなければ保存しない。保存scriptの`--timestamp`は`save_image_asset.py`が完成assetを保存する`saved_at`であり、`reviewed_at <= saved_at`を満たす必要がある。

保存scriptは最終PNGから同じ決定的処理でpreviewを再生成し、目視確認した`preview_sha256`との一致を確認して、完成画像に結び付いたpreviewも保存する。保存後は`validate_image_assets.py`を実行する。差し絵ではQAの`preview_sha256`を`null`とし、briefへ挿入位置、QAへキャプションと80字以内のALTを含める。見出し画像にはキャプションとALTを付けない。

## 利用者へ返すもの

見出し画像は、通過した完成画像一枚と、保存できた場合だけ保存先を記事制作タスクへ返す。制作手段、内部比較、採点、prompt、QA表は付けない。利用者に「記事制作タスクへ戻ってください」と手作業だけを委ねず、利用可能なtask coordinationで完了報告を返す。coordinationが使えない環境でもasset registryを完了receiptとし、記事制作タスクが再開できるpathを明示する。

差し絵は完成画像一枚に加え、挿入位置、キャプション、ALT、保存できた場合だけ保存先を返す。

画像生成または保存が失敗した時は、維持できた記事とbrief、未完了の画像工程、再開に必要な一手だけを短く伝える。

## 完了条件

- 確定タイトル後に開始している。
- 一件のbriefから一画像だけを扱っている。
- 記事全文やprivateな背景を画像工程へ渡していない。
- 目標寸法と実寸が一致している。
- 見出し画像は320×168pxの実表示を含め、人の目で確認している。
- 見出し画像にcopyがある場合、visualと文字を同じ画像生成で完成させ、後載せ合成していない。
- 未解決の誤字、破綻、切れ、記事との不一致がない。
- 記事保存より後に生成し、生成より後にQAし、QA以後にassetを保存している。
- local保存時はbrief、画像、metadata、registryのvalidatorがpassしている。
- 標準運用では対象記事、asset revision、image path、preview pathを記事制作タスクへ返している。
- 記事、note、公開、SNS、クラウド、永続タスクを変更していない。

Referenced files: 14

View saved version →

---
name: note-source-log
description: note Workspaceで日々の出来事や気持ちを聞き、質問から始まる日記の会話も原文のまま利用者のworkspaceへ残す。今日あったことを話したい、何か質問してほしい、メモを残したい、過去の記録を企画や記事に使いたい時に使う。記事本文の執筆や外部公開には使わない。
---

# 日記・体験ログを残す

話したいことを気軽に話せる場所にする。利用者の原文を先に保存し、質問を頼まれたら一つずつ聞く。入力のたびに記事化を迫らず、小さな出来事や感情を勝手に教訓へ変えない。

## 最初に読むもの

- 原文やカードへ書き込む前に[一次情報のデータ契約](references/data-contract.md)を読む。
- 日記担当として会話する時、質問から始める時、会話を再開する時は[日記の会話手順](references/diary-conversation.md)を読む。
- 記事別の材料を取り出す時だけ[文脈パック契約](references/context-pack-contract.md)を読む。

## 適用範囲

このSkillは次を担当する。

- 利用者の入力を日時付き、追記式で保存する。
- 同じ実行の再試行を重複登録しない。
- 原文を要約で置き換えず、追加回答を元入力へリンクする。
- 再利用できる場面、観察、感情、判断、発言、変化を一次情報カードへ整理する。
- 一記事に関係するカードだけを、公開範囲と元ログID付きで文脈パックへまとめる。

記事方向、構成、本文、画像、note下書き、公開は作らない。

## 1. workspaceと入力境界を確認する

利用者が選んだworkspaceの絶対パスを使い、`workspace.json`と`strategy/operating-settings.json`を確認する。source repository、Plugin cache、Skill install先、別利用者のworkspaceへ保存しない。

次を含む場合は、その部分を再掲して広げず停止する。

- ID、パスワード、Cookie、認証コード、APIキー。
- 利用者が処理権限を持たない第三者資料。
- AI利用を禁止された資料。
- 顧客や勤務先との契約上、外部AIへ渡せない情報。

新規の標準構成には`📔 note｜日記・体験ログ`（role: `diary`）がある。セットアップで保存先と会話保存を案内・承認済みの日記担当へ話しかけることは、その会話を同じworkspaceへ残す依頼として扱う。準備確認のメッセージは保存しない。他の担当や1task簡易運用でも日記・記録の依頼があれば同じSkillを使えるが、無関係な会話まで保存しない。従来の4task構成へタスクを無断追加せず、別の保存先やクラウドへの承認にも広げない。

「保存しないで」と言われた発言、その引用を含む返答、そこからのカードは書き込まない。「ここから保存しない」なら再開の明示まで保存を止める。既に保存した記録の削除は別の確認が必要であり、今後の保存停止と混同しない。ローカル保存でも会話自体は利用中のAIサービスで処理される。

## 2. 原文を先に追記する

日記の会話では[日記の会話手順](references/diary-conversation.md)の会話ID・話者付き保存を使う。以下は単発メモと従来形式の追加回答の保存方法である。

入力を整えたり要約したりしてから保存しない。同梱scriptへ、利用者の原文をUTF-8 fileまたはstdinで渡す。再試行時に同じ値を使える`request_id`を一件ごとに作る。

```bash
python3 scripts/append_log.py WORKSPACE --input-file INPUT.txt --input-type text --request-id REQUEST_ID
```

音声起こしは`voice_transcript`、日記は`diary`、箇条書きは`bullet_notes`を使える。入力方法が不明なら`text`にする。公開範囲を利用者が明示していない時は`confirm_before_use`を使う。

質問を一つ返す意味がある場合は、原文と同じrecordへ質問も保存できる。質問の生成や回答を待つことで原文保存を遅らせない。

```bash
python3 scripts/append_log.py WORKSPACE --input-file INPUT.txt --input-type text --request-id REQUEST_ID --follow-up-question-file QUESTION.txt
```

回答が後から届いた場合は、新しい追記recordとして保存し、元の`log_id`を`parent_log_id`へ指定する。過去recordを上書きしない。

```bash
python3 scripts/append_log.py WORKSPACE --input-file ANSWER.txt --input-type follow_up_answer --parent-log-id PARENT_LOG_ID --request-id REQUEST_ID
```

## 3. 必要な時だけ一つ質問する

記録だけの依頼では、原文を保存した後、話を理解するために必要な時だけ短い質問を一つ返す。「何か質問して」と頼まれた時は原文の出来事がまだなくても質問から始められる。一度に一問を目安に会話を続け、答えたくない質問は飛ばせる。質問のために原文保存を遅らせない。

- 見えたもの、聞いた言葉、起きた順序が曖昧な時。
- なぜ迷ったか、なぜ選んだかが重要な時。
- 前後の変化や、今も残る違和感が重要な時。

回答は任意であり、答えなくても保存完了とする。入力のたびに質問しない。記事化、結論、学び、読者価値を押し付けない。

## 4. 一次情報カードを作る

後で検索しやすくなる材料だけをカード化する。一つの入力から必要以上に分割せず、原則0〜3枚にする。

card configを[card schema](references/schemas/source-card-input.schema.json)に合わせ、利用者所有の場所または一時領域へ置く。`source_log_ids`は実在する元ログだけを指定する。

```bash
python3 scripts/upsert_card.py WORKSPACE --config CARD.json
```

- `kind`で出来事、観察、感情、判断、発言、変化、問いを分ける。
- `statement_type`で`fact`、`experience`、`inference`、`unknown`を分ける。
- 本人の正確な言葉を残す時だけ`exact_words`を使う。元ログに存在しない文は引用として保存しない。
- 公開範囲が未確認なら`confirm_before_use`、非公開なら`private`とする。`public`は利用者が一般利用を明示した時だけ使う。
- summaryは原文の代わりではない。解釈を事実として書かない。
- 会話からカードを作る時は、本人の`user`発言だけを`source_log_ids`に指定する。AIの質問、推測、共感の言い換えを本人の経験や引用として採用しない。旧version 1の原文は本人の入力として読める。

挨拶、質問の依頼、保存設定だけの発言を材料カードにしない。具体的な経験や考えが残った時に0〜3枚作り、記事に向くかで保存の価値を決めない。

同じカードを更新する時は同じ`source_card_id`を指定する。scriptは過去の版を書き換えず、新しいrevisionを追記する。

## 5. 記事別の文脈パックを作る

利用者、戦略担当、執筆担当が具体的な記事テーマを示した時だけ作る。生ログ全体を渡さず、関係する最新カードだけを選ぶ。

まず同じworkspaceの`source-cards/cards.jsonl`を参照する。カードにない記録を探す時や原文を確かめる時は`scripts/read_source_logs.py WORKSPACE --query KEYWORD --limit 10`または`--log-id LOG_ID`を使い、必要な範囲だけ読む。通常の検索は本人の発言だけを返す。関係する未整理の原文はカード化してから渡す。非公開背景や使用前確認の材料を、確認なしで記事本文へ使わない。

```bash
python3 scripts/build_context_pack.py WORKSPACE --config CONTEXT_PACK.json
```

- `public`またはこの記事で明示承認されたカードを「記事へ使用できる材料」へ置く。
- `confirm_before_use`は「公開前確認が必要な材料」へ分ける。
- `private`は「記事へ使用しない背景」へ分け、本文の事実として使わない。
- 各カードへ元ログIDを残す。
- 材料が足りない点は`missing_information`へ明記し、推測で埋めない。
- 同じ`article_id`の既存packを上書きしない。同じ`request_id`の再試行だけ重複として成功扱いにできる。
- packとは別に`context-packs/registry.jsonl`へ作成eventを追記し、記事ごとの承認、card revision、pack全体のhashを固定する。pack作成後にregistry追記で中断した再試行は、同一内容を確認してeventだけを回復する。

## 6. 検証して返す

追記、カード化、文脈パック作成後は同梱validatorを実行する。

```bash
python3 scripts/validate_source_data.py WORKSPACE
```

日記では自然な返答を中心にし、保存確認は短く添える。毎回IDや保存先を並べず、初回、利用者からの質問、保存失敗の時に必要な場所を案内する。単発の記録依頼では保存したものを短く返す。内部hash、lock、schema、script名は通常の返答へ出さない。保存が失敗したら未保存と伝え、同じrequest IDで再試行できる状態を保つ。カードや文脈パックを作らなかった場合は、作成済みと報告しない。

## 完了条件

- 原文が一度だけ追記され、元の文字列へ戻れる。
- 任意の追加回答が元ログIDへリンクしている。
- カードを作った場合、元ログID、statement type、公開範囲を持つ。
- 正確な引用は元ログ内に存在する。
- 文脈パックは作成時点の最新カードだけを含み、公開範囲を分け、packとregistry eventが一致している。
- validatorがpassしている。
- note、SNS、クラウド、別repositoryへ送信していない。

## 停止条件

- workspaceの正本または所有者を確認できない。
- 原文を保存する前に、要約だけで置き換える必要がある。
- 同じ`request_id`が異なる内容に使われている。
- 元ログにない言葉を正確な引用として保存する必要がある。
- 公開範囲が不明なカードを、確認なしで記事へ使用可能として扱う必要がある。
- 既存file、card revision、context packを無断で上書きする必要がある。

Referenced files: 15

View saved version →

---
name: note-strategist
description: note Workspaceの目的、継続条件、一次情報、過去記事、参考指標を分けて読み、次に書く候補、週間計画、方向修正を提案する。次のテーマを考えたい時、週間計画を確定・差し替えたい時、目標、投稿頻度、休止状態を見直したい時に使う。記事本文の執筆、指標取得、外部公開には使わない。
---

# noteの次の一歩を一緒に決める

利用者が今書きたいことと、実際に使える本人の材料を中心に、無理なく続けられる次の行動を提案する。指標や流行だけで決めない。定期実行では未確定の推奨を記録できるが、利用者の確定判断と混ぜない。

## 最初に読むもの

- 候補を考える前に[戦略契約](references/strategy-contract.md)を読む。
- 参考指標を分析する時は[目的別の参考指標分析](references/goal-aware-analysis.md)を読む。
- 週間計画へ保存する時だけ[週間計画契約](references/weekly-plan-contract.md)を読む。
- 目標、頻度、休止状態を変更する時だけ[戦略変更契約](references/strategy-change-contract.md)を読む。

## 適用範囲

このSkillは次を担当する。

- 「次は何を書こう」「今週は何を書く」の相談。
- 目標、一次情報、過去記事、参考指標、公開情報を分けた候補提案。
- 定期実行による未確定の週間推奨と、利用者が確定した週間選択のrevision保存。
- 目標、希望頻度、最低限の頻度、継続・休止状態の承認済み変更。
- 記事制作へ渡す方向、想定読者、中心材料、足りない情報の整理。

記事本文、構成、タイトル、画像、note下書き、公開、指標取得は行わない。利用者が計画外のテーマを書きたい場合は、その指定を計画より優先し、計画へ無理に戻さない。

標準5task運用では`🧭 note｜戦略・編集方針`が利用者向けの入口である。初回setup task自身をtitle変更して引き継ぐのを標準とし、別strategy taskを黙って作らない。引き継ぎを公式host read-backで確認できない場合は、役割task作成を止めて利用者へ伝える。Skill名を利用者へ指定させない。

## 1. workspaceと現在地を確認する

利用者が選んだworkspaceの絶対パスを使い、`workspace.json`、`strategy/operating-settings.json`、`strategy/strategy.md`、`profile/standing-instructions.md`を確認する。source repository、Skill install先、別利用者のworkspaceへ計画を書かない。

次を必要な範囲だけ読む。

1. `profile/creator-profile.md`と`strategy/strategy.md`の目的、読者、テーマ、継続条件。
2. 直近の`plans/weekly/`。存在しなければ未作成として扱う。
3. `source-cards/cards.jsonl`の最新有効revision。`primary-log/`全体は読まない。
4. `articles/registry.jsonl`と`metrics/history.jsonl`。空または取得不能でも企画を止めない。metrics recordは`note-tracker`のvalidatorを通った項目別の観測として読み、旧`views`と現行の`impressions`・`page_views`を接続しない。

日記担当の記録も同じ`source-cards/`に蓄積する。関連カードの原文や未整理の体験が必要な時は`note-source-log`の読取scriptで語句またはlog IDを絞って参照し、本人に同じ話を聞き直さない。AIの質問・解釈は本人の体験に数えず、privateな話を具体的な公開候補へ移す前に使用範囲を確認する。

週間企画機能が無効でも、利用者が明示的に相談した一回の候補提案はできる。定期実行や機能設定を黙って有効にしない。

## 2. 判断材料を混ぜない

候補ごとに次を言葉で説明する。固定点数、秘密の重み、総合スコアで自動選定しない。

- 利用者が今書きたいか。
- 中心にできる具体的な一次情報があるか。
- 読者が読む理由を一文で言えるか。
- 過去記事の繰り返しではなく何を深められるか。
- 今書く理由があるか。
- 今週の時間で仕上げられるか。
- 記録、交流、専門性、仕事、収益等のどの役割を持つか。

指標を使う時は、その回の依頼と既存プロフィールから主レンズを一つ、必要な時だけ副レンズを一つ選ぶ。新しい必須質問を増やさず、目的に不要なpanelは毎回集めない。`unavailable`、`not_visible`、`fetch_failed`、`not_collected`を`0`へ変換せず、少ないデータから一般則を作らない。収益化を選んでいない利用者へ販売目的を追加しない。

現行ダッシュボードでは期間、集計時刻、記事またはアカウントのscopeを揃える。増減は原則として同じ長さの完了期間で比べ、当日を含む途中値は現況確認として分ける。PV÷インプレッションをクリック率、スキ÷PVを満足率や読了率、流入domainを記事別流入や相談成果と呼ばない。

## 3. 必要な時だけ公開情報を調べる

現在性、季節、制度、製品仕様、読者の疑問等が候補の価値を変える時だけ調査する。利用者の一次情報より流行を優先せず、調査結果、推測、本人の経験を分ける。候補を増やすためだけに一般的な検索結果を水増ししない。

調査できない時は未調査と明示し、既存の目的と材料だけで提案できる範囲へ下げる。

## 4. 候補を提案する

投稿予定数は上限の目安であり、埋める義務ではない。材料が一件分なら一件だけ提案できる。各候補には次を含める。

- 記事の方向を表す短い名称。
- 想定読者と、読む人が得るもの。
- 中心にする一次情報カード。
- 記事の役割。
- 今書く理由と、今週の負担感。
- 調べたい論点。
- 足りない本人情報。
- `ready`または`needs_more_source`の材料状態。

一次情報が薄い候補を`ready`にしない。本人が重要だと思う記録は、反応見込みが小さくても候補から外さない。

## 5. 推奨と利用者の判断を分けて保存する

会話で候補を示しただけなら、その場で利用者の判断を待ってよい。strategy heartbeatとして定期実行されている場合は、同じworkspaceのtracker heartbeatが先に完了したか、その取得時刻とstatusを確認し、最新の計測状態、一次情報、記事台帳を読んだうえで、`strategy_recommendation`を週間計画へ保存する。trackerが失敗または未実行でも取得不能を0にせず、その状態と利用可能な材料で提案する。これは利用者の確定判断ではなく、writerが「今週の候補」として示せる既定候補である。

利用者が採用、修正、保留、差し替え、今週は休む、または別テーマを選んだ時は`user_selection`として保存する。タイトル選択や一般的な肯定を、別候補を含む週間計画全体の承認へ広げない。利用者確定後の同じ週をheartbeatが新しい推奨で上書きしない。

定期推奨または利用者の決定後、[週間計画入力schema](references/schemas/weekly-plan-input.schema.json)に合うconfigを利用者所有の場所または一時領域へ作る。利用者選択の保存前には対象週、候補、想定本数、変更理由を短くread-backする。heartbeatの推奨では`confirmed_by_user`を必ずfalseにする。

```bash
python3 scripts/save_weekly_plan.py WORKSPACE --config WEEKLY_PLAN.json
python3 scripts/validate_strategy_data.py WORKSPACE
```

同じ週を変更する時は既存fileを消さず、新しいrevisionを追記する。保留した候補を利用者確定候補として保存しない。

## 6. 目標、頻度、休止状態を変更する

変更を頼まれたら、現在値、新しい値、週間計画や定期実行への影響を先に示す。利用者が変更内容を明示的に承認した後だけ、[戦略変更入力schema](references/schemas/strategy-change-input.schema.json)を使う。

```bash
python3 scripts/update_strategy.py WORKSPACE --config STRATEGY_CHANGE.json
python3 scripts/validate_strategy_data.py WORKSPACE
```

このscriptはlocal workspaceの目的、頻度、継続・休止状態と変更履歴だけを更新する。scheduled task、クラウド同期、保存先、note、既存記事は変更しない。`automation_follow_up_required: true`は定期実行の存在確認済みを意味せず、利用者が希望したscheduleがあるためplatformのlive確認が必要という意味である。定期実行を調整、状態報告、重複判定する前にautomation ID、対象task、schedule、次回実行を読み戻し、取得不能なら`未確認`として作成済みとも未作成とも断定せず、重複作成しない。調整が必要でも、別の外部状態として未実施を報告する。

読者、中心テーマ、公開範囲、保存先等の構造的変更は`note-workspace-setup`へ引き継ぐ。

## 7. 次の工程へ渡す

週間計画の候補を記事制作へ渡す時は、record status、revision、candidate ID、方向、想定読者、source card ID、材料状態、足りない情報だけを渡す。未確定の推奨なら、その状態をwriterが利用者へ分かる言葉で示す。生ログ全体、無関係な候補、長い会話履歴を渡さない。

利用者が計画外テーマを指定した場合は、その指定を新しい入力として尊重し、必要なら一次情報カードを確認して記事制作へ渡す。週間計画を先に書き換えることを必須にしない。

## 完了条件

- 候補が目的、本人材料、読者価値、時間制約を分けて説明している。
- 指標を使った場合、既存目的に合う主レンズが一つに絞られ、期間、scope、旧新定義が混ざっていない。
- 指標がなくても候補を提案でき、取得不能値を`0`にしていない。
- 定期推奨と利用者確定が異なるrecord typeとstatusで保存されている。
- 利用者確定後の同じ週を自動推奨で上書きしていない。
- 保存した計画は過去revisionへ戻れる。
- 材料不足を推測で埋めず、`needs_more_source`として残している。
- 戦略変更を行った場合、変更履歴と現在値が一致している。
- validatorがpassし、外部操作を行っていない。

## 停止条件

- workspaceの正本または所有者を確認できない。
- 利用者の採用判断がない推奨を、利用者確定として保存する必要がある。
- `ready`候補に実在する本人材料がなく、推測で補う必要がある。
- 同じ`request_id`が異なる計画や変更へ使われている。
- 既存revision、変更履歴、lockを無断で削除する必要がある。
- 取得不能な指標を正確な`0`として扱う必要がある。
- 計画の相談を記事執筆、note登録、公開までの承認として扱う必要がある。

Referenced files: 13

View saved version →

---
name: note-style-profile
description: note Workspaceで、利用者本人が権利を持つ過去記事、下書き、文章サンプルから書き方の傾向だけを抽出し、確認済みの文体プロフィールを履歴付きで保存・更新する。自分らしい文体へ近づけたい、避けたい癖を決めたい、文体プロフィールを見直したい時に使う。記事固有の事実、個人属性、元本文はプロフィールへ保存しない。
---

# note Workspace 文体プロフィール

## 役割

本人が書いた文章から、語り口、文の長さ、読点、改行、導入、見出し、具体性、好む表現、避ける表現を整理する。過去記事を複製するのではなく、今後の記事で本人らしさを再現しやすくする設定を作る。

利用者向けの入口は、初回の戦略task、普段の記事制作task、または1task簡易運用であり、Skill名を指定させない。記事制作中の今回の指定は、保存済みプロフィールより常に優先する。

## 必ず読むもの

- 利用者workspaceの`STUDIO.md`、`workspace.json`、`profile/style-profile.md`、`profile/standing-instructions.md`。
- [`references/style-profile-contract.md`](references/style-profile-contract.md)。
- 保存する時は[`references/schemas/style-profile-input.schema.json`](references/schemas/style-profile-input.schema.json)。

## 入力を絞る

本人が書いた、または分析する権限を持つ文章を2〜5本使う。一記事だけでも始められるが、結果は`provisional`とする。公開URL、利用者workspace内の下書き、添付、会話へ貼られた文章を使える。

最初に一度だけ次を確認する。

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

本文が長い時も、必要以上の記事や生ログ全体を読まない。分析対象へ第三者の文章が混ざる場合は、その部分を本人の文体根拠にしない。

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

次を、観察できた傾向と利用者の希望に分けて整理する。

- 読者との距離、敬体・常体、温度。
- 一文の長さ、長短のリズム、読点、改行。
- 導入、見出し、節の長さ、締め方。
- 場面、会話、数字、感情、ユーモアの使い方。
- 残したい表現、本人が避けたい表現。
- 言い切りと不確実性の表し方。
- 記事ごとに決めるトーン、長さ、画像表現。

特定の語、比喩、語尾の制約は、利用者が望む場合にだけ設定する。提供側の好みや一般的な「AIらしい表現」の一覧を、本人の希望として持ち込まない。

職業、年齢、居住地、顧客、家族、健康、信条等を文体設定として推測しない。記事の固有名詞、出来事、成果、長い言い回し、本文抜粋をプロフィールへ転記しない。

## 確認後だけ保存する

最初は会話内で案を示し、根拠が一記事だけ、記事間で揺れる、または利用者の希望と観察が違う項目を断定しない。

次の意味を明確にして確認する。

> この文体プロフィールを、今後の記事で使う設定として保存しますか。直したい項目があれば先に反映します。

承認前は`profile/style-profile.md`を書き換えない。承認後は、元文章を入力JSONへ含めず、sample ID、種類、文字数、SHA-256だけを保存scriptへ渡す。

```bash
python3 scripts/save_style_profile.py \
  /absolute/path/to/user-workspace \
  --config /absolute/path/to/style-profile-input.json
```

保存scriptは現在版を`profile/style-profile.md`へ置き、旧版、metadata、registry eventを追記型で残す。同じrequest IDと同じ内容は既存revisionを返し、同じIDで内容が違う時は停止する。process強制終了でjournalとlockが残った時は、記録したprocessが終了済みであることを確認して同じrevisionを回復する。現在版がjournal開始時とも保存予定版とも異なる場合は、利用者または別processの変更として上書きせず停止する。保存後は`validate_style_profiles.py`を実行する。

## 記事制作への適用

- `note-writer`は記事ごとの構成とトーンを決める時に現在版を読む。
- 戦略、記事制作、画像の各taskは会話履歴から文体を推測せず、同じcurrent profileを読む。
- 今回の明示指定がプロフィールと違う時は、今回の指定を優先する。
- `note-draft-quality`の一次性・文体確認を省略しない。
- 過去記事にある経験、感情、成果、引用を今回の記事へ移植しない。
- プロフィールは型の強制ではない。記事ごとに選ぶ項目を固定しない。

## 完了条件

- 本人が権利を持つ1〜5本だけを根拠にしている。
- 内容や個人属性ではなく書き方だけを整理している。
- 観察、利用者の希望、不確実な項目を混同していない。
- 利用者の確認前にworkspaceを書き換えていない。
- 保存物に元本文、private URL、個人情報、Plugin cacheの変更を含めていない。
- 保存時はrevision、hash、registryのvalidatorがpassしている。

Referenced files: 8

View saved version →

---
name: note-tracker
description: note Workspaceで、公開済みnote記事とブラウザ版ダッシュボードのインプレッション、ページビュー、スキ、コメント、売上、流入元を、対象期間・scope・集計時点とともに確認し、取得不能を0にせず履歴へ追記する。公開後の反応を記録したい、定期計測または手動計測を再開したい時に使う。旧ビューとの混在、記事評価、テーマの自動決定、公開や編集は行わない。
---

# note Workspace 参考指標の記録

## 役割

公開済み記事とアカウント全体の参考指標を、対象範囲と意味の違う項目を混ぜずに利用者workspaceへ追記する。数字を記事の採点や次のテーマの自動決定に使わない。

標準5task運用では`📊 note｜計測・公開ログ`が利用者向けの入口である。手動実行もheartbeatも同じworkspaceへ記録し、戦略担当が後から読める状態までを担当する。Skill名を利用者へ指定させない。

公開ページや利用者本人のcreator画面はread-onlyで確認する。このSkillはnoteの公開、編集、下書き、削除、SNS投稿を行わない。

## 必ず読むもの

- 利用者workspaceの`STUDIO.md`、`workspace.json`、`strategy/operating-settings.json`、`strategy/strategy.md`、`profile/creator-profile.md`、`profile/standing-instructions.md`。
- [`references/metrics-contract.md`](references/metrics-contract.md)。
- 定期実行または手動fallbackを扱う時は[`references/collection-operation.md`](references/collection-operation.md)。

`features.metrics_tracking.enabled`がfalseなら記録を始めず、利用者が設定変更を望む場合だけ影響を示して`note-workspace-setup`へ戻す。

## 観測範囲を特定する

現行schema version 2では、一recordを一つの対象期間における記事一件またはアカウント全体の観測にする。同じ取得runでアカウント観測一件と、目的に関係する記事観測を必要数だけ記録できる。全記事を毎回取ることは必須にしない。

記事scopeでは次のどちらかへ結ぶ。

- Workspaceで作った記事: `article_id`、記事revision、`articles/registry.jsonl`の対応event hashへ結ぶ。
- 導入前からある公開記事: `existing_public_article`として安定したlocal article IDを付け、公開URLを正本にする。存在しないdraft revisionを装わない。

URLは実際に開いた`https://note.com/...`だけを使う。schemaとruntimeで同じ正規URLを扱うため、明示port、末尾`/`、query、fragmentを除いたURLだけを入力する。検索結果の抜粋、推測URL、private下書きURLを公開記事として保存しない。

アカウントscopeでは架空の記事IDや記事URLを作らず、workspace IDへ結ぶ。通常ダッシュボードの流入元はアカウントscopeだけへ記録し、記事別へ配分しない。

## 指標を別々に観測する

schema version 2では、2026年9月8日以降のブラウザ版ダッシュボードについて`impressions`、`page_views`、`likes`、`comments`、`sales`を毎回別項目で記録する。各recordに対象期間、`completed`または`includes_current_day`、画面を確認した時刻、画面の集計時刻を持たせる。

- `impressions`: note内で記事が表示された回数。人数や記事ページを開いた回数ではない。
- `page_views`: 記事ページが開かれた回数。人数や読了ではない。
- `likes`、`comments`: 選択期間中に新たに付いた件数。公開ページの現在累計と混ぜない。
- `sales`: 選択期間の売上額（円）。受取額や利益ではない。

- `available`: 画面または利用者提供値で確認できた非負整数。正確な0を含む。
- `unavailable`: 現在の環境では取得手段がない。
- `not_visible`: 対象画面に項目が表示されていない。
- `fetch_failed`: 取得を試したが通信、認証、画面変更等で失敗した。
- `not_applicable`: その記事または取得元では対象外である。
- `not_collected`: 今回の目的には不要なため、意図して収集しなかった。

`available`以外は`value: null`と具体的な理由を必須にする。取得不能、空欄、画面にない値を`0`へ変換しない。新画面で`-`と見えた値は、読み込み完了と指標の対象期間を確認してから扱う。インプレッションの記録開始前等、0を意味しない条件では`available: 0`にしない。

流入元は表示名とPVをそのままアカウントscopeへ残し、流入元合計が上段PVと一致するよう補正しない。`no referrer`を直接訪問、Googleや`chatgpt.com`等を検索順位やAI引用の証拠へ置き換えない。

schema version 1の`views`、`likes`、`comments`は旧履歴の検証と再現のためだけに受け付ける。旧`views`をv2の`impressions`または`page_views`へ変換せず、足し合わせて旧値を復元しない。スマートフォンアプリに残る旧表示もv2へ記録しない。

## localへ追記する

現行ブラウザ版の確認結果を[`references/schemas/metrics-observation-input-v2.schema.json`](references/schemas/metrics-observation-input-v2.schema.json)へ整え、次を実行する。旧schemaは[`metrics-observation-input.schema.json`](references/schemas/metrics-observation-input.schema.json)に残す。

```bash
python3 scripts/record_metrics_observation.py \
  /absolute/path/to/user-workspace \
  --config /absolute/path/to/metrics-observation.json
```

scriptは`metrics/history.jsonl`へ一行追記するだけで、Webやnoteへ接続しない。同じrequest IDと同じ内容は既存recordを返し、同じIDで内容が違う時は停止する。同じ期間の再取得は、新しい観測時刻とrequest IDで次のrecordとして残す。

保存後は`validate_metrics_history.py`でworkspace ID、記事参照、status/value、hash、request ID、同一scope・期間・観測時刻の重複を確認する。

## 振り返りへ渡す

結果を伝える時は、観測、未収集、取得不能、前回との差を分ける。増減を見る時は同じscope、同じ定義、同じ長さの完了期間を使う。少数回の増減から原因、読了、共感、相談、契約を断定しない。

`note-strategist`へ渡す時も、生の項目、scope、期間、集計時刻を保つ。PV÷インプレッションをクリック率、スキ÷PVを満足率や読了率と呼ばず、一つの点数へまとめない。本人が残してよかった記事は、反応が小さくても候補判断から落とさない。

## 定期実行

定期実行は、手動で一度通した後、対象workspace、アカウント観測の有無、対象記事、比較期間、曜日、時刻、実行環境、権限、対象のtracker taskを示して利用者が承認した場合だけadapterから作る。計測と翌週企画は別の実行にし、tracker heartbeatをstrategy heartbeatより先に動かす。

失敗したrunも`fetch_failed`として必要な範囲を記録できる。次回または手動実行で再開し、過去recordを削除しない。scheduled task自体の作成・変更・停止はlocal記録とは別の外部状態である。

## 完了条件

- 記事scopeは実在を確認した公開記事一件へ、アカウントscopeはworkspace IDへ結び付いている。
- 現行ブラウザ版は5指標が別項目で、対象期間、完了状態、集計時刻、scopeが記録されている。
- 流入元はアカウントscopeだけにあり、記事別へ推測配分されていない。
- 旧`views`と現行の`impressions`・`page_views`を変換、合算、連続比較していない。
- 各項目の値、status、取得元、理由が整合している。
- 取得不能値を0にしていない。
- 同じ依頼の再送と異なる内容の競合を区別している。
- local validatorがpassしている。
- 標準の定期実行ではtracker taskと対象workspaceへ結び付き、後続のstrategy heartbeatより先に記録している。
- 記事評価、テーマ決定、noteへの書き込み、scheduled task作成を同時に行っていない。

Referenced files: 10

View saved version →

---
name: note-workspace-setup
description: note Workspaceの導入支援として、初回ヒアリング、運用提案、利用者所有のローカルworkspace作成、通常運用への引き継ぎを行う。noteを継続運用する環境を新しく整えたい時、保存先や投稿頻度を見直したい時、移行や修復を行う時に使う。通常の記事制作やメモ保存だけには使わない。
---

# note Workspaceを初期設定する

利用者が続けられるnote運用と、本人の一次情報を安全に残せる作業場所を整える。質問へ答えた瞬間に作成を始めず、目的、運用、保存先、作成対象を一つの提案にして確認してから書き込む。

## 最初に読むもの

- 提案を作る前に[セットアップ契約](references/setup-contract.md)を読む。
- workspaceへ書き込む前に[workspace契約](references/workspace-contract.md)を読む。
- 利用者向けタスクを作成、再利用、修復する前に[役割別タスクのオーケストレーション契約](references/task-orchestration-contract.md)を読む。
- Pluginとして使う場合は、[Plugin実行手順](../../adapters/openai-plugin/README.md)から導入状態、同梱Skill、継続先を確認する。

## 適用範囲

このSkillが担当するのは、初回セットアップ、設定変更、移行、修復である。標準構成ではセットアップを行った利用者向けタスクが戦略・編集方針担当を引き継ぎ、記事制作、計測、画像制作、日記・体験ログはそれぞれのタスクが担う。利用者が望む場合は1タスク簡易運用も選べる。

- noteの目的、優先順位、読者、テーマ、公開範囲、継続条件を整理する。
- 利用者が所有するworkspaceと初期ファイルを作る。
- host共通の`STUDIO.md`とhost adapterを作り、自然な会話で使う通常運用へ引き継ぐ。
- 標準5タスクまたは1タスク簡易運用を選び、名前、責任、開始指示、ready確認、受け渡しを整理する。
- 定期実行やクラウド同期は希望を記録できるが、対応Skillとadapterが揃い、対象を再確認するまで作らない。

一記事の調査、取材、執筆、画像制作、note下書き登録はこのSkillで実行しない。セットアップ後に利用者が「今日はこれを書きたい」と依頼した場合は、初回質問をやり直さず、`STUDIO.md`に従う記事制作タスクへ引き継ぐ。記事原稿を利用者へ返す直前には`note-draft-quality`を内部で使い、品質結果を付けず納品原稿だけを返す。単発記事だけを作りたい利用者には、環境を限定せず、対応環境で`note Studio mini｜ROGNALIA`または記事制作Skillを案内する。

## セットアップ開始時に期待値を伝える

最初の質問をする前に、長い説明書を読ませず、次を短く伝える。

- note Workspaceは、一記事だけでなく今後のnote運用を支える自分専用の編集部を作るためのものである。
- 最初だけ、目的、テーマ、文体、続け方、保存先等を数回に分けて質問する。
- 利用者が行う中心作業は質問へ答え、最後の提案を確認することであり、承認後のworkspace作成と担当taskの準備はAIが行う。
- 一記事をすぐ作れれば十分な場合は、環境を限定せず`note Studio mini｜ROGNALIA`も選べる。

質問数を謝罪したり、全質問を先に列挙したりしない。何を作るための質問かと、回答後に受け取れる状態を示してから、最初の一まとまりへ進む。

## 1. 既存状態を確認する

Pluginの開始文またはGitHub URLからのinstall依頼を引き継いだ場合は、利用者に開始commandやSkill IDを聞かず、そのままセットアップへ進む。会話ですでに分かっていることは聞き直さない。利用者が既存workspaceを示した場合は、新規作成と決めつけず、読み取り可能なら同梱のvalidatorで状態を確認し、正常なら`STUDIO.md`から依頼された通常運用へ進む。Pluginの導入だけを、workspaceやタスクの作成承認にしない。

- miniを使ったことがあるか、既存のnote、下書き、メモ、音声、文体設定があるかを確認する。
- 既存資産は、利用者が望むまで移動や複製をせず、参照、移行、使わないを分ける。

- 新規作成先は利用者が確認できる絶対パスで確定する。
- source repository内、Plugin cache内、別利用者の場所には作らない。
- 同名のfileまたはfolderが存在する場合は上書きしない。既存workspaceの修復や移行は、新規作成と分けて対象を確認する。
- 利用者のID、password、Cookie、認証code、API keyを受け取らない。

## 2. 足りない情報を段階的に聞く

質問数を機械的に固定しない。意味の近いまとまりを一つずつ扱い、一度に全項目を並べない。最低限、次を確認する。

1. 現在のnote運用、既存資産、miniの利用、止まりやすい工程。
2. noteで達成したいことと、半年後の成功の形。
3. 中心テーマ、避けたいテーマ、読んでほしい人、公開できる範囲。
4. 使える時間、希望頻度、最低限続けられる頻度、残しやすい入力方法。
5. 必要な制作工程と追加module。文章や画像の好みは、該当moduleを使う人だけ確認する。
6. 保存先、主な実行環境、標準5タスクまたは1タスク簡易運用、下書き登録、計測、週間企画、定期実行の曜日と時刻。

各まとまりの回答後に、利用者向けの普通の言葉で「決定済み」「要確認」「あとで決める」を短く返す。この途中経過を承認済み設定とは扱わず、workspaceへ書き始めない。

task modeを聞く時は名前だけを選ばせない。標準5タスクは、日々の話を日記担当へ、記事を書く時は記事制作へ話しかけ、ほかの担当も同じworkspaceから材料を参照する構成と説明する。日記担当での会話は原文を話者別に保存し、保存しない話は指定できること、記事への使用は別に公開範囲を確認することも提案に含める。1タスク簡易運用では一つの会話で同じ役割を切り替える。情報コピーは不要で、後から構成変更できる。

利用者の公開済み記事やプロフィールを調べる場合は、本人が確認を許可した公開情報だけを使う。人気の型を複製せず、本人の材料が差になる場所と無理なく続く条件を探す。

## 3. 書き込む前に一つの提案を出す

[セットアップ契約](references/setup-contract.md)の形式で、次を一度に示す。

- 目的と優先順位。
- 想定読者と中心テーマ。
- 投稿頻度と一次情報の残し方。
- 役割別タスクの名前と責任。
- 各タスクが最初に返す案内と、同じworkspaceを参照する確認方法。
- workspaceの絶対パスと作成する主要file。
- 下書き登録、計測、週間企画、定期実行、クラウド同期の扱い。
- 最初の一週間の行動。
- 今回実際に作成するものと、まだ作成しないもの。

利用者は全体承認、項目修正、一部保留を選べる。承認前にworkspace、タスク、定期実行、クラウド接続を作らない。

## 4. 承認済みworkspaceを作る

local fileへ書ける場合は、承認内容からsetup configを作る。configは公開repository、Plugin cache、Skill install先へ保存しない。利用者所有の場所または一時領域だけで扱う。同梱scriptは、この`SKILL.md`があるfolderを基準に解決する。

最初にdry-runを行う。

```bash
python3 scripts/create_workspace.py ABSOLUTE_DESTINATION --config SETUP_CONFIG.json --dry-run --workspace-id WORKSPACE_ID
```

dry-runの対象pathと作成予定fileが承認内容と一致した場合だけ、本作成を行う。親folderも新規作成する必要があり、その親folderまで承認されている時だけ`--create-parents`を付ける。

```bash
python3 scripts/create_workspace.py ABSOLUTE_DESTINATION --config SETUP_CONFIG.json --workspace-id WORKSPACE_ID
python3 scripts/validate_workspace.py ABSOLUTE_DESTINATION
```

`WORKSPACE_ID`はdry-runで使った値を本作成でもそのまま使う。dry-runと本作成の間でconfig、destination、workspace IDのいずれかが変わった場合は、変わった対象を確認してdry-runをやり直す。

scriptが拒否したpathを迂回して直接fileを上書きしない。作成に失敗した場合は、既に作った別のworkspaceを代わりに使わず、維持できた状態と次の一手を一つ返す。

## 5. 役割別タスクをセットアップする

workspaceの作成と検証が成功した後だけ、承認済みの役割別タスクを扱う。

- 新規の標準は`standard_five`で、`strategy`、`tracker`、`writer`、`image`、`diary`の5つの利用者向けタスクである。希望がある時は`compact`一つへまとめる。既存の`standard_four`は引き続き読めるが、日記担当を作成済みと扱わない。
- 標準5タスクでは、現在のセットアップタスクを`strategy`へtitle変更して再利用するのを既定とする。adapterは新しい役割タスクを作る前に現在タスク自身のtitle変更を試し、公式host read-backで実task ID、host ID、titleを確認する。確認できた時だけ`binding_origin: reused_setup`として扱い、新規作成するのは`tracker`、`writer`、`image`、`diary`の4タスクにする。
- title変更能力がない、現在タスクを同じworkspaceで継続できない、または変更後の公式read-backを取得できない場合は、役割タスクの作成前に停止して理由を伝える。別の`strategy`を黙って作らず、セットアップタスクを残す構成への変更を利用者が明示的に承認した場合だけ新規作成へ進む。title変更後にready確認を同じturnで完了できない時は、同じタスクの次turnで再開し、重複strategyを作らない。
- 公式のタスク作成能力がある時は、再利用しない承認済みroleだけを、承認済みtitle、同じworkspace path、`strategy/role-task-plan.md`の開始指示で作る。hidden subtaskではなく、利用者が開けるtaskを使う。Codex固有の現在タスク再利用手順はadapterに従う。
- 実際のtask IDとhost IDを得たら`prepare_role_task_kickoff.py`で現在generation専用の予測不能な一回限りnonceと開始指示を作る。challengeはworkspace内へ`issued`状態で保存される。各タスクへ出力された開始指示をそのまま送り、hostの公式task読取機能から開始messageとready返答を読み戻す。
- hostから読み戻したtask、message、時刻を`verify_role_task_readback.py`へ渡す。専用scriptがtask ID、host ID、title、開始文全文、workspace、role、継続指示revision、nonce、返答順序を照合し、challengeを`verified`へ進めた時だけbinding configを発行する。手作りのreceiptや任意のhashをbinding入力にしない。
- verifierが出したbinding configだけを`record_role_task_binding.py`へ渡す。記録成功時にchallengeを`consumed`へ進め、別bindingへの再利用を拒否する。最後に`validate_role_task_bindings.py --require-ready`を実行する。host read-back自体の取得はadapterの責任であり、local validatorだけでtaskの実在確認を代替しない。
- 対応能力がない環境では、偽のtask IDを記録せず、同じtitleと開始指示を利用者へ返す。SDKや新規dependencyを必須にしない。
- 画像は通常一つのtaskを再利用する。同時制作や長期化で追加taskが必要な場合だけ、利用者に理由と対象を示して承認を得る。
- 定期実行はtrackerをstrategyより先に動かす。対応Skillが実装済みで、曜日、時刻、実行場所、書き込み先、対象taskを再確認した時だけ作る。作成、変更、再実行、状態報告、重複判定の前にhostから現在のautomation ID、対象task、schedule、次回実行を読み戻す。読み戻せない時は`未確認`とし、作成済みとも未作成とも断定せず、重複作成しない。作成後も同じ項目を読み戻し、trackerが先であることを確認する。localの`automation_preferences`は希望の記録であり、現在状態の証拠にしない。

タスク、定期実行、クラウド同期の作成はlocal workspace作成とは別の外部状態である。実行していない操作を完了報告へ混ぜない。

## 6. 通常運用へ引き継ぐ

workspace validatorがpassし、承認済みのtaskを作成した場合はbinding validatorもpassしたら、`workspace.json`と`strategy/operating-settings.json`で通常運用のphaseが`operation`、runtime guideが`STUDIO.md`であることを確認する。生成済みの`START_HERE.md`を読み、その利用者のtask名と選択済み機能に合う「30秒で分かる使い方」を完了報告の本文にも出す。fileへのlinkだけを渡して終えない。

標準5タスクでは、日々の話や「何か質問して」は日記task、記事を書く時は記事制作task、方針相談は戦略taskが入口であると伝える。計測taskと画像taskは通常自分で開かなくてよく、全taskが同じworkspaceを読むため情報コピーは不要である。1タスク簡易運用では、その一つへ記事、企画、日記を自然に頼めると伝える。定期実行や役割taskを実際には作成していない場合、希望の記録と作成済みを混同しない。定期実行の現在状態をhostから読み戻せない場合は`未確認`と伝える。

既存の4タスクから5タスクへの変更は、日記の保存範囲、新しいタスク名、設定・ガイドの変更を提案し、承認後だけ行う。既存ログとtask IDを維持し、`binding_generation`を1増やす。同じ4タスクを再利用して新しい開始指示とreadyを照合し、追加作成するのは日記taskだけとする。既存bindingを新generationのreadyに流用しない。Plugin更新だけで利用者workspaceを移行しない。

最初の行動は利用者の目的に合わせて一つだけ始める。「メモを残したい」は一次情報ログ、「今日はこれを書きたい」は記事制作、「次に何を書くか考えたい」は企画へつなぐ。必要な役割Skillがない場合は実行済みと装わず、現在できる範囲と次の一手を返す。

テーマ、読者、公開範囲、保存先、機能構成等の構造的設定変更、移行、validator異常の修復を除き、通常運用からこのSkillへ戻さない。目標、希望頻度、最低限の頻度、継続・休止状態の見直しは、通常運用の`note-strategist`へ引き継ぐ。

利用者が「今後も」「毎回」等で複数taskに共通する指示を明示した場合は、記事一件の指定、文体、戦略変更と分ける。保存する現在一覧を短くread-backし、その更新への承認後だけ次を使う。

```bash
python3 scripts/update_standing_instructions.py WORKSPACE --config APPROVED_INSTRUCTIONS.json
python3 scripts/validate_standing_instructions.py WORKSPACE
```

入力は現在の全指示を持つため、既存指示を外す時も削除対象をread-backする。別taskの会話だけを根拠に暗黙追加せず、記事固有の指定を永続化しない。

## 完了条件

- 利用者が目的、頻度、テーマ、公開範囲、保存先を確認している。
- 作成対象と保留対象が分かれ、承認済みのものだけが作られている。
- workspace validatorがpassし、利用者が場所を見つけられる。
- 利用者が`START_HERE.md`と完了報告の30秒案内から、普段話しかけるtaskと最初の一言を判断できる。
- workspaceが`operation` phaseになり、`STUDIO.md`とhost adapterから役割分担または1タスク簡易運用を開始できる。
- 選択された役割別タスクは、対応能力がある環境では全taskがreadyを返しbinding validatorがpassしている。未対応環境では未作成と開始指示が明示されている。
- 定期実行とクラウド同期は、hostから確認できた実際の状態と`未確認`を分けて報告している。
- 次の行動が、一次情報を一件残す、既存資産を一件整理する、週間方針を作る、記事制作へ引き継ぐ、のいずれかに決まっている。

## 停止条件

次の場合は該当工程を止め、必要な次の一手を一つ返す。

- 保存先の絶対パスまたは所有者を確認できない。
- source repository内、Plugin cache内、既存の別用途folderしか指定されていない。
- 作成対象への明示承認がない。
- setup configがschemaを満たさない。
- 認証情報、権限不明資料、第三者の秘密を保存する必要がある。
- local fileへ書けないのに、workspaceを作成済みとして報告する必要がある。

fileへ書けない環境では、承認済み提案とsetup configのコピー用内容を返し、作成済みとは報告しない。

Referenced files: 21

View saved version →

---
name: note-writer
description: note Workspaceで一記事を、利用者指定または承認済み企画から、必要な調査、最大3問の取材、構成とトーン確認、本文、タイトル、noteタグ、X投稿文まで仕上げる。記事を書きたい、既存下書きを整えたい、記事一式を完成させたい時に使う。画像生成、noteへの書き込み、公開は行わない。
---

# note Workspace 記事執筆

## 役割

一度に一記事だけを扱い、本人固有の一次情報を中心に、利用者が確認できる記事一式へ仕上げる。利用者向けの入口は記事制作タスク、または1タスク簡易運用の執筆サポーターであり、Skill名を指定させない。

画像は確定タイトル後の別工程、noteへの下書き登録は完成物への明示承認後の別工程である。このSkillは画像生成、browser操作、noteへの書き込み、公開、予約投稿、既存記事更新を行わない。

## 必ず読むもの

記事制作前に次を読む。

- 利用者workspaceの`STUDIO.md`、`workspace.json`、`strategy/operating-settings.json`。
- `strategy/strategy.md`、`profile/creator-profile.md`、`profile/style-profile.md`。
- `profile/standing-instructions.md`。今回の記事で明示された指示を最優先する。
- [`references/writing-contract.md`](references/writing-contract.md)。
- 完成原稿をlocal保存する時は[`references/article-package-contract.md`](references/article-package-contract.md)。

記事別文脈パックがある場合はそれを読み、生ログ全体を読まない。原稿返却前には必ず`note-draft-quality`を使う。

`profile/style-profile.md`は本人らしさの既定値として使う。今回の記事で利用者がトーン、長さ、表現を明示した場合は今回の指定を優先し、プロフィール更新まで自動で行わない。プロフィール自体を見直す依頼は`note-style-profile`へ分ける。

## 記事制作

### 1. 記事の方向を決める

利用者が今回のテーマ、読者、目的、既存下書きを指定した場合は、その指定を週間計画より優先し、`direction_source: user_request`として残せる。指定がない時だけ最新の週間recordから一候補を示す。`recommended`は戦略担当の未確定推奨、`confirmed`は利用者選択として区別する。予定本数を埋めるために複数記事を同時生成しない。

記事IDは`article-`から始まる小文字英数字とハイフンで一件に固定する。別の記事へ分岐する時は同じ記事IDへ混ぜない。

### 2. 調査と本人材料を揃える

現在情報、外部の事実、既存記事との重複確認が必要な時だけ、質問より先に公開情報を調査する。検索結果の抜粋だけを根拠にせず、実際のsourceを読む。本人の経験だけで成立する記事へ、見栄えのための調査を増やさない。

既存の一次情報カードと今回の入力で記事が成立するか確認する。必要な本人情報だけを最大3問で聞く。質問済みのこと、既存下書きに書かれていること、文脈パックで確認できることを聞き直さない。

日記担当で残した経験も同じworkspaceから参照する。関係するカードと元ログを`note-source-log`で絞り、未整理の記録は読取scriptの語句検索から確認できる。利用者へ別taskの会話をコピーさせない。AIの発言を本人の経験へ転用せず、公開範囲が未確認の材料は使用可否を聞く。

新しい回答を今後も使う場合は`note-source-log`で原文とカードを残す。最終的に記事へ使う材料が揃ってから、その記事IDの文脈パックを作る。確認前の材料とprivateな背景を本文、タイトル、タグ、告知文へ移さない。

### 3. 構成とトーンの確認を取る

本人材料と調査を踏まえ、記事の中心、読み手、見出しの流れ、終わり方が分かる短い構成案と、具体的なトーン候補を提示する。構成とトーンの両方が利用者の意図として決まるまで本文を書かない。

利用者が最初から構成またはトーンを明示している場合は、その指定を承認済みとして使い、同じ確認を繰り返さない。方向が大きく変わった時だけ、影響する側を確認し直す。

### 4. 記事一式を書く

一記事について次を作る。

- タイトル3案。
- 承認済み構成とトーンに沿う本文。
- 本文末尾へ置くnoteタグ5〜6個。
- 記事内容と異なる約束をしないX投稿文。

本文に見出しを置く場合は、大見出し行を`[大見出し] 見出し名`、必要な小見出し行を`[小見出し] 見出し名`とする。これは後続の`note-draft`が種別を確認してnoteの見出し書式へ変換するための識別子であり、本文中の通常語として使わない。見出しが不要な短い記事へ無理に追加しない。

本人の場面、観察、言葉、判断が記事の流れを作るようにする。架空の経験、感情、成果、数字、引用を補わない。公開情報、本人経験、推測を同じ確度で書かない。

### 5. 原稿品質ゲートを通す

利用者へ原稿を返す直前に`note-draft-quality`を内部で使う。依頼された範囲で、読みにくさや不要な説明の反復を整える。本人の引用や記憶の言葉を一般的な表現へ均さず、語尾や記号の回数だけで直さない。品質チェック結果、点数、修正一覧、内部工程名を納品へ付けない。

一次情報が足りず、創作なしでは本人固有の記事にできない時は完成原稿を装わず、不足を埋める質問を一つだけ返す。この質問も記事全体の最大3問へ数える。

### 6. 納品してタイトルを確定する

品質確認後は、合意した順序でタイトル3案、本文、noteタグ、X投稿文だけを返す。工程説明や品質レポートを前後へ加えない。利用者がタイトルを一つ選ぶまで、画像工程やnote下書き登録へ進まない。

利用者が選んだ後、local保存が可能で選択済みworkspaceがある場合は、同梱scriptで追記型のdraft revisionとregistry eventを保存する。保存できない環境では会話内の完成物を返し、保存済みと報告しない。

記事revisionの保存と検証が完了した後、記事制作タスクは利用可能な`note-image`タスクへ画像工程をつなぐ。渡すのは記事ID、revision、記事metadataの相対path、確定タイトル、読む理由、記事固有のフック、主役となる場面、トーン、禁止事項だけにし、記事全文、private背景、長い会話履歴を複製しない。このSkill自体は画像を生成しないが、利用者向けの記事制作タスクは画像のQA済み完了報告が戻るまで制作フローを保持する。画像工程が失敗しても保存済みの記事revisionを維持する。

```bash
python3 scripts/save_article_draft.py \
  /absolute/path/to/user-workspace \
  --config /absolute/path/to/article-package.json \
  --body-file /absolute/path/to/body.md
```

保存前に文脈パックとその別registry eventの一致を確認し、保存後は`validate_article_data.py`で記事file、metadata、registry、文脈パック、そのregistry eventのhashを確認する。scriptのJSON結果は内部の保存確認であり、原稿本文へ貼り付けない。

## 画像制作タスクから納品まで

標準5タスク運用では、`strategy/role-task-bindings.jsonl`でreadyが確認されたprimary image taskへbounded briefを送る。毎記事で新しいtaskを作らず、通常は同じ画像制作タスクを再利用する。hidden subtaskへ渡さない。

画像制作タスクは、brief作成、生成、実寸と小表示の目視QA、asset保存、`ready_for_draft` eventまで完了し、記事制作タスクへimage path、preview path、article revision、asset revisionを返す。記事制作タスクは`validate_image_assets.py`を通し、対象記事と一致するQA済み画像を実際に確認する。画像タスクを起動しただけ、promptを送っただけ、生成中の候補があるだけでは完了にしない。

記事制作タスクは完成記事と画像を利用者へまとめて納品し、その後だけ次の文面で確認する。

```text
noteの下書き登録まで進めますか？ 公開はしません。
```

画像タスクの失敗や中断時は、記事revisionを巻き戻さず、保存済みbrief、未完了工程、再開方法を保持する。1タスク簡易運用では別taskを使わないが、同じbrief、QA、asset、納品順を守る。

## 再開と改稿

既存記事を直す時は、最新revision、利用者の変更指示、現在の文脈パックを読む。過去revisionを上書きせず、新しいrequest IDで次のrevisionを保存する。同じrequest IDと同じ内容の再送は既存結果を使い、同じrequest IDで内容が変わった場合は停止する。

事実、中心主張、構成、トーンが変わった場合は、影響する承認と品質確認をやり直す。誤字修正だけの依頼を全文の書き換えへ広げず、無関係な質問や調査を繰り返さない。部分修正の後も前後を読み、内容や用語が食い違っていないか確認する。

## 完了条件

- 一記事だけを扱っている。
- 本文前に構成とトーンが決まっている。
- 質問は必要なものだけで最大3問である。
- 使用可能な一次情報と調査sourceの境界が保たれている。
- `note-draft-quality`を通した納品原稿だけを返している。
- タイトル、本文、noteタグ、X投稿文が揃っている。
- local保存時は記事revisionとregistryのvalidatorがpassしている。
- 標準運用では画像taskからQA済みassetが戻り、記事と画像を納品してから下書き登録を確認している。
- このSkill内では画像生成、note操作、公開、クラウド同期を始めていない。

Referenced files: 9