Back to skills
SKILL.md
Decisions
ASecurityaccepted (2026-08-18)
- 9 stars
- 0 votes
- 0 copies
- 3 views
- Added September 3, 2026
Security analysis
100/100Pro scans all 13 files and shows the line behind each finding
npx -y skills add berlysia/dotfiles --skill decisions --agent claude-codeAre you the author of Decisions?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/berlysia-decisions)# ADR-0012: 文体規範ハブスキル berlysia-writing と、規範を測定対象として扱う構造
## Status
accepted (2026-08-18)
## Context
日本語の文章を書く際に発火しうるスキルが 4 つ並存していた。`japanese-tech-writing`(整形・論証・冗長排除、公開 `.skills/`)、`cognitive-rhythm-writing`(拍・密度波形・駄文判定、公開 `.skills/`、`japanese-tech-writing` を「併用する規範」として参照する階層を既に持つ)、`berlysia-style`(blog の「だ/である」調、private-skills)、`berlysia-slide`(スライド文体、private-skills)。どれが発火するかは description のマッチ次第で、工程は無い。
一方、同人誌プロジェクト CPK-C108 の `notes/prose-style.md`(470 行)に、実測ベースの文体規範が蓄積されていた。これは他のプロジェクトへ持ち出せず、癖の検出は毎回 grep を手で組み直していた。
発端はオーダー「berlysia流テキスト表現SKILLを構築したい。CPK-C108 の作業結果と `coji/natural-japanese` の SKILL.md を悪魔合体できないかな。あと技術文書のリズムのスキルとか」。セッション内でユーザーが「ハブ型構成」「工程 + 検査スクリプトを bun/TS で自作」「配置先は private-skills」を確定した。
素材を読むと、三者は同じ層の規範ではなく空白を互いに埋める三層だった。`natural-japanese` が持つのは工程(設計 → 執筆 → 検査 → 収束)であって規範の中身は薄く、既存 2 スキルが持つのは規範であって工程は無く、`prose-style.md` が持つのは規範を作り直す方法論であって規範そのものではない。
## Analysis
検討案:
- **差分最小案(reject)**: `prose-style.md` の癖カタログを `berlysia-style/SKILL.md` の Vocabulary/Avoid セクションへ追記する。新スキルを作らず 4 スキルの並置を維持する。変更は 1 ファイルで済む。→ 3 点で reject。(a) `berlysia-style` の Canon は URL 参照のみで本文実体を持たず、「書くときにその場で数える」が実行できない。(b) `berlysia-style` は「だ/である」調の blog 専用で、C108 由来の癖は敬体の分析文で測られており、レジスタが違う規範を 1 ファイルへ混ぜると適用範囲が不明になる。(c) `cognitive-rhythm-writing` が既に階層参照を持つため、ハブを足すのは新構造の導入ではなく既存構造の 1 段上への延長にすぎない。
- **白紙設計案(採用)**: 工程(いつ測るか)、方法論(どう測るか)、規範(何を守るか)を縦に積み、下の層が上の層を差し替え可能にする。そのうえでカタログと再測定ループを別々の成果物にせず、カタログの各項目が「いつ・何に対して・どのバージョンの計測器で検証したか」を自分で持ち、その検証を機械が再実行でき、再実行の結果が工程の完了条件に接続される形にする。
この選択の origin は `prose-style.md` が記録している 2 つの事故にある。ひとつは許可リスト事故で、「逆に使ってよい」と据え置いた語の根拠が改稿で消えていたのに測り直さず、草稿で「こしらえる」が 5 箇所まで増殖した。もうひとつは自己増殖で、Claude が起草した節題の型が規範へ昇格し、第三部で著者本文の 2.4 倍の密度になった。
**2 つの事故はどちらも「項目を書いた時点」と「コーパスが変わった時点」のあいだの未検知 drift であって、書くときの記述精度の問題ではない。** したがって出典を書かせる作成時ルールでは防げない。さらに、検知しても報告が読まれなければ結果は同じである(どちらの事故も「気づかなかった」ことが直接の原因)。
この構造的欠陥は、設計層レビュー 2 ラウンド(各 7 名)で 2 度にわたり独立に指摘された。Round 1 では 4 名(logic-validator / greenfield-perspective-reviewer / data-integrity-guardian / scope-justification-reviewer)が別々の観点から「K1 は canon について複製すると鮮度が壊れると判断したのに、癖カタログには同じ原則を適用していない」という同一の結論に到達した。Round 2 では 3 名(greenfield / architecture-strategist / data-integrity-guardian)が「監査が drift を検出した後の処置フローが未定義で、Goal が言う『機械検証で担保する』が『検出して報告する』に留まっている」と指摘した。いずれも初版の spec が事故を説明はしていたが構造としては再現していたことを示す。
## Decision
1. **ハブは規範を複写せず、規範軸と測定軸の 2 軸で委譲する(K2)**: `blog` は `berlysia-style`、`slide` は `berlysia-slide`、`tech` は `japanese-tech-writing` + `cognitive-rhythm-writing` へ委譲する。`analysis`(敬体の分析文)のみ委譲先が存在しないためハブが規範本体を持つ。1 軸委譲にすると規範の委譲先が持たない測定を受け取れないプロファイルが生じるため、規範(何を守るか)と測定(何を数えるか)を別の表で解決する。canon の充足状況は委譲表に書かず `canon/INDEX.md` を唯一の情報源とする。
2. **canon は複製せずプロファイル別のパス参照とし、別プロファイルの基準値で代用しない(K1)**: 複製した瞬間に「用例は改稿で消える。書くときにその場で数える」が成立しなくなる。glob が解決しなければ同じプロファイルのスナップショット値を使い、該当プロファイルの基準値が無ければ「基準比較はできない」と報告して測定値だけを提示する。
3. **癖カタログの各項目は 7 要素を必須とする(K3)**: 出典 / 適用範囲 / 判定基準 / 言い換え / 最終検証日 / 検証時カウント / 計測器バージョン。後ろ 3 つが再測監査の入力になる。計測器バージョンを持つのは、再測で値が動いたときに「コーパスが変わった」のか「計測器を直した」のかを区別するため。C108 の比喩体系に依存する項目(名札 / 席 / 当てるの分担、章ごとの所有語彙)は一般化せず C108 側に残す。
4. **監査はコストクラスで 2 本に分け、安価な検査は全モードで走らせる(K8)**: 除外の基準は実行時間の実測ではなく、コーパスを走査するかどうかという入出力の性質で決める。`audit-static.ts`(7 要素欠落 / 記法違反 / 委譲先の実在 / 鮮度の日付比較)は quick を含む全モードで走り、`audit-remeasure.ts`(検証時カウントの再測)は full と明示呼び出しのみ。再測は項目の適用範囲に含まれる全プロファイルの canon に対して個別に行う。
5. **監査の出力を判断台帳へ流し、未処置のまま工程を閉じない(K5)**: audit が報告した drift は文書の finding と同じ 5 列の台帳(出所 / 対象 / 内容 / 処置 / 理由)へ起こす。drift の処置は 3 分岐(カタログを更新 / コーパスの変化として受け入れる / 計測器の変更として扱う)で、判定材料は計測器バージョンの一致。これが無いと「検出して報告する」に留まり、2 つの事故の直接原因である「気づかなかった」が再発する。
6. **出典は行番号ではなく引用文とコミットハッシュで持ち、原稿本文を引かない(K3・K10)**: 行番号は元ファイルの編集で無言でずれる。引用してよいのは `notes/prose-style.md` の規範記述に限り、コーパスの原稿本文は引かない。未公開稿の断片が `~/.codex/skills/` へ同期される経路を作らないための制限で、`出典` と `言い換え` の両フィールドに課す。
7. **既存 4 スキルのファイルは変更しない(K6)**: ハブは rewrite / check の出力形式を持たず、工程・検査・プロファイル解決に徹する。`japanese-tech-writing` と `cognitive-rhythm-writing` は chezmoi 公開リポジトリにあり、ハブ(private)のために公開側を書き換えると private の都合が公開物へ漏れる。
8. **配置は private-skills、スクリプトは依存パッケージゼロの bun + TypeScript(K7)**: 個人の癖カタログと実測コーパスのパスを含むため公開 `.skills/` には置かない。`berlysia-style` / `berlysia-slide` と同じリポジトリに置き、rsync の private overlay で `~/.claude/skills/` と `~/.codex/skills/` の両方へ展開する。正規表現と文字列処理だけで実装するため `node_modules` を要求しない。
## Consequences
**正**:
- 癖カタログが CPK-C108 の外へ持ち出され、blog・技術文書へも適用できるようになった。実測では `analysis` と `blog` の両プロファイルで 12 項目のカウントが取れている。
- 規範が古びたことを機械が検出する。`audit-static.ts` は形式欠落・参照切れ・鮮度を全モードで、`audit-remeasure.ts` はコーパスに対する再測を full モードで報告する。
- Python 実装からの移植が値を保存した。同じ標本で文数 515(基準 515)、平均文長 42.625 字(基準 42.6)、読点per文 1.229(基準 1.23)、読点間 18.571 字(基準 18.6)、8 字以下区切り 10.976%(基準 11.0%)。
- `tech` プロファイルの予備測定から、箇条書き主体の文書では `tempo.ts` が測定として成立しないことが判明した。句点がほとんど無い文書では全体が 1 文として数えられる。また ADR の 8 字以下 2.6% と規範文書の 29.4% はどちらも `analysis` の基準 11.0% から外れるが、それは基準を持ち込んだことによる誤判定であって文章の欠陥ではない。K1 の「別プロファイルのスナップショット値は使わない」が守っているのはこの誤りである。
**負・限界**:
- 一般化した項目の SSoT は `quirks.md` 側へ移したが、CPK-C108 の `notes/prose-style.md` への graduation 明記は本オーダーのスコープ外として別作業に残した。それまで両ファイルの drift を検知する機構は無い。
- 作業ファイルの削除は工程側の手続きであり機構的強制ではない。配置を専用サブディレクトリに固定して削除を 1 コマンドに単純化したが、実行そのものは honor-system である(ADR-0011 の Phase 1 と同型の限界)。
- `manual-checklist.md` とスクリプトの対応検査は項目 ID の存在までで、記述内容と判定ロジックの意味的一致は検証しない。自然言語と実装の等価性は機械判定できないため恒久的に非提供とし、限界をファイル冒頭に明記した。
- `canon/INDEX.md` はコーパスの絶対パスを持ち `~/.codex/skills/` へ同期される。露出するのはパス文字列と集約統計値と規範記述の引用に限られ、原稿本文は複写されないが、`berlysia-style` が URL 参照のみだった境界からは広がっている。
- スコアモード(自然度の数値化)は非提供とした。canon が揃っているのは `analysis` のみで、blog は 6 本、tech と slide は基準値そのものが無い。この段階で合成すると重み付けの根拠を持てない。
**プロセス上の知見**:
- レビュアーが実際にコードを実行したことが最も効いた。実行層レビューで `logic-validator` が plan のテスト期待値を Node で再現し、テスト入力の文字数の見積もり誤りを検出した。以後、plan に書いた期待値はすべて実行して確認する運用に切り替えた。
- subagent へ「テスト期待値を実測に合わせて書き換えない」と制約したことで、実装フェーズでも plan 側の誤りが検出された。書き換えを許していれば静かに修正され、誤りに気づかないまま進んでいた。
- 「検証済みの範囲」を正直に限定して書いたことが安全装置になった。plan の Approval に検証済みタスクを明示列挙していたため、そのリストに含まれない期待値を subagent が「未検証」と判断できた。全部検証したと書いていれば実装のほうを疑ったはずである。
## 関連
- 実装: `~/.local/share/private-skills/berlysia-writing/`(private リポジトリ)
- 規範の出所: CPK-C108 の `notes/prose-style.md` と `notes/style-review-protocol.md`(private リポジトリ)
- 工程の出所: <https://github.com/coji/natural-japanese>
- 委譲先: `.skills/japanese-tech-writing/`、`.skills/cognitive-rhythm-writing/`、private-skills の `berlysia-style` と `berlysia-slide`
- 配置経路: `home/.chezmoiscripts/run_after_sync-skills.sh.tmpl` の private overlay
Files in this skill
- 0001-document-workflow.md
- 0002-hooks-typescript-bun.md
- 0003-document-workflow-enforce.md
- 0004-greenfield-perspective-reviewer.md
- 0005-always-on-reviewers-ssot.md
- 0006-document-workflow-two-layer.md
- 0007-superpowers-process-discipline.md
- 0008-document-workflow-feedback.md
- 0009-document-workflow-mechanical-lane.md
- 0010-context-md-mechanism.md
- 0011-autonomous-lane-charter.md
- 0012-berlysia-writing-hub-skill.md
Attribution
Comments
Loading comments…
Newsletter
Get the weekly list of safe new skills, and the ones we pulled.