sembr

sembr

物理的な行構造が意味構造を反映するように文章を再整形します。 https://sembr.org/ の Semantic Line Breaks 仕様に従ってください。 以下のルールは必須です — 黙って省略したり、都合に合わせて MUST ルールを緩和したりしないでください。

モード

明示的な再整形

ユーザーが既存のテキストの再整形を依頼した場合に適用します。 対象の文章 （スニペット、ファイル、セクション）に MUST／SHOULD／MAY ルールを適用してください。 対象範囲内をすべて再整形し、 周囲の段落には手を加えないでください。

編集時のデフォルト適用

.md、.markdown、.rst ファイル内の文章を追加または変更した際に、 ユーザーから明示的な依頼がなくても自動的に適用されます。 基本方針： 編集対象の部分だけを sembr 形式にし、 それ以外はすべてバイト単位で変更しないことです。

• 新しい文章（新規ファイル、新しい段落、新たに挿入されたブロック）： 最初から sembr 形式で記述してください。
• 既存の段落内の編集： 段落内の既存の改行スタイルに合わせてください。 すでに sembr に従っている場合 （複数の短い行で、文末や節の後に改行されている） — 編集箇所も sembr 形式を維持してください。 1 行が長い場合、一定の桁数で折り返されている場合、 または他の明確な規則に従っている場合は — その規則に合わせてください。 段落が短すぎて判断できない場合は — デフォルトで sembr を適用してください。
• 未編集の段落： 再整形しないでください。 1 つの段落を編集しても、 隣接する段落の改行、空白、文言を変更してはいけません。 差分は編集箇所に限定してください。
• 適用除外： ユーザーが «не применяй sembr здесь»／「ここでは sembr を適用しないでください」 （またはプロジェクトレベルの設定）と指定した場合は — ファイル内の既存の規則に従ってください。

適用しない場合

プレーンな .txt、 <br> による改行表示を使用する GFM、 メール、 チャット（Slack、Telegram、Discord）、 または単一の改行が表示上の改行になるあらゆる形式では、 どちらのモードも適用しないでください。 そのような場合に Sembr を適用すると、表示結果が変わり、ルール 2 に違反します。

入力

編集前に対象を特定してください：

• 会話に貼り付けられたスニペット → 再整形したテキストを返します。
• ファイル内のパスまたはセクション → ファイルを直接編集します。
• Markdown／HTML ドキュメント → 表示形式 （見出し、リスト、コードブロック、リンク、インラインマークアップ）をすべて保持します。

Sembr が適用されるのは、文章の段落と、文章を含むリスト項目および引用ブロックだけです。 変更禁止領域 — 以下の中の空白、 改行、 内容は一切変更しないでください：

• フェンス付きコードブロック（```）とインデント付きコードブロック。
• インラインコードスパン（`）。
• HTML の領域。
• Markdown の表。
• YAML／TOML のフロントマター。
• reST の行ブロック（| で始まる行）。
• reST ディレクティブ（.. name:: とそのインデントされた内容）。
• reST のリテラルブロック（行末の :: の後からインデントが戻るまで）。
• reST のグリッド表およびシンプルな表。
• reST の doctest ブロック（>>> で始まる行）。

対象が曖昧な場合は、編集前に確認してください。

ルール

MUST（必須、例外なし）

1. すべての文末記号の後で改行する — ., !, ?。 . が文末記号となるのは、文を終える場合だけです — 略語（e.g., Mr., U.S., etc.）、 バージョン番号やドット区切りの識別子（1.22.4, node.js, co.uk）、 または三点リーダー（…, ...）の中にある場合は該当しません。 判断に迷った場合は、 次の文字を確認してください： 新しい文が始まる場合 （スペースの後に大文字が続く場合、または段落の末尾の場合）は、 改行してください。 それ以外の場合は改行しないでください。

2. 表示結果を絶対に変更しないこと。 レンダリング後の表示結果（Markdown、HTML など）は、 入力とバイト単位で同一でなければなりません。 許可される変更は、段落内のスペースを 1 つの改行に置き換えること （またはその逆）だけです。 禁止事項：

   • 空白以外の文字を追加、削除、変更すること。
   • 空行を挿入または削除すること。
   • 変更禁止領域（「入力」を参照）内に手を加えること。
   • 行末の空白、タブ、空行の数を正規化すること。

   検証： 入力と出力の差分を確認してください — 文章の段落内で、スペース ↔ 改行を置き換えた箇所だけが変更されていること。

3. ハイフンでつながれた単語の途中では絶対に改行しない （例：state-of-the-art は 1 行に保ちます）。

SHOULD（MUST ルールに違反する場合、または意味が変わる場合を除き適用）

4. 独立節ごとに改行する ,、;、:、または —（ダッシュ）で区切られている場合。 判断の目安：独立節には主語と定形動詞があり、 それだけで文として成立します。 «I went to the store, and I bought eggs» — どちらも独立節です。 コンマの後で改行します。 «I went to the store to buy eggs» — «to buy eggs» は従属節なので、 改行しません。 構造が本当に曖昧な場合は、 節を分割せずに残し、そのケースをレポートに記載します （Reporting を参照）。
5. 列挙または項目別リストの前で改行する。
6. 行の長さを80文字未満に保つ。 1行が80文字を超える場合は、 条件を満たす意味上の区切りのうち、最も後ろの位置で改行します。

MAY（読みやすさの向上、または MUST／SHOULD の適用に役立つ場合に使用）

7. 読みやすさの向上や行の長さを短くするために、従属節の後で改行します。
8. 関連する項目をまとめるために、リスト項目の間で改行します。
9. ハイパーリンクまたはインラインマークアップの前後で改行します。
10. 80文字を超える部分が分割できない単位 （URL、コードスパン、インラインマークアップ）である場合は、 行が80文字を超えてもかまいません。

手順

1. 入力をそのまま読みます。
2. レンダリングコンテキストを確認します。 .md、.markdown、.rst、.html、 または CommonMark／reST／標準的な HTML のセマンティクスに 従うことが分かっているコンテキストでは、 そのまま作業を進めます。 プレーンテキスト、 <br> による改行処理を行う GFM、 メール、 チャット（Slack、Telegram、Discord）、 または単独の改行が可視の改行として表示されるコンテキストでは、 明示的な再フォーマットモードの場合は続行前にユーザーに確認し、 デフォルトの編集モードの場合は sembr を適用しません。 そのような場所で Sembr を適用すると、出力が目に見えて変わり、 ルール2に違反します。
3. まず MUST ルールを適用します。
4. MUST ルールと競合せず、意味を損なわない範囲で SHOULD ルールを適用します。
5. 80文字の目安に収め、読みやすさを高めるために MAY ルールを使用します。
6. 内容を言い換えたり、追加したり、削除したりしてはいけません。 原文の曖昧さによって構造上の選択が必要になる場合は、 編集前に確認します。
7. レンダリング後の出力が入力と一致することを確認します。

例

悪い例 — 複数の節があるのに、意味上の構造を示す改行がない：

The build pipeline succeeded; however, the deploy step failed because the secret rotated overnight, and we did not refresh the cache — so production is now serving stale config.

良い例 — sembr 形式で整形：

The build pipeline succeeded;
however, the deploy step failed because the secret rotated overnight,
and we did not refresh the cache —
so production is now serving stale config.

悪い例 — ハイフンでつながれた単語の途中で改行する （MUST ルール3に違反）：

This is a state-
of-the-art system.

良い例：

This is a state-of-the-art system.

レポート

編集後、 再フォーマットしたファイルまたはセクションを簡潔に記載します。 ユーザーから求められない限り、 再フォーマットした全文をそのまま再掲しないでください。

作業中にルールを緩和または適用しなかった箇所がある場合は、 そのすべてを列挙します。 これには、曖昧な独立節を分割せずに残した場合、 標準外のレンダリングコンテキストの場合、 分割できない単位によって80文字を超えた行がある場合、 または厳密に適用できるか確信を持てなかったその他の箇所が含まれます。 これにより、ユーザーはどの箇所がベストエフォートであり、 厳密な適用ではないかを把握できます。