kotonoha 0.1.6-dev.0 → 0.2.0

package/CHANGELOG.md

@@ -7,14 +7,31 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.2.0] - 2026-09-29
+
 ### Changed
 
+- Make Japanese prose optimization built in through kotonoha's original
+  GiNZA-based `japanese-prose` skill, installed by the default
+  `install --skill all` workflow.
 - Generate Markdown with half-width spaces around `**strong emphasis**`
   whenever the delimiters would otherwise touch surrounding prose, and flag
   violations in the structural lint.
 - Add a Qiita article template whose highest-level body sections use `#` and
   subsections use `##`.
 
+### Added
+
+- Add original GiNZA-based prose lint, reading-load analysis, terminology
+  extraction, outline inspection, scoring, baseline comparison, writing
+  guidelines, and convergence workflow without bundling third-party prose
+  skill source code.
+- Add `README-ja.md` as a complete Japanese guide and link it from the
+  English README.
+- Explain the meaning of the name `kotonoha` in both READMEs, distinguishing
+  the *Kokin Wakashu*'s explicit "leaves of words" image from the related
+  *kotodama* tradition in the earlier *Man'yoshu*.
+
 ## [0.1.5] - 2026-09-29
 
 ### Added

package/README-ja.md

@@ -0,0 +1,246 @@
+# kotonoha
+
+kotonohaは、技術文書の作成とプレゼンテーション設計を支援するGitHub Copilot CLIスキルを提供します。`tech-writer`は、開発文書、要件・設計文書、運用・移行文書、調達文書、Qiita・Zenn記事の構成と文章を整えます。対応する文書の一覧は「対応している文書」に掲載しています。`presentation-planner`は、プレゼンテーションシナリオ、スライド構成、デザイン仕様、PPTX作成スキル向けの引き継ぎ情報を生成します。
+
+[English](./README.md) | [日本語](./README-ja.md)
+
+## kotonoha（言の葉）という名前
+
+`kotonoha`は、「言葉」「言語」「和歌」を表す古典的・詩的な表現「言の葉（ことのは）」に由来します。読み手の意図を、明確で構造化された言葉へ育てるという、このプロジェクトの目的を表しています。
+
+『万葉集』との関係には補足が必要です。『万葉集』という書名を「万（よろづ）の言の葉、すなわち数多くの歌」と解釈する伝統的な説がありますが、書名の由来は確定していません。「やまとうたは、人の心を種として、よろづの言の葉とぞなれりける」という有名な表現の直接の典拠は、『万葉集』ではなく紀貫之による[『古今和歌集』仮名序](https://ja.wikisource.org/wiki/%E5%8F%A4%E4%BB%8A%E5%92%8C%E6%AD%8C%E9%9B%86%E4%BB%AE%E5%90%8D%E5%BA%8F)です。
+
+それ以前の『万葉集』にも、言葉が現実に働きかけるという近い思想が「言霊」として詠まれています。奈良県立万葉文化館の「万葉百科」では、山上憶良の[894番歌](https://manyo-hyakka.pref.nara.jp/db/detailLink?cls=db_manyo&pkey=894)や[3254番歌](https://manyo-hyakka.pref.nara.jp/db/detailLink?cls=db_manyo&pkey=3254)で確認できます。「言の葉」の歴史的な語義については、[コトバンク](https://kotobank.jp/word/%E8%A8%80%E3%81%AE%E8%91%89-503155)も参照しています。
+
+## tech-writerが解決する課題
+
+技術文書には、「文章が自然か」と「必要な情報が適切な構成で含まれているか」という別々の課題があります。kotonohaは両方の機能を同梱しています。`tech-writer`が構成と情報の完全性を担当し、独自実装の`japanese-prose`が[GiNZA](https://github.com/megagonlabs/ginza)を使って、文単位の自然さ、読解負荷、用語統一、係り受けの深さ、AIらしい反復表現を検査します。
+
+kotonohaは文書構造と技術的な不変条件を固定してから日本語表現を最適化し、構造を再検証した後にrubber-duck reviewを実施します。
+
+## 主な機能
+
+- README、設計書・ADR、APIリファレンス、PR説明・コミットメッセージ・Issue、リリースノート、ユーザーマニュアル、コードコメント、要件定義書、システム設計書、テスト計画書、運用設計書・Runbook、移行計画書、セキュリティ設計書、技術提案書、RFI・RFP、Qiita・Zenn記事の作成とレビュー
+- 文書種別ごとの推奨構成とチェックリスト
+- ID、事実、表、コード、受け入れ基準を変更せずに日本語表現を反復的に最適化する、GiNZAベースの独自`japanese-prose`文章診断
+- 文書作成後のrubber-duck reviewと、対応可能な指摘がなくなるまでの修正・再レビュー
+- `scripts/lint.py`による構造検査。見出しレベルの飛び、言語指定のないコードブロック、未解決のプレースホルダー、不審なリンク、文章に隣接した強調記号を検出
+- コミットメッセージ本文とコードコメント・docstringを除き、すべての文書種別でMarkdownを標準形式として使用
+- 日本語を主な対象言語とし、英語文書にも対応
+
+## 対応している文書
+
+| 文書種別 | 例 | Doctype |
+|---|---|---|
+| プロジェクト概要 | README | `readme` |
+| 設計判断 | 設計書、ADR、RFC | `design-doc` |
+| 要件定義 | 要件定義書、機能要件、非機能要件 | `requirements-definition` |
+| システム設計 | システム設計書、アーキテクチャ設計、詳細設計 | `system-design` |
+| テスト計画 | テスト計画書、テスト戦略、受け入れ証跡 | `test-plan` |
+| 運用 | 運用設計書、Runbook、インシデント対応手順 | `operations-runbook` |
+| 移行 | 移行計画書、データ移行、システム切り替え計画 | `migration-plan` |
+| セキュリティ | セキュリティ設計書、脅威モデル | `security-design` |
+| APIリファレンス | REST API、イベント、SDKリファレンス | `api-docs` |
+| 開発ワークフロー文書 | PR説明、コミットメッセージ、バグ報告、機能要求 | `pr-commit` |
+| リリース文書 | リリースノート、CHANGELOG | `release-notes` |
+| 利用者向け文書 | ユーザーマニュアル、手順書、チュートリアル | `user-manual` |
+| ソースコード文書 | コードコメント、docstring | `code-comments` |
+| 社内向け技術提案 | アーキテクチャ、投資、デリバリー提案 | `technical-proposal` |
+| 情報提供依頼 | RFI | `rfi` |
+| 提案依頼 | RFP | `rfp` |
+| 技術記事 | Zenn記事 | `zenn` |
+| 技術記事 | Qiita記事 | `qiita` |
+
+再利用可能なテンプレートには、README、設計判断、ユーザーマニュアル、PR説明があります。要件定義、システム設計、テスト、運用、移行、セキュリティの各文書にも対応しています。技術提案、RFI、RFP、Qiita記事のテンプレートも含まれます。すべての文書種別には、`skills/tech-writer/references/doctypes/`配下に専用の構成ガイドとレビューチェックリストがあります。
+
+## presentation-plannerの機能
+
+- 対象者、意思決定、行動喚起、プレゼンテーションの制約を定義
+- ブリーフ、対象者の理解を導くシナリオ、主張型タイトルを使ったスライド構成を生成
+- YAMLデザイン仕様とPPTX作成スキル向けの決定的な引き継ぎ情報を生成
+- 経営判断、技術説明、データ報告向けのシナリオテンプレート
+- 経営提案、技術説明、データ報告向けのデザイン仕様
+- `.pptx`の生成、バイナリ編集、レンダリング、視覚的な品質確認は専用PPTXスキルへ委譲
+
+## セットアップ
+
+### 前提条件
+
+- GitHub Copilot CLIがインストールされていること
+- tech-writerの構造lintを実行する場合はPython 3.9以上
+- 同梱`japanese-prose`の文章lint、読解負荷分析、アウトライン抽出、用語検査を実行する場合はPython 3.10以上と`uv`。GiNZA、`ja_ginza`、spaCyは初回実行時に`uv`が解決
+
+### npmからインストール
+
+パッケージをインストールし、同梱CLIでスキルをスキルディレクトリへコピーします。
+
+```bash
+npm install --save-dev kotonoha
+npx kotonoha install
+```
+
+### 同梱スキルをまとめてインストール
+
+`kotonoha install`は、まだ存在しない同梱スキルをすべてインストールします。次のコマンドは、`tech-writer`、`japanese-prose`、`presentation-planner`を`.github/skills/`へインストールします。
+
+```bash
+npm install --save-dev kotonoha
+npx kotonoha install --skill all
+```
+
+`--skill all`が既定値であるため、`npx kotonoha install`も同じ動作です。3つのスキルがインストールされたことを確認します。
+
+```bash
+test -f .github/skills/tech-writer/SKILL.md
+test -f .github/skills/japanese-prose/SKILL.md
+test -f .github/skills/presentation-planner/SKILL.md
+```
+
+いずれかのディレクトリがすでに存在する場合、既定のコマンドはそのディレクトリを保持し、不足しているスキルだけをインストールします。すべてのインストール済みスキルをまとめて置き換える場合は、ローカルのカスタマイズを確認またはバックアップしてから実行します。
+
+```bash
+npx kotonoha install --skill all --force
+```
+
+### 内蔵された日本語表現最適化
+
+kotonohaには独自開発の`japanese-prose`が同梱されるため、文章最適化スキルを別途インストールする必要はありません。`npx kotonoha install`により`tech-writer`と同じスキルルートへ配置され、GiNZAを使った文章lint、読解負荷検査、用語抽出、アウトライン検査、反復的な文章レビューをローカルで実行できます。この実装はkotonoha向けにゼロから開発しており、`natural-japanese`のソースコードを含みません。GiNZAの依存関係とライセンス情報は`skills/japanese-prose/NOTICE.md`に記録しています。
+
+既定のインストール先は、現在のプロジェクトの`.github/skills/tech-writer`、`.github/skills/japanese-prose`、`.github/skills/presentation-planner`です。スキルを1つだけインストールする場合や、別の対応ディレクトリを使用する場合は、次のように指定します。
+
+```bash
+npx kotonoha install --skill presentation-planner
+npx kotonoha install --target .claude/skills
+npx kotonoha install --target ~/.copilot/skills
+```
+
+`--skill <name>`を明示したインストールは、既存のスキルディレクトリを上書きしません。既存のインストールを確認またはバックアップし、選択したスキルを置き換える場合にだけ`--force`を指定します。
+
+```bash
+npx kotonoha install --force
+```
+
+すべてのスキルをインストールする場合、既存のスキルディレクトリはスキップされ、不足しているスキルだけが追加されます。このため、`tech-writer`だけをインストール済みの環境から安全に更新できます。
+
+```bash
+npx kotonoha install
+# Skipped tech-writer (...)
+# Installed japanese-prose (...)
+# Installed presentation-planner (...)
+```
+
+### kotonohaを更新
+
+インストール済みスキルディレクトリ内のローカル変更を、先に確認してコミットまたはバックアップします。`--force`による更新は、ローカルのカスタマイズを含む対象ディレクトリ全体を置き換えます。
+
+最新の安定版へ更新します。
+
+```bash
+npm install --save-dev kotonoha@latest
+```
+
+現在のプレリリース版を試す場合は、`next`タグをインストールします。
+
+```bash
+npm install --save-dev kotonoha@next
+```
+
+npmパッケージを更新しても、コピー済みのスキルは自動更新されません。パッケージ更新後に、同梱スキルを再インストールします。
+
+```bash
+npx kotonoha install --force
+```
+
+スキルを1つだけ更新する場合は、次のように実行します。
+
+```bash
+npx kotonoha install --skill tech-writer --force
+npx kotonoha install --skill japanese-prose --force
+npx kotonoha install --skill presentation-planner --force
+```
+
+最初のインストールで別のインストール先を指定した場合は、同じディレクトリを再度指定します。
+
+```bash
+npx kotonoha install --target ~/.copilot/skills --force
+```
+
+インストール済みパッケージのバージョンを確認し、置き換えられたファイルをコミット前に確認します。
+
+```bash
+npx kotonoha --version
+git diff -- .github/skills
+```
+
+`--force`なしで`npx kotonoha install`を実行しても既存のスキルディレクトリは更新されず、不足しているスキルだけがインストールされます。
+
+### ソースチェックアウトからインストール
+
+このリポジトリでは、スキルが`.github/skills/`配下にリンクされているため、Copilot CLIで使用するための追加設定は不要です。
+
+別のプロジェクトでソースチェックアウトのスキルを使用する場合は、スキルのディレクトリを対象リポジトリの`.github/skills/`、`.claude/skills/`、またはグローバルの`~/.copilot/skills/`へコピーします。
+
+```bash
+cp -r skills/tech-writer /path/to/your-repo/.github/skills/tech-writer
+cp -r skills/japanese-prose /path/to/your-repo/.github/skills/japanese-prose
+cp -r skills/presentation-planner /path/to/your-repo/.github/skills/presentation-planner
+```
+
+## Copilotに文書作成を依頼
+
+Copilot CLIセッションで必要な文書種別を依頼すると、対応するスキルが自動的に呼び出されます。
+
+- 「READMEを書いて」「この設計書をレビューして」「PR説明文を書いて」「この手順書を分かりやすくして」
+- 「要件定義書を作って」「承認済み要件からシステム設計書を書いて」「移行計画とRunbookを作って」
+- 「この提案書からPPTXを作って」「経営層向けプレゼンを設計して」「技術説明資料を設計して」
+
+構造だけを簡単に診断する場合は、次のコマンドを実行します。
+
+```bash
+uv run skills/tech-writer/scripts/lint.py --json path/to/document.md
+```
+
+`uv`がない場合も、標準ライブラリだけを使う次のコマンドで実行できます。
+
+```bash
+python3 skills/tech-writer/scripts/lint.py path/to/document.md
+```
+
+## リポジトリ構成
+
+```text
+skills/tech-writer/          # tech-writerスキル
+  SKILL.md                   # スキル定義
+  references/                # 構成原則、文書種別ごとの規則とチェックリスト
+  references/doctypes/       # README、要件、設計、テスト、運用、移行、セキュリティ、API、PR・Issue、リリースノート、提案、RFI・RFP、Qiita・Zenn
+  scripts/lint.py            # 構造とMarkdown表示のlintスクリプト
+  assets/templates/          # 要件、設計、テスト、運用、移行、セキュリティ、調達などの文書テンプレート
+skills/japanese-prose/       # 独自開発のGiNZAベース文章最適化スキル
+  SKILL.md                   # 執筆、lint、レビュー、収束のワークフロー
+  references/                # 執筆規則、レビューワークフロー、採点規則
+  scripts/                   # 文章lint、読解負荷、アウトライン、用語検査
+  NOTICE.md                  # GiNZAの依存関係とライセンス情報
+skills/presentation-planner/ # シナリオ、デザイン仕様、PPTX引き継ぎスキル
+  SKILL.md
+  references/                # 責任境界、シナリオ・デザインガイド、カスタマイズ、引き継ぎ契約
+  assets/scenario-templates/ # 経営判断、技術説明、データ報告向けシナリオ
+  assets/design-templates/   # 経営提案、技術説明、データ報告向けYAMLデザイン
+.github/skills/tech-writer   # Copilot CLIが読み込むskills/tech-writerへのシンボリックリンク
+.github/skills/japanese-prose
+.github/skills/presentation-planner
+```
+
+## 既知の制約
+
+- `skills/tech-writer/scripts/lint.py`は、見出し、コードブロック、プレースホルダー、リンク、Markdown強調記号などの構造・表示上の問題を検出します。文章の自然さ、語彙、リズム、読解負荷は、別工程として呼び出される同梱`skills/japanese-prose`がGiNZAで検査します。
+- 文書種別は主に日本語の技術文書作成規則を前提としています。コミットメッセージの命令形などを含む多くのガイドは、英語文書にも適用できます。
+- `presentation-planner`だけでは`.pptx`バイナリを生成または検証できません。生成と視覚的な品質確認には専用PPTXスキルが必要です。
+- デザインのカスタマイズ方法は、`skills/presentation-planner/references/customizing-design-templates.md`に記載されています。
+
+## 謝辞
+
+- [GiNZA](https://github.com/megagonlabs/ginza)（MIT License）— kotonoha独自の日本語文章診断に、形態素解析、品詞タグ付け、係り受け解析、見出し語化、文境界、固有表現抽出を提供します。
+
+## ライセンス
+
+MIT。詳細は[LICENSE](./LICENSE)を参照してください。

package/README.md

@@ -11,16 +11,40 @@ structured so readers never get lost. `presentation-planner` turns source
 material into a reusable presentation scenario, slide outline, design
 specification, and handoff for a dedicated PPTX creation skill.
 
+[English](./README.md) | [日本語](./README-ja.md)
+
+## Why the name kotonoha
+
+`kotonoha` comes from the Japanese expression 言の葉 (*kotonoha*), a
+classical and poetic name for words, language, and verse. The name reflects
+this project's purpose: helping a reader's intent grow into clear,
+well-structured words.
+
+Its connection to the *Man'yoshu* needs one qualification. One traditional
+interpretation reads the anthology's title as "countless words or poems,"
+but the title's etymology is not settled. The famous explicit image,
+"Japanese poetry takes the human heart as its seed and grows into myriad
+leaves of words," is from the
+[*Kokin Wakashu* Kana Preface](https://ja.wikisource.org/wiki/%E5%8F%A4%E4%BB%8A%E5%92%8C%E6%AD%8C%E9%9B%86%E4%BB%AE%E5%90%8D%E5%BA%8F),
+not the *Man'yoshu*. The earlier *Man'yoshu* expresses a related belief in
+the power of language through *kotodama*, including poems
+[894](https://manyo-hyakka.pref.nara.jp/db/detailLink?cls=db_manyo&pkey=894)
+and
+[3254](https://manyo-hyakka.pref.nara.jp/db/detailLink?cls=db_manyo&pkey=3254).
+The broader historical meaning of 言の葉 is summarized by
+[Kotobank](https://kotobank.jp/word/%E8%A8%80%E3%81%AE%E8%91%89-503155).
+
 ## What tech-writer solves
 
 Technical documents tend to have two separate problems: "is the prose
 natural" and "does the structure have the right amount of information".
-`tech-writer` specializes in the latter and delegates the former
-(sentence-level naturalness, reading load, terminology, and removing
-"AI smell") to a prose-polishing skill such as
-[natural-japanese](https://github.com/coji/natural-japanese). With both
-installed, kotonoha locks the structure and technical invariants, invokes the
-Japanese prose pass, then rechecks the structure before rubber-duck review.
+Kotonoha includes both layers. `tech-writer` owns structure and completeness;
+the original bundled `japanese-prose` skill uses
+[GiNZA](https://github.com/megagonlabs/ginza) to check sentence-level
+naturalness, reading load, terminology, dependency depth, and repeated
+AI-like patterns. Kotonoha locks the structure and technical invariants, runs
+the Japanese prose pass, then rechecks the structure before rubber-duck
+review.
 
 ## What it does
 
@@ -30,9 +54,9 @@ Japanese prose pass, then rechecks the structure before rubber-duck review.
   operations runbooks, migration plans, security designs, technical proposals,
   RFI/RFP procurement documents, and Qiita/Zenn articles
 - Doctype-specific structure and checklists to guide writing
-- Optional `natural-japanese` integration for Japanese phrase lint,
-  reading-load review, terminology checks, and iterative prose optimization
-  without changing IDs, facts, tables, code, or acceptance criteria
+- Original GiNZA-based `japanese-prose` lint, reading-load review, terminology
+  checks, and iterative prose optimization without changing IDs, facts,
+  tables, code, or acceptance criteria
 - Iterative rubber-duck review after document creation, with fixes and
   re-review until no actionable findings remain; unavailable reviews are
   reported as `review not performed`, while unresolved review loops are
@@ -94,10 +118,10 @@ structure guidance and a review checklist under
 ### Prerequisites
 
 - GitHub Copilot CLI installed
-- Python 3.9+ if you want to run the lint script (standard library only,
-  no extra install needed)
-- `uv` when using `natural-japanese` diagnostics such as phrase lint,
-  reading-load analysis, outline extraction, and terminology checks
+- Python 3.9+ for tech-writer's structural lint
+- Python 3.10+ and `uv` for the bundled GiNZA diagnostics such as prose lint,
+  reading-load analysis, outline extraction, and terminology checks; `uv`
+  resolves GiNZA, `ja_ginza`, and spaCy on first use
 
 ### Install from npm
 
@@ -109,10 +133,10 @@ npm install --save-dev kotonoha
 npx kotonoha install
 ```
 
-### Install tech-writer and presentation-planner together
+### Install all bundled skills together
 
 `kotonoha install` installs every packaged skill that is not already present.
-The following commands install both `tech-writer` and
+The following commands install `tech-writer`, `japanese-prose`, and
 `presentation-planner` into `.github/skills/`:
 
 ```bash
@@ -121,43 +145,37 @@ npx kotonoha install --skill all
 ```
 
 `--skill all` is the default, so `npx kotonoha install` has the same behavior.
-Confirm that both skills were installed:
+Confirm that all three skills were installed:
 
 ```bash
 test -f .github/skills/tech-writer/SKILL.md
+test -f .github/skills/japanese-prose/SKILL.md
 test -f .github/skills/presentation-planner/SKILL.md
 ```
 
-If either directory already exists, the default command preserves it and
-installs only the missing skill. To replace and update both installed skills
-at once, review or back up local customizations first, then run:
+If a directory already exists, the default command preserves it and installs
+only the missing skills. To replace and update all installed skills at once,
+review or back up local customizations first, then run:
 
 ```bash
 npx kotonoha install --skill all --force
 ```
 
-For Japanese sentence-level optimization, also install
-`natural-japanese` using one of its supported installation methods:
-
-```bash
-npx skills add coji/natural-japanese
-```
-
-Ensure the installed skill is visible to Copilot CLI in the same registered
-skill root used by this project, such as
-`.github/skills/natural-japanese` or
-`~/.copilot/skills/natural-japanese`. If the command installs it for a
-different host, follow the upstream alternative installation instructions
-and place or link the skill into a Copilot-visible skill directory.
+### Built-in Japanese prose optimization
 
-If no compatible Japanese prose-polishing skill is registered, kotonoha
-finishes the structural workflow and reports
-`Japanese prose optimization not performed` instead of claiming that the
-prose was optimized.
+Kotonoha includes its own `japanese-prose` skill, so no separate prose skill
+installation is required. `npx kotonoha install` places it beside
+`tech-writer`, allowing the writing workflow to run GiNZA-based prose lint,
+reading-load checks, terminology extraction, outline inspection, and
+iterative prose review locally. The implementation was developed from
+scratch for kotonoha and does not include `natural-japanese` source code.
+GiNZA dependency and license information is recorded in
+`skills/japanese-prose/NOTICE.md`.
 
-The default destinations are `.github/skills/tech-writer` and
-`.github/skills/presentation-planner` in the current project. To install
-only one skill, or use another supported skill directory:
+The default destinations are `.github/skills/tech-writer`,
+`.github/skills/japanese-prose`, and
+`.github/skills/presentation-planner` in the current project. To install only
+one skill, or use another supported skill directory:
 
 ```bash
 npx kotonoha install --skill presentation-planner
@@ -180,6 +198,7 @@ installation safe:
 ```bash
 npx kotonoha install
 # Skipped tech-writer (...)
+# Installed japanese-prose (...)
 # Installed presentation-planner (...)
 ```
 
@@ -212,6 +231,7 @@ To update only one skill:
 
 ```bash
 npx kotonoha install --skill tech-writer --force
+npx kotonoha install --skill japanese-prose --force
 npx kotonoha install --skill presentation-planner --force
 ```
 
@@ -244,6 +264,7 @@ into that repository's `.github/skills/`, `.claude/skills/`, or your global
 
 ```bash
 cp -r skills/tech-writer /path/to/your-repo/.github/skills/tech-writer
+cp -r skills/japanese-prose /path/to/your-repo/.github/skills/japanese-prose
 cp -r skills/presentation-planner /path/to/your-repo/.github/skills/presentation-planner
 ```
 
@@ -277,21 +298,27 @@ skills/tech-writer/          # the skill itself
   references/doctypes/       # README, requirements/design/test/operations/migration/security, API docs, PR/issue, release notes, proposals, RFI/RFP, Qiita/Zenn
   scripts/lint.py            # structural lint script
   assets/templates/          # doctype skeletons including requirements, design, test, operations, migration, security, and procurement
+skills/japanese-prose/       # original GiNZA-based prose optimization skill
+  SKILL.md                   # writing, lint, review, and convergence workflow
+  references/                # writing guidelines, review workflow, and scoring
+  scripts/                   # prose lint, reading-load, outline, and terminology diagnostics
+  NOTICE.md                  # GiNZA dependency and license information
 skills/presentation-planner/ # storyline, design-spec, and PPTX handoff skill
   SKILL.md
   references/                # boundary, scenario/design guidance, customization, handoff contract
   assets/scenario-templates/ # executive, technical, and data-report narrative scenarios
   assets/design-templates/   # executive, technical, and data-report YAML designs
 .github/skills/tech-writer   # symlink to skills/tech-writer (where Copilot CLI reads it)
+.github/skills/japanese-prose
 .github/skills/presentation-planner
 ```
 
 ## Known limitations
 
-- `scripts/lint.py` only detects structural issues (headings, code blocks,
-  placeholders, links); it does not detect prose naturalness, vocabulary,
-  or rhythm by itself. Those checks require a registered prose-polishing
-  skill such as `natural-japanese`.
+- `skills/tech-writer/scripts/lint.py` detects structural and Markdown
+  rendering issues. Prose naturalness, vocabulary, rhythm, and reading load
+  are handled by the separately invoked but bundled
+  `skills/japanese-prose` workflow and GiNZA diagnostics.
 - The doctypes are written mainly with Japanese technical-writing
   conventions in mind; most of the guidance (especially the commit-message
   imperative-mood rule) applies directly to English documents as well.
@@ -302,10 +329,10 @@ skills/presentation-planner/ # storyline, design-spec, and PPTX handoff skill
 
 ## Acknowledgment
 
-- [natural-japanese](https://github.com/coji/natural-japanese) (MIT
-  License) — the design principle "machines detect, humans (or agents)
-  judge" and "prevent at generation time rather than fix afterward"
-  informed this project's design.
+- [GiNZA](https://github.com/megagonlabs/ginza) (MIT License) — provides
+  tokenization, part-of-speech tagging, dependency parsing, lemmatization,
+  sentence boundaries, and named-entity recognition for kotonoha's original
+  Japanese prose diagnostics.
 
 ## License
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kotonoha",
-  "version": "0.1.6-dev.0",
+  "version": "0.2.0",
   "description": "GitHub Copilot CLI skills for technical writing and PPTX presentation planning.",
   "license": "MIT",
   "author": "nahisaho",
@@ -16,7 +16,8 @@
     "kotonoha": "bin/kotonoha.js"
   },
   "scripts": {
-    "test": "node --test"
+    "test": "node --test",
+    "test:ginza": "uv run skills/japanese-prose/scripts/test_engine.py"
   },
   "engines": {
     "node": ">=18"
@@ -35,7 +36,10 @@
   ],
   "files": [
     "CHANGELOG.md",
+    "README-ja.md",
     "bin/",
-    "skills/"
+    "skills/",
+    "!skills/**/__pycache__/",
+    "!skills/**/*.pyc"
   ]
 }

package/skills/japanese-prose/NOTICE.md

@@ -0,0 +1,17 @@
+# GiNZA dependency notice
+
+This skill is an original kotonoha implementation and does not include source
+code from `coji/natural-japanese`.
+
+Morphological and syntactic analysis uses
+[GiNZA](https://github.com/megagonlabs/ginza), its `ja_ginza` model, and
+spaCy. These dependencies are resolved by `uv` when a diagnostic script is
+run. GiNZA and its Japanese Universal Dependencies models are distributed
+under the MIT License. spaCy is distributed under the MIT License.
+SudachiPy and SudachiDict are distributed under the Apache License 2.0.
+GiNZA documents the licenses of its remaining dependencies and training
+datasets.
+
+The implementation targets GiNZA 5.2.x and uses token surface forms, lemmas,
+universal part-of-speech tags, dependency relationships, sentence boundaries,
+and named-entity labels.

package/skills/japanese-prose/SKILL.md

@@ -0,0 +1,108 @@
+---
+name: japanese-prose
+description: >-
+  Improves Japanese prose in technical and business documents using
+  kotonoha's original GiNZA-based diagnostics. Use when writing, rewriting,
+  reviewing, or scoring Japanese prose; when the user asks for more natural,
+  readable, concise, or less AI-like Japanese; or when tech-writer delegates
+  its sentence-level quality pass. Owns wording, sentence rhythm, reading
+  load, terminology review, and formulaic-expression detection. Does not own
+  technical-document structure or presentation storylines.
+license: MIT
+argument-hint: "[write|review|score] [quick|full] <target file or request>"
+---
+
+# japanese-prose
+
+Improves Japanese wording without changing approved facts, obligations,
+identifiers, evidence, code, or document structure. This is an original
+kotonoha implementation. It uses
+[GiNZA](https://github.com/megagonlabs/ginza) for tokenization, part-of-speech
+tagging, dependency parsing, lemmatization, and named-entity recognition.
+
+## Responsibility boundary
+
+- `tech-writer` owns doctype selection, section structure, completeness,
+  traceability, and Markdown organization.
+- `presentation-planner` owns audience strategy, scenarios, slide order, and
+  design specifications.
+- `japanese-prose` owns sentence-level Japanese: clarity, rhythm, reading
+  load, terminology, repeated patterns, and contextual rewriting.
+
+Never move, add, or remove sections unless the calling skill explicitly
+authorizes it. Never alter requirement IDs, risk IDs, control IDs, numbers,
+units, dates, proper nouns, citations, URLs, commands, tables, schemas,
+acceptance criteria, approval states, or normative force.
+
+## Modes
+
+- `write`: write or rewrite Japanese prose. Use `quick` unless the document
+  is external-facing, high-risk, or longer than roughly 10,000 Japanese
+  characters.
+- `review`: report problems and proposed corrections without editing.
+- `score`: run diagnostics and report the 0–100 score without rewriting.
+- `quick`: run prose lint once, review findings in context, edit, and rerun
+  until no new actionable findings appear.
+- `full`: run prose lint, reading-load lint, outline extraction, and
+  terminology extraction; then review the whole document against
+  `references/review-workflow.md`.
+
+## Workflow
+
+1. Read the target, audience, intended outcome, and calling skill's frozen
+   invariants.
+2. Read `references/writing-guidelines.md` before generating or rewriting
+   prose.
+3. Run the GiNZA prose diagnostic:
+
+   ```bash
+   uv run scripts/lint.py <target-file> --genre tech --json > <workdir>/prose-baseline.json
+   ```
+
+4. For `full` mode, also run:
+
+   ```bash
+   uv run scripts/lint.py <target-file> --genre tech --reading-load --json
+   uv run scripts/outline.py <target-file>
+   uv run scripts/terms.py <target-file> --json
+   ```
+
+5. Classify each finding as `fix` or `keep`. A detector identifies a review
+   target; it does not authorize blind replacement.
+6. Apply only fixes that improve the intended reader's understanding while
+   preserving the frozen invariants.
+7. Rerun the prose diagnostic with
+   `--baseline <workdir>/prose-baseline.json` to classify new, persisting,
+   and resolved findings. Replace the baseline only after recording the
+   decisions for the current round.
+8. Stop when every finding has a decision, no new actionable finding appears,
+   and the document passes the checks in `references/review-workflow.md`.
+
+Allow at most three edit-and-diagnose rounds per invocation. If actionable
+findings or invariant violations remain, report that the optimization did not
+converge and list the unresolved items.
+
+## Markdown emphasis
+
+When strong emphasis touches surrounding prose, put half-width spaces outside
+the delimiters: `これは **重要** です`, not `これは**重要**です`. Spaces are
+unnecessary at line boundaries or next to punctuation, and must not be placed
+inside `**`.
+
+## Diagnostic interpretation
+
+The score is a triage aid, not a quality certificate. Read
+`references/scoring.md` before presenting it. GiNZA provides linguistic
+observations; the agent remains responsible for deciding whether a change is
+correct in context.
+
+## Completion report
+
+Report:
+
+- mode and diagnostics executed
+- initial and final scores
+- findings fixed and findings deliberately kept
+- any skipped diagnostic and its reason
+- invariant verification result
+- `completed` or `did not converge`