Node.js security releases (October 2026): update Node to 22.23.4, 24.22.1 or 26.12.1 before you use yokoten
yokoten
Docs The core rules

The guide

The core rules

Source: docs/guide.md · v0.1.2

The full table, with the reasons, is in kit/project/AGENTS.md.

  1. Every piece of work starts as an issue. No todo files.
  2. Nothing reaches main without a pull request and green CI.
  3. Only the owner creates tags and releases. A general “merge” or “ship it” does not approve a release.
  4. A fix task changes code, never tests (YOKOTEN_FIX_TASK=1).
  5. A worker doesn’t change lead-only files: the rules, agent config, hooks, CI.
  6. Never skip the commit check. Reading core.hooksPath is fine. A new hooks folder is fine when its pre-commit is an executable shell script that runs yokoten check on a line of its own and stops the commit when the check fails, as yokoten init sets up for husky. Change a setting by name: git config --edit and a new config include are refused. So is a shell write to .git/config, .git/commondir, .git/hooks or .githooks: a redirect, cp, mv, tee, sed -i, rm, chmod, ln, install, truncate, patch, awk -i inplace, ed, vim, tar -x -C, unzip -d or find -delete. A path with a glob that could match them counts too (.git/conf*). So is setting GIT_CONFIG_GLOBAL, GIT_CONFIG_SYSTEM, GIT_CONFIG_COUNT, GIT_CONFIG_KEY_n or GIT_CONFIG_VALUE_n for git or a shell, or for the rest of the line. Reading those files passes, and so do mkdir .githooks, files in another repo (/tmp/x/.git), and the lead’s git checkout or git restore of the committed hook. Use git -c <name>=<value> for one setting in one command, and your edit tool or yokoten init for a hook.
  7. No plain force push. Never rebase a shared branch.
  8. Squash merge. One pull request, one purpose; small polish goes in one batch.
  9. Review and test the exact commit that merges.
  10. No folder holds more than 7 entries.
  11. Nothing in the repo, or in what yokoten prints, points at a person or holds a secret.
  12. Decisions are written down once and kept. Facts are replaced. Times are UTC.

How to release

Only the owner releases (rule 3). An agent that is stopped from releasing tells the owner, and the owner takes these steps:

  1. Ask an agent to prepare the release pull request. The release skill writes the changelog and the version.
  2. Read the pull request, approve it, and merge it.
  3. Create the tag yourself: git tag vX.Y.Z && git push origin vX.Y.Z.
  4. If the project publishes from CI, approve the publish on the run page (Review deployments).

An agent can push the tag only in a session the owner starts with approval: YOKOTEN_RELEASE_APPROVAL=1 claude. For another agent, put the same variable before its command: codex, gemini, agy, or dsh tui --patch .dsh/yokoten.patch.yml. Copilot CLI uses the Claude Code command. Muse Code and OpenCode are not known to pass the variable to their hooks, so the owner releases outside them. If Gemini CLI’s strict environment sanitization is on, the variable is dropped, and the owner releases outside Gemini CLI.