---
title: "インストールとコマンド"
description: "「インストールとコマンド」：yokoten ガイドの一章。"
canonical: https://yokoten.app/ja/docs/guide/install-and-commands
lang: ja
source: https://github.com/yokoten-labs/yokoten/blob/v0.1.2/docs/i18n/ja/guide.md
ref: "v0.1.2"
---

> For AI agents: the documentation index is at https://yokoten.app/llms.txt. To set up yokoten in a project, follow https://yokoten.app/agents.md.

# インストールとコマンド

Node 22.23.4 以降（Node 24 は 24.22.1 以降、Node 26 は 26.12.1 以降）が要ります。TypeScript をそのまま走らせるからです。22.18 から 22.23.3 のリリースも TypeScript を走らせますが、使わないでください。Node が 2026-10-21 に直したセキュリティの穴があります（[advisory](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases)）。だから npm はそれらに警告し、完全な `doctor` は `machine:` の下に注意します。依存はありません。インストールの方法は二つです。Claude Code のプラグインか、npm またはクローンからの `install` コマンドです。片方だけ使ってください。yokoten が書くフックのコマンドには POSIX シェルが要ります。Windows では Git Bash を使ってください。

ほとんどの人に必要なのは一つのコマンド、`npx yokoten` だけです。`install`、`init`、`doctor` の
仕事をまとめて行い、足りないものを整えてから、いまの位置と次の一歩を見せます。そのほかに、`yokoten help` が並べるコマンドは
`desk`、`kanban`、`check`、`tidy` の四つです（[記録 0043](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/docs/records/0043-v012-three-commands.md)）。古いコマンドも動き、移動先を教えてくれます。
`yokoten help --all` で全部を一覧にでき、下の「コマンド」の表で一つずつ説明します。

## Claude Code のプラグイン

Claude Code のセッションで、こうします。

```text
/plugin marketplace add yokoten-labs/yokoten
/plugin install yokoten@yokoten
```

最初のコマンドは、このリポジトリをプラグインのマーケットプレイスとして足します。二つ目はプラグインを開きます。「Install for you」（ユーザースコープ）を選んでください。シェルからなら、`claude plugin marketplace add yokoten-labs/yokoten` のあと `claude plugin install yokoten@yokoten` でも同じです。

プラグインはこのリポジトリです。`install` がコピーするのと同じファイルを使うので、二つの方法が離れることはありません。

| プラグインが足すもの | 出どころ |
|---|---|
| スキル: `/yokoten:dispatch`、`/yokoten:inspect`、`/yokoten:merge`、`/yokoten:rca`、`/yokoten:record`、`/yokoten:release`、`/yokoten:yokoten` | `kit/user/skills/` |
| エージェント: `yokoten:worker`、`yokoten:reviewer`、`yokoten:verifier` | `kit/user/agents/` |
| `/yokoten:init`、`/yokoten:doctor`、`/yokoten:update`。プラグインから yokoten を走らせる | `kit/plugin/skills/` |
| SessionStart の `doctor` フックとコマンドの番人。`install` が足すのと同じ二つのフック | `.claude-plugin/plugin.json` |

コマンドの番人はどのフォルダでも走るので、コマンドのルールに従います。例外が一つあります。yokoten のリポジトリ（`yokoten.json` があるもの）の中のファイルへの編集には、セッションをどこで始めても、そのリポジトリのファイルのルールが付きます。セッションのフォルダの外のワークツリーにいるワーカーも、リード専用ファイルを変えられません。

Claude Code は、プラグインの `.ts` ファイルを `node` で走らせます。プラグインのフォルダが `node_modules` の下にないので、Node はそれができます。新しい yokoten にするには、`/plugin` を開き、**Installed** タブで yokoten を選び、**Update now** を選びます。第三者のマーケットプレイスは、あなたが自動更新をオンにするまで、自分では更新しません。シェルからなら `claude plugin update yokoten@yokoten` でも同じです。そのあと Claude Code を再起動してください。プラグインが `doctor` を走らせる yokoten より古いときは、`doctor` が注意でそう言います。

プラグインは Claude Code でだけ動きます。非公開の印のファイルは作りません。`doctor` がそのファイルを名指しし、あなたが作ります。ユーザー設定でプラグインがオンのときは、`doctor` はそのフックとスキルをインストール済みと数えます。

プラグインか `install` の片方だけを使ってください。プラグインがオンのとき、`install` はグローバルのフォルダに自分のコピーを置きません。前から両方あったマシンでは、番人とセッションの doctor が二回走り、すべてのスキルが二回出ます。`doctor` が注意でそう言い、プラグインがオンの `install` は自分が書いたグローバルのコピーを取り戻します。`install` からプラグインに移るには、`yokoten uninstall` を実行します。`install` が書いたものを消します。`~/.config/yokoten` にあるあなた自身のファイル（追加した非公開の印など）は残ります。

プラグインがオンのとき、`install` は自分の番人を書きません。番人はプラグインのもの一つだけです。プラグインをオフにするか消すと、この機械には番人が一つも残りません。そのとき `doctor` は「no guard for Claude Code」で失敗し、`yokoten install` が `install` 自身の番人を書きます。

## npx でインストールする

Codex CLI と Gemini CLI のため、またはプラグインなしで、こうします。

```sh
npx yokoten install      # このマシン: スキル、エージェント、フック
cd your-project
npx yokoten init         # このプロジェクト: ファイルを足し、決して上書きしない
npx yokoten doctor       # 道: どこにいて、次は何か
```

`npx` はパッケージをダウンロードして走らせます。パッケージに依存はありません。`install` と `init` は、yokoten の実行時ファイルをパッケージからコピーします。`~/.local/share/yokoten` と `.yokoten/` へです。フックはそのコピーを走らせるので、ネットワークも `npx` も要りません。

パッケージはビルド済みの JavaScript を走らせます。Node は `node_modules` の下の TypeScript を走らせないからです。リポジトリにビルドはなく、`npm pack` がパッケージの `dist/` を作ります（[記録 0008](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/docs/records/0008-npm-package.md)）。

パッケージを公開するのはオーナーです。オーナーがリリースのタグを作るのと同じです。タグがリリースのワークフローを始めます。チェックが走ったあと、公開のジョブが `release` 環境でオーナーの承認を待ちます。そのときだけ npm に公開し、npm のトークンはどこにも保存しません（[記録 0009](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/docs/records/0009-release-environment.md)）。最初のリリースだけは例外です。オーナーが手で公開します。npm は、まだ持っていないパッケージのワークフローを信頼できないからです。最初のリリースが npm に載るまでは、[クローンからインストール](https://yokoten.app/ja/docs/guide/install-and-commands.md#クローンからインストールする)してください。

## クローンからインストールする

同じコマンドを、このリポジトリの複製から使います。最初のリリースが npm に載るまでは、この方法を使ってください。

```sh
git clone https://github.com/yokoten-labs/yokoten
node yokoten/bin/yokoten.ts install      # このマシン: スキル、エージェント、フック
cd your-project
node ~/.local/share/yokoten/bin/yokoten.ts init     # このプロジェクト: ファイルを足し、決して上書きしない
node ~/.local/share/yokoten/bin/yokoten.ts doctor   # 道: どこにいて、次は何か
```

yokoten のメッセージは `yokoten init` と `yokoten doctor` と言います。だから `install` は、小さな `yokoten` の起動役を `~/.local/bin` に置きます（Windows では `yokoten.cmd`）。そのフォルダはほとんどの環境で PATH にあり、次に開くシェルで `yokoten` が動きます。起動役は `bin/yokoten.mjs` を走らせます。フックが走らせるのと同じ速い入口です。次の `install` は、古い install が書いた起動役を書き直します。

`~/.local/bin` が PATH にないとき、`install` は一度だけ聞きます。`Add ~/.local/bin to your PATH in ~/.bashrc? [Y/n]` です（zsh なら `~/.zshrc`、macOS の bash なら `~/.bash_profile`）。はいなら、そのファイルにこの一行を足します。いいえなら、あなたが足すための行を出力します。

```sh
export PATH="$HOME/.local/bin:$PATH" # added by yokoten
```

yokoten がシェルの設定を編集するのは、その「はい」のあとだけです。ターミナルに誰もいないとき（パイプ、フック、CI）は、決して聞かず、決して編集しません。yokoten が書いていない `~/.local/bin/yokoten` はそのまま残り、`install` がそれを名指しします。`uninstall` は起動役と印を付けた行を消します。PATH の `yokoten` がインストール済みのコピーを走らせないときは、`doctor` が注意します。

これらのコマンドと npx のコマンドは、ウェブサイトが読む [docs/facts.json](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/docs/facts.json) にもあります。だから変更は両方に入れます。

## GitHub Action として使う
GitHub のどのリポジトリでも、ワークフローのファイル一つで yokoten のチェックを CI で走らせられます。リポジトリには何もインストールせず、何もジョブの外へ出ません。トークンも、外部のサービスもありません。

```yaml
# .github/workflows/yokoten.yml
name: yokoten
on:
  pull_request:
    # `edited`、`labeled`、`milestoned` は、修正のあと `check --pr` をもう一度走らせる。
    types: [opened, edited, synchronize, reopened, labeled, unlabeled, milestoned, demilestoned]
  push:
    branches: [main]
permissions:
  contents: read
jobs:
  yokoten:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          fetch-depth: 0
          persist-credentials: false
      - uses: yokoten-labs/yokoten@<full commit SHA>
```

アクションは Node を用意し、そのあと `check` を走らせます。プルリクエストでは `check --pr` も走らせます。指摘は、yokoten 自身の CI と同じく、プルリクエストのページに出ます。

三つのイベントを扱います。

- **`push`**: `check`。
- **`pull_request`**: `check`、そのあと `check --pr`。
- **`issues`**: `check`、そのあと issue のタイトルに `check --issue`。走らせるには、`on:` の下に `issues:` と `types: [opened, edited]` を足します。

`pull_request_target` では、チェックアウトがプルリクエストではなく基底ブランチを持つので、アクションは `check --pr` を飛ばし、注意を残します。プルリクエストのチェックは `pull_request` で走り、`pull_request_target` では走りません。

- **固定する。** 完全なコミットの SHA を使ってください。`@main` のようなブランチ名は、あなたの下で変わります。リリースが出たあとは、リリースのタグも使えます。
- **チェックアウト**には `fetch-depth: 0` が要ります。`check --pr` は基底と head のコミットの間のファイルを一覧するので、両方が要ります。
- **権限**: `contents: read` で足ります。アクションはトークンを取りません。
- **入力**: `pr-check`（既定は `true`）、`issue-check`（既定は `true`）、`node-version`（既定は `^22.23.4`。2026 年 10 月のセキュリティ修正を含む最初の Node 22）です。`pr-check: false` でプルリクエストの標準を飛ばし、`issue-check: false` で issue タイトルの標準を飛ばします。
- **Node**: アクションは、ジョブの残りのためにも Node を用意します。

`check --pr` は、プルリクエストを核心ルール 8 の標準に保ちます。まだそれに従っていないリポジトリは、`pr-check: false` で始められます。Dependabot が開くプルリクエストにはタイトルのチェックが付き、ほかのルールは注意として出ます。Dependabot が自分の本文を書くからです。キットの `check` ワークフローは、まずプロジェクトの `.yokoten/` のコピーを走らせます。コミットフックと同じ yokoten なので、同じチェックです。そのあとこのアクションを最初のリリースのコミットに固定して走らせるので、`.yokoten/` を変えたプルリクエストも、書き換えられないチェックを受けます。Dependabot がこの固定を新しいリリースのコミットに更新します。キットの `pr` と `issue` のワークフローは、プロジェクトの `.yokoten/` のコピーを走らせます。

## CI なしの非公開リポジトリ

無料プランの非公開リポジトリは、GitHub Actions の分数を払います。そのようなプロジェクトは、リポジトリが公開されるまで CI を切っておけます。そのときはコミットフックと `yokoten check` が関門です。

`init` はリポジトリの公開範囲を `gh` から読みます。非公開リポジトリでは、ワークフローが Actions の分数を使うと伝えます。それでも書きます。`init` がこの選択をあなたの代わりにすることは決してありません。CI を切っておくには、こうします。

```sh
yokoten init --no-ci
```

`--no-ci` は三つのことをします。

- `yokoten.json` の `"notNow"` に、理由つきで `"ci"` を足します。
- 三つのワークフローと `.github/dependabot.yml` を省きます。キットの Dependabot は、CI が走らせるアクションだけを更新します。
- それらのファイルがまだキットの複製なら、それぞれを消します。あなたが変えたファイルや、シンボリックリンクを通して届くファイルは残し、`init` がそれを名指しします。

`"notNow": { "ci": "<reason>" }` があると、道はコミットフックと `yokoten check` を関門と数えます。CI が要るステップは一緒に待ちます。`tests`、`ci`、`titles` です。`security-files` のステップは Dependabot を求めず、完全な `doctor` も必須の CI チェックを求めません。あとで `init` や `init --github --yes` を実行しても、ワークフローはもう書きません。

CI がないと、チェックされないものがあります。完全な `doctor` が `no-ci` の注意で一度だけそう言います。

- サーバーでは、プルリクエスト、issue のタイトル、ワークフローをチェックするものが何もありません。
- CodeQL のようなコードのスキャンは走りません。
- フックを切って作られたコミットは、チェックされずに `main` へ届きます。

だからマージする前に、各プルリクエストをチェックしてください。

```sh
yokoten check --pr 12
```

`check --pr <number>` は、そのプルリクエストを `gh` を通して読みます。CI と同じことを、あなたのクローンのコミットでチェックします。コミットが足りないときは、何を取り込むべきかを言います。

関所 5 からは、リポジトリが公開されたらこの選択を終えるよう、注意が思い出させます。完全な `doctor` がリポジトリの公開を読むと、そう言います。CI を再び使うには、`"notNow"` から `"ci"` を消して `yokoten init` を実行します。ワークフローが書かれ、ステップが CI を再び数えます。

## コマンド

`init` は実行時ファイルを、あなたのプロジェクトの `.yokoten/` にコピーします。それをコミットしてください。フックと CI が、ネットワークもグローバルなインストールもなしで走ります。

`init` はプロジェクト自身の設定を動き続けさせます。`## This project` のない `AGENTS.md` には、核心ルールが上に付きます。自分のテキストは `## This project` の下に移り、その見出しは一段下がります。ほかは何も変わりません。`init` は移した各見出しを出力します。git が古いファイルをそのまま持っているときは、`init` はそれを戻すコマンドを出力します。そうでなければ `AGENTS.md.before-yokoten` に複製を保ちます。YAML のフロントマターは一番上にとどまります。リンクである `AGENTS.md` はそのまま残ります。`CLAUDE.md` があると、末尾に `@AGENTS.md` の行を足します。Claude Code はその取り込みを通してだけ `AGENTS.md` を読むからです。`.claude/CLAUDE.md` も数え、ルートにないときは `@../AGENTS.md` を受け取ります。husky などの `core.hooksPath` があると、そのフォルダを保ち、コミットチェックをそこに足します。
クローンは `.git/hooks` に自分のフックを持つこともあります。lefthook、pre-commit フレームワーク、または手書きのものです。git を `.githooks` に向けるとそれらがすべて切れるので、`init` は `.githooks/pre-commit` と `.githooks/pre-merge-commit` を書き、先にチェックを走らせてから古いフックを走らせます。ほかの実行可能なフック（`commit-msg` や `pre-push` など）には、古いものだけを走らせる `.githooks` のファイルを書きます。どれも同じ引数と stdin を受け取ります。古いフックは `.git/hooks` に残り、`init` は残したものを一つずつ名指しします。実行可能でないフックは今日の git が飛ばすので、`init` は先に進み、どう残すかを言います。渡せないとき（コミットフックがグローバルの `core.hooksPath` から来る、プロジェクト自身の `.githooks` ファイルがチェックを `if` の中に持つ、古いフックのように stdin を読む）は、`init` は `core.hooksPath` を設定せずに残し、何をすべきかを出力します。グローバルの `core.hooksPath` があると `.git/hooks` のファイルは決して走らなかったので、`init` はそれらを省きます。そのようなフックが落とされる間は、`doctor` はコミットチェックを done と数えません。`init` が残すプロジェクト自身のワークフローには、`doctor` が足すべきステップを与えます。

`init` は三つのワークフローを `.github/workflows/` にも書きます。`yokoten.yml`（コミットチェック、actionlint と zizmor の lint ジョブ、必須チェックを作る `ci` ジョブ一つ）、`pr.yml`、`issue.yml` です。各アクションはコミットに固定され、各ジョブに時間制限があり、チェックアウトはトークンを保たず、`yokoten.yml` では同じプルリクエストへの新しい push が古い実行を取り消します。`main` への push は何も取り消しません。どのコミットも単独でテストされます。`pr.yml` は何も取り消しません。その実行はどの順でも始められるので、各実行はジョブのトークンで、プルリクエストのタイトル、本文、ラベル、マイルストーンを今のまま読み、再実行はまた読みます。あなたのテストは `yokoten.yml` のジョブとして足し、`ci` の `needs` 一覧にも足してください。非公開リポジトリは CI を切っておけます。[CI なしの非公開リポジトリ](https://yokoten.app/ja/docs/guide/install-and-commands.md#ci-なしの非公開リポジトリ)を見てください。

`yokoten.yml` と `pr.yml` は `merge_group` でも走るので、マージキューはプルリクエストと同じ必須チェックを走らせます。マージグループの実行にはプルリクエストがありません。`yokoten.yml` はすべてのジョブを完全に走らせ、`pr` ジョブは飛ばします。キューには緑と数えます。キューはリポジトリの設定でオンにします。`issue.yml` はそこで決して走りません。issue はマージのチェックではないからです。

ワークフローがすでにあるとき、`init` はあなたが変えたかを確かめます。キットは書いたすべての版の一覧を保ちます。そのどれかと一致するファイルは、Windows の行末でもそうでなくても、あなたが変えていない複製です。`init` はそれを最新版に更新し、そう言います。`init` は決してコミットしないので、`git restore <file>` で古いものを戻せます。あなたの変更があるファイルはそのまま残ります。`init` と完全な `doctor` は、キットの最新の複製と比べるコマンドを示します。`doctor` はキットの版ごとに一度そう言います。シンボリックリンクもそのまま残ります。`init` は決してリンクを通して書きません。

`yokoten.yml` では、`changes` ジョブがプルリクエストの変えるファイルを読みます。各ファイルが `docs/` か `changes/` の下、または `README.md` か `CHANGELOG.md` なら、そのプルリクエストは docs のみです。あなたのジョブは docs のみのプルリクエストを飛ばせます。`ci` の上のコメントが、足す二行を示します。`ci` はその飛ばしを緑と数えます。コミットチェックと lint ジョブは常に走ります。main への push はすべてのジョブを走らせます。ファイルの一覧を読めないプルリクエストも同じです。警告がそう言います。yokoten 自身の CI では、docs のみのプルリクエストは Ubuntu と Node 24 でテストを一度だけ走らせ、`typecheck` と Action のジョブを飛ばします。

`.github/` にも三つの安全な既定を置きます。

- `dependabot.yml` は、CI が走らせるアクションと、`init` が見つけたパッケージ（npm、cargo、pip、Go など。ルートと一つ下のフォルダ）を更新します。それぞれに月一つのプルリクエストを開き、リリースは一週間たってからだけ取り込みます。すでにあるファイルは残し、`init` は更新しないパッケージを名指しします。
- `SECURITY.md` は、脆弱性を公開の issue ではなく非公開で報告するよう求めます。そのために非公開の脆弱性報告をオンにしてください。`doctor` がそれをほかのセキュリティのスイッチと一緒に一覧します。
- `CODEOWNERS` は、既定でリード専用のすべてのパスにオーナーを名指しします。`AGENTS.md`、`yokoten.json`、`.yokoten/`、フック、エージェントの設定、`.github/` です。番人はマシン上でワーカーを止め、このファイルは同じ変更をサーバー上で止めます。オーナーは GitHub の `origin` リモートのアカウントです。それがなければ、ファイルには仮の値が入ります。リポジトリを作り、リモートを足して push すると、`doctor` があなたの GitHub のハンドルを入れるよう頼みます。GitHub は組織をオーナーに取らないので、`gh` がアカウントを組織と言うときもファイルには仮の値が入り、`init` は人か `@org/team` を求めます。完全な `doctor` は、オーナーが組織だけのファイルに印を付けます。それが効くのは、ブランチ保護で「Require review from Code Owners」がオンのときだけです。プロジェクトがすでに持つ CODEOWNERS ファイル（`.github/`、ルート、`docs/` のどれか）はそのまま残ります。

| コマンド | すること |
|---------|--------------|
| `install` | 入口のスキル `yokoten` 一つを `~/.claude/skills` と `~/.agents/skills` に、エージェントを `~/.claude/agents` に、SessionStart の `doctor` フックとユーザーレベルのコマンドの番人と空の非公開の印のファイルを入れます。書く前に、書くファイルと設定キーを表示します。二つのフックは Claude Code に入り、`~/.codex` や `~/.gemini` がすでにあるときは Codex と Gemini CLI にも入ります。Claude Code のプラグインがオンのときは、グローバルのスキル、エージェント、フックを書かず、古い `install` が書いたものを取り戻します。このマシンで見つけた印を足し、git の mailmap のファイルを書きます。git のグローバルの `mailmap.file` を設定する前には尋ねます。[プライバシー](https://yokoten.app/ja/docs/guide/privacy.md)を見てください |
| `init [dir]` | 実践をプロジェクトに入れます。ファイルを足し、すでにあるものは残してそう言います。あなたが変えていないキットのワークフローは最新版になります。GitHub も `gh` を通して読み、足す標準のラベルとマイルストーンを言います。GitHub は決して変えません。`gh`、サインイン、GitHub のリモートがないときは、飛ばしたものを言います |
| `init --github --yes [--remove-default-labels] [--board]` | 足りない標準のラベルと、開いているマイルストーンがないときは「First release」を足します。閉じたマイルストーンがすでにそのタイトルを持つときは、新しいものは「Next release」です。閉じたマイルストーンは決して開き直しません。すでにある標準のラベルは標準の色と説明になります。`yokoten.json` の領域が 8 つ以下なら、領域ごとに灰色のラベルを一つ足します。二回目の実行は何も変えません。その集合の外の GitHub の既定のラベル（`question`、`wontfix` など）は `--remove-default-labels` のときだけ消します。`--board` はリポジトリにリンクしたボードも作ります。gh トークンの `project` スコープが要ります |
| `init --no-ci` | CI を切っておきます。`yokoten.json` の `"notNow"` に `"ci"` を足し、ワークフローも Dependabot の設定も書かず、それらがまだキットの複製なら消します。[CI なしの非公開リポジトリ](https://yokoten.app/ja/docs/guide/install-and-commands.md#ci-なしの非公開リポジトリ)を見てください |
| `update [dir] [--write] [--all]` | 既定では変わったルールごとに1行、`--all` は変わった行をすべて示します。この yokoten がプロジェクトの `AGENTS.md` の核心ルールに何を変えるかを示します。`--write` はそれを置き換え、「This project」の部分はそのまま保ちます。[ルールを更新する](https://yokoten.app/ja/docs/guide/install-and-commands.md#ルールを更新する)を見てください |
| `doctor [--session] [--json]` | 道: すべての関所とステップ、そしてこのマシンに足りないもの。`--session` はセッションの始めのために次のステップだけを出力します。`--agent gemini` を付けると、Gemini CLI が読む JSON としてステップを出力します |
| `adopt [--json]` | 古いプロジェクトの導入の表の下書き: 今日どうしているかと、各ステップへの提案された決断。`--json` は行を出力します。何も書きません |
| `check [--staged] [--all] [--json]` | 1画面：問題はすべて示し、注意は件数にまとめます。`--all` は注意を1つずつ示します。ツリーまたは次のコミットの、レイアウト、プライバシー、リード専用ファイル。コミットはビルドの出力やバイナリを足せません。各変更ファイルは `changelog` が読むように読むので、間違ったものはコミットで失敗します。何もステージしていないとき、`--staged` はそう注意し、問題なしとします。ツリーでは、英語の元より遅れた翻訳は注意です。[翻訳](https://yokoten.app/ja/docs/guide/install-and-commands.md#翻訳)を見てください |
| `check --pr` | CI で: プルリクエストのタイトル、`tier:` の行、節、リンクした issue、変更ファイル、マイルストーン、ラベル。最後の行は各 AI とモデルを名指しします。`🤖 Made with <agent> (<model>)` で、一つ以上のカンマ区切りの組です。レビュアーを足せます。`🤖 Made with worker <X> (<model>), reviewed by <Y> (<model>) and <Z> (<model>), lead Claude Code (<model>)`（レビュアーは一人か二人、決してそれ以上ではない）。CODEOWNERS が持つファイルには `tier: A` が要ります。変更された Markdown の長い文、変更されたコードの読みにくい名前、400 行を超える差分は注意です |
| `check --pr <number>` | CI のないリポジトリのために、`gh` を通して一つのプルリクエストに同じチェックをします。[CI なしの非公開リポジトリ](https://yokoten.app/ja/docs/guide/install-and-commands.md#ci-なしの非公開リポジトリ)を見てください |
| `check --issue` | CI で: issue のタイトルとラベル。[issue のタイトル](https://yokoten.app/ja/docs/guide/install-and-commands.md#issue-のタイトル)を見てください |
| `redact` | stdin のテキストを読み、あなたの詳細を隠して書きます。`<owner>`、`<email>`、`<host>`、`<mark>` です。ツール呼び出しの番人は危険なコマンドをこれに通します。[プライバシー](https://yokoten.app/ja/docs/guide/privacy.md)を見てください |
| `marks allow <mark> --here` | あなたの非公開の印の一つを、このリポジトリでだけ通します。`yokoten.json` は要りません。許可はこのマシンに保ち、リポジトリには決して入れません。`--remove` で取り消します。[プライバシー](https://yokoten.app/ja/docs/guide/privacy.md)を見てください |
| `changelog [--write]`、`changelog --notes <バージョン>` | `changes/` のファイルが `[Unreleased]` の下に足す項目を示します。`--write` はそれらを `CHANGELOG.md` に入れてファイルを消します。`--notes` はそのバージョンのリリースノートを `CHANGELOG.md` の節から作るので、二度書く必要がありません。リリースの前に走らせてください。[変更履歴](https://yokoten.app/ja/docs/guide/install-and-commands.md#変更履歴)を見てください |
| `learn <issue> [--write]` | インシデントの issue からチェックを下書きし、人がレビューします。`--write` は `lessons/` にファイルを足します。[インシデントから学ぶ](https://yokoten.app/ja/docs/guide/install-and-commands.md#インシデントから学ぶ)を見てください |
| `learn --ship <id>` | yokoten で: レビュー済みの教訓を `kit/lessons/` のグループに移し、そこから走る yokoten の `doctor` がすべてのプロジェクトでそれを走らせます。`TODO(reviewer)` が残っていたり、そのテストが失敗したりする間は拒否されます |
| `learn --upstream "<what happened>" [--area <name>] [--fix <idea>]` | yokoten 自身の隙間についての注意を、プロジェクトとあなたを隠して保ちます。`--list` は注意を一覧し、`--done <id>` は一つを消します。[yokoten 自身のための教訓](https://yokoten.app/ja/docs/guide/install-and-commands.md#yokoten-自身のための教訓)を見てください |
| `check --history` | すべてのブランチのすべてのコミットへのプライバシーチェック。非公開リポジトリを公開する前に走らせてください。浅いクローンは古いコミットを見られないので、スキャンせずに失敗します。CI では履歴全体をチェックアウトしてください（`fetch-depth: 0`）。ファイルの当たりは、それを足したコミットと、そのコミットでのパスを名指しします。`file @ <commit>` です。`git replace` より先のコミットも読み、grafts のファイルがコミットを隠しうるときも同じように失敗します。 |
| `hook [--agent <name>] [--commands-only] [--json]` | ツール呼び出しの番人。stdin で一つのツール呼び出しを読みます。既定は Claude Code の PreToolUse 呼び出し、`--agent codex` で Codex の PreToolUse 呼び出し、`--agent gemini` で Gemini CLI の BeforeTool 呼び出し、`--agent antigravity` で Antigravity CLI の PreToolUse 呼び出し、`--agent muse` で Muse Code の PreToolUse 呼び出し、`--agent deepseek-harness` で DeepSeek Harness の PreToolUse 呼び出し、`--agent grok` で Grok CLI の PreToolUse 呼び出し、`--agent opencode` で OpenCode のツール呼び出し |
| `hook --stop [--agent <name>]` | 停止チェック。stdin でターン終了のイベントを読み、変更されたファイルをチェックします。既定は Claude Code の Stop か SubagentStop のイベント、`--agent codex` で Codex の Stop イベント、`--agent muse` で Muse Code の Stop イベント、`--agent gemini` で Gemini CLI の AfterAgent イベント、`--agent grok` で Grok CLI の Stop イベント。ワーカーはタスクの done-when のコマンドも走らせます。[停止チェック](https://yokoten.app/ja/docs/guide/install-and-commands.md#停止チェック)を見てください |
| `explain [<id>] [--json]` | ルールか道のステップ: 何か、なぜか、yokoten がどうチェックするか |
| `worker mark <dir>` | `<dir>` のワークツリーをワーカーのものとして印を付けます。すると番人はそこにいるすべてのエージェントをワーカーとして扱います。`YOKOTEN_ROLE` を落とす実行環境（Muse Code）のエージェントもです。番人はワーカーが印を消す素朴な方法を拒否し、読めない `.git` のリンクは印ありと数えます。本当の錠はサーバーとワーカーから保たれる資格情報です。`git worktree remove <dir>` が印を消します。サブフォルダを渡すと、ワークツリーの一番上のフォルダに印を付け、どれかを言います。デスクのような普通のクローンにも印を付けます。印はその `.git` に入ります（#672）。リードは自分のチェックアウトからクローンに印を付けます。メインのチェックアウト（リードが走るクローン、またはワークツリーを持つもの）とサブモジュールには決して印を付けません。ワーカーは印を付けられず、外せません。[対応しているもの](https://yokoten.app/ja/docs/guide/works-with.md)を見てください |
| `worker env [runtime]` | yokoten のエージェント環境がこのシェルから保つ名前を一覧し、落とす名前を数えます。実行環境を渡すと、そのログイン名も数えます。値は決して見せません。`desk` はこれを使ってエージェントを始めます。[エージェントの環境が持つもの](https://yokoten.app/ja/docs/guide/privacy.md#エージェントの環境が持つもの)を見てください |
| `msg send <to> [<text>]`、`msg inbox`、`msg who`、`msg log` | どのベンダーのエージェントも、このマシンのファイルを通して互いにメッセージを送ります。`log` はリードだけが走らせます。[エージェント同士のメッセージ](https://yokoten.app/ja/docs/guide/managing-agents-like-a-team.md#エージェント同士のメッセージ)を見てください |
| `desk [<issue> \| "<task>"] [--agent <name>] [--pr] [--no-install]` | 引数なしなら、デスクを一覧し、何も書きません。issue 番号かタスクを渡すと、デスク `../<repo>-desks/<n>/`（自分のクローン、ブランチ `desk/<n>`）を作り、ブリーフを書き、囲いの中で AI（まず Claude Code）を始めます。AI が終わると、囲いの中でチェックとテストを走らせ、一画面で証拠を見せます。push はしません。`--pr` でブランチを push し、プルリクエストを開きます（bot があれば bot で）。途中で止まったデスクは次の起動で見え、`desk <n>` で最後のコミットから続けます。ネイティブの Windows では WSL で走らせてください |
| `desk <agent> <folder> [--name <name>] [--read <paths>] [--host <hosts>] [--marks] -- <command>` | ワーカーのエージェントを囲われたデスクで始めます。自分のクローン、自分の状態フォルダ、そして自分のモデルの API 以外のネットワークなしです。走らせるのはリードだけです。[デスク](https://yokoten.app/ja/docs/guide/managing-agents-like-a-team.md#デスク)を見てください |
| `uninstall` | `install` が書いたものを取り消します。yokoten が管理すると印を付けた入口スキルとエージェント、Claude Code、Codex CLI、Gemini CLI、Antigravity CLI、Copilot CLI、Grok CLI、Muse Code の設定にあるフック、OpenCode のプラグイン、`~/.local/share/yokoten` です。非公開の印と mailmap のファイルは、`install` の見出しだけのときに消します。`install` が作ったフォルダと git の設定ファイルは、空のときに消します。`install` の前からあったフォルダは残ります。あなた自身のファイル、編集、設定は残ります。止めた記録は消えます。二回目の実行は何も変えません |
| `bot -- <command>` | 一つのコマンド（`gh`、`git push`）を、決して出力しない一時間のトークンでボットとして走らせます。`gh issue` や `gh pr` の `create` か `edit` にタイトルがあるときは、CI のルールでタイトルをチェックします。悪いタイトルは拒否され、何も送られません。issue やプルリクエストのパスへの `gh api` も同じようにチェックします。`--body` か `--body-file` があると、`gh pr create` と `gh pr edit` は、`check --pr` の本文のルールで本文もチェックします。プルリクエストのブランチと、基底ブランチの CODEOWNERS に対してです。悪い本文も拒否され、何も送られません。最後の行が `🤖 Made with <agent> (<model>)`（一つ以上のカンマ区切りの組）でない本文も拒否されます。各プルリクエストは、それを作った各 AI とモデルを名指しするからです。その行には `reviewed by <agent> (<model>)` を一つ、または `and` でつないだレビュアー二人まで足せます。決して三人以上ではありません。コメント（`gh pr comment`、`gh issue comment`）、本文のあるレビュー（`gh pr review --body`）、新しい issue（`gh issue create --body`）も同じ行を持ちます。最後の行が `Made with` の行でない本文は拒否されます。`--attach` のある注意は拒否されます。アップロードが `Made with` の行より後ろに着くからです。編集（`gh pr edit --body`、`gh issue edit --body`）はそのままです。タイプかティアのラベルのない `gh pr create` にはそれらを足します。タイプはタイトルから（`fix` なら `bug`）、ティアは本文の `tier:` の行からです。`gh pr edit` も、新しいタイトルや本文について同じことをし、本文が新しいティアを設定したときは古いティアのラベルを外します。あなたが渡したラベルは残ります。本文と一致しないティアのラベルは、`check --pr` のメッセージとともに拒否されます。リポジトリが持たないラベルは注意で名指しされ、省かれます。ボットは決してラベルを作りません。`--milestone` のない `gh pr create` は、最初のリンクした issue（`Closes #N`、`Part of #N`）のマイルストーンを受け取ります。リンクした issue がどれも持たないときは拒否され、何も送られません。`--milestone` を足してください。gh が issue を読めないときは、プルリクエストは注意つきでマイルストーンなしに送られます。走らせるのは `gh` と `git` だけなので、`env gh …` や `sh -c …` は拒否されます。gh のエイリアスは読まないので、それを通して設定したタイトルはチェックされません。設定: [server.md](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/docs/server.md#3-the-bot-a-github-app) |
| `kanban [--text] [--json] [--no-open]` | 古い名前の `board` も、`kanban` を名指す一行のあとで同じように走ります。このマシンでだけ動く読み取り専用のページを出します。セッション、あなたを待つプルリクエスト、Actions です。ページから仕事を始めたり止めたり変えたりはできません。ブラウザーでページをサインイン済みで開き、あなたが止めるまで走ります（`--no-open` はアドレスを出力するだけ）。サインインの鍵はブラウザーにだけ渡ります。`--text` は同じスナップショットを素のテキストで、`--json` はデータとして出力します。[チームのボード](https://yokoten.app/ja/docs/guide/managing-agents-like-a-team.md#カンバン)を見てください |
| `tidy [--local \| --empty [--yes]]` | 引数なしでは古いものを、できることごとに並べます。マージ済みかリモートで消えたブランチ、作業の残っていないワークツリーとデスク、消えたデスクのログです。各行に理由と大きさを書き、何も変えません。`--local` はまず一つずつ保存し（ブランチは bundle、未コミットの変更は patch、それに `index.json`）、そのあと `~/.local/state/yokoten/trash` の日時つきフォルダーへ移します。保存が一つでも失敗したら何も移しません。使用中のデスクやワークツリーには触れません。GitHub 上のブランチは一覧に出すだけです。`--empty` は一度たずねてから、7 日を過ぎたごみ箱のフォルダーを消します。端末がないときは `--yes` が要ります |

各コマンドは `--help` か `-h` で自分のヘルプを出力します。何をするか、オプション、例一つです。`yokoten help <command>` も同じものを出力します。`yokoten help` は最初に使う四つのコマンド `desk`、`kanban`、`check`、`tidy` を一覧し、`help --all` はすべてのコマンドを一覧します。移ったコマンドも走り、まず stderr に移った先を一行で言います。`yokoten version`（または `--version`、`-v`）はバージョンを出力します。ヘルプは何も変えず、0 で終わります。打ち間違いには、yokoten が一番近いコマンドかオプションを名指しします。`yokoten docter` は `unknown command docter` と言い、続けて `Next: \`yokoten doctor\`, if you meant it; \`yokoten help\` lists every command` と出します。`bot --` のあとは、すべての語がそれが走らせるコマンドのものです。だから `yokoten bot -- gh --help` は `gh --help` を走らせます。

`check`、`doctor`、`hook`、`explain`、`adopt` は `--json` を受け取ります。すると stdout は JSON だけを持ち、エージェントやスクリプトのためのものになります。エラーも JSON です。使用法のエラーやクラッシュは `{ command, ok: false, error }` を出力して終了コード 1 になり、メッセージはまだ stderr へ行きます。各指摘は同じフィールドを持ちます。`id`、`what`、`why`、`fix`、`docs`（ガイドがルールを説明しているときのリンク）、そしてファイルの中なら `file` と `line` です。`yokoten explain <id>` はその `id` を取ります。どのフィールドも非公開の値を持ちません。

- `check --json`: `{ check, ok, findings, notes }`。`check` は `tree`、`staged`、`history`、`pr`、`issue` のどれかです。注意がチェックを失敗させることは決してありません。CI の実行にプルリクエストも issue もないとき、`check --pr` と `check --issue` は ok で、`skipped` に理由を足します。
- `doctor --json`: `{ version, ok, selfTest, repo, stage, stages, next, findings, steps, notes, server, lessons }`。教訓の指摘は `notes` にあります。新しい教訓は `isNew: true` を持ちます。`--session` では、次のステップ、非公開の印の指摘、そしてルールが遅れているときの `core-rules` だけです。そのとき `notes` は、このマシンだけで作業する件と、セッションが今聞いた教訓の指摘（あれば）を持ちます。
- `hook --json`: 止めるとき `{ blocked: true, finding }`、通すとき `{ blocked: false, toolCall: true }`、stdin がツール呼び出しでないとき `{ blocked: false, toolCall: false }`。実行環境はこれを使いません。フックのプロトコルが言うとおり、終了コードと stderr の理由を読みます。
- `hook --stop --json`: `{ blocked, stop, findings }`。リードでは、`stop_hook_active` が `skipped` に理由を足します。ワーカーはそのフィールドがあってもチェックされます。チェック自体が失敗したときも `skipped` がそう名指しします。ワーカーの done-when チェックが失敗したときは `doneWhen` もです。試行の上限のあと、`skipped` は `stopped with failing checks` です。その停止は、リンクしたワークツリーの `.yokoten-agent.json` に `checks` を `failing` として書きます。そこの通過は `checks` を `passing` にします。stdin が Stop イベントでないときは `{ blocked: false, stop: false }`。
- `explain --json`: `{ found, id, kind, what, why, check, docs, stage, standard }`。知らない id では `{ id, found: false, ids }` で終了コード 1。id なしでは `{ ids }` で終了コード 0。

人向けの出力は一つのルールに従います。結果は stdout へ。拒否、エラー、`check` が見つけた問題は stderr へ。`doctor` の道の行（MISSING など）は結果の一部なので、stdout のままです。知らないオプションは拒否され、決して無視されません。

`init`、`update`、`doctor`、`check`、`adopt`、`bot` は git のリポジトリが要ります。外ではそう言い、何も書かず、終了コード 1 になります。`init <dir>` は存在しないフォルダも拒否します。`doctor --session` はリポジトリの外では静かにしています。そこのセッションが雑音を受け取らないようにです。

CI では、何が失敗したかを見るのにログを開く必要はありません。`check` が GitHub Actions で走るとき、各指摘はプルリクエストの変更行への注釈になります。ジョブの概要は各指摘を、場所、ルール、何が、なぜ、直し方とともに一覧します。ルールはこのガイドのその節へリンクします。注意は警告として出て、決してチェックを失敗させません。ほかの出力と同じく、これらは場所を名指しし、一致したもの自体は決して出しません。

## 終了コード

| コード | 意味 |
|------|-------|
| 0 | すべて問題なし。道に残ったステップは to do であり問題ではないので、`doctor` はそれらがあっても 0 を返します。`doctor --session` は常に 0 を返すので、セッションは常に始まります |
| 1 | 問題が見つかった: `check`、または `doctor`（失敗した自己テスト、MISSING と印を付けた core-rules、ツリー、マシンの行）、知らない id（`explain`）、使用法のエラー、yokoten 自身のエラー |
| 2 | フックがツール呼び出しを止めた、または停止チェックがエージェントを送り返した。理由は stderr にある |

これらのコードは変わりません。yokoten 自身は壊れたとき 1 を返します。しかし三つのエージェントすべてで呼び出しを止めるのは終了コード 2 だけなので、壊れた番人は呼び出しを通してしまいます。`init`、`install`、プラグインが書くツール呼び出しのフックは、ほかの終了を 2 に変えます。番人がクラッシュし、メモリを使い果たし、殺されたとき、呼び出しは一行で拒否されます。`` yokoten's guard failed (exit N), so the command is refused; run `yokoten doctor` `` です。その行が stderr のすべてです。node 自身のエラーとシェルの「Killed」の行は落とされます。二つの場合は 1 のままです。実行環境が消えたとき、または `node` がエージェントの PATH にないときは、フックが一行でそう言い、呼び出しは進みます。消えたフォルダや足りない node がすべてのツール呼び出しを止めるわけではないので、まだ `yokoten doctor` を走らせられます。停止チェックとセッションの doctor は失敗をそのまま渡します。

実行環境は、フックがタイムアウトを過ぎて走ったときも呼び出しを通します。だから呼び出しの読み取りに番人が 5 秒より長くかかる（`YOKOTEN_GUARD_DEADLINE_MS` で変えられ、最大 30 秒）か失敗すると、番人は呼び出しを 2 で拒否します（`unreadable-command`）。

## マシンについての注意

マシン上のいくつかの問題は、すべてのエージェントのセッションを止め、エージェントには見えません。完全な `doctor` はそれらを `machine:` の下に注意として一覧します。注意が終了コードを変えることは決してありません。[記録 0012](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/docs/records/0012-machine-checks.md) が、doctor がどの問題を探すかと、なぜかを書いています。

- **disk-space**: リポジトリのあるディスクの空きが少ない。満杯のディスクはすべてのセッションを止めます。doctor は 20 GB を下回り、かつディスクの 10% を下回るときに警告します。`YOKOTEN_MIN_FREE_GB` で別の上限にし、`0` で警告を切れます。セッションもこの注意を聞きます。
- **host-disk**、WSL 2 でだけ: Linux のディスクファイルのある Windows のドライブ。WSL の中では、`df` はディスクファイルの大きさを見せ、そのドライブの空きは見せません。完全な `doctor` は `reg.exe` を通してドライブを読み、多くても 3 秒待ちます。読み取りは `~/.config/yokoten/machine.json` に保ちます。セッションはプログラムを走らせません。最後の読み取りが低く、それが 7 日以内なら、それを繰り返します。ドライブをもう一度読むには `yokoten doctor` を走らせてください。`WSL_DISTRO_NAME` がないと（`sudo` の下など）、doctor はドライブを見つけられず、何も言いません。VM のディスクファイルは大きくなるだけです。VM の中でファイルを消しても、Windows のドライブは空きません。だから注意はこう言います。まず作業を別のドライブにバックアップしてください。そのあと Windows のドライブを空けるか、[Microsoft のガイド](https://learn.microsoft.com/windows/wsl/disk-space)でディスクファイルを縮めるか移してください。yokoten は WSL の疎なモードを勧めません。WSL が安全でないと印を付けるからです。
- **agent-temp-dir**: Claude Code の一時フォルダ `claude-<uid>` を別のユーザーが所有している。フォルダは `CLAUDE_CODE_TMPDIR`、なければ `TMPDIR`、既定では `/tmp` にあります。root のプロセスが先にフォルダを作ったとき（再起動のあとなど）に起こります。すると Claude Code は始まりません。注意は引用符つきで `sudo rm -rf '<folder>'` を出力します。あなた自身で走らせてください。doctor は決して何も消しません。
- **leftover-temp-folders**: 一時フォルダにある一日より古い `yokoten-*` のフォルダ。テストの実行がそれらを残し、何千もたまるとディスクが満杯になります。完全な `doctor` がそれらを数えます。大きさは足し上げないので、速いままです。注意は古いものだけを消す `find ... -exec rm -rf` のコマンドを出力します。あなた自身で走らせてください。doctor は決して何も消しません。
- **node-security**: yokoten を走らせる Node に、2026-10-21 のセキュリティ修正がない。その系統の修正（22.23.4、24.22.1、26.12.1）より古いリリースには知られた穴があります。修正が来なくなった系統（23、25、22 より下など）はサポートされません。注意は入れるべきバージョンを名指しします。完全な `doctor` でだけ、そして決して失敗にはしません。

## トラブルシューティング

**エージェントが始まらない。** そのときは理由を言えません。プロジェクトのターミナルを開き、`npx yokoten doctor` を走らせてください。`machine:` の下の行を読んでください。満杯のディスクと、root が所有する一時フォルダがよくある原因です。各注意が、直すコマンドを出力します。
## 停止チェック

ツール呼び出しのフックはコマンドを読みます。`sed` やスクリプトが変えたファイルは見えません。コミットチェックはそれを見ますが、コミットのときだけです。停止チェックはもっと早く走ります。エージェントがターンを終えようとするときです。Claude Code、Codex、Muse Code、Grok CLI では Stop イベント、Claude Code では SubagentStop、Gemini CLI では AfterAgent です。

```mermaid
flowchart LR
  S["エージェントがターンを終える"] --> U{"サブエージェントで、その種別がワーカーでない?"}
  U -- はい --> N["ターン終了、チェックなし"]
  U -- いいえ --> W{"ワーカー?"}
  W -- いいえ --> A{"すでに一度送り返した?"}
  A -- はい --> E["ターン終了"]
  A -- いいえ --> C{"変更されたファイルに指摘?"}
  C -- いいえ --> E
  C -- はい --> B["エージェントが指摘を受け取り、直す"]
  W -- はい --> D{"done-when チェックが通る?"}
  D -- はい --> E
  D -- いいえ --> K{"試行回数は保存済み?"}
  K -- いいえ --> H{"stop_hook_active、または過去 5 分に拒否された?"}
  H -- はい --> X["停止を許す。チェックはまだ失敗中"]
  H -- いいえ --> F["一度だけ拒否。次の停止は通す"]
  K -- はい --> T{"この試行は 1、2、3 のどれか?"}
  T -- はい --> F2["ワーカーが出力を受け取り、直す"]
  T -- いいえ --> X
```

- 変更されたファイルだけをチェックします。ステージ済み、未ステージ、そして git が無視しない新しいファイルです。`check --staged` のプライバシー、秘密情報、ファイルのルールを使います。
- サブエージェントは、その種別がワーカーのときだけチェックされます。親セッションの役割は数えません。ワーカーが始めたレビュアーはチェックされません。その停止は 0 で終わります。種別がワーカーなのは、`worker` のとき、または `:worker` で終わるときだけです。`coworker` と `code-worker` はワーカーではありません。そのようなエージェントには `worker` と印を付けるか、`:worker` で終わる名前を使ってください。レビュアー、Explore エージェント、検証役はチェックされません。
- リードでは、エージェントを一度だけ送り返します。エージェントはそのあと `stop_hook_active` を設定し、次の停止は必ずターンを終えます。ループはありません。
- ワーカーでは、タスクの done-when のコマンドも走らせます。コマンドは `YOKOTEN_DONE_WHEN`、またはワークツリーの git フォルダの `yokoten-done-when` から来ます。両方あるときは環境変数が勝ちます。ブリーフにないときは、変更されたファイルのチェックがプロジェクトのチェックです。
- コマンドはその環境のシェルを使います。Linux と macOS では `sh`、Windows では `cmd.exe` です。二分会走ることがあります。タイムアウトでは、yokoten はコマンドと、それが始めたすべてのプログラムを止めます。Windows では、シェルがまだ走っている間にその木を止めます。
- 失敗したチェックはワーカーを送り返し、出力を短く、何を直すかとともに渡します。ワーカーには三回の試行があります。三回目で、フックは次の停止を通すと言います。ワーカーのリードへの最後のメッセージは `NOT DONE: checks failing` で始まらなければなりません。失敗した出力を引用しなければなりません。タスクは done ではありません。
- 許された停止は、リンクしたワークツリーのルートに `.yokoten-agent.json` を書きます。メインのチェックアウトではそのファイルを書きません。`checks` を `failing` に、`updated` を UTC の時刻にします。通過は `checks` を `passing` にします。ほかのフィールドは残ります。リードがそのファイルを読みます。カンバンは `checks` をコミットチェックとして示します。許された停止の stderr は誰にも届きません。yokoten が読めない状態ファイルは変えずに残し、停止チェックが理由を言います。
- 試行回数を保存できないときは、一度の拒否が次の停止を通すと言います。同じワーカーは、過去 5 分に拒否されていても通されます。実行環境が `stop_hook_active` を決して設定しないときもです。ワーカーが罠にかかることは決してありません。回数はチェックが通ったとき消え、ワーカーが通されたときにもまた消えます。再開したワーカーは試行 1 からチェックされます。一日より古い回数のファイルは、新しい回数を書くときに消します。
- サブエージェントのワーカーは、リードのフォルダと環境を共有します。自分の `YOKOTEN_DONE_WHEN` は受け取りません。チェックはイベントのフォルダで走ります。ワーカーのワークツリーで走るのは、停止イベントがそのワークツリーを名指しするときだけです。
- DeepSeek Harness、Antigravity CLI、OpenCode には停止フックがありません。リードがチェックを走らせます。
- Claude Code、Codex、Muse Code、Grok CLI は、このフックを 600 秒待ちます。Gemini CLI は `timeout` をミリ秒で読むので、そのフックは 600000 ミリ秒待ちます。どれも 10 分です。二分のコマンドを覆います。Muse Code の設定のフック（`.muse/hooks.json` を含む）も `timeout` を秒で読みます。
- 履歴を読まず、ネットワークを使いません。
- yokoten のエラーでは、ターンが終わり、stderr に一行が出ます。
- チェックから外したい新しいファイルは `.gitignore` か、`yokoten.json` の `privacy.skip` に入れます。

`init` はフックを `.claude/settings.json`（Stop と SubagentStop）、`.codex/hooks.json`（Stop）、`.muse/hooks.json`（Stop）、`.gemini/settings.json`（AfterAgent）、`.grok/hooks/yokoten.json`（Stop）に足します。Claude Code、Codex、Muse Code、Grok CLI は 600 秒待ちます。Gemini CLI は 600000 ミリ秒待ちます。`install` はユーザーレベルでは足しません。ファイルを読むので、ツール呼び出しのフックのファイルのルールと同じく、各プロジェクトがオンにします。

コミットチェックは、`dist/`、`build/`、`out/` フォルダのファイルと、バイナリのファイルを拒否します。ビルドはそのようなファイルをまた作り、レビュアーはバイナリを読めません。画像とフォント（`png`、`jpg`、`gif`、`webp`、`svg`、`ico`、`woff`、`woff2`）は通ります。それでもファイルを残すには、`yokoten.json` にグロブとして並べます。`"allowBuild": ["docs/manual.pdf"]` です。

## 止められるコマンド

プロジェクトの技術スタックのルール、たとえば「Python 禁止」や「yarn 禁止」は、エージェントがタスクの途中で忘れがちです。AGENTS.md にだけ書いてあれば、それは願いです。プログラムを `yokoten.json` に理由つきで並べれば、ツール呼び出しの番人がそのルールを保ちます。

```json
"commands": {
  "block": {
    "python": "this project is TypeScript only",
    "python3": "this project is TypeScript only"
  }
}
```

すると番人は `python3` を走らせるコマンドを、リードにもすべてのワーカーにも止めます。メッセージはプログラムを名指しし、あなたの理由を与え、プロジェクト自身のスタックを使うようエージェントに伝えます。

- 番人は各コマンドのプログラムを、その名前で見ます。`/usr/bin/python3` と `python3.exe` は `python3` と数えます。
- コマンドのすべての部分を数えます。`a && b`、`a | b`、`a; b`、`$(...)`、そしてシェルが走らせる文字列です。`bash -c '...'`、`ssh host '...'`、`flock file -c '...'` です。
- 代入、リダイレクト、起動役、シェルのキーワードはプログラムを隠しません。`X=1 python3`、`2>/dev/null python3`、`env`、`sudo`、`nice`、`timeout`、`xargs`、`setsid`、`stdbuf` のような起動役、`if`、`for`、`while`、`!` のあとのコマンド、`find -exec` が走らせるプログラム、`env -S` の文字列です。
- 名前を持つだけの語は通ります。`echo python`、`cat python.md`、`pythonic`、`python3)` のような `case` のパターンです。`command -v python3` も通ります。プログラムがどこにあるかを言うだけだからです。
- 名前にフォルダも空白もありません。`"commands"` の間違った形は、[yokoten.json](https://yokoten.app/ja/docs/guide/install-and-commands.md#yokotenjson) のどのキーと同じく設定のエラーです。すると番人はどのプログラムも止めず、そう言い、核心のチェックはまだ走ります。

番人はコマンドのテキストを読みます。スクリプト、`make` のターゲット、npm のスクリプト、シェル関数が走らせるプログラムは見えません。止めたい各版を名指ししてください。`python3.12` は `python3` ではありません。

## yokoten.json

リポジトリのルートの `yokoten.json` がプロジェクトの設定を持ちます。どのキーも任意です。キーがない、キーが `null`、ファイルがない、のどれでも既定になります。

| キー | でなければならないもの | 既定 |
|-----|---------|---------|
| `layout` | `{ "maxEntries": 7, "exempt": ["docs/records"] }`: 0 より大きい整数と、フォルダかグロブの一覧 | 7、除外するフォルダなし |
| `tests` | グロブの一覧 | `*.test.*`、`*.spec.*`、`*_test.go`、`test/**`、`tests/**` |
| `leadOnly` | グロブの一覧 | ルール、エージェントの設定、フック、CI |
| `privacy` | `{ "allow": [], "skip": [], "utc": true, "output": "run", "skipOwnName": true }`: テキストの一覧二つ、true か false、`"run"` か `"stop"`、true か false | ロックファイルを飛ばし、UTC はオン、output は run、自分の名前は飛ばす |
| `notNow` | ステップ名ごとの理由: `{ "ci": "no remote yet" }` | なし |
| `allowBuild` | グロブの一覧 | なし |
| `areas` | 語の一覧 | 小文字の任意の語 |
| `translations` | `{ "fail": true }` | `false` |
| `commands` | `{ "block": { "<program>": "<reason>" } }` | 止めるプログラムなし |

yokoten は各キーをこの表と、一か所で照らします。

- 形の間違ったキー（`"leadOnly": "x"` など）は設定のエラーです。`check` と `doctor` は終了コード 1 になります。メッセージは間違ったキーを一つずつ名指しし、どうあるべきかを言うので、一度の実行ですべて分かります。
- ツール呼び出しのフックは、そのあとそのキーの既定を使います。stderr に一行でそう言い、核心のチェックはまだ走ります。オブジェクトの中の間違ったフィールド（`layout.maxEntries` など）は、そのフィールドだけ既定になります。間違った `"commands"` は止める一覧全体を落とします。
- `yokoten.json` が正しい JSON でないとき、または一つの JSON オブジェクトでないときは、`check` と `doctor` が設定のエラーを報告します。フックはそのあとすべての既定を使い、一行でそう言い、核心のチェックはまだ走ります。
- yokoten が知らないキーは `check` の注意で、決してエラーではありません。新しい yokoten のために書いた設定が、古い yokoten でも動くようにです。オブジェクトの中の知らないフィールド（`"commands": { "blok": ... }` など）も注意です。

## issue のタイトル

issue のタイトルは領域を名指しし、そのあと作業を名指しします。すると issue の一覧が、これからのコミットの一覧のように読めます。

- タスク: `area: verb phrase`。たとえば `doctor: add the review step` です。
- インシデント: `area: symptom`。たとえば `check: misses a key in a JSON file` です。直し方ではなく、見たものを名指ししてください。
- 60 文字まで。最後にピリオドを付けません。`#N` を入れません。ほかの issue は本文でリンクします。
- 領域は小文字の一語か、ハイフンでつないだ語です。
- タイプのラベル一つ（`feat`、`bug`、`docs` など）と、ティアのラベル一つ（`tier A`、`tier B`、`tier C`）。リポジトリにそのラベルがあるときだけです。タイプもティアもないリポジトリには行を足しません。

`init` は `.github/workflows/issue.yml` を足します。issue が開かれたり編集されたりしたときに `check --issue` を走らせます。タイトルとラベルをチェックします。タイプのラベル一つとティアのラベル一つで、リポジトリにそのラベルがあるときだけです。読むだけで、issue にコメントしたり名前を変えたりは決してしません。赤い実行は、著者にタイトルかラベルを直すよう伝えます。リポジトリがどの種類を持つかは、チェックが `gh` を通してラベルを一覧して知ります。`gh` が一覧できないときは、タイトルだけをチェックします。

エージェントのタイトルは、送られる前にチェックされます。`yokoten.json` のあるリポジトリでは、ツール呼び出しの番人が `gh issue create|edit` と、タイトルのある `gh pr create|edit` に同じチェックを走らせます。直接でも `yokoten bot` を通してもです。悪いタイトルはコマンドを止めるので、CI がそれを見ることは決してありません。`yokoten bot` は、リポジトリが持つタイプかティアのラベルのない `gh issue create` も拒否します。悪い issue が送られないようにです。ユーザーレベルのフックはタイトルをチェックしません。ほかのプロジェクトには自分のルールがあるからです。

小文字の領域なら何でも通ります。領域を限るには、`yokoten.json` に並べます。`"areas": ["doctor", "check", "docs"]` です。プルリクエストのタイトルも同じ一覧を `type(area): summary` で使います。

## 変更履歴

ユーザーが気づくものを変えるプルリクエストは、小さなファイルを一つ足します。`changes/<issue>-<slug>.md` です。`CHANGELOG.md` は編集しません。どのプルリクエストも同じファイルの先頭に行を足すと、マージのたびにほかが衝突します。別々のファイルは決して衝突しません。

ファイルは素の Markdown です。1 行目は節です。Added、Changed、Deprecated、Removed、Fixed、Security、Internal のどれかです。2 行目は空です。3 行目から、変更履歴に載るべき形で項目を書きます。`- ` はこちらで足します。一つのファイルに複数の箇条書きを入れても構いません。項目に見出しはなく、ファイルは `changes/` の直下の素のファイルです。フォルダの中やリンクの先ではありません。

```markdown
Fixed

`doctor` no longer stops when the repo has no remote (#42).
```

`yokoten changelog` はファイルが足すものを示し、何も書きません。リリースの前に、`yokoten changelog --write` が各項目を `[Unreleased]` のその節の下に入れ、使ったファイルを消します。リリース済みの版には決して触れません。ファイルが間違っていれば、どのファイルがなぜかを言い、何も書きません。

`check --pr` は `changes/` の新しいファイルをプルリクエストの変更履歴の項目として受け取り、その形をチェックします。`CHANGELOG.md` の行もまだ通ります。まだ移っていないプロジェクトのためです。`check` は `changes/` のファイルを同じように読み、`check --staged` はステージされたものを読みます。だから git のフックが、CI より先に、コミットで間違ったファイルを止めます。ステージされた変更ファイルの長い文にも注意します。まだ git に足していない変更ファイルも数えます。`changelog` と同じです。`init` は形を示す `changes/README.md` を足します。`changes/` は 7 ファイルより多く持てます。リリースのたびに空になるからです。

## 翻訳

英語が元で、翻訳はそれに従います。英語のテキストが変わると翻訳は遅れ、誰もそれを見ません。だから翻訳された各ファイルは、1 行目に元を名指しします。HTML のコメントで、GitHub は表示しません。

```markdown
<!-- source: docs/guide.md -->
```

パスはリポジトリのルートからの英語のファイルです。相対パスだけが印です。`<!-- source: https://example.com/post -->` のような帰属のコメントや、絶対パスはそのままにします。この行は一度だけ書き、決して変えません。英語を変えたら、同じコミットかプルリクエストで翻訳を更新します。

`check` は各 Markdown と HTML ファイルの 1 行目を読みます。そのあと現在のブランチのコミットを、最初の親だけを、翻訳を足したコミットまでさかのぼって読みます。英語を変えて翻訳を変えないコミットは、翻訳を一つ後ろにします。あとで翻訳だけを変えるコミットが追いつきます。両方を変えるコミットは問題ありませんが、その前の英語だけのコミットを覆うことはありません。だから、あるプルリクエストが英語だけを変え、別のものが両方を変えると、どちらが先にマージされても最初のものが注意されます。翻訳のどの行も数えます。

なぜ英語の版を記録する行にしないのか。英語を変えるすべてのプルリクエストが、その行を編集することになるからです。そのような二つのプルリクエストは、必ずそこで衝突します。決して変わらない行なら、並行するプルリクエストは自分が翻訳する段落だけに触れます。

代償です。第一に、翻訳だけを変えるコミットは、その前のすべての英語の変更に追いつきます。翻訳の誤字の修正が、誰も翻訳していない英語の変更を隠せます。だから誤字を直す前に `check` を走らせてください。翻訳が遅れていると注意されたら、先に翻訳を更新します。第二に、squash マージでは、英語だけのプルリクエストは、翻訳だけを変えるコミットが来るまで注意されたままです。あとで別のプルリクエストが自分の変更と一緒に翻訳してもです。注意を消すには、翻訳をそれだけのプルリクエストで更新してください。

作業ツリーでは、翻訳だけの編集は後の変更と数えます。英語だけの編集は翻訳を遅れさせます。両方の編集は両方を変えるコミットと数えます。

翻訳が遅れているとき、`check` は `translation-behind` の注意を出します。注意は何コミット遅れかと、変更の見方 `git diff <commit> HEAD -- docs/guide.md` を言います。注意が CI を失敗させることは決してありません。失敗させるには、`yokoten.json` に `"translations": { "fail": true }` を入れます。

1 行目の古い形は英語の blob を足します。`<!-- source: docs/guide.md blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad -->` です。`check` はまだそれを読みます。英語のテキストと同じ blob なら現在です。そうでなければコミットが決めます。blob はいつでも落とせます。

浅いクローンは新しいコミットだけを持ちます。それで分かるなら、`check` はいつもどおり答えます。見える英語だけのコミットは「少なくとも」その数だけ遅れています。分からないときは、`check` は実行全体に一つの注意を出します。注意はチェックされなかった翻訳の数を言い、ファイルごとの注意はありません。その注意は `"fail": true` でも決して失敗しません。`check` は決してフェッチしません。CI では `fetch-depth: 0` を使います。キットの `yokoten.yml` はそうしています。
## ルールを更新する

yokoten が教訓を学ぶと、核心ルールが変わります。`yokoten install` はあなたのマシンのスキルとエージェントを更新します。あなたのプロジェクトの `AGENTS.md` はあなたのファイルなので、あなたが頼んだときだけ変わります。`## This project` が一度できると、`init` は決してそれに触れません。

`doctor` は `AGENTS.md` の `## This project` より上の部分を、あなたが走らせる yokoten の核心ルールと比べます。違うときは `core-rules` を報告し、セッションもそれを聞きます。

`yokoten update` は変更を示し、何も書きません。変わった節を名指しし、足す行（`+`）と消す行（`-`）を一つずつ並べます。`yokoten update --write` は核心の部分を置き換えます。`## This project` から下はバイト単位でそのまま残ります。

核心の部分であなたが手で編集した行は `-` として出ます。更新がそれを置き換えるからです。自分のルールは先に `## This project` の下へ移してください。その見出しがないと、yokoten は核心ルールとあなたのルールを見分けられません。そのときはそう言い、何も比べず、何も書きません。

`AGENTS.md` の 1 行目は、核心ルールを書いたキットを名指しします。GitHub が表示しないコメントで、`<!-- yokoten kit 0.1.0 -->` です。`init` がそれを書き、`update --write` が新しい版にします。プロジェクトのキットが、あなたの走らせる yokoten より新しいときは、`update` は拒否して何も書きません。ルールが古いキットに戻ることは決してありません。そのとき `doctor` は、プロジェクトではなく yokoten 自身を更新するよう言います。その行のないファイルは、テキストだけで比べます。

`.yokoten/` のコピーは、キットの `AGENTS.md` とその教訓を保つので、CI の `doctor` とフックは、あなたのプロジェクトが取り込んだキットと比べます。新しいルールを取るには、インストール済みの yokoten、プラグイン、またはクローンから `update` を走らせます。`.yokoten/` も新しくするには、そこからもう一度 `init` を走らせます。`.yokoten/` 自身から走らせた `init` は、そのコピーをそのまま保ちます。

Claude Code のプラグインでは、`/yokoten:update` を走らせます。プラグイン自身の yokoten を走らせ、変更を示し、あなたが同意したあとだけ書きます。

## インシデントから学ぶ

インシデントは教訓です。`yokoten learn` はそれを、すべてのプロジェクトが走らせるチェックに変えます。

```mermaid
flowchart LR
  A[インシデントの issue] --> B[yokoten learn]
  B --> C[チェックの下書き]
  C --> D[人がレビュー]
  D --> E[learn --ship: キットに入る]
  E --> F[すべてのプロジェクトの doctor]
```

issue の番号か、別のリポジトリの issue ならその URL を渡します。あなた自身のサインインで、`gh` を通して issue を読みます。AI モデルは呼びません。下書きは issue の節から来ます。

| 下書きのフィールド | 出どころ |
|---|---|
| `id` | `incident-<number>` |
| `what` | `area: ` のあとのタイトル |
| `why` | 「Why it matters」の節。なければ「Why it got through」と、書き直すための `TODO(reviewer)` |
| `fix` | 「Fix」の節 |

issue にその節がないフィールドは `TODO(reviewer)` になり、決して推測しません。下書きはレビュアーのために、issue の節をコメントにも写します。

`yokoten learn 138` は下書きを出力し、何も書きません。`yokoten learn 138 --write` は `lessons/incident-138/` に二つのファイルを足します。

- `lesson.ts`: 指摘と、チェックのための空の `findProblems`。
- `lesson.test.ts`: 陽性の対照。チェックに知られた悪い入力を与え、捕まえることを期待します。

人がチェックを書くまで、テストは失敗します。だから下書きが自分だけで通ることは決してありません。`--write` は足すだけで、すでにあるファイルは残します。

`findProblems` はリポジトリのフォルダを受け取ります。問題のある場所ごとに一つの指摘を返します。ファイルを読むだけで、ネットワークも書き込みもしません。`doctor` がすべてのプロジェクトで走らせるので、速く保ってください。

レビューが終わったら、教訓を出荷します。yokoten の複製で `yokoten learn --ship incident-138` を走らせます。教訓を番号つきのグループ、たとえば `kit/lessons/1/incident-138/` に移します。どのフォルダも 7 項目を超えないようにです。一つのグループは教訓を 5 つと、さらにグループを 2 つ持ち、教訓は空きのある最初のグループに入ります。教訓の表 `kit/lessons/README.md` に行を足します。id、フォルダ、インシデント、yokoten の版です。`TODO(reviewer)` が残っていたり、テストが失敗したりする間は拒否し、何も移しません。yokoten のテストが、キットのすべての教訓に同じことを確かめます。`git mv` ではなくコマンドなので、移動、表の行、テストの実行が一つのステップです。

プロジェクトは、その `doctor` を走らせる yokoten の教訓を走らせます。yokoten の各コピーは自分の `kit/lessons/` を読み、何もダウンロードも同期もしません。だから出荷のあとはこうなります。

| プロジェクトで `doctor` を走らせる人 | 教訓を持つ |
|---|---|
| このコピー: `node path/to/yokoten/bin/yokoten.ts doctor` | すぐに |
| このマシン: `yokoten doctor` | このコピーから `node bin/yokoten.ts install` を走らせたあと |
| プロジェクト自身のコピー: `node .yokoten/bin/yokoten.ts doctor` | このコピーからもう一度 `init` を走らせ、`.yokoten/` をコミットしたあと |
| ほかの全員、npm かプラグインを通して | 次のリリースで、自分の yokoten が更新されたとき |

`learn --ship` は同じ一覧を出力します。問題を見つけた教訓は注意を出します。

```
Project:
  note        lesson incident-138: test/api.test.ts: a test calls a server on this machine and does not set NO_PROXY; set NO_PROXY and no_proxy to 127.0.0.1,localhost while the test runs, then put the old values back
```

プロジェクトの完全な `doctor` が新しい教訓を初めて走らせたときは、一度だけそう言います。何も見つけない教訓は `note    a new check ran: ok (incident-138); doctor now runs it in this project` と言います。問題を見つけたものは `note    new lesson: incident-138 (<what>); doctor now runs it in this project` と言い、そのあと問題を出します。見た教訓は `.git/yokoten/state.json` に保つので、そのファイルがコミットされることは決してありません。

セッションの開始も、ここで問題を見つけたときは、新しい教訓を一度だけ聞きます。一行で、どこを見るかのコマンドを名指しします。``yokoten: a new lesson learned in another project found a problem here: <what>. Run `yokoten doctor` to see where.`` あとのセッション、または圧縮のあとの同じセッションは、もうそれを聞きません。セッションは各新しい教訓を一つの開始でだけ走らせ、どれを走らせたかを同じファイルに保つので、あとの開始はそれに時間を使いません。あとで出てくる問題は、完全な `doctor` が報告します。

注意が `doctor` を失敗させることは決してありません。一つのプロジェクトで教訓を止めるには、その id を `yokoten.json` の「notNow」に理由つきで足します。`"notNow": { "incident-138": "a setup file sets it" }` です。

**ループを試す。** yokoten のクローンで `node scripts/demo/loop.ts` を走らせます。約一秒で、一時フォルダの中のループ全体を歩きます。インシデント、下書き、拒否された出荷、レビュー、出荷、そして二つ目のプロジェクトの注意です。偽の `gh` で、オフラインで走り、あとでフォルダを消します。`--keep` はフォルダを保ち、どこにあるかを出力します。本当のループも同じコマンドで、あなた自身の issue とあなた自身のチェックを、yokoten のクローンで使います。

## yokoten 自身のための教訓

ときには問題が、あなたのプロジェクトではなく yokoten にあることがあります。番人が場合を見落とした、メッセージが分かりにくかった。見つけた場所に書き留めてください。

```
yokoten learn --upstream "the guard let git push --tags through" --area hook --fix "match the flag too"
```

注意は `~/.config/yokoten/upstream/` へ行きます。あなたのマシンで、どのリポジトリの外です。`--area` と `--fix` は任意です。`--area` がなければ、部分は `unknown` です。保たれる前に、注意は掃除されます。

- プロジェクトの名前は `<project>` になります。つづりは問いません。`secret-proj`、`secret_proj`、`SecretProj`、`secretproj` は同じです。三文字未満の名前はそのままにします。あまりに多くの語を隠してしまうからです。あなたを指すなら、非公開の印に足してください。
- プロジェクトへのパスは `<project>` で始まります。シンボリックリンクを通るときもです。
- あなたのホームフォルダは `~` になります。行がそのパスを短く切っているときもです。
- あなたの名前、メール、gh のログイン、Linux と Windows のユーザー名、非公開のホスト、非公開の印は仮の値になります。`yokoten redact` と同じです。メールアドレスは `<email>` になります。

知られた秘密の形を持つ注意は保ちません。コミットチェックが知るトークン、URL の中のパスワード、値のある `password=`、`token=`、`api_key=`、JSON web token、OpenAI の鍵です。掃除のあとも IP アドレスや非公開の印を持つ注意も保ちません。yokoten は見つけた詳細の種類を言い、値を決して言いません。どこにも何も送りません。ホームフォルダがないとき（空の HOME）は、何も保ちません。

yokoten のリポジトリでは、セッションの開始と `doctor` が、待っている注意の数を言います。`yokoten: 3 lessons from other projects wait to become issues: yokoten learn --upstream --list` です。ほかのリポジトリはこの行を決して見ません。注意ごとに issue を開き、`yokoten learn --upstream --done <id>` でそれを消します。

## 設定

リポジトリのルートの `yokoten.json` がプロジェクトの設定を持ちます。どのキーも任意です。あなたが設定した一覧は既定の一覧を置き換え、足しはしません。

| キー | 既定 | すること |
|-----|---------|--------------|
| `layout.maxEntries` | `7` | 一つのフォルダが持てる項目の最大数（核心ルール 10） |
| `layout.exempt` | なし | それを超えて育ってよいフォルダ。[大きくなってよいフォルダ](https://yokoten.app/ja/docs/guide/install-and-commands.md#大きくなってよいフォルダ)を見てください |
| `tests` | `*.test.*`、`*.spec.*`、`*_test.go`、`test/**`、`tests/**` | 修正タスクが変えてはいけないテストのファイル |
| `leadOnly` | ルール、エージェントの設定、`.githooks/**`、`.github/**`、取り込んだ実行時ファイル `.yokoten/**`、`.yokotenignore` | ワーカーが変えてはいけないファイル |
| `privacy.allow` | なし | プライバシーチェックが通す正確な文字列。公開のサポートアドレスや、非公開の印にあるこのプロジェクト自身の名前など |
| `privacy.skip` | ロックファイル | プライバシーチェックが読まないファイル |
| `privacy.utc` | `true` | コミットの時刻は UTC でなければならない |
| `privacy.output` | `"run"` | Claude Code 以外のエージェントで、アカウントの詳細を出力するコマンドをそのまま走らせる。`"stop"` は止め、絞り込んだコマンドを見せる |
| `privacy.skipOwnName` | `true` | このリポジトリの名前である非公開の印を、このリポジトリで探さない。`false` ならそれも探す |
| `notNow` | なし | まだ取り組んでいないステップ。`doctor` の名前ごとに理由を付ける: `{ "ci": "no remote yet" }` |
| `allowBuild` | なし | コミットチェックが通すビルドの出力とバイナリ |
| `areas` | 任意 | タイトルが名指ししてよい領域。[issue のタイトル](https://yokoten.app/ja/docs/guide/install-and-commands.md#issue-のタイトル)を見てください |
| `translations.fail` | `false` | 元より遅れた翻訳がチェックを失敗させる |

### 大きくなってよいフォルダ

核心ルール 10 は、各フォルダを 7 項目以下に保ちます。二種類のフォルダはそれを超えて育ってよく、`changes/` と `.worktrees/` は常に育ってよいです。

- **記録**、たとえば `docs/records`。各項目は一度足され、保たれます。
- **第三者のフィクスチャの一式**で、テストが読むもの。上流の名前のまま、`NOTICE` をそばに置いて保ちます。テスト、`NOTICE`、上流のバグ報告は、ファイルをその名前で見つけます。フォルダにすると、各検索と上流からの更新が難しくなります。

そのようなフォルダを `layout.exempt` に手で並べます。項目はルートからのパスか、グロブです。グロブでは `*` が一つのフォルダ、`**` が何個でもフォルダ（0 個でもよい）です。ほかの文字に特別な意味はありません。一つのグロブが Rust ワークスペースのすべてのクレートを覆います。

```json
{ "layout": { "exempt": ["docs/records", "crates/*/tests/data"] } }
```

`check` と `doctor` は、どのフォルダにも一致しないグロブに注意します。古い項目が見えるようにです。

環境変数:

| 変数 | すること |
|----------|--------------|
| `YOKOTEN_ROLE=worker` | セッションはワーカー。リード専用ファイルを変えてはいけない |
| `YOKOTEN_DONE_WHEN` | このワーカーがタスクを終えるとき、停止フックが走らせるコマンド。ワークツリーの git フォルダの `yokoten-done-when` より勝つ。サブエージェントはリードの環境を共有し、自分のものを受け取らない。[停止チェック](https://yokoten.app/ja/docs/guide/install-and-commands.md#停止チェック)を見てください |
| `YOKOTEN_LEAD_ONLY_OK` | このワーカーが変えてよいリード専用のパス。リポジトリのルートから、カンマ区切り。[対応しているもの](https://yokoten.app/ja/docs/guide/works-with.md)を見てください |
| `YOKOTEN_FIX_TASK=1` | セッションは修正タスク。テストのファイルを変えてはいけない |
| `YOKOTEN_RELEASE_APPROVAL=1` | オーナーがこのセッションからのリリースを許す。Muse Code がフックに渡すかは分かっていない |
| `YOKOTEN_PRIVATE_MARKS` | 二つ目の非公開の印のファイル。印は `~/.config/yokoten/private-marks` のものに足され、そのファイルを置き換えることは決してない。[プライバシー](https://yokoten.app/ja/docs/guide/privacy.md)を見てください |
| `YOKOTEN_MIN_FREE_GB` | 空きがこれより少ないディスクに `doctor` が注意する。GB 単位。`0` で注意を切る。[マシンについての注意](https://yokoten.app/ja/docs/guide/install-and-commands.md#マシンについての注意)を見てください |
| `YOKOTEN_BOT_APP_ID`、`YOKOTEN_BOT_KEY`、`YOKOTEN_BOT_INSTALLATION` | ボット。`~/.config/yokoten/keys.env` の行にもできる。[server.md](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/docs/server.md#3-the-bot-a-github-app)を見てください |
| `YOKOTEN_GITHUB_API` | 別の GitHub API のアドレス。GitHub Enterprise Server など |
| `YOKOTEN_PR_LIVE=1` | `check --pr` が、イベントのファイルではなく、`GITHUB_TOKEN` でプルリクエストのタイトル、本文、ラベル、マイルストーンを今のまま読む。読めないときは失敗する。キットの `pr.yml` が設定する |
| `LLAMA_API_KEY` か `MODEL_API_KEY`、`LLAMA_API_BASE`、`LLAMA_MODEL` | `adopt` のモデル。[表の最初の下書き](https://yokoten.app/ja/docs/guide/four-layers.md#表の最初の下書き)を見てください |

---

前の章: [対応しているもの](https://yokoten.app/ja/docs/guide/works-with.md)
次の章: [Shipping an MCP server that works in every agent](https://yokoten.app/ja/docs/guide/shipping-an-mcp-server-that-works-in-every-agent.md)