accelint-english-manager

English Manager

読みやすく、ざっと目を通しやすく、すぐに行動に移せる、平易で率直な英語を使います。

簡潔さだけを追求しないでください。文章をより明確で、一貫性があり、誤解されにくくしながら、ユーザーが意図した意味、対象読者、トーン、明示された制約を保ってください。

このスキルでは、次の要素を組み合わせた標準のライティング方式を使います。

• 直接的で具体的な表現を使う「平易な言葉」の徹底
• 技術的な明確さと用語の一貫性を重視する「STE 寄り」の構成
• 文章が読み手の行動を助ける場合に、ざっと目を通しやすく、行動に移しやすい形にする「ADHD に配慮した」整え方

これらを組み合わせて使ってください。別々のモードではありません。

厳守事項

これらは、文体上の好みより優先されます。

• 表現を最適化する前に、ユーザーの意味を保ってください。
• 求められたトーン、対象読者との適合性、明示された形式上の制約を保ってください。
• ユーザーが望む場合は、意図的な親しみやすさ、リズム、ユーモア、説得力、ブランドの声を保ってください。
• ユーザーが明示的に書き換えを求めない限り、コード、識別子、コマンド、ファイルパス、引用されたエラー、製品名、API 名、設定キー、法的文言は変更しないでください。
• 実際の不確実性、微妙なニュアンス、義務の度合いを保ってください。文章を分かりやすくするために、正確さを損なわないでください。
• ASD-STE100 への公式な準拠を主張しないでください。厳密な STE を求められた場合は、完全な準拠には公式規格と辞書の確認が必要だと伝えてください。

まずここから

編集する前に、最も適した最小限の手順を選んでください。

ステップ 1：最初にモードを確認する

ユーザーがモードを明示していない場合、下書きや書き換えの依頼では、まず確認してください。

次の選択肢を提示してください。

• mode=default — 特に指定がなければ、平易で率直な局所的な書き換え
• mode=strict — より厳密な技術的制御。必要に応じて構成の書き換えも可能

ユーザーがモードを選んでいない場合は、決めつけずに短い確認質問をしてください。 完了条件：書き換えモードが明示されているか、依頼が明らかに監査のみであること。

ステップ 2：出力モードを選ぶ

前提条件：書き換えモードの確認が必要な依頼では、ステップ 1 が完了していること。

編集する前に、次のいずれかの出力モードを選んでください。

• 監査のみ — 書き換えを求められない限り、文章をレビューします。
• 書き換えのみ — 改善した最終版をそのまま返します。
• 監査と書き換え — まず指摘事項を示し、その後に書き換えを提示します。

ユーザーが書き換えのみを求めている場合は、書き換えだけを返してください。求められていない監査メモは返さないでください。 完了条件：出力モードが明示されていること。

ステップ 3：制約を守る

前提条件：ステップ 2 が完了していること。 書き換えや再構成を行う前に、必ず実施してください。

次の項目を先に特定し、維持してください。

• 意味
• 対象読者
• トーン
• 形式
• 変更してはいけない正確な文言
• 正確なまま維持する必要がある引用文や技術的な文言

文体上のルールとユーザーの明示的な制約が競合する場合は、制約を優先してください。 完了条件：維持すべき制約が特定されていること。

ステップ 4：モードに沿って範囲を選ぶ

前提条件：ステップ 3 が完了していること。

書き換えの標準範囲は、モードに従って決めてください。

• mode=default — 原則として局所的に書き換えます。提示された文章だけを引き締めたり、明確にしたりしてください。ユーザーがより完成度の高い成果物を明確に求めている場合や、現在の構成では重要な意味が伝わりにくい場合を除き、元の構成を維持してください。
• mode=strict — 文章の目的をより確実に達成するために有効であれば、構成の書き換えも可能です。現在の構成では順序、論理、安全性、要件、運用上の明確さが伝わりにくい場合は、内容を並べ替えたり、分割したり、見出しを付け直したりしてください。

mode=strict を、気軽に依頼の範囲を広げてよいという許可だと捉えないでください。どちらのモードでも、ユーザーがより広範な書き換えを明示的に求めていない限り、実際の問題を解決する最小限の変更にとどめてください。 完了条件：許可される書き換えの範囲が明確であること。

標準のライティング手法

より厳密な追加ルールが明らかに適している場合を除き、この手法を使ってください。

1. 要点を先に伝える

要点、結果、または次のアクションから始めます。

• 説明文では、主な事実を先に述べます。
• 作業手順を示す文では、次のアクションを先に示します。
• サポートやエラーの案内では、何が起きたか、分かっていればその理由、次に何をすべきかを示します。

前置きがないほうが伝わりやすい場合は、前置きを加えないでください。

2. 率直で具体的な言葉を使う

正確さを保ちながら、最も明確な文を書きます。

• 抽象的な表現より、具体的なアクションや結果を優先します。
• 意味が変わらない場合は、短くなじみのある言葉を使います。
• 冗長な表現、不要なまとめ、誇張された言い回しを削ります。
• 行為者が重要な場合は、誰が行うのかを明記します。
• 明確になる場合は、受動態より能動態を優先します。

簡単な言葉にすると正確さが損なわれる場合は、正確な言葉を使います。

3. 1つの概念には1つの用語を使う

繰り返し登場する概念ごとに用語を1つ選び、一貫して使います。

繰り返しを避けるためだけに、同義語を使い分けないでください。

4. 読み取りやすい文章にする

基本として、ADHD のある人にも読みやすい構成にします。

• 文や段落を適切な長さに保ちます。
• 可能な場合は、1文につき主なアクションまたは事実を1つにします。
• 作業の流れを追いやすくなる場合にのみ、リストを使います。
• 関連する段階になるまでは、主要な流れに補足事項を持ち込みません。
• 読者が行動する必要がある場合は、次のアクションを明確に示します。

気軽な文章、創作的な文章、または語り口が重要な文章に、無理にチェックリスト形式を当てはめないでください。

5. 目的に合った構成にする

文章の目的に合う形式を使います。

• 手順や作業に関する文章：命令形の手順を使い、コマンドの前に条件を示し、各ステップでは1つのアクションを示し、警告は明確な指示として記述します。
• 説明文：1文につき主な事実を1つ示し、関連する事実をまとめ、説明の段落に指示を埋め込みません。
• 語り口や説得力を重視する文章：文章の役割を果たす語り口を損なわずに、明確さを高めます。

6. 必要なニュアンスを保つ

率直に書きつつ、確実性や強さを誇張しないでください。

• 事実に不確実性、条件、推定、または不完全さがある場合は、適切な留保を残します。
• 不明瞭さを加えるだけの不要な留保は削ります。
• 要求、推奨、許可、能力の強さを正確に保ちます。
• 行為者が不明、重要でない、配慮が必要、または意図的に強調を避ける場合にのみ、受動態を使います。

モードの指定

効果がある場合は、次の文章作成モードを使います。

モード	使用する場面	適用内容
mode=default	ほとんどの依頼	平易な言葉遣い、一貫した用語、読み取りやすい構成、必要に応じて行動を先に示す構成、原則として部分的な書き換え
mode=strict	ユーザーが STE、ASD-STE100 スタイルの文章、非常に厳格な平易な言葉遣い、厳密に統制された技術表現、または技術文書のより厳密なレビューを明示的に求めた場合	デフォルトモードの内容に加え、STE の構成、法助動詞の使い分け、手順と説明の区分、用語の統制をさらに強化し、明確さや統制に必要な場合は構成も書き換えます。

ユーザーが厳格な STE スタイルのレビューを求めた場合：

1. STE に沿った厳格なレビューができることを伝えます。
2. ASD-STE100 への公式な準拠には、公式の規格と辞書が必要であることを伝えます。
3. 依頼に必要な references/ste-rules.md の関連部分だけを読み込みます。
4. 実際に読み込んだ references/ste-rules.md の部分に記載されたルール番号だけを引用します。
5. 関連するルールの本文を読み込んでいない場合は、ルール番号を引用しません。

これらの対応を1文にまとめないでください。順序を明示してください。

ユーザーが「plain English」「simple English」「clean this up」など、モードを指定せずに一般的な文章の整理を求めた場合は、mode=strict の指定とはみなさず、平易な言葉遣いを目指す依頼として扱います。

シリアル順序の検出と対応

テキストで、読者やエージェントにあることを別のことより先に行うよう伝えている場合、順序を伴う指示として扱います。

以下のケースを検出し、明確にします。

• 明示的な順次指示 — 番号付きの手順、first/next/then/finally、before/after/until、requires、depends on、done when、return to
• 暗黙の手順の順序 — 1つの文に複数のアクションが隠れている、あるアクションが別のアクションの出力に依存している、または警告が欠けている確認手順を示唆している
• スキルファイル内の順序を示す手がかり — 最初にモードを確認する、出力モードを選んでから提供する、書き換える前に制約を保持する、引用する前にルールの参照資料を読み込む、提供する前にセルフチェックを行う
• 一般的な文章内の順序を示す手がかり — 手順、運用上のメモ、サポート手順、オンボーディングのテキスト、プロンプト、設定・実行・検証・提供が混在する段落

順序が重要な場合：

• 順序を明確にする
• 順序のある短い手順が2～3個の場合は、番号付きリストを使う
• 順序のある手順が4個以上の場合は、### Step 0とチェックリストを使い、その後に### Step N: Nameを記載する
• 手順が前の手順に依存する場合は、Requires:を追加する
• 後続の作業がチェックの成功に依存する場合は、Done when:を追加する
• 後続の手順を合格するチェックまで待たせる必要がある場合は、名前付きの失敗時の分岐を追加する
• 指示の明確な遵守に役立つ場合は、do X and then Yを別々の手順に分ける
• タイミングがより明確になる場合は、アクションより先に条件を記載する
• 後続のアクションが先行するチェックにすでに依存している場合に限り、強調だけの警告を、確実に実行されるゲートに置き換える
• 順序のある作業を通常の箇条書きのままにしない

実際のワークフローの順序、ゲート、分岐、検証ループを含むテキストを書き換えたり監査したりする前に、references/serial-instruction-guidance.mdを読み込んでください。SKILL.mdは実用的な内容にしてください。より詳しい検出ロジック、構成ルール、例外については、この参照資料を使用してください。

出力ルール

監査のみ

ユーザーがより正式な形式を求めていない限り、簡潔なレビューを標準とします。

次の形式を使用します。

1. 概要 — 明確さ、トーン、実行しやすさに関する主な課題を1～3文で説明します
2. リスクの高い問題から順に — 特に意味のずれ、曖昧さ、隠れたアクション、義務のずれ、構成の破綻を優先します
3. 対象を絞った指摘 — 役立つ場合に限り、原文、リスク、簡潔な説明を記載します
4. 任意の全文書き換え — ユーザーが求めた場合、または文章に繰り返し問題がある場合に限り含めます

書き換えのみ

ユーザーが書き換えのみを求めた場合は、書き換えた文章だけを返します。

ユーザーが求めていない限り、監査メモや説明を前置きしないでください。

監査と書き換え

先に指摘事項を示し、その後に書き換えを提示します。

参照資料の読み込みガイド

実質的に役立つ場合に限り、参照資料を読み込みます。

• references/serial-instruction-guidance.md — 順序のある指示、暗黙の順序、ゲート、分岐、検証ループ、段落を明示的な手順に変えるべき場合
• references/substitutions.md — 表現の整理、冗長表現の削除、一貫性の確認、法助動詞のチェック
• references/checklist.md — 最終確認または詳細な監査のサポート
• references/ste-rules.md — 技術的、手順的、指示的な文章、またはSTEを明示的に求められた場合。また、mode=strictの場合
• references/adhd-patterns.md — 読者に実行支援、負担の少ない次の手順、または標準よりもADHDに配慮した形式が必要な場合の、より行動指向の構成
• references/use-cases.md — ドキュメント、プロンプト、サポートへの返信、インシデントメモ、UIテキスト、または声のトーンに配慮した文章へのコア手法の適用
• references/rfc-2119.md — 規範的な内容、またはポリシー、要件、インターフェース契約、ガバナンス、手順などの動作を定義する文章に限る。非公式な重要度の表現が実際の義務を曖昧にしている場合に使用
• references/examples.md — 依頼が曖昧な場合や、明確さの目標と声のトーンに関する制約が混在する文章の指針となるパターン

提供ワークフロー

ゼロから作成する場合

ステップ 1：モードを確認する

ユーザーがすでにモードを指定している場合を除き、最初に行います。 完了条件：書き換えモードが明確になっていること、または依頼が本当に監査のみであること。

ステップ 2：出力モードを選ぶ

前提条件：書き換えモードが必要な依頼の場合、ステップ 1 が完了していること。 下書きを作成する前に、Audit only、Rewrite only、Audit plus rewrite のいずれかを選びます。 完了条件：出力モードが明確になっていること。

ステップ 3：制約を抽出する

前提条件：ステップ 1 と 2 が完了していること。 下書きを作成する前に、意味、対象読者、トーン、形式、固定する必要がある正確な文言を特定します。 完了条件：保護すべき制約が特定されていること。

ステップ 4：モードを適用する

前提条件：ステップ 3 が完了していること。 mode=default または mode=strict によって、標準の適用範囲を設定します。 完了条件：許可される書き換えの範囲が明確になっていること。

ステップ 5：直接的な英語で下書きを作成する

前提条件：ステップ 1〜4 が完了していること。 ユーザーの意図する意味、対象読者、トーン、明示された制約を保ち、平易で直接的な英語で書きます。 完了条件：下書きが原文と同じ役割を果たしていること。

ステップ 6：繰り返し使う用語を統一する

前提条件：ステップ 5 が完了していること。 1つの概念には1つの用語を使います。表現に変化をつけるために類義語を使い分けないでください。 完了条件：繰り返し登場する概念に一貫した用語が使われていること。

ステップ 7：行動の流れを見通しやすくする

前提条件：ステップ 5 と 6 が完了していること。 読者が行動する必要がある場合に実施します。 文章に順序付きのアクションが含まれる場合は、順序を明確にする前に references/serial-instruction-guidance.md を読み込みます。 完了条件：順序付きのアクションが、順序のあるものとして明示されていること。

ステップ 8：提出前にセルフチェックを行う

前提条件：ステップ 1〜7 が完了していること。 ステップ 8 が完了するまでは提出しないでください。 セルフチェックに不合格となった場合は、影響を受けた最初のステップに戻ります。 完了条件：セルフチェックに合格していること。

既存の文章を修正する場合

ステップ 0：進捗を記録する

書き換えワークフローに実質的なアクションが4つ以上ある場合は、ほかの作業より先に行います。 作業中の状態または返信に短いチェックリストを作成し、各ステップの後に更新します。

• ステップ 1：モードを確認する
• ステップ 2：ユーザーの意図と制約を守る
• ステップ 3：モードを適用する
• ステップ 4：最小限の安全な変更で表現を引き締める
• ステップ 5：冗長な表現、古い言い回し、避けられる抽象表現を取り除く
• ステップ 6：代替表現だけでは不十分な場合に限り、過度に長い文を分割するか、構成を変更する
• ステップ 7：代名詞、法助動詞、変更不可の要素を再確認する
• ステップ 8：提出前にセルフチェックを行う

ステップ 1：モードを確認する

ユーザーがすでにモードを指定している場合を除き、最初に行います。 完了条件：書き換えモードが明確になっていること、または依頼が本当に監査のみであること。

ステップ 2：ユーザーの意図と制約を守る

前提条件：ステップ 1 が完了していること。 書き換えを行う前に実施します。 完了条件：意味、対象読者、トーン、形式、変更不可の要素が特定されていること。

ステップ 3：モードを適用する

前提条件：ステップ 1 と 2 が完了していること。 mode=default または mode=strict によって、標準の適用範囲を設定します。 完了条件：許可される書き換えの範囲が明確になっていること。

ステップ 4：最小限の安全な変更で表現を引き締める

前提条件：ステップ 1〜3 が完了していること。 原文の役割、意味、トーン、対象読者、明示された制約を保ちながら、安全な書き換えを1回行います。 完了条件：下書きの役割を変えずに、より明確になっていること。

ステップ 5：冗長な表現、古い言い回し、避けられる抽象表現を取り除く

前提条件：ステップ 4 が完了していること。 意味を加えず、内容を曖昧にする表現を取り除きます。 完了条件：残った表現が意味または制御の役割を担っていること。

ステップ 6：代替表現だけでは不十分な場合に限り、過度に長い文を分割するか、構成を変更する

前提条件：ステップ 4 と 5 が完了していること。 原文に順序、条件、分岐のロジックが隠れている場合は、順序を明示して書き換える前に references/serial-instruction-guidance.md を読み込みます。 順序のチェックに不合格となった場合は、ステップ 4 に戻ります。 完了条件：ワークフローが、順序のない助言として読まれる余地がないこと。

ステップ 7：代名詞、法助動詞、変更不可の要素を再確認する

前提条件：ステップ 4〜6 が完了していること。 完了条件：指示対象が明確で、義務の強さが原文と一致していること。

ステップ 8：納品前にセルフチェックを実行する

必要条件：ステップ 1 から 7 までが完了していること。 ステップ 8 が完了する前に納品しないでください。 セルフチェックに失敗した場合は、影響を受けた最も早いステップに戻ってください。 完了条件：セルフチェックに合格していること。

書き換えではなくテキストの確認を行う場合

ステップ 1：最もリスクの高い問題を最初に特定する

意味のずれ、曖昧さ、隠れたアクション、義務のずれ、順序付けの弱さを優先してください。 完了条件：リスクの高い問題が順位付けされていること。

ステップ 2：依頼に応じた範囲でレビューする

必要条件：ステップ 1 が完了していること。 完了条件：監査の深さが依頼に見合っていること。

ステップ 3：ユーザーから求められた場合、またはテキストの影響が重大な場合に限り、より厳格なルールベースの監査形式を使用する

必要条件：ステップ 1 と 2 が完了していること。 完了条件：監査形式がリスクと依頼に見合っていること。

ステップ 4：引用する前に適切な参照資料を読み込む

必要条件：ステップ 3 が完了していること。 ユーザーが STE チェックを依頼した場合は、必要な箇所だけ references/ste-rules.md から読み込んでください。ルール番号を捏造しないでください。 テキストに順序のあるアクションや、順序が不明確な手掛かりが含まれる場合は、順序が十分明確かどうかを判断する前に references/serial-instruction-guidance.md を読み込んでください。 完了条件：引用するルールはすべて、読み込んだ参照資料に記載されていること。

ステップ 5：納品前にセルフチェックを実行する

必要条件：ステップ 1 から 4 までが完了していること。 ステップ 5 が完了する前に納品しないでください。 完了条件：セルフチェックに合格していること。

競合の解決

ルールが競合する場合は、次の優先順位に従ってください。

1. ユーザーの意図、対象読者、トーン、明示的な制約
2. 変更不可の要素と、指定された厳密な表現
3. 明確さと実行可能性
4. テクニカルライティングの原則
5. 簡潔さ

具体的な解決方法：

• 人間関係に配慮したトーン、説得力、リズム、ブランドとの適合性が重要な文章では、温かみや語り口を保ってください
• STE に似た原則は明確さを高めるために使い、創作的または複合的な文章の形式を無理に変えるために使わないでください
• 見せかけのヘッジ表現は取り除きますが、実際の不確実性は残してください
• 基本的には能動態を使いますが、配慮、不確実性、意図的な強調が重要な場合は受動態を保ってください

納品前に必ず行うセルフチェック

納品前に、次の点を確認してください。

1. 書き換え後の文章が、同じ対象読者に対して同じ役割を果たしている。
2. 重要な用語が一貫している。
3. 義務、許可、能力、不確実性にずれが生じていない。
4. 変更不可の要素が正確に保たれている。
5. 明示的または暗黙的な順序付き指示が、引き続き順序付き指示として明確に示されている。
6. 必須のゲート、依存関係、検証ステップによって、後続のステップが引き続き明確に制限されている。
7. 最終回答が指定された出力形式に合っている。
8. 最終回答が指定された書き換え形式に合っている。
9. 残っている定性的な表現に明確な運用上の役割があり、隠れたゲートとして機能していない。

さらに詳細な機械的チェックを行う場合は、references/checklist.md を読み込んでください。

制限事項

このスキルは、明確さと実行のしやすさを高めます。専門家による正確性の確認、法務レビュー、ブランドレビュー、または公式の ASD-STE100 認証に代わるものではありません。

また、これはライティングスキルであり、ファクトチェックやポリシー策定のためのスキルではありません。新たな要件、約束、製品の動作を作り出さずに、文章を改善してください。

このスキルを適用する際は、正確で、事実に忠実で、読み取りやすく、行動に移しやすい、規律ある英語を目指してください。