qa-report-humanizer

.agents/qa-project-context.md

• Who reads this — an engineer, an exec, or a customer? An engineer wants the failing selector and the repro; an exec wants ship/no-ship and open blockers; a customer wants impact and timeline. The register and what you cut differ for each.
• What channel — Slack, PR comment, or a formal report? Slack gets 2-3 lines and a link; a PR comment gets the specific code/selector fix; a report gets structure. Length and formatting follow the channel.
• Are the numbers and severities locked facts that must survive verbatim? If the source says "9 failed" and "P1," those carry through unchanged. If a figure is missing, you name the gap — you do not invent one (see Core Principle 5).

1. Specific beats comprehensive. "Login fails when the email has a plus sign" beats "Various authentication edge cases were identified." The reader fixes the first and learns nothing from the second. Name the behavior, the trigger, and the scope.
2. Say what happened, not what category it falls into. "Authentication module" is a bucket; "login with plus-sign emails" is a bug. Categories let the writer sound thorough while hiding that they don't know the specifics. Replace every category with the concrete thing inside it.
3. If the reader can't tell what broke or what to do, the report failed. Write for the person who has to fix it at 4pm on a Friday. Lead with what's broken or risky, then what they should do about it. Skip the parts nobody reads.
4. Preserve every fact; cut every adjective. The rewrite changes the prose, never the data. No number, error string, severity, bug description, or test result may shift. The only things you delete are filler, hedging, and synonym cycling — not information.
5. Never invent the specifics you're asked to add. "Make it specific" tempts the model to manufacture an exact percentage, an incident count, or a repro it never saw. Do not. If the source is vague and the number isn't verifiable, the honest rewrite names the gap ("user impact not measured") instead of writing "8% of users." A fabricated metric is a worse failure than a vague one.

Test execution was completed successfully for Sprint 47. A total of 342 test cases were executed across 5 test suites, achieving a 97.4% pass rate. The following sections provide detailed results.

Sprint 47: 342 tests run, 9 failed. 6 of the failures are in checkout (payment form validation). The other 3 are flaky timing issues we've seen before.

Deleting a user doesn't revoke their API tokens — they can still call the API after deletion. Repro: create a user, mint a token,

DELETE /api/users/{id}

, then

GET /api/me

with that token. Returns

200 OK

with the user's data instead of

401 Unauthorized

. Found in the user-management API.

1. Cut the opening paragraph. Most intros are throat-clearing. Delete everything before the first useful fact.
2. Lead with what matters. What broke? What's risky? What should someone do? That goes first.
3. Replace categories with specifics. "Authentication module" → "login with plus-sign emails." "Performance degradation" → "dashboard takes 8s to load (was 2)." "Several edge cases" → "empty cart, expired coupon, currency mismatch."
4. Kill the filler. Remove every phrase in

   references/filler-blocklist.md

   — "It is worth noting that," "Moving forward," "Despite challenges," "The team is committed to," "Stakeholders can feel confident," and the rest.
5. Add what's useful — without inventing it. What should the reader do next? What's the risk if they don't? How confident are you (be honest — "I'm not sure this is stable yet" is fine)? If a number to back a claim isn't in the source, say so; don't manufacture one.
6. Read it out loud. If you wouldn't say it in standup, rewrite it.

• Inventing the specifics you were asked to add. Rewriting a vague draft into a precise-sounding one by manufacturing a percentage, an incident count, or a repro that wasn't in the source. This breaks the fact-preservation guarantee — name the gap instead.
• Opening with "Test execution was completed successfully" when tests failed. The opener contradicts the body. Lead with the failures.
• "Potential impact" instead of the actual impact. If you know the impact, state it; if you don't, say it's unmeasured. "Potential" is a hedge that hides which one you mean.
• Writing "the team is aligned" in any context. It conveys zero information and is a pure AI tell.
• Padding 3 bullets into 12 by rewording the same thing. Synonym cycling. One outcome, one statement.
• Closing with optimistic statements that add no information. "Moving forward, the focus will be on continuous improvement" — delete it.
• Passive voice to avoid naming what broke. "An issue was identified" hides the subject. Name what broke and where.
• Starting a bug report with the testing session instead of the bug. Nobody needs "while conducting regression testing of the module." Start with the broken behavior.

1. Numbers and severities preserved. Extract every figure from input and output and diff the sets. The output set must be a subset of the input set — anything in the output that isn't in the input is a fabricated fact:
   bash

   grep -oE '[0-9]+(\.[0-9]+)?%?|P[0-3]|[0-9]{3}' input.md  | sort -u > /tmp/in.txt
   grep -oE '[0-9]+(\.[0-9]+)?%?|P[0-3]|[0-9]{3}' output.md | sort -u > /tmp/out.txt
   comm -13 /tmp/in.txt /tmp/out.txt   # must be empty (allow only obvious rounding, e.g. 97.4 -> 97)

2. Filler blocklist returns zero matches. Copy the "Grep-ready regex" line from

   references/filler-blocklist.md

   into

   BLOCKLIST

   and grep the output:
   bash

   BLOCKLIST='it('\''?s)? worth noting|moving forward|in conclusion|despite (several )?challenges|the team is (committed|aligned)|stakeholders can feel confident'
   grep -iE "$BLOCKLIST" output.md   # expect no output; extend BLOCKLIST with the full regex from the reference

   Any hit is a surviving AI tell — rewrite that line.
3. Second-pass clean. Run the output through the global

   humanizer

   (or

   avoid-ai-writing

   ) skill in detect mode. It should flag no remaining em-dash overuse, tricolon, or vague attribution. If it flags something QA-specific that this skill missed, fix it here too.

• Every number, severity, error string, and bug description in the output also appears in the input (the

  comm -13

  diff in Verification step 1 is empty, rounding aside).
• The filler blocklist regex returns zero matches against the output (Verification step 2).
• No synonym cycling: each distinct test outcome is stated once (no "passed / completed without issues / returned positive results" chains).
• The output passes the global humanizer/avoid-ai-writing pass with no flagged patterns (Verification step 3).
• The deliverable is the rewritten version; the original draft is archived or discarded, not shipped alongside.

• ai-bug-triage

  — Bug-report templates and the severity/priority matrix. Triage decides what a bug is and how to classify it; this skill rewrites the prose of an already-classified report.

• qa-metrics

  — What to actually track. Use it when the report should cite real metrics; this skill makes sure those metrics are stated with context, not as vanity numbers.

• qa-dashboard

  — Dashboard setup and stakeholder report layout. This skill humanizes the narrative that accompanies the dashboard.

• quality-postmortem

  — Postmortem structure and root-cause analysis. Build the postmortem there; humanize the writeup here.

skills/

• humanizer

  /

  avoid-ai-writing

  — General-purpose anti-AI-writing engines. When both apply, run the global skill for language-level cleanup (em-dash overuse, tricolon, vague attribution) and this skill for QA-specific structure and fact preservation. If an engineer's real standup/Slack voice is available, feed a sample to the global humanizer's voice mode so the rewrite matches that person rather than a generic "human" register.

• filler-blocklist.md — Copy-paste blocklist of banned filler phrases, the grep-ready regex used in Verification, synonym-cycling tells, and passive-voice "who broke it" dodges.