japanese-tech-writinglisted

<!-- このスキルは k16shikano 氏の gist を元に改変したものです。 出典: https://gist.github.com/k16shikano/fd287c3133457c4fd8f5601d34aa817d --> # 日本語技術文書の文章規範 日本語で技術的な原稿（解説文、記事、Issue や PR の本文、README）を書く・推敲するときは、以下の規範に従う。 ## 文体（敬体・常体） このリポジトリの日本語ドキュメント（`README.ja.md` など）と GitHub Issue / PR の本文は、 敬体（ですます調）で書く。AGENTS.md や SKILL.md のような作業規範の文書は、簡潔にするため常体 （だ・である調）で書く。どちらの場合も、一つの文書のなかで敬体と常体を混在させない。敬体にするのは文末の述語だけで、連体修飾節や接続・条件の形（「〜する場合」「〜すると」 「〜であり」）は常体のままにする。見出しや純粋な体言止めのラベルには繋辞を付けない。 ## 整形 - 段落の区切りは空行で示す。 - コード、差分、ログ、設定ファイルの断片はコードブロックで示す。 - 用語の由来や定式化の名称など、本筋から一段外れる補足は、本文に並べず脚注（`[^ラベル]`）に降ろす。 - 定義や分類の列挙は箇条書きで示してよい。定義される用語は太字にする。 - 用語を本文中で初めて定義・導入するときも、その語は太字にする。すでに導入した語を話題として指すとき、引��、通称には「」を使い、太字と使い分ける（初出の定義は太字、以後の言及は「」）。 - ダッシュ（em ダッシュ `—`、horizontal bar `―`、いわゆる2倍ダッシュ「——」）を日本語の地の文・見出しで使わない。同格・補足の挿入は括弧（）に、言い換え・敷衍は句点で二文に分けるか読点でつなぐ。範囲を示す en ダッシュ `–` や英語の複合語、コードブロック・書誌情報は対象外。 - 中黒（・）を日本語の並列で使わない。ただし単一の固有名詞の内部では使ってよい。 - 見出しに、区切り線（罫線 `─` やダッシュ類）で「種別──主題」のように二要素を詰め込まない。見出しは単一の自然な句にする。 - 用語とその定義を並べる箇条書きは、区切り線ではなく全角コロンで「**用語**：説明」と書く。 ## 段落と論証の構成 パラグラフライティングを基本とする。段落は論証の一歩であり、読者は段落単位で論理を追えなければならない。 - 一つの段落には一つのトピックだけを置く。場面の進行（調査、報告、検証、評価）が複数混ざった長い段落は、一歩ずつの段落に分割する。 - 段落の最初の文を読めば、その段落が何の話かわかるようにする。 - 段落の先頭では、前の段落との論理関係を接続表現で明示する。 - 論証は一方向に進める。結論を出してから反論を処理し、結論を言い直す構成にしない。反論と疑念の処理を終えてから、結論を一度だけ置く。 - 読者が立てそうな誤った解釈は、明示的に否定してから本当の理由を述べる（「その理由は『〜だから』ではない。〜だからだ」）。 - 「AではなくB」と否定するときは、否定の根拠を一文添える。 - 譲歩（「確かに〜」）では、事実の確認にとどめる。あとで訂正する内容を著者の声で因果として断定すると、自己矛盾になる。 - 何かを否定・限定するときは、否定する命題そのものを「」で正確に書き出す。漠然とした否定で済ませない。 ## 論