---
title: "The core rules"
description: "「The core rules」：yokoten 使用指南的一章。"
canonical: https://yokoten.app/zh-tw/docs/guide/the-core-rules
lang: en
source: https://github.com/yokoten-labs/yokoten/blob/v0.1.2/docs/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.

> 這一頁還沒有繁體中文版，下面是英文原文。

# The core rules

The full table, with the reasons, is in [`kit/project/AGENTS.md`](https://github.com/yokoten-labs/yokoten/blob/v0.1.2/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.

---

上一章: [Shipping an MCP server that works in every agent](https://yokoten.app/zh-tw/docs/guide/shipping-an-mcp-server-that-works-in-every-agent.md)
下一章: [Naming](https://yokoten.app/zh-tw/docs/guide/naming.md)