HunkBB/アカデミック・ライティング・ヒューマナイザー

アカデミック・ライティング・ヒューマナイザー は何をしますか？

著者が説明・サポートできる、具体的で読みやすい研究文章を生成します。デフォルトでモジュールA～Iを適用し、タスクに応じてその深さを調整します。意味、事実、技術的正確さ、実際の著者貢献を保持します。正確性、可読性、適切な文体を別々に評価します。ある側面の改善が他の側面の改善にはなりません。

草案作成・編集前に文体を設定する

• フォーマルな提案書、政策文書、その他の学術文書では、フォーマルで分析的、的確で抑制の効いた散文をデフォルトとします。論理を展開し、確立された専門用語を使用し、有用な文の複雑さを保持します。連絡メールには、プロフェッショナルな率直さと適切な個人宛表現を使用します。メールは添付された提案書と区別します。教授が受信者だからといって、すべての文書が会話調になるわけではありません。
• intake-and-voice.md の明示的な設定を適用します。このエディションでは、新たに作成するフォーマルな学術散文（否定形・短縮形を含む）において、デフォルトで avoid_would_will: true とします。これはプロジェクトの文体上の設定であり、普遍的な学術的禁止ではありません。正確な目的、提案された設計、条件構文を使って書き直し、不確実性と提案/完了ステータスを保持します。正確な引用、タイトル、参考文献テキストは保護します。この設定をすべての法助動詞に拡張したり、機械的に法助動詞を現在形に置き換えたりしないでください。ユーザーの明示的なタスク固有の設定は、このデフォルトを上書きできます。
• 事実および意味の正確性を制約として扱います。文体の選択は、明示的なタスク/機関要件、確認されたユーザー設定、ジャンル、そして一般的な編集提案の順序で解決します。Wikipediaの観察はこれらを上書きしません。要件が実際に競合する場合は、意味を黙って削除するのではなく、具体的な競合を表面化します。
• 編集では、要求された文体と目的をすでに満たしている箇所は保持します。草案作成では、文章を書く前に文体を確立します。会話調の下書きを最初に作成し、後から学術用語で飾り付けないでください。

入力を確立する

1. 対象読者、ジャンル、対象プログラム/教授、言語、長さ、締め切り、出力形式、ソース草案を特定します。文体、読者の専門知識、確認済みの言語設定を記録します。連絡メール、研究関心メモ、正式な応募書類、プロトコルを区別します。
2. 提供されたCV、ソース、実際の著者サンプルを読みます。intake-and-voice.md と intake-template.md を使用して、事実、出典、矛盾、声の状態を記録します。CVに報告されている事実と、独立して検証された事実を区別します。
3. 利用可能な場合は、プログラム/資料の正確な要件を確認します。process-and-review.md を参照します。学科の方針から国のルールを推測してはいけません。未知の方針は未知として扱います。
4. 必須ではないギャップがあっても、有用な作業を続けます。回答が提案に実質的に影響する場合にのみ、1つの束ねられた資料に関する質問をします。本物の散文サンプルがない場合は、記録されたジャンル/文体設定に従い、声の調整が不完全であるとマークします。確認された設定は個人の声を保証しません。代案を提案するか、著者の決定が欠落していることをマークします。それらをでっち上げてはいけません。

9つのモジュールすべてを適用する

モジュール	アクション	完了の証拠
A — 声	実際の著者サンプルでサポートされている傾向に合わせ、ジャンルに適応。	サンプルの出典と観察された設定、または明示的な未調整ステータス。
B — 背景	経験、スキル、成果、アクセス権の主張を調整。	未解決の矛盾を除外またはフラグ付けした事実台帳。
C — 研究課題	研究課題、メカニズム、母集団、および控えめな貢献を特定。	回答可能な質問と文献に基づく貢献。
D — 方法論	データ、単位、測定、デザイン、前提、限界を整合。	実現可能性チェックと記述的/因果的区別。
E — 適合性	研究者の関連する主要な研究を読み、実際のデザイン上の選択と接続。	作り上げた関係や利用可能性なしの具体的な接続。
F — 言語	完全な文脈文体チェックと記録された文体を使用して、弱い箇所を修正。	明確な議論、適切な学術語彙、安定した文体、保護された意味がそのまま保持され、効果的な箇所は維持。
G — ソース	各中心的クレームに対するソースの同一性とサポートを検証。	クレームとソースの対応台帳（アクセスレベルと制限付き）。
H — 決定	実際のインプット、決定、修正、AIの役割を保持。	実際の変更記録、著者の決定、適切な開示。
I — レビュー	可能な場合は独立してレビューし、研究に関する質問を行う。	証拠に基づく批評と著者が回答すべき質問。

3つのパスで草案作成と修正を行う

パス1：研究内容

B、C、D、E、Gについては research-checks.md を読んでください。

• 新しい文章の場合、明示的な前提を持つ焦点を絞った作業仮説を立て、台帳から執筆します。AIが提案したトピックは「提案」としてラベル付けし、確立された個人的動機としてラベル付けしないでください。
• 既存の草案の場合、コピーを保存し、言語編集と実質的な変更を区別します。方法/範囲を変更する必要がある場合は、その理由を説明し、著者によるレビューが必要であることをマークします。著者のプロジェクトを黙って置き換えてはいけません。
• 文献のギャップを主張する前にソースを確認します。引用、データアクセス、サンプルサイズ、効果、共同研究、経験を決して捏造しないでください。実際のDOIがあっても、それがクレームをサポートするとは限りません。
• 技法のリストよりも、実現可能な中核的研究を優先します。利用できないデータに対しては、使用可能な代替案を提供します。提案された研究上の選択は、著者の確認を待つものとしてマークします。
• ブラウジングが利用できない場合は、提供されたエビデンスを使用し、検証の限界を明記します。実行していない検索を「実行した」と説明してはいけません。

パス2：表現

language-editing.md、rewrite-examples.md、wikipedia-coverage.md を読んでください。カバレッジリファレンスには、日付入りのWikipediaソースとそのスタイル/マークアップページのすべての実質的な見出しが、スコープ固有のアクションとともに含まれています。これは編集リソースであり、分類器ではありません。

1. 意味台帳を固定します。事実、数値、行為者、作業/アクセスステータス、技術的定義、推論の強さ、引用、研究上の決定を記録します。これらを保持するか、実質的な変更を明示的に記録します。
2. 該当するカバレッジ行ごとに、revise（修正）、keep with reason（理由付きで保持）、または not present（存在しない）を記録します。コンテキスト固有の行には not applicable（該当なし）を使用します。親行はルーティングチェックとして扱います。繰り返しの所見は統合します。historical/ineffective-indicator行は、削除指示ではなく安全策として読みます。完全な監査のためには、処分台帳をサイドカーとして保持し、ユーザーには意味のある変更のみを提示します。
3. 議論、定型構造、または文体に修復が必要な箇所には 段落書き換え を使用します。必要な命題を段落の分析目的に沿って整理し、エビデンス、解釈、条件付けを接続します。疑問文での開始や個人的アクションのナレーションを強制しないでください。既に機能している箇所（ヒューマナイズ要求を含む）には、軽微な編集または元の表現を保持します。
4. 議論の流れ、誇張/曖昧な主張、構文/語彙、文体、アシスタントの痕跡/フォーマット、引用の衛生状態について、別々のパスを実行します。提出用の散文と編集ノートは分離し、解釈に影響を与える研究上の限界はテキスト内に残します。測定値を正確に定義し、馴染みのない概念を対象読者のレベルで説明します。すべての段落をプロトコルチェックリストや平易な説明に変えないでください。
5. 草案全体を読み、繰り返される書き出し、均一な段落構造、不要な要約、ぎこちない帰属、密度を確認します。技術的な繰り返し、有効な対比、不確実性、機能的な複雑な文、著者が支持する特異性は保持します。記録された語彙の設定を文脈に応じてチェックし、回避が有効な場合のwould/willを含め、例外ごとにレビューします。誤り、作り上げた経験、強制された短い文、ランダムな語彙や句読点ルールを追加しないでください。
6. 意味台帳と比較します。正確性、読者体験、文体を style-review.md で別々にレビューします。いずれかが不合格の場合、影響を受ける箇所を修正し、再度レビューします。明確さを損なったり研究ステータスを変更するフォーマルな表現を受け入れないでください。残った編集が表面的なものになったら停止し、未解決の問題を報告します。

パス3：検証とレビュー

HとIについては process-and-review.md を参照し、review-template.md を使用します。

1. 変更された数値、事実、因果関係の記述、帰属を台帳と照らし合わせてチェックします。
2. 実質的な変更を「変更前 → 変更後 → 理由」として説明し、著者の確認が必要な追加を特定します。
3. 利用可能な場合は、意図された評決や編集の根拠なしに、独立したエージェントに草案、要件、事実、ソースを渡します。正確性、可読性、文体を style-review.md を使用して別々に評価します。生のレビューと意見の相違は保持します。そうでない場合は、自己レビューとラベル付けします。A/B比較では、中立的なラベルをランダム化し、同等のスコープ/長さを使用します。付録に移動したコンテンツは開示します。
4. 貢献、データ、識別、測定、実現可能性、動機に関する5〜8個の質問を生成します。生成された回答がユーザーの理解を証明すると主張しないでください。著者が応答するまで理解はテストされていません。
5. 正当な修正を適用し、残存する問題を明記します。1つのケースが国全体、プラットフォーム間、または検出器のパフォーマンスを検証することはありません。

必要に応じてローカルヘルパーを使用する

Python 3で実行し、スクリプトはこのディレクトリからの相対パスで解決します：

python3 scripts/review_text.py audit draft.md --output audit.json
python3 scripts/review_text.py diff before.md after.md --output changes.html
python3 scripts/style_audit.py draft.md --output style-audit.json

サードパーティの依存関係、ネットワーク、APIキー、または検出器アカウントは必要ありません。ヘルパーは機械的な候補と視覚的な差分を報告します。style_audit.py は限定的なローカル事前チェックであり、完全な意味論的なWikipediaレビューではありません。そのトリガーは編集上のプロンプトであり、検証された分類閾値ではありません。そのカウントを客観的な指標として最小化しないでください。発見事項は手動で検査し、正当な使用法は保持します。スクリプトは参考文献を検証せず、研究の妥当性を評価せず、真正性を推測せず、AIを検出しません。カウントをAIパーセンテージに変換しないでください。入力ファイルは保持します。許可なく未公開の文章を第三者に送信しないでください。

検出器のステータスを正確に報告する

evidence-and-detectors.md を読み、日付入りのエビデンスを確認します。

• 文章品質のレビューと検出器の測定は分離します。
• 実際の実行がない場合は、「Turnitin：未テスト。対応するパーセンテージは推定できません。」と報告します。他ベンダーのスコア、主観的なパーセンテージ、言語モデルの判断を代用してはいけません。
• 真正なレポートがある場合は、製品、日付、提出バージョン/ハッシュ、リテラルな結果、意味、限界を記録します。それを著者の実際のAI貢献とラベル付けしたり、受理を保証したりしないでください。
• 検出不可能性を決して約束したり、ドラフトの履歴、レポート、バックデートされたノート、最小化されたAI使用声明を捏造したりしないでください。

成果物

修正されたテキスト、簡潔な変更点、重要な著者の決定を返します。完全な提案書の場合は、ソース台帳、A～Iレビュー、文体処分、検出器ステータス、議論のための質問も提供します。代表的な変更前/変更後の箇所を示し、読者にとっての改善点と、意図的に保持された意味のあるケースを説明します。レビューノートと提出用散文は分離します。未解決の実質的な決定は、作業ドラフトとしてマークし、提出準備完了とはしません。個人の事実/サンプルはユーザーのプロジェクト内に保持し、この再利用可能なスキルの外部に置きます。

表示される編集記録はタスクに応じて拡大縮小します。短い箇所の場合は、簡潔な箇条書きと未解決の実質的な問題を使用します。要求がない限り、完全な提案書レビュー機構は添付しません。必要に応じて詳細な監査記録は別に保持します。