skills/note-strategist/SKILL.md

---
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登録、公開までの承認として扱う必要がある。