Imported from cry999/blog-posts (.agents/skills/refine-article/SKILL.md). Install upstream with npx skills add cry999/blog-posts --skill refine-article. Copyright stays with the author.

記事の壁打ちブラッシュアップ

draft-article などで作った叩き台（articles/ の Markdown）をベースに、対話を通じて記事を磨いていく。 このスキルの主役はユーザー。Codex が一気に完成原稿へ書き換えるのではなく、問いかけ → ユーザーの考えを引き出す → 合意した分だけ反映するを繰り返すのが目的。壁打ち相手として、読者目線のツッコミ・論理の穴・説明不足を指摘し、ユーザー自身が記事を良くしていくのを助ける。

新規に叩き台を作りたい場合は draft-article、見出し構成だけ練りたい場合は create-outline を使う。本スキルは「叩き台がある」状態が前提。

原則（壁打ちの作法）

• 一度に全部やらない。1 ラウンドで扱う観点・セクションを 1〜2 個に絞る。情報過多にしない。
• 勝手に書き換えない。指摘と改善案は出すが、本文への反映はユーザーの合意を取ってから行う。何を変えるかは常にユーザーが決める。
• 書くのはユーザー、引き出すのが Codex。答えを丸ごと提供するより、「ここは何を伝えたい？」「読者はここで何を疑問に思う？」と問いを投げて、ユーザーの言葉を引き出す。出てきた言葉を整えて本文に落とす。
• 断定しない。技術的事実（計算量・API 仕様・数式など）が怪しければ「要確認」と明示し、勝手に埋めない。
• テンポを保つ。毎ラウンド「現状 → 指摘 → 次の一手」を短くまとめ、ダラダラ長文にしない。

工程

1. 対象の叩き台を特定する

どの記事を壁打ちするかを確認する。

• ユーザーがファイルを指定していればそれを使う。
• 指定がなければ articles/ を一覧し（特に published: false のものが叩き台候補）、直近作成・編集されたものを提示して選んでもらう。
• 対象ファイルを読み込み、frontmatter と本文の現状を把握する。

2. ゴールと現状をすり合わせる

磨き始める前に、短く方向性を確認する。AskUserQuestion でまとめて聞いてもよい。

• この記事のゴール: 誰に何を伝えたい記事か（対象読者・狙い）。叩き台から読み取れるなら「〇〇向けに△△を伝える記事、で合ってる？」と確認する。
• 今日のスコープ: 全体をざっと一周したいのか、特定セクションを深掘りしたいのか。
• 完成度の目安: 公開前の仕上げ段階か、まだ骨子を肉付けする段階か。

そのうえで、Codex 視点での現状の第一印象を 3〜5 行で短く返す（良い点 1〜2・気になる点 2〜3）。ここで全部直そうとしない。次にどこから手を付けるかの地図を示す程度にとどめる。

3. 壁打ちの観点を提示し、入口を選ぶ

記事をどの切り口で磨くか、観点の候補を提示してユーザーに選んでもらう（AskUserQuestion が向く）。記事の状態に応じて取捨選択する。主な観点:

• 構成・流れ: 見出しの並びは自然か。話の順序に飛躍はないか。各セクションの役割は明確か。
• 導入のつかみ: 冒頭で「読む価値」が伝わるか。誰のどんな課題に応える記事かが最初に分かるか。
• 論理・説得力: 主張に根拠・具体例・データが伴っているか。読者が抱く疑問に先回りできているか。
• 具体例・コード: 例が具体的で再現可能か。コードは動くか・最小限か。図や表が要る箇所はないか。
• 読みやすさ・表現: 一文が長すぎないか。専門用語に説明があるか。冗長・重複はないか。
• 正確性: 技術的事実・数値・用語の誤りや要確認箇所はないか。
• タイトル・frontmatter: タイトルは内容と一致し惹きがあるか。emoji / topics / type は適切か。
• まとめ・締め: 学びが回収されているか。次のアクション（リンク等）があると親切か。

ユーザーが「とにかく全体を見て」と言えば、工程 2 の地図に沿って Codex が優先度の高い観点から提案する。

4. 壁打ちラウンドを回す（中心の工程）

選んだ観点について、1 ラウンドずつ以下を繰り返す。1 ラウンド = 1〜2 個の論点に絞る。

1. 指摘する: 該当箇所を引用（file_path:line で具体的に）し、何が気になるかを簡潔に述べる。
2. 問いかける: 「ここで読者は〇〇を疑問に思わないか？」「この主張の根拠は？」など、ユーザーの考えを引き出す問いを投げる。必要なら改善案を 1〜2 個たたき台として添える（押し付けない）。
3. ユーザーの返答を受ける: 出てきた意図・言葉・追加情報を拾う。
4. 合意のうえ反映する: どう直すか合意できたら、その箇所だけ Edit で書き換える。大きく変える場合は反映前に変更後のイメージを一度見せる。
5. 次の一手を示す: 「次はこの観点／このセクションに行く？それともここを続ける？」と区切る。

毎ラウンドの冒頭で、前ラウンドからの変化と残りの論点を 1〜2 行で確認できるとよい。ユーザーが「ここはこのままでいい」と言えば深追いしない。

5. 区切りで全体を見直す

数ラウンドごと、または一周し終えたら、部分最適で崩れていないかを通しで確認する。

• 流れが分断されていないか、トーンが揃っているか、重複が生まれていないか。
• 工程 2 で確認したゴールに照らして、伝えたいことが伝わる記事になったか。
• 残っている「要確認」箇所を洗い出し、ユーザーに確認を促す。

気になる点があれば工程 4 のラウンドに戻る。

6. 仕上げと次のアクションを案内する

ユーザーが「ひとまずここまで」と区切ったら、状態をまとめて次を案内する。

• 今回の変更点と、まだ残っている論点・要確認箇所を箇条書きで整理する。
• npm run preview でローカル確認できることを伝える。
• 公開する場合は frontmatter を published: true にし、published_at（YYYY-MM-DD HH:MM）を設定することを案内する。叩き台のままなら published: false を維持する。
• まだ磨きたい論点が残っていれば、次回はそこから壁打ちを再開できることを伝える。

注意

• 本文の書き換えは必ずユーザーの合意を取ってから。勝手に文章のトーンや主張を変えない。
• 一度に多くを直さない。壁打ちはテンポと対話量のバランスが命。長大なリライト案を一気に出さない。
• 不確かな技術的事実は埋めずに「要確認」として残し、ユーザー自身に確認してもらう。
• 対象が見つからない／叩き台がまだ無い場合は、draft-article で先に叩き台を作ることを提案する。