miqdadbadjuber/anti-slop v3.2.20

v3.2.20: usage modes become a saved preference

on GitHub

The question antislop opens every session with can now be answered once. During and After have always been a choice made per session, and the core asked again at the start of the next one. This release lets that answer be saved, and it changes nothing for anyone who does not save one.

A mode you set once

npx antislop-ai --mode during

after saves the other mode, ask restores the question in every session, and --mode on its own prints what is saved and where it lives. The file is shared, so one command covers every agent and every project: ~/.config/antislop/settings.json on Linux and macOS, and %APPDATA%\antislop\settings.json on Windows, falling back to ~/.config when %APPDATA% is unset. If your agent can write files, asking it to remember a mode works too.

Resolution follows a strict order: an explicit mode request in the current chat, then the saved preference, then the question. A session request wins for that session and never rewrites what is saved, so asking for an audit in one chat does not turn every later chat into an audit. When either applies, the skill names the mode and where it came from once, as antislop active: during (global preference). or antislop active: during (session override)., because a mode that applies silently is a mode nobody can check.

The preference is opt-in. With no settings file on disk, antislop asks exactly as it does today, which is why this release adds no question to an install that never runs the command. A settings file that cannot be parsed is reported and left untouched rather than overwritten, since a parse error is the one failure that could take a saved preference down with it.

What the pointer block now says

The block the installer writes into an entry file carries the order above, so an agent that never reads the core still knows a session choice outranks a saved one. It also states the two cases that look like a mode but are not: a request to review, audit, or avoid file edits does not select one, and another skill's mode does not select antislop's. Older copies carry the unconditional question, so an existing install needs the update command below before any of this applies to it.

Copilot reads a second folder

This release was re-validated end to end before it shipped, and the read turned up one agent missing from the rows that load more than one project folder. Copilot reads the shared .agents/skills and also .claude/skills beside it, which is where a Claude Code install lands, so a project holding both fills two folders Copilot loads and the installer now names that instead of leaving it to surface later as a skill that behaves strangely. The guide said six agents share the property and says seven.

Also in this release:

• The guide gained a Usage modes entry under Reference, with the table of contents row that points at it, so the feature is documented where a reader looks for it rather than buried in one install route's steps.
• SECURITY.md said a project install adds a pointer block to one entry file. It adds one per distinct entry file, so Claude Code and Codex together write CLAUDE.md and AGENTS.md, and the page says that now, along with the settings write the mode command performs.
• The em dash guardrail reads rules/antislop.md and rules/antislop.mdc, the two pointer files that ship to plugin users and were the only shipped documents sitting outside it.
• A smoke test asserts the Copilot collision is named, so a row that loses its second folder fails a test rather than a user.

Updating is unchanged:

npx antislop-ai --update

Skills load when a session starts, so start a new one afterwards. Every route is in the README's Update table and walked through in the guide. Full detail is in the ROADMAP.