skills/note-writer/SKILL.md

---
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操作、公開、クラウド同期を始めていない。