Negafix

No Negative Parallelism

Negative parallelism is the sentence shape "it's not just X, it's Y": a modest claim negated and restated grander, where the second clause adds nothing the first lacked. In classical rhetoric the figure is antithesis; in generated text it is filler that performs depth instead of delivering it. This skill bans the construction in new text and, on request, audits a project for it and scores the result.

The ban covers the construction, not negation itself. "The function does not retry" is plain factual negation and is always fine. "This is not a retry helper, it's a whole resilience philosophy" is the banned shape.

The construction inflates a claim the same way in every language, so the ban holds across languages. What changes with the language is the noise level of the detection patterns, which the Detection patterns section covers.

Write mode

Always on while this skill sits in context; applies to file edits, new files, commit messages, PR descriptions, and your own replies.

• State the claim positively, anchored in a concrete, checkable detail.
• Rewrite recipes:
• Keep the stronger half and drop the negated half: "It's not just a linter, it enforces the release checklist" becomes "It enforces the release checklist."
• If the second half is abstract ("transforms your workflow"), replace it with the specific fact it was gesturing at, or delete the sentence.
• If a real misconception needs correcting, name whose misconception it is and give the correction its own sentence; that is contrast with content, not the banned filler.
• Verbatim quotations and diagnostic output inherit the quotation verdict, and the examples in this skill inherit it too. Reproduce a violation as it stands when you report it rather than paraphrasing the evidence away.

Single-file check

Before handing off one new or edited file, skip the project score and check just that file: run the Step 1 pattern on it, treat every match as a candidate, read the full sentence, and assign one of the four verdicts. Rewrite only the violation rows with the write-mode recipes, then re-run the pattern to confirm nothing banned remains. No score is computed; the full audit contract stays for project-wide requests.

Detection patterns

Heuristics for the audit; they overmatch by design. A match is a candidate, never a verdict: record it as candidate until you have read the full sentence and assigned one of the four verdicts below. Equating regex output with violations is the one mistake this section exists to prevent.

English, case-insensitive: not just, not only, not merely, not simply, not about, more than just, isn't just, isn't about, no longer just, not a ... but a.

Ukrainian: не просто, не лише, не тільки, не стільки, це не про.

The Ukrainian patterns are far noisier than the English ones: не лише and не тільки introduce plain factual enumeration in ordinary prose ("скрипт оновлює не тільки README"), so expect most of their matches to score as plain negation. Treat не стільки X, скільки Y as the construction proper, since it exists only to negate and restate.

Ukrainian analytical prose often casts the construction as не A, а B, which the default pattern does not cover because the comma form is too common to scan blind. Run it as an exploratory pattern only, with a mandatory manual verdict per match:

rg -nP 'не [^,.;]{1,60}, а ' <paths>

A match is a violation only when B restates A and the negation merely inflates it; a factual correction ("не в кеші, а в конфігурації") is plain negation or justified contrast.

Verdicts

• violation - negative parallelism: the negated clause and the restatement carry the same idea, the negation only inflates it.
• plain negation - the negation states a fact on its own; no penalty.
• justified contrast - corrects a real, named misconception or draws a genuine distinction the reader needs; no penalty, and the reason must say what is being corrected.
• quotation - verbatim external text, a diagnostic, or a translation source string; no penalty.

Audit mode

Run on request ("audit for negative parallelism", "negafix this repo", "what's our negation score"). Audit is read-only; do not edit files in this mode.

Step 1 - Inventory

All three passes share one pattern, so set it first and run them in the same shell. Every later block opens with a guard, because rg given an empty pattern matches every line and reports a total that has nothing to do with the project:

PATTERN="not (just|only|merely|simply|about)|more than just|isn'?t (just|about)|no longer just|not an? [^,.;]{1,40}? but an?\b|не (просто|лише|тільки|стільки)|це не про"

Working tree:

: "${PATTERN:?set PATTERN from the first block of Step 1}" &&
rg -niP --no-heading "$PATTERN" \
  --glob '!package-lock.json' --glob '!*.min.*' .

The trailing . is what keeps the scan honest: handed a piped stdin and no path, rg reads that pipe instead of the tree and reports zero matches on a project full of them.

Commit messages, which a working-tree scan never reaches. git log --grep selects the commits, including a merge commit and a commit whose only match sits in the body; the inner pass then prints the matching lines with their hash so the catalog gets its snippets:

: "${PATTERN:?set PATTERN from the first block of Step 1}" &&
git log --all -i -P --grep="$PATTERN" --format='%h' |
  while read -r commit; do
    git show -s --format='%B' "$commit" |
      rg -niP --no-heading "$PATTERN" | sed "s/^/$commit:/"
  done

rg skips .git, binary files, and .gitignore entries by default. Add two classes of exclusion yourself instead of copying a fixed list: everything generated (lock files, minified bundles, snapshots, coverage output, generated changelogs) and every file whose text is data rather than prose (fixtures, seed databases, translation catalogs). Name each exclusion you added in the report.

Both commands print one line per matching line, so a sentence tripping two patterns shows up once. Take the occurrence total from a counting pass instead, and reconcile it with the catalog:

: "${PATTERN:?set PATTERN from the first block of Step 1}" &&
rg -niP --count-matches "$PATTERN" \
  --glob '!package-lock.json' --glob '!*.min.*' .

Report that total; the catalog must account for every occurrence in it. The total counts candidates, not violations: only the verdicts in the catalog decide what each match is.

Step 2 - Catalog

One table, grouped by file, one row per matching line; every row carries exactly one of the four verdicts - violation, plain negation, justified contrast, or quotation - and a bare candidate never survives into the final catalog. When a line holds more than one match, say how many in the row and give them a shared verdict. When their verdicts differ, split the line into a row per match and number them in reading order, <file>:<line>#<n>, so no two rows share a key:

Catalog the commit-message matches in a separate table keyed by <hash>:<line>, <hash>:<line>#<n> when a line splits, and carrying its snippet the same way; history