No Negative Echo: a Codex skill that regenerates commit and PR text from the final diff

The delivery residue problem No Negative Echo targets

An agent revises a plan mid-session, then writes the commit message as if the rejected plan were still part of the work. The README shows the shape of it with a diff: a title reading 番茄炒蛋（没有东坡肉） becomes 番茄炒蛋. The rejected dish is gone from the code but still present in the packaging. That is the failure the project names negative echo, and it is a packaging failure rather than a code failure, which is why a linter will not catch it.

The intended users are people who let Codex finish a task and then accept whatever commit subject, PR title, PR body or delivery note comes out. The README lists three situations: writing commit and PR text from the final diff, rewriting an article title or opening from the kept body, and closing out a long conversation with several rounds of edits. Anyone who reviews the diff carefully but skims the commit message is exactly the audience.

How the skill separates control information from deliverable content

The mechanism is a classification rule, not a transformation. Per the README, anything discussed in the session that never entered the final baseline is control information. Rejected options, assistant drafts, intermediate attempts and the user's wording corrections all fall into that bucket and should be omitted from the final artifact. What survives is anything that is a real change in the authoritative baseline and that the current delivery surface must explain.

The README gives a table for this. Published API removals, migrations and external operations must be stated as they are. Security, legal, compatibility and audit facts stay. Comparisons, quotations and decision records stay when the user asked for them. User edits that existed before the task started keep their attribution and are not counted as this task's output.

Each output position gets asked three questions: does a reader who did not see this conversation need this information, would omitting it cause a factual error, a safety risk, a misleading statement or a compatibility gap, and is it a real change in the authoritative baseline that this surface needs to explain. The README is explicit that merely having appeared or having been rejected is not a reason to keep something.

The AGENTS.md block also rules out a tempting shortcut: do not write no X when told not to mention X. Titles, file names, openings and labels should be regenerated from the positive goal rather than patched word by word from the rejected text.

Installing the skill and running a first finalization pass

The README offers two paths. Installing the skill gives you the decision procedure, the check script and the high-assurance mode. Appending the core rules to AGENTS.md gives you the persistent constraint without any of the tooling. The two can be used together.

The local install example in the README clones the repository, enters it, and runs the installer with the published provenance hash and the host name:

python3 -I -B scripts/install_skill.py \
  --expected-provenance-sha256 d42280b21f519ea00e417c68f31c68ca3d7faae607faf6dcb6e04beeff9c5ed6 \
  --agent codex

The README states that the installer verifies provenance, the runtime file manifest, target conflicts and the copied bytes itself. It also states that a default install does not require reading every Python file first, running the full test suite, or enumerating unrelated skills. The flags shown are the ones the README shows; the installer is the authority on anything else.

The README also documents an agent-driven install, where you hand the agent a network, terminal and file access plus this instruction:

请安装 no-negative-echo Skill：
https://raw.githubusercontent.com/LB623/no-negative-echo/main/INSTALL.md
装完告诉我安装结果，以及是否需要开启新会话或重启。无法验证时，不要宣称安装成功。

After installation, the README recommends invoking the skill explicitly before an important delivery, for example to write the commit subject, PR title, PR body and delivery note from the final diff, or to rewrite an article title and opening from the retained body. The README notes that the skill being discovered is not the same as it being active, which is the reason for the explicit call.

The AGENTS.md route and what it does not give you

If you only want the constraint to hold across a project, append the README's block to AGENTS.md at the repository root, creating the file if it does not exist and not overwriting existing instructions in it. The block tells the agent to describe only the final adopted state, to treat rejections and intermediate attempts as control information, to judge each delivery surface separately, and to re-read all user-visible content including file names, metadata and hook rewrites after the content changes.

This route depends on the host supporting project instructions. The README states that Codex reads project instructions at the start of each run, so edits to the file need a new run or session before they take effect, and it points to the OpenAI documentation for the loading rules. It also states that the AGENTS.md route does not install the skill and cannot invoke scripts/check_surface.py or the high-assurance flow. When both routes are active, AGENTS.md supplies the always-on core rules and the skill supplies the fuller check before an important delivery.

What the scanner does not check

The README's boundaries section is the most useful part of the document for anyone deciding whether to rely on this. It states that the project is a prompt-layer mitigation, not a deterministic filter. A skill being discovered does not mean it was activated. It cannot clear context the model has already read, and it does not control tool logs or the host UI. The built-in scanner covers text, file names and suspicious Unicode, and a PASS from it does not mean semantic review is finished.

There is a second boundary that matters more than it first appears: the README warns against changing APIs, migrations, tests, snapshots or existing user edits just to make a check pass. A tool that pushes you toward editing the artifact to satisfy the checker has the incentive backwards. Credentials, privacy and compliance questions are left to dedicated tools.

The README also splits the workflow by risk. The default procedure lives in no-negative-echo/SKILL.md, and the high-assurance document is read on demand for sensitive information, public releases and strict acceptance. That means the stricter path is opt-in, and a routine commit will not get it unless someone asks.

How this differs from a commit-message linter

Commitlint and similar tools check the form of a message: type prefix, subject length, imperative mood. They operate on the string you already wrote and know nothing about which draft the message came from. No Negative Echo works one step earlier, at generation time, and asks whether each claim in the message corresponds to the final baseline. A commitlint rule cannot tell you that the phrase about removing an option refers to something you decided against.

The trade-off runs the other way too. A linter is deterministic and runs in CI; this is a prompt-level constraint whose effect depends on the model following instructions, and the README says so. The repository does contain a deterministic piece, scripts/check_surface.py, along with a test suite run with python3 -I -m unittest discover -s tests -p 'test_*.py'. The README states that CI runs only the deterministic scripts and the grader tests, and that it does not present them as evidence about model behavior. That is an unusually honest line for a project in this category, and it tells you what the green badge does and does not mean.

Maintenance, licence and the cost of staying current

The repository is not archived and the last push was on 2026-08-31. There are no retrieved releases, so there is no versioned upgrade path to follow; updates arrive as commits on main. Practical consequence: if you install from the raw INSTALL.md URL or clone main, you are tracking the branch, and the provenance hash in the README's install command is tied to a specific state. A later commit can change what that hash verifies, so an install command copied from a stale page may fail its own provenance check rather than silently install something else. That failure is the intended behavior, but it means you should read INSTALL.md at install time rather than reuse a command from a blog post.

The licence is MIT, stated in the README and in the LICENSE file. MIT permits use, modification and redistribution with the copyright notice and permission notice retained; it provides no warranty. Nothing here is legal advice, and if you redistribute the skill inside a commercial product, the notice requirement is the part your legal reviewer will care about. The project has no homepage and no published release artifacts, so there is no vendor, support contract or deprecation policy behind it.

Editorial conclusion

Adopt No Negative Echo if your Codex sessions run long enough that rejected options, wording corrections and abandoned drafts leak into commit subjects, PR descriptions or article titles, and you want a written rule set plus a scanner instead of relying on memory. Skip it if you need deterministic output filtering: the README states the scanner only covers text, file names and suspicious Unicode, and that PASS does not mean semantic review is complete. Before relying on it, run the install command with the published provenance hash, confirm the installer reports the copied bytes it verified, and check whether your host reads AGENTS.md at the start of a run, since edits there need a new session to load.

Frequently asked questions

Official sources

1. Issues
2. LB623/no-negative-echo on GitHub
3. License: MIT
4. README