subsection-polisher について
subsection-polisher は、サーベイ執筆者が統合前に H3 本文を一つずつ改稿するためのスキルです。論旨の構成、複数論文の統合、根拠の限界を重視し、引用キーと範囲を維持します。
主な機能
- 01冒頭を主張が明確な形に改稿
- 02対比と評価の基準を追加
- 03引用論文の根拠を統合
- 04引用キーと小節の範囲を維持
- 05定型表現と段落の流れを点検
活用シーン
- 01統合前に個々の H3 本文を推敲
- 02話題の羅列を一貫した論旨に整理
- 03上流で補うべき根拠不足を特定
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ willoscar/ research-units-pipeline-skills --skill subsection-polisherインストール後、Claude Code で/subsection-polisherを入力して読み込まれたか確認します。
詳細
小節の推敲(ローカル、マージ前)
トリガーとルーティング
- トリガー:小節の推敲、小節ごとの推敲、セクションファイルの推敲、小节润色, 去模板, 结构化段落。
- 次の場合に使用:
sections/S*.mdが存在するものの、文章が硬くテンプレート的に感じられ、section-mergerの前にローカルで品質を改善したい場合。
目的:sections/S<sub_id>.md(H3 の本文のみ)を、output/DRAFT.md にマージする前に、サーベイらしい文章へと改善します。
これは意図的にローカルで行う作業です。1つずつ単位を修正し、ゲートを再実行して、論文全体を書き直すことなく品質を高めます。
役割カード(明示的に使用)
ローカルセクション編集者
使命:引用キーを変更せずに、1つの H3 の論旨の密度と論文らしい文体を改善します。
実施すること:
- 冒頭を「緊張関係 → 重要である理由 → 主張」の流れに書き換えます(第1段落の末尾を主張にします)。
- 不足している場合は、明示的な対比と評価の基準を1つ加えます。
- 解釈を変える、その小節に固有の限界を加えます。
避けること:
- 引用キーの追加・削除や、小節をまたいだ引用の移動。
- 内容を汎用的な定型文に置き換えること。
エビデンス管理者(内容の水増しを防止)
使命:エビデンスが乏しい場合に、推敲が根拠のない創作につながるのを防ぎます。
実施すること:
- 推測なしに対比や評価の基準を書けない場合は、作業を中止し、上流工程に差し戻します。
避けること:
- 既存の引用で裏付けられる範囲を超えて主張を強めること。
役割プロンプト:ローカルセクション編集者(一度に H3 を1つ)
You are editing one survey subsection to make it read like paper prose.
Your goal is to remove generator voice and strengthen argument moves without changing citation keys:
- opener: tension + why-it-matters + thesis (no narration)
- add explicit contrasts and an evaluation anchor if missing
- make at least one cross-paper synthesis paragraph (>=2 citations)
- add a subsection-specific limitation (not boilerplate)
Constraints:
- do not add/remove citation keys
- do not invent facts
- keep scope local to this H3
入力
- 対象ファイル:
sections/S<sub_id>.md(H3 の本文のみ) - 優先するコンテキスト:
outline/writer_context_packs.jsonl - 代替コンテキスト:
outline/subsection_briefs.jsonl+outline/evidence_drafts.jsonl citations/ref.bib
出力
- 更新後の
sections/S<sub_id>.md(同じパス。引用キーは変更しない)
必須条件(契約)
- 引用キーは変更不可です。
[@BibKey]マーカーを追加・削除してはいけません。 - スコープは変更不可です。この H3 に許可されたスコープ(
outline/evidence_bindings.jsonl/ writer packallowed_bibkeys_*)内に、すべての引用を収めてください。 - 事実を捏造しないでください。推測なしに具体的な対比や評価の基準を書けない場合は、中止して上流のエビデンスを修正してください。
- 本文のみ:見出しは含めません。見出しは
section-mergerが追加します。
目指す品質(「推敲済み」の基準)
推敲済みの H3 は、話題の羅列ではなく、論旨として読めるものです。
- 第1段落は主張(結論を先に示す要点)で終わり、語りの定型文を使いません。
- 対比を示す語句を使った、明示的な対比(A と B)が2つ以上あります。
- 少なくとも1つの評価基準を示す段落(タスク/ベンチマーク+指標+該当する場合は制約/予算/ツールへのアクセス)があります。
- 同じ段落に2つ以上の引用を含む、論文横断の統合を示す段落が少なくとも1つあります。
- プロトコルの不一致/詳細の欠如/脅威モデルの不明確さに結びついた限界または留保が少なくとも1つあります(定型的な記述は不可)。
論文らしい文体の制約(強く避けるべきパターン)
以下は生成文らしく見えるため、削除または書き換えてください。
- アウトラインの説明:「この小節では……」「本小節では……」
- スライドのような案内:「次に……」「ここでは次に……」「次のセクションでは……」
- メタ的な指示:「サーベイの統合/比較では……すべきです」
- エビデンスポリシーに関する免責の多用:H3 内で「要約のみ/タイトルのみ/暫定的」といった定型文を繰り返すこと。
- 数に基づく定型的な書き出し:段落の冒頭に「2つの限界……」「3つの要点……」を繰り返し使うこと。
以下を優先してください(論文らしい文体):
- 内容から始める書き出し:「中心的な緊張関係は……」「実際には……」「繰り返し見られるパターンの1つは……」
- 案内ではなく、論旨をつなぐ表現:「この対比が重要なのは……」「こうした前提は……を形作ります」
- 引用をエビデンスとして文章に織り込み、文末に引用をまとめて付けないでください。
ワークフロー(1つの小節)
- 小節の契約を読み込む
outline/writer_context_packs.jsonlで、この小節のパックを読みます。- パックが存在しない、または情報が少ない場合は、
outline/subsection_briefs.jsonl(thesis/tension/paragraph_plan)とoutline/evidence_drafts.jsonl(comparisons/eval/limitations)を参照します。 - 次の内容を抽出します(本文には書かず、別途書き留めます)。
tension_statement+thesis- A対Bの対比に使う
comparison_cardsを2〜3個 evaluation_anchor_minimalを1つ(task/metric/constraint)- evidence pack から limitation hook を1つ
- 事前確認(最終本文には含めません)
- 1行の文を4つ下書きします。
- 緊張関係
- 対比(A対B。引用を2つ以上)
- 評価の軸(task/metric/constraint)
- 限界
これらを推測なしに書けない場合は中止し、その不足を上流工程(
paper-notes/evidence-draft)にフィードバックします。
- 書き出しの書き直し(第1段落)
- 説明的な書き出しを削除します。
- 緊張関係/判断/視点を示す1〜2文と、それが重要な理由を示す1文を書き、最後を thesis で締めます。
悪い例:
This subsection surveys tool interfaces for agents.
良い例:
エージェントのツールインターフェースには、表現力のあるアクション空間と検証可能な実行を両立させるという中心的な緊張関係があり、インターフェースの契約が、どの評価上の主張に意味があるかを大きく左右します。
- 段落の見直し(列挙より論旨の展開)
grad-paragraphのミクロ構成を使い、段落ごとに書き直します。- ベスト・オブ・2の書き直し(推奨):段落が型にはまっていると感じたら、書き直し案を2つ作り、論旨の展開がより明確で、テンプレート的なリズムが少ない方を採用します(引用は変更しません)。
- 緊張関係 → 対比 → 評価の軸 → 限界
- 次の内容を必ず含めます。
- 明示的な対比を2つ以上(「Aの次にB」形式の要約ではありません)
- 評価の軸を扱う段落を1つ以上
- 複数の論文を横断して統合する段落を1つ以上(引用を2つ以上)
- 小節に固有の限界を扱う段落または節を1つ以上
- 引用の埋め込みを見直す(引用の羅列を避ける)
- 引用が段落末の
[@a; @b; @c]のみに現れる段落を書き直します。 - 残す引用キーがすべて
citations/ref.bibで定義されていることを確認します。
悪い例(引用の羅列):
多くのシステムがツールスキーマを採用しています。[@a; @b; @c]
良い例(証拠として引用):
X [@a] や Y [@b] などのシステムは、アクションの曖昧さを減らすためにツールスキーマを明確に定義しています。一方、Z [@c] はインターフェースをより柔軟に保ち、検証の負担を移しています。
- リズムの調整とテンプレート感の解消
- 段落の書き出しに変化をつけ、多くの段落で同じ統合表現(特に
Taken together)を繰り返さないようにします。 - 主張、対比、プロトコルの詳細、限界を加えない、内容のないつなぎの文を削除します。
- 再確認(省略しないこと)
section-logic-polisherを実行し、FAIL(thesis と connector density)に対処します。引用キーは変更しません。writer-selfloop(または strict quality gate)を再実行し、レポートで指摘された箇所だけを修正します。
リライトの指針(よくある失敗 -> 修正)
これらは、そのままコピーして使うテンプレートではなく、リライトの意図として活用してください。
- 説明的な書き出し -> 内容を主張する書き出し
This subsection surveys ...->A central tension is ...; this matters because ...(第1段落の末尾を論旨で締めます)。
- スライド風の案内 -> 議論をつなぐ橋渡し
Next, we move from planning to memory.->Planning specifies how decisions are made; memory determines what information those decisions can reliably condition on under a fixed protocol.
- 免責事項の乱発 -> 方針を1つの段落にまとめ、必要な箇所に限って注意書きを付ける
- 繰り返される
abstract-only evidenceの定型文を削除します。 - 根拠に関する方針は Intro/Related Work で一度だけ示します。H3 では、特定の比較の解釈が変わる場合に限り、その箇所に注意書きを加えます。
- 「サーベイでは〜すべき」というメタな表現 -> 先行研究に即した観察
Therefore, survey comparisons should control for tool access.->Across reported protocols, tool access and budget assumptions vary widely, making head-to-head comparison fragile unless those constraints are normalized.
- 曖昧すぎる定量的な主張 -> 最小限の文脈を加える(または表現を弱める)
- 段落に数値を残す場合は、同じ段落にタスクの種類/指標の定義/制約(予算・コスト・ツールへのアクセス)を加え、引用を文中に組み込みます。
- 根拠資料から文脈が分からない場合は、主張を定性的な表現に書き換え、定型文を使わず、欠けている項目を要検証事項として示します。
中止条件(推敲よりも上流の見直しが必要な場合)
以下に該当する場合は、推敲を中止して上流の工程に戻ってください。
- 推測せずには対比を書けない(根拠資料がタイトル/要旨のみ)
- 小節に評価の根拠となる情報がない(メモにベンチマーク/指標/プロトコルの詳細がない)
- 議論を成立させるために、対象範囲外の引用が必要になる
受け入れチェックリスト
- 第1段落が論旨で終わっている(説明的な定型文がない)。
- 明示的な対比が2つ以上、評価の根拠が1つ以上、総合的な考察の段落が1つ以上(引用2件以上)、限界点が1つ以上ある。
- スライド風の案内/メタな指示/繰り返される根拠方針の定型文がない。
- 引用だけを並べた段落がなく、主張の文中に引用が組み込まれている。
-
section-logic-polisherとwriter-selfloopがこのファイルに警告を出さなくなっている。
コメント
Markdown 対応