style-harmonizer

スタイル調整ツール（定型表現の解消エディター）

トリガーとルーティング

• トリガー：スタイル調整ツール、定型文の語幹、スロット句の削除、談話の語幹、写作风格统一、去槽位句式、去生成器味。
• 使用する場面：writer-selfloop が PASS である一方、output/WRITER_SELFLOOP_TODO.md でスタイル上の問題（例：数を使った書き出しの繰り返し）が指摘されている場合、または草稿の多くのセクションが同じリズムで書かれているように読める場合。

目的：構成上のゲートを通過しても残る、生成器らしい語り口の微妙な兆候を取り除きます。

このスキルは全面的な書き直しではありません。対象を絞った書き直しキューです。

• ## Style Smells で指摘された特定の sections/*.md ファイルのみを編集します
• 事実と引用キーは変更しません

入力

必須：

• output/WRITER_SELFLOOP_TODO.md（Style Smells セクション）
• 参照されている sections/*.md ファイル

任意（対象範囲内での書き直しに役立ちます）：

• outline/writer_context_packs.jsonl（使用可能な引用＋書き出しモードのヒント）

出力

writer-selfloop の後、opener-variator とロジックの推敲の前に、この対象を絞ったパスを実行します。レポート以降に大幅な編集を行った場合は、writer-selfloop を再実行して ## Style Smells を現在のテキストに反映させます。決定論的なスクリプトは認定アダプターです。最新のレポートに問題のあるファイルが記載されている場合、またはレポートがいずれかの sections/*.md ファイルより古い場合、マーカーの作成を拒否します。意味を保つ書き直しは、このスキルまたは担当する上流のライターを通じて行い、writer-selfloop を再実行してからアダプターを再試行します。合格マーカーには、認定済みの Section ツリーの SHA256 が記録されます。

• 更新した sections/*.md ファイル（ファイル名は同じ、本文のみで、見出しは含めません）
• writer-selfloop を再実行すると監査証跡になります（Style Smells が減っていること）。
• 完了したら、空の sections/style_harmonized.refined.ok ファイルを作成します（パイプライン契約上のシグナル。このユニットを DONE としてマークする場合は必須です）。

役割カード（明示的に使用）

スタイル調整ツール（エディター）

ミッション：意味を変えずに、定型句と語幹の繰り返しを解消します。

行うこと：

• 主張ではなく、表現形式（書き出し／結び／リズム）を書き換えます
• 各段落に内容を持たせます（案内ではなく、議論をつなぐ役割を担わせます）
• 全体的なスタイルの見直しより、小さく局所的な編集を優先します

避けること：

• 新しい事実や引用を追加すること
• 引用を別の段落や別の小節に移動すること
• 薄い内容のセクションを書き直すこと。証拠を増やす必要がある場合は上流に差し戻します

エビデンス管理者（懐疑的な立場）

ミッション：スタイル調整が内容の逸脱につながらないようにします。

行うこと：

• 書き直すたびに、引用された主張が引き続き同じ文に対応しているかを抜き取り確認します
• 文章をよく見せるために新しい内容を追加しなければならないと感じたら、作業を止めて上流に差し戻します

よくあるスタイル上の問題と修正方法

1) 数を使った書き出しの定型表現（制限事項は2つです……、要点は3つです……）

重要な兆候である理由：H3 全体で繰り返し使われる文の型が生まれるためです。

書き換え方（いずれかを選択）：

• 留保事項を対比段落に組み込みます（最後の文）。解釈を変える境界条件を述べます。
• 数を使わない単一の留保文で始めます。ただし、H3 ごとに表現を変え、同じ語幹の繰り返しを避けます：「これらの結果は……に左右されます」／「解釈は……によって異なります」／「……の場合、証拠は限られています」／「留意すべき点として……があります」（控えめに使います）。
• 列挙が本当に必要な場合は、数を表に出しません。1文の中で2つの節を並列させるか、構文に変化をつけます（セクション間で繰り返さないでください）。

簡単な例（言い換えのみ）：

• 悪い例：制限事項は2つあります。まず、...
• 良い例：これらの結果は……に左右されます。これは、プロトコル間で結果をどのように適用できるかが変わるため、重要です。

2) 談話の語幹の繰り返し（要点は……ということです）

書き換え方：

• 次のいずれかに置き換えます：「実務上の示唆は……ということです」「要点の1つは……ということです」「これらの結果を読み解くうえで有用なのは……です」。
• リズムを変えます。短い主張の文に分け、条件や理由を述べる文を続けます。

3) 多数の H3 にわたって同じ書き出しのリズムが続く

書き換えの手順:

• セクションの書き出しモードを切り替える（緊張先行／意思決定先行／プロトコル先行／対比先行）。
• 汎用的な接続語（Additionally/Moreover）を、内容を伴う転換表現（「プロトコルレベルでは、…」「予算制約のもとでは、…」）に置き換える。

4) 概要／ナレーション型の書き出し（「このセクションでは概要を示す …」）

なぜシグナルが強いか: 論文の主張ではなく、生成された目次のナレーションのように読めてしまうためです。

書き換えの手順:

• 「概要」のナレーションを、内容を伴う視点（緊張／意思決定／失敗／プロトコル／対比）に置き換える。
• 最初の文は反証可能に保つ: 制約とそれが重要な理由を述べる（これから何をするかではなく）。

ミニ例（言い換えのみ）:

• 悪い: This section provides an overview of tool interfaces for agents.
• より良い: Tool interfaces define what actions are executable; interface contracts therefore determine which evaluation claims transfer across environments.

5) 接続副詞で繰り返し始まる段落（Moreover, In addition, Therefore, Overall, As a result）

なぜシグナルが強いか: 内容がしっかりしていても、文章が機械的につなぎ合わされたように聞こえ始めるためです（どの段落も同じ接続語で始まる）。

書き換えの手順:

• 論理関係は保ちつつ、接続語を文の内部に移す: 主語から始め（例:「Tool catalogs also ...」）、文の途中で関係を加える（「..., which in turn ...」）。
• 副詞の書き出しではなく節の形を使う: 「While ... , ...」／「Although ... , ...」／「Because ... , ...」。
• 要約するときは、「Overall,」を既定のラベルとして避ける。結論を主張文として直接述べる。

ミニ例（言い換えのみ）:

• シグナルが強いと感じる表現: 「Moreover, ...」（複数の段落で繰り返される）
• より良い: 内容を表す名詞句から始め（「One implication is ...」／「A practical constraint is ...」）、文の内部で関係を表現する。

6) 内部的な略記が論文の語り口に漏れ出す（「token(s)」をプロトコル名詞として使う）

なぜシグナルが強いか: NLP の文脈（token budget／context window）以外では、「token」は内部的な略記のように読めます。このパイプラインでは、しばしば packs／schemas に由来して文章にコピーされ、草稿が中間成果物のように感じられる原因になります。

書き換えの手順:

• 「X tokens」を読者向けの名詞に置き換える: 「X protocol details/assumptions/fields/parameters/dimensions」。
• 本当に言語モデルのトークンを意味する場合は、数値的かつ具体的に保つ（例:「a 60k-token context window」「token budget」）。プロトコルのメタデータに対する総称的なラベルとして「token」を使うのは避ける。
• 「three tokens: ...」のようなスロットは避ける。 (a) 結論を直接述べるか、(b)「three reporting fields」を使って文に自然に埋め込む。

ミニ例（言い換えのみ）:

• 悪い: Overall, self-improvement should be reported as a protocol with three explicit tokens: the feedback channel, the update rule, and the accounting rule.
• より良い: Self-improvement results are easiest to compare when papers make three reporting fields explicit: the feedback channel, the update rule, and the accounting assumptions.

ワークフロー（最小）

1. output/WRITER_SELFLOOP_TODO.md を読む

• ## Style Smells とファイル一覧を確認します。

2. 指摘されたファイルのみを書き換える

• 局所的な正規表現によるクリーンアップに頼るよりも、そのリズムの問題を生み出した上流のライタースキルを修正することを優先します。
• それでも局所的な書き換えが必要な場合は、小さな編集にとどめます: 書き出し／締めくくりの語幹、文の形、接続語の多様性。
• Best-of-2 書き換え（推奨）: 触れる段落ごとに 2 つの代替表現を起草し、(a) スロットの語幹を取り除き、(b) H3 をまたいで新たな繰り返しのリズムを持ち込まないものを採用します。
• 必要に応じて outline/writer_context_packs.jsonl を参照し、opener_mode のヒントを得て、書き換え中も引用スコープの安全を保ちます。
• 引用キーには触れないでください。

3. writer-selfloop を再実行する

• 期待: PASS は PASS のまま。
• 期待: Style Smells セクションが短くなる（または消える）。

完了チェックリスト

• 同じスロット句が複数の H3 で繰り返されていないこと（特に数に基づく書き出し）。
• 引用キーが追加・削除・移動されていないこと。
• writer-selfloop が引き続き PASS を報告し、Style Smells が減少していること。

スクリプト

クイックスタート

• uv run python .codex/skills/style-harmonizer/scripts/run.py --workspace <workspace>

すべてのオプション

• --workspace <dir>（必須）
• --unit-id <U###>
• --inputs <semicolon-separated>
• --outputs <semicolon-separated>
• --checkpoint <C#>

例

• サーベイのワークスペースでスタイルを調整します：
  • uv run python .codex/skills/style-harmonizer/scripts/run.py --workspace workspaces/survey-llm-agents