何を見つけたか
設計工程は design → document-restructuring → pr → cross-review の順で、markdown-writing のセルフチェックと document-restructuring の 4 段を通すことになっている。しかし、通したことは progress-tracking の記録でしか分からず、通した結果の検査が無い ため、規約に反する文書がレビューを通り抜けて develop に入っている。
例 1: issues/issue-624-478-648-design.md（PR #667 、2026-09-15 マージ）
見たもの
結果
## 進行 の記録設計 14:11 / ドキュメント再構成 14:11 / ドキュメントレビュー 14:11 と 3 工程が同じ分に記録 されている
PR #667 の本文・コメント・6 コミット
「再構成」「平均文長」「最長文」「セルフチェック」の語が 0 件。前後の値の表が無い
markdown-writing ルール 1（説明文に識別子を持ち込まない）決定の見出し 19 件のうち 11 件 が識別子（support / review_assign / --exclude / $ONLY / resume_changes / None）を主語・目的語に持つ。コードブロック外で識別子を含む説明文は 98 行
セルフチェックの grep（検討痕跡・強い否定・装飾・曖昧な断定・多義語）
0 件
再構成の工程は記録されたが実施された痕跡が無く 、markdown-writing のルール 1 は守られていない。cross-review（codex / agy / kiro）もこれを指摘していない。
supervisor は document-restructuring の前後の値（平均文長・最長文・結論の位置）を報告しており、こちらは実施の痕跡がある。しかし markdown-writing のルール 1 は同じ形で破られている。
設計文書
識別子を含む見出し
識別子を含む説明文の行（コードブロック・表を除く）
issue-729-619-584-design.md18
31
issue-727-687-478-664-648-design.md17
23
issue-732-624-706-design.md9
35
issue-728-647-592-553-design.md17
36
4 本とも cross-review は収束（approved）している。
どこで見つけたか
マイルストーン 13 の設計 PR の承認の関門。利用者が issues/issue-624-478-648-design.md を開いて「色々違反」と指摘し、「設計工程では /ndf:markdown-writing と /ndf:document-restructuring を通すことになっていますが、通っていましたか？」と問った。conductor は記録からは「通した」としか言えず、実物を見て初めて「通っていない」と分かった。
直さないと何が起きるか
修正レイヤー
場所
いまの形
何が足りないか
plugins/ndf/skills/markdown-writing/SKILL.md「書き終えたらセルフチェック」grep の候補を人が見て判断する。ルール 1 の grep（[a-z]+_[a-z0-9_]{2,}）は候補であって合否ではない
見出し（#）の行に識別子があるときは合否として扱う判定が無い。実行結果をどこにも残さない
plugins/ndf/skills/document-restructuring/SKILL.md「報告」段 4 の表を「報告に載せる」
載せる先が定まっていない（会話の中で消える）。PR 本文か設計文書の末尾に残す規約が無い
plugins/ndf/skills/design/SKILL.md と references/design-template.md決定の見出し ### 決定 N: {結論を 1 文で}
見出しは業務用語で書き、識別子は本文の括弧書きに置くという規約が無い
plugins/ndf/skills/progress-tracking工程に入った時点で記録する
工程を出た ときの成果（検査の結果）を持たない。入った記録だけで「通った」と読まれる
plugins/ndf/skills/development-workflow/references/agent-layers.md「持ち場の報告」最後に記録した工程再構成の前後の値とセルフチェックの結果を報告の項目に持たない
CI（.github/workflows/）
pr-body-decisions / check-doc-line-limit / check-markdown-links / check-doc-staleness設計文書の見出しの識別子・前後の値の有無を見る検査が無い
採る手
通過の判定を記録から検査結果へ移す （move_responsibility）。
markdown-writing のセルフチェックのうち機械で合否を出せるもの（見出し行の識別子・禁止表現の grep）をスクリプトにし、設計 PR の CI に足す。候補と合否の線は Skill が決める（見出しは合否、本文は候補）document-restructuring の段 4 の表を PR 本文の節（例: ## 再構成の前後）へ書く規約にし、pr-body-decisions.sh と同じ位置で有無を検査するdesign/references/design-template.md と decisions.md に「見出しは業務用語、識別子は本文の括弧書き」を書く（設計工程: 設計 PR と設計文書のタイトルが仕組みの語だけで、承認する人が目的を読めない → 目的（今の問題と直した後に成り立つこと）をタイトルと最初の章に置く規約を工程に入れる #785 agent-layers.md の持ち場の報告（設計）に、セルフチェックの結果と前後の値の置き場所を項目として足す既存の issues/issue-624-478-648-design.md と 4 本の設計文書（cross-review: 利用上限で止まった担当が「結果ファイル無し」と報告されて空振りの起動し直しで待たされ、止めた担当が後から結果を書く → 上限を理由に報告して同じラウンドで起動し直さず、止めた後は書かせない（#729 #619 #584） #781 cross-review / cross-refactoring: 参加する CLI が 1 者でも使えないと収束ループを開始できず、再開で渡した引数が黙って無視される → 使える者だけで開始し、cross-review は毎ラウンド 2 席を確保し、再開で渡した引数は反映されるか反映しないと知らされる（#727 #687 #478 #664 #648） #782 cross-review: 誤りを示されていない重大な指摘が数えられずに承認で終わる → 数えない指摘を棄却と軽微な指摘に限る（#732 #624 #706） #783 cross-refactoring: 実装担当が結果を残さないと同じ群が上限なしに開き直され、未検証のコミットが残る → 結果なしを取り込みの 1 か所で受けて取り消し、群が開いた回数と結末で開き直しを決める（#728 #647 #592 #553） #784
1 と 2 は「記録が無いことは通っていないことと同じではない」の原則を保つ。 拒否ではなく、検査の結果を PR 上に見える形で残し、承認する人が読めるようにする。
完了条件
由来
マイルストーン 13 の承認の関門での利用者の指摘（2026-09-19）。
🤖 Generated with Claude Code
追記（2026-09-19）: supervisor が Skill を読んでいたかの記録
4 本の設計の supervisor の会話の記録（JSONL）から Skill ツールの呼び出しと SKILL.md の読み取りを抜き出した。
束
markdown-writingdocument-restructuringセルフチェックの grep の実行
読み方
G3 #781
読んだ
読んだ
13 回
Skill ツール。それでも識別子を含む見出し 18 件が残った（grep のヒットを「候補」として通した）
G1 #782
読んでいない 本文だけ読んだ
0 回
他の Skill も Skill ツールでなく cat / sed で SKILL.md を読んだ
G2 #783
読んでいない 読んでいない 0 回
読んだのは design/SKILL.md と progress-tracking/SKILL.md だけ。再構成の値は測って記録した
G4 #784
読んでいない 読んだ
0 回
他は Skill ツールで読んだ
分かったこと
design の工程表に「markdown-writing を呼ぶ」が無いため、3 本の supervisor は読まずに設計文書を書いた。document-restructuring の段 3 が markdown-writing を呼ぶと定めているが、その段そのものを飛ばした supervisor（G2）は到達しないbypass の権限モードでは「Read の代わりに Bash の cat」を使う指示が出るため、SKILL.md を cat で読む supervisor が出る。Skill ツールの呼び出しの記録から工程を数える skill-stats は、この読み方を拾えない
読んだ supervisor（G3）でもルール 1 は守られていない。grep の結果が「確認の候補」で、見出し行のヒットを合否にしていないため
採る手への追加
design/SKILL.md の工程表に markdown-writing の読み込みとセルフチェックの実行を明記する（document-restructuring 経由に頼らない）3 層の起動の指示（agent-layers.md）に「工程の Skill は Skill ツールで読み込む。cat で代用しない」を書く。記録から通過を数える側（skill-stats）と読み方を揃えるため
追記（2026-09-19）: mermaid の描画エラーもレビューを通り抜けた
利用者が PR #781 の設計文書を GitHub で開き、構成要素図が「Lexical error on line 20. Unrecognized text.」で描画されないと指摘した。原因は subgraph cross-refactoring（G4 が実装） のように、subgraph の題名へ括弧を含む文字列を引用符なしで置いたこと。書き直しの担当も cross-review の 3 者も気づいていない。
機械で見られる。 mermaid（npm）を jsdom の上で読み込み mermaid.parse() を呼ぶと、GitHub と同じ文言のエラーを再現した。4 本の設計 PR の mermaid 20 個を通したところ、壊れていたのはこの 1 個だけで、直した後は 20 個とも通る（subgraph CR["cross-refactoring（G4 が実装）"]、PR #781 のコミット 98292ea
採る手への追加
設計 PR の CI に mermaid の構文検査を足す（Markdown から ```mermaid ブロックを抜き、mermaid.parse() で解析する。描画までは要らないので puppeteer は使わない）
markdown-writing/01-diagram-guide.md に「subgraph の題名と node のラベルに括弧・記号を含めるときは id["題名"] の形で引用符で囲む」を足す
何を見つけたか
設計工程は
design→document-restructuring→pr→cross-reviewの順で、markdown-writingのセルフチェックとdocument-restructuringの 4 段を通すことになっている。しかし、通したことはprogress-trackingの記録でしか分からず、通した結果の検査が無いため、規約に反する文書がレビューを通り抜けてdevelopに入っている。例 1:
issues/issue-624-478-648-design.md（PR #667、2026-09-15 マージ）## 進行の記録markdown-writingルール 1（説明文に識別子を持ち込まない）support/review_assign/--exclude/$ONLY/resume_changes/None）を主語・目的語に持つ。コードブロック外で識別子を含む説明文は 98 行再構成の工程は記録されたが実施された痕跡が無く、
markdown-writingのルール 1 は守られていない。cross-review（codex / agy / kiro）もこれを指摘していない。例 2: 2026-09-19 の設計 PR 4 本（#781 #782 #783 #784）
supervisor は
document-restructuringの前後の値（平均文長・最長文・結論の位置）を報告しており、こちらは実施の痕跡がある。しかしmarkdown-writingのルール 1 は同じ形で破られている。issue-729-619-584-design.mdissue-727-687-478-664-648-design.mdissue-732-624-706-design.mdissue-728-647-592-553-design.md4 本とも cross-review は収束（
approved）している。どこで見つけたか
マイルストーン 13 の設計 PR の承認の関門。利用者が
issues/issue-624-478-648-design.mdを開いて「色々違反」と指摘し、「設計工程では /ndf:markdown-writing と /ndf:document-restructuring を通すことになっていますが、通っていましたか？」と問った。conductor は記録からは「通した」としか言えず、実物を見て初めて「通っていない」と分かった。直さないと何が起きるか
approval-request.md）。識別子だらけの見出しでは承認する人が判断できず、設計工程: 設計 PR と設計文書のタイトルが仕組みの語だけで、承認する人が目的を読めない → 目的（今の問題と直した後に成り立つこと）をタイトルと最初の章に置く規約を工程に入れる #785 の書き直しと同じ手戻りが毎回起きる修正レイヤー
plugins/ndf/skills/markdown-writing/SKILL.md「書き終えたらセルフチェック」[a-z]+_[a-z0-9_]{2,}）は候補であって合否ではない#）の行に識別子があるときは合否として扱う判定が無い。実行結果をどこにも残さないplugins/ndf/skills/document-restructuring/SKILL.md「報告」plugins/ndf/skills/design/SKILL.mdとreferences/design-template.md### 決定 N: {結論を 1 文で}plugins/ndf/skills/progress-trackingplugins/ndf/skills/development-workflow/references/agent-layers.md「持ち場の報告」最後に記録した工程.github/workflows/）pr-body-decisions/check-doc-line-limit/check-markdown-links/check-doc-staleness採る手
通過の判定を記録から検査結果へ移す（
move_responsibility）。markdown-writingのセルフチェックのうち機械で合否を出せるもの（見出し行の識別子・禁止表現の grep）をスクリプトにし、設計 PR の CI に足す。候補と合否の線は Skill が決める（見出しは合否、本文は候補）document-restructuringの段 4 の表を PR 本文の節（例:## 再構成の前後）へ書く規約にし、pr-body-decisions.shと同じ位置で有無を検査するdesign/references/design-template.mdとdecisions.mdに「見出しは業務用語、識別子は本文の括弧書き」を書く（設計工程: 設計 PR と設計文書のタイトルが仕組みの語だけで、承認する人が目的を読めない → 目的（今の問題と直した後に成り立つこと）をタイトルと最初の章に置く規約を工程に入れる #785 の「何のために何を決めた」の規約と同じ場所に置く）agent-layers.mdの持ち場の報告（設計）に、セルフチェックの結果と前後の値の置き場所を項目として足すissues/issue-624-478-648-design.mdと 4 本の設計文書（cross-review: 利用上限で止まった担当が「結果ファイル無し」と報告されて空振りの起動し直しで待たされ、止めた担当が後から結果を書く → 上限を理由に報告して同じラウンドで起動し直さず、止めた後は書かせない（#729 #619 #584） #781 cross-review / cross-refactoring: 参加する CLI が 1 者でも使えないと収束ループを開始できず、再開で渡した引数が黙って無視される → 使える者だけで開始し、cross-review は毎ラウンド 2 席を確保し、再開で渡した引数は反映されるか反映しないと知らされる（#727 #687 #478 #664 #648） #782 cross-review: 誤りを示されていない重大な指摘が数えられずに承認で終わる → 数えない指摘を棄却と軽微な指摘に限る（#732 #624 #706） #783 cross-refactoring: 実装担当が結果を残さないと同じ群が上限なしに開き直され、未検証のコミットが残る → 結果なしを取り込みの 1 か所で受けて取り消し、群が開いた回数と結末で開き直しを決める（#728 #647 #592 #553） #784）の見出しを、業務用語へ書き直す1 と 2 は「記録が無いことは通っていないことと同じではない」の原則を保つ。 拒否ではなく、検査の結果を PR 上に見える形で残し、承認する人が読めるようにする。
完了条件
issues/issue-624-478-648-design.mdと cross-review: 利用上限で止まった担当が「結果ファイル無し」と報告されて空振りの起動し直しで待たされ、止めた担当が後から結果を書く → 上限を理由に報告して同じラウンドで起動し直さず、止めた後は書かせない（#729 #619 #584） #781 cross-review / cross-refactoring: 参加する CLI が 1 者でも使えないと収束ループを開始できず、再開で渡した引数が黙って無視される → 使える者だけで開始し、cross-review は毎ラウンド 2 席を確保し、再開で渡した引数は反映されるか反映しないと知らされる（#727 #687 #478 #664 #648） #782 cross-review: 誤りを示されていない重大な指摘が数えられずに承認で終わる → 数えない指摘を棄却と軽微な指摘に限る（#732 #624 #706） #783 cross-refactoring: 実装担当が結果を残さないと同じ群が上限なしに開き直され、未検証のコミットが残る → 結果なしを取り込みの 1 か所で受けて取り消し、群が開いた回数と結末で開き直しを決める（#728 #647 #592 #553） #784 の設計文書の見出しに、識別子を主語・目的語にした行が無い（説明文の識別子は括弧書きに寄せる）由来
マイルストーン 13 の承認の関門での利用者の指摘（2026-09-19）。
🤖 Generated with Claude Code
追記（2026-09-19）: supervisor が Skill を読んでいたかの記録
4 本の設計の supervisor の会話の記録（JSONL）から
Skillツールの呼び出しとSKILL.mdの読み取りを抜き出した。markdown-writingdocument-restructuringSkillツール。それでも識別子を含む見出し 18 件が残った（grep のヒットを「候補」として通した）Skillツールでなくcat/sedでSKILL.mdを読んだdesign/SKILL.mdとprogress-tracking/SKILL.mdだけ。再構成の値は測って記録したSkillツールで読んだ分かったこと
designの工程表に「markdown-writingを呼ぶ」が無いため、3 本の supervisor は読まずに設計文書を書いた。document-restructuringの段 3 がmarkdown-writingを呼ぶと定めているが、その段そのものを飛ばした supervisor（G2）は到達しないcat」を使う指示が出るため、SKILL.mdをcatで読む supervisor が出る。Skillツールの呼び出しの記録から工程を数えるskill-statsは、この読み方を拾えない採る手への追加
design/SKILL.mdの工程表にmarkdown-writingの読み込みとセルフチェックの実行を明記する（document-restructuring経由に頼らない）agent-layers.md）に「工程の Skill はSkillツールで読み込む。catで代用しない」を書く。記録から通過を数える側（skill-stats）と読み方を揃えるため追記（2026-09-19）: mermaid の描画エラーもレビューを通り抜けた
利用者が PR #781 の設計文書を GitHub で開き、構成要素図が「Lexical error on line 20. Unrecognized text.」で描画されないと指摘した。原因は
subgraph cross-refactoring（G4 が実装）のように、subgraphの題名へ括弧を含む文字列を引用符なしで置いたこと。書き直しの担当も cross-review の 3 者も気づいていない。機械で見られる。
mermaid（npm）を jsdom の上で読み込みmermaid.parse()を呼ぶと、GitHub と同じ文言のエラーを再現した。4 本の設計 PR の mermaid 20 個を通したところ、壊れていたのはこの 1 個だけで、直した後は 20 個とも通る（subgraph CR["cross-refactoring（G4 が実装）"]、PR #781 のコミット 98292ea）。採る手への追加
```mermaidブロックを抜き、mermaid.parse()で解析する。描画までは要らないので puppeteer は使わない）markdown-writing/01-diagram-guide.mdに「subgraphの題名と node のラベルに括弧・記号を含めるときはid["題名"]の形で引用符で囲む」を足す