個人の開発や創作の過程で得た知見のうち、特定のプロジェクトに依存せず、公開してよいものだけを蒸留して置く repository である。 各プロジェクトの成果物を集める場所ではない。
Preserve the lesson, not the source.
| ノート | タグ |
|---|---|
| 複数の AI の指摘を多数決で集約しない | ai writing review evaluation |
| 「初めて読むつもりで」では初読レビューにならない | ai writing review evaluation |
| AI による文章レビューは「検出、判定、意思決定」の三段階に分ける | ai writing review |
- 設計、調査、計測、問題分析、レビューから得た、他のプロジェクトでも使える知見
- AI agent と協働する作業の進め方のうち、再利用できるもの
- 文章や創作の進め方のうち、再利用できるもの
- 別の場面でもそのまま使えるチェックリストや手順
- 特定のプロジェクトの記録（計画書、作業ログ、計測結果そのもの）
- 勤務先、顧客、取引先の業務に由来する情報（匿名化や一般化をしても置かない）
- 他人から預かった情報や、非公開のやり取りに由来する情報
- 認証情報、識別子、個人情報、private なリソースへの参照
- 元になった repository、パス、commit、文書といった provenance
詳しい基準は PUBLICATION_POLICY.md にある。 agent 向けの指示、skill、チェックリストは、すべてこのポリシーを正本として参照している。
- Standalone：元の repository や作業の文脈を知らない読者が、その文書だけで理解できる。
- Generalized：特定のプロジェクトの記録ではなく、他のプロジェクトでも使える知見になっている。
- Public-safe：第三者が無条件で閲覧しても問題がないことを、積極的に確認できている。
判断に迷うものは公開しない。
When provenance or confidentiality is uncertain, do not extract.
ノートには、元にした repository、ファイル、commit、組織を書かない。 読者に必要なのは知見が単独で使えるかどうかであり、出どころはその判断の役に立たない。 一方で出どころの記録は、非公開の repository や組織の存在、ローカルの環境を示す手がかりになる。 同じ理由で、公開の可否を repository 名やパスの denylist で判断することもしない（そのルール自体が手がかりを公開してしまう）。
- 元の文脈がなくても読める
- 何が分かったかが書いてある
- 観測の範囲と、どの条件で成り立つかが分かる
- 別の場面でどう使うかが分かる
雛形は templates/note.md にある。 本文の見出しは例であり、内容に合わせて統合、追加、削除してよい。
.
├── README.md
├── PUBLICATION_POLICY.md 公開の基準（唯一の正本）
├── AGENTS.md agent 向けの指示（Codex などが読む）
├── CLAUDE.md AGENTS.md の import と Claude Code 固有の補足
├── notes/ ノート。平らに置き、tags で分類する
├── assets/ README などで使う画像
├── templates/note.md ノートの雛形
├── checklists/
│ └── publication-safety.md 公開前レビューの確認項目
├── .agents/skills/ skill の正本
│ ├── junkyard-harvest/ 他の repository から知見を抽出する
│ └── junkyard-review/ 公開前の敵対的な判定
├── .claude/skills/ .agents/skills への symlink（Claude Code 用）
├── scripts/
│ ├── build_readme.py README のノート一覧を生成する
│ ├── check.py 静的 safety check
│ └── test_*.py
└── .githooks/
├── pre-commit README の一覧と、commit するファイルを検査する
├── pre-merge-commit conflict のない merge で pre-commit と同じ検査をする
└── commit-msg commit message とブランチ名を検査する
ノートは Obsidian の vault のようにディレクトリを分けずに置き、frontmatter の tags で知識の種類ごとに分類する（ai、engineering、writing など）。
一つのノートに複数のタグを付けてよい。
元の repository ごとには分類しない。
agent は junkyard のルートで起動し、source の repository を読めるようにする。 逆に source の repository で起動すると、別のコンテキストで判定させるサブエージェントまで source の中で動き、source のファイルに触れうる。
Claude Code では --add-dir で source を追加する。
claude --add-dir /path/to/sourceCodex も junkyard のルートで起動し、source のパスを依頼の中で指定する。 サンドボックスの設定で source を読めない場合は、source の読み取りだけを許可する。
起動したら、source のパスを明示して頼む。
/path/to/source の Markdown を調べて、junkyard に残せそうな知見を抽出して
skill は junkyard の .agents/skills/（Codex）と .claude/skills/（Claude Code）から読み込まれる。
junkyard の場所は、環境変数 JUNKYARD_DIR か、SKILL.md があるディレクトリ（symlink を解決したもの）の 3 階層上として特定する。
junkyard-harvest は次の順に進む。
- 対象が本人の個人作業であり、公開用の抽出に使えることをユーザーに確かめる（肯定がなければ中止する）
- 文書ごとに分類し、業務や第三者に由来する文書は読み進めない
- 残った文書から lesson を選び、
drafts/に新しい文書として書く - 非公開の個人資料から抽出した場合は、別のコンテキストの
junkyard-reviewに source を渡さずに判定させる - 結果を報告する
source repository には何も書き込まない。
PASS または SELF-CHECKED のドラフトを notes/ へ移すのはユーザーの承認後である。
commit はユーザーの明示的な指示がある場合だけ行う。
push はユーザーが行う。
ノートを notes/ に追加、変更、削除したら、README の「ノート」の一覧を生成し直す。
python3 scripts/build_readme.py一覧はスクリプトが書き換えるので、手で編集しない。
各ノートの最初の H1 と tags を、ノートを最後に変更した commit の日時が新しい順に、同じ日時ならファイル名の順に並べる。
まだ commit していないノートは、次の commit に入るものとして先頭に置く。
pre-commit フックは、インデックス上のノートと一覧が合っているかを確かめるので、ノートと README.md は一緒に add する。
非公開の個人資料から抽出した drafts/ の文書は、書いたのとは別のセッションで junkyard-review を実行して判定する。
junkyard-harvest は判定をサブエージェントに任せるが、そのサブエージェントは --add-dir で追加した source の場所を環境の情報として知りうる。
より確実にするには、source を追加せずに junkyard のルートで起動した新しいセッションで判定する。
公開情報だけを根拠にした文書や、非公開資料から抽出せず直接書いた文書は、独立した reviewer を必須としない。
確認項目は checklists/publication-safety.md にある。
python3 scripts/check.py
python3 scripts/check.py drafts/some-note.md引数を省くと、作業ツリーの tracked と未追跡（ignore 以外）のファイルを検査する。 主に次のものを検出する。
- ローカルのパス、IP アドレス、MAC アドレス、メールアドレス、電話番号
- 既知の形式の秘密情報と、認証情報らしい値の代入（token、URL に埋め込まれた認証情報、署名付き URL を含む）
- Git ホスティングの URL、PR や issue の番号、commit hash、UUID、クラウドの識別子とデプロイ先、組織内のホスト名
- repository の外や、存在しないファイル（ignore されたファイルを含む）への相対リンク
- ノートの中の、元の文脈を示す言い回し、HTML コメント、
titleとtags以外の frontmatter - ファイル名と symlink の参照先に含まれる上のもの、repository の外を指す symlink、submodule、公開しないパス（
drafts/、鍵、認証情報のファイルなど） - バイナリ。例外は
assets/の下の PNG で、画素と色の情報以外のチャンク（テキスト、Exif、ICC プロファイル、C2PA など）を含まないものだけを置ける。ノートに画像を貼らないのは、スクリーンショットに写り込んだものを機械的に検査できないからである - commit message、ブランチ名、author と committer の名前とメールアドレスに含まれる上のもの（
--commit-msg）
検出 0 件は安全の証明ではなく、意味的なレビューを補う safety net である。
誤検出で、確認のうえ公開して問題ないものは、同じ行か、抑制コメントだけを書いた直前の行に <!-- junkyard-allow: <rule-id> --> を書いて抑制できる。
抑制はユーザーが確認して書くものであり、agent には書かせない。
そのため drafts/ と repository 外のファイルでは抑制コメントが効かず、それ自体を検出する。
既知の形式の秘密情報、denylist、frontmatter、symlink、バイナリ、公開しないパス、名前に含まれるものは抑制できない。
固有語を止めるためのローカル denylist は、repository の外に置く。
既定の場所は ${XDG_CONFIG_HOME:-~/.config}/junkyard/denylist.txt で、環境変数 JUNKYARD_DENYLIST で変えられる。
一行に一語を書き、大文字と小文字を区別せずに照合する。
re: で始まる行は正規表現として、# で始まる行はコメントとして扱う。
repository の中に置いた denylist は、commit されると固有語をそのまま公開してしまうので、チェッカーは読まずにエラー終了する。
denylist と同じ内容のファイルが repository の中にあれば、それも検出する。
commit の前に、インデックス上の内容（pre-commit）と、commit message とブランチ名（commit-msg）を検査する。 clone した後に一度だけ有効にする。
git config core.hooksPath .githooksフックに止められたら、--no-verify で回避せず、原因を取り除く。
conflict のない merge では、pre-commit の代わりに pre-merge-commit が同じ検査をする。
rebase と cherry-pick は、これらのフックを呼ばずに commit を作ることがある。
使った後は python3 scripts/check.py と python3 scripts/build_readme.py を実行し、検出がなく、README に差分が出ないことを確かめる。
CI では検査しない。 CI が走るのは push の後、つまり公開した後なので、公開前の gate にならないからである。
commit の author と committer のメールアドレスも公開される。 commit-msg フックは、noreply などの一部と、公開してよいと登録したアドレスを除くメールアドレスでの commit を止める。 勤務先のアドレスのような、公開したくないアドレスでうっかり commit しないためである。
GitHub の noreply アドレスを使うか、既に公開しているアドレスを repository ローカルの設定に登録する（この設定は commit されない）。
git config user.email "<id>+<username>@users.noreply.github.com"
git config --add junkyard.publicEmail "<公開してよいアドレス>"既に公開したくないアドレスで作った commit がある場合は、push する前に author を書き換える。
python3 -m unittest discover -s scripts