| name | source-to-wiki |
| description | sources/ にある原資料を読み、wiki/ 以下の日本語Wikiページへ整理・統合し、関連リンク、wiki/index.md、wiki/changelog.md を更新するSkill。ユーザーが「sourcesをwiki化して」「source-to-wikiして」「取り込んだメモをwikiに整理して」「wikiを更新して」のように依頼したら必ず使うこと。sources/ の本文編集やファイル移動は対象外で、原資料をもとにした知識ベース更新だけを行う。 |
source-to-wiki
sources/ の原資料を読み、wiki/ 以下の日本語Wikiを更新する。
sources/ 側の移動、frontmatter整備、本文編集はこのSkillの範囲外。
最初に処理対象を確認し、対象となる sources/**/*.md が1件も無ければ「処理対象がない」と報告して終了する。
--dry-run が指定された場合は、手順1 (現状確認と方針決定) だけを行い、作成・更新する予定のページと統合方針を提示して終了する。ファイルの作成・編集は一切行わない。
併用するSkill
wiki/ の本文を書く・更新する前に、local skill の japanese-tech-writing と stop-ai-slop-jp を読む。
最終本文は、日本語の技術文書として読みやすく、AI臭の少ない文章に整える。
これらのskillが環境に無い場合は、この節をスキップし、後述の本文方針に従って書く。
ルール
- sources編集禁止：
sources/ 配下は読むだけにする。frontmatter、本文、画像パス、ファイル名を変更しない。
- 根拠を残す：Wikiページのfrontmatter
sources または本文の「参照元」に、使った原資料への相対リンクを必ず残す。
- 過度に要約しない：原資料の事実、判断、未確認事項を混ぜない。推測は推測として書く。
- ページは主題単位：1メモごとに機械的にWikiページを作らない。逆に、カテゴリ全体を1ページに集めた「○○メモの整理」のようなカタログページも作らない。「NFS運用」「PyTorchのCUDA環境構築」のように、主題で括れる範囲を1ページにする。
- リンク紹介文の羅列にしない：本文には原資料から抽出した知識 (結論、手順の骨子、判断とその理由) を書く。「XはYのメモである。Zを見る」という紹介文だけで本文を構成しない。
- 統計値を書かない：件数などの統計は原資料の増減ですぐ古くなるため、本文に書かない。
- index/changelog更新：Wiki本文を更新したら、
wiki/index.md と wiki/changelog.md も更新する。
対象の決め方
ユーザーが対象ファイルやカテゴリを指定した場合は、その範囲だけ処理する。
指定がない場合は、直近で追加・変更された sources/**/*.md を git status --short や更新日時から確認する。
sources/ideas/ のアイデアメモや、frontmatter に model があるAI回答による下調べメモは、未検証の内容を含むことがあるため、1メモごとに機械的にWiki化しない。
継続テーマ、実装方針、研究テーマとして整理する価値が出たものだけ、wiki/index.md にある既存カテゴリのページに統合する。
通常の原資料からWikiページを作る場合は、_template/wiki.md を使う。
手順
1. 現状を読む
- 対象の
sources/ メモを読む。
- 関連する既存Wikiページ、
wiki/index.md、wiki/changelog.md を読む。
- 既存ページに統合するか、新規ページを作るかを決める。統合先が複数の主題を抱えて肥大している場合は、そこへ追記し続けず、主題に合う新規ページを作る。肥大したページの分割が必要なら、最後の報告で
wiki-maintenance の実行を提案する。
- 主題としてまだ書くことが無いメモは、無理にWiki化せず、その旨を報告する。
2. Wikiページを作成・更新する
新規ページを作る場合は、_template/wiki.md を使う。
ファイル名は内容が分かる短い名前にし、既存のカテゴリ構成に合わせる。
必要なら wiki/{category}/ を作るが、1ページだけの細かすぎるカテゴリは避ける。
frontmatterは次を基準にする。
---
title: "<title>"
aliases: []
category: "<category>"
tags: []
status: draft
sources:
- "<relative-path-to-sources>/<category>/YYYY-MM-DD_slug.md"
related: []
created: "<YYYY-MM-DD>"
updated: "<YYYY-MM-DD>"
---
title はページ内容を端的に表す。category は wiki/index.md の主要カテゴリに合わせる。sources は使った原資料への相対リンクを入れる。wiki/ 直下のページなら ../sources/...、wiki/{category}/ 配下のページなら ../../sources/... のように、ページ位置からの相対パスにする。related は既存Wikiページと明確に関連する場合だけ入れる。updated は実質更新日を入れる。
本文は次の方針で書く。
- 結論、背景、具体、未確認事項を分ける。
- 原資料が英語でも、日本語で整理する。
- 原資料の引用が必要な場合は短くし、基本は要約する。
- 出典のない一般化や断定を避ける。
- 原資料同士が矛盾する場合は、統合せず違いを明示する。
_template/wiki.md の見出しは次のように使う。
## 概要：主題の結論を2〜5文で書く。この節だけ読めば要点が掴めるようにする。## 詳細：背景、手順の骨子、判断とその理由を書く。具体的な設定値や長い手順は原資料へのリンクに逃がす。## 関連ページ：関連する既存Wikiページへの相対リンクを置く。無ければ空のままでよい。## 参照元：使った原資料への相対リンクを置く。frontmatter sources と一致させる。
本文の悪い例 (リンク紹介文の羅列。原資料を読まないと何も分からない)：
- NFSのマウント手順は [2026-01-10_nfs-setup.md](...) を参照。
- NFSのトラブル対応は [2026-02-03_nfs-trouble.md](...) を参照。
本文の良い例 (結論と判断の理由を抽出し、詳細だけリンクに逃がす)：
NFSv4のマウントはautofs経由に統一した。
fstab直書きではサーバー再起動時にクライアントが固まるため。
設定値と手順の詳細は [2026-01-10_nfs-setup.md](...) を参照。
3. 関連リンクを張る
更新したWikiページから関連ページへリンクする。
必要なら関連ページ側にもリンクを追加する。
ただし、関連が弱いページへ網羅的にリンクしない。
4. indexを更新する
wiki/index.md の該当カテゴリにページを追加する。
既存のカテゴリ説明を大きく変えない。
カテゴリを新設する場合は、なぜ既存カテゴリでは足りないかを最後の報告に含める。
5. changelogを更新する
wiki/changelog.md の先頭に履歴を追記する。
形式は既存の見出しに合わせる。
## [YYYY-MM-DD] update | <短い説明>
- `<source>` をもとに `<wiki>` を作成・更新しました。
- `wiki/index.md` にリンクを追加しました。
最新の履歴が一番上に来るようにする。
6. 検証する
oxfmt で編集したMarkdownを整形する。scripts/check_image_links.py を実行し、Markdown画像リンクが壊れていないことを確認する。git diff で sources/ に意図しない変更がないことを確認する。
報告
次を簡潔に報告する。
- 作成・更新したWikiページ
- 使った原資料
wiki/index.md / wiki/changelog.md の更新有無- 新設カテゴリがあればその理由
- 検証結果
