Every instruction has exactly one right home. This skill finds it, writes there, and keeps the\nharness checkout as the source of truth for everything generic.
\npython3 - <<'EOF'\nimport json, pathlib\nm = json.load(open(pathlib.Path.home() / \".local/state/agent-harness/manifest.json\"))\nprint(m[\"repo\"])\nEOF\ngit -C \"$(…)\" remote -v\nIf the manifest is missing, locate or install the harness before editing managed content.\nDo not create a second authority in a runtime configuration directory. If origin is <owner>/agent-harness and you are that owner, you are the\nmaintainer. If origin is a fork and upstream is the harness, you are a fork user.
policy/hooks/, dispatched by\nlib/harness_core/lifecycle.py; native registrations belong in runtime adapters.docs/primitive-authoring.md; other personal guidance stays in the runtime personal file.\nA fact about one repo goes in that repo's AGENTS.md.primitives/stances/<pref>/<variant>.md, and a line in config.example.json and\ndocs/preferences.md. Never a core rule.primitives/skills/<name>/SKILL.md, with a description that says when to use it.paths: frontmatter, in the repo it\napplies to.primitives/rules/<topic>.md. Check every existing\nrule first; the usual outcome is one sentence folded into an existing file, not a new one.A \"remember this\" request runs the same ladder from the top. A fact about one project or one\nmachine is auto memory for that project, never the harness. A correction to how the agent\nshould behave anywhere is a rule or a stance, and you say so before writing it. A fact about\nthe user is a personal file, outside the repo.
\nprimitives/rules/ and primitives/stances/ for the\ntopic. Do not restate a policy that lives in a global rule inside a project rule; link it.bin/harness generate for native views and bin/harness generate --check to verify them.\nSee docs/primitive-authoring.md for custom dimensions and native bindings.\nVerify sync in a disposable home with HARNESS_HOME, CLAUDE_CONFIG_DIR, and CODEX_HOME\nredirected. Sync normal installations from the reviewed release, not the development worktree.bin/harness lint — fails on personal strings and secret patterns.main\nruleset requires green checks and a squash merge. Code changes (bin/harness, shared policy,\ntests) carry a test; content changes are gated by the lint and review.main, which is your live harness. If the change is\nworth sharing, git fetch upstream && git rebase upstream/main, push a branch to the fork,\nand gh pr create --repo <owner>/agent-harness.conciseness.md was cut to its operative lines when the always-loaded context was capped. Its\nworked examples live here.
Explain a decision once. Pick the single most natural home for a design rationale — usually\nthe module or class docstring where the thing is defined, or the user-facing doc page for\nanything a user needs. Every other file that touches the concept gets a short pointer back, not\na restatement.
\n# Bad — restates the full rationale in a consuming file\n# We chunk at 999 rather than the documented 10,000 limit because early testing\n# suggested the endpoint became unreliable above 1,000 records, and because ...\n\n# Good — one line, points at the canonical explanation\n# Chunked per `batch_size`; see the class docstring for the API's limits.\nIf a second doc explains the same concept as a first, it links to it.
\nDon't narrate what the code already says. Comments explain a non-obvious why. If a comment\nwould be an accurate one-line summary of the next line of code, delete it.
\nDocstrings follow the house pattern. Match the surrounding style exactly. Read a neighbouring\nfunction before writing a new one. Do not add docstrings purely to satisfy a linter that isn't\nrunning; add them where a user of the public API needs them.
\nNo private-context references in shipped code. Code, tests, and docs must stand on their own\nto a stranger. No references to planning docs, other repos, internal ticket numbers, or\nevaluation notes. Public issue and PR numbers are fine and useful — they are resolvable by any\nreader.
\nPR descriptions. Lead with what and why in a few bullets, plus a link to the issue. Fill in\nthe template's sections and delete none, but keep each short. A long PR description with heavy\nheading and bold formatting is harder to review, not more informative. Long explanatory content\nbelongs in the issue or in docs/, referenced from the PR body.
primitives/instructions.md, every file in primitives/rules/, and the longest variant of each\nstance dimension are loaded on every turn of every session. harness lint fails when their combined\nsize exceeds ALWAYS_LOADED_TOKEN_CAP in bin/harness — a third of the 12,607-token standing\ncontext measured in issue #430, and the binding limit — or the secondary ALWAYS_LOADED_CAP in\nlines. Both are printed on every lint run. A rule that needs more room than the\ncap allows is telling you it wanted to be a skill: keep the operative line resident, move the\nrationale, examples and evidence into the skill the rule points at, and leave a one-line pointer\nbehind. The stance count uses the longest variant per dimension, so no configuration a user\ncan select is ever over the cap.