@wazir-dev/cli 1.0.0

package/expertise/humanize/domain-rules-code.md

@@ -0,0 +1,79 @@
+# Domain Rules: Code Artifacts
+
+freshness_date: 2026-03-16
+
+Rules for humanizing commit messages, code comments, PR descriptions, and CHANGELOG entries. Code artifacts demand brevity and precision. Format preservation is critical.
+
+For AI-specific code writing failures, see `expertise/antipatterns/process/ai-coding-antipatterns.md`.
+
+## Role Mappings
+
+- **executor** -- commit messages, code comments, PR descriptions, CHANGELOG entries, execution notes
+
+## Rules
+
+### 1. Conventional commit format is sacred
+
+The `<type>(<scope>): ` prefix is a machine-readable contract. Never humanize it. Humanize only the description field after the colon.
+
+```
+# Wrong: humanizing the prefix
+good(auth): add JWT verification middleware
+
+# Right: humanize only the description
+feat(auth): add JWT verification to /api/protected routes
+```
+
+### 2. Code comments must be technically precise
+
+No idioms, no hedging, no metaphors in code comments. State what the code does, why it exists, or what constraint it satisfies.
+
+```
+// Wrong: metaphor in code
+// This function navigates the complex landscape of user permissions
+
+// Right: precise description
+// Returns true if the user has any of the required roles
+```
+
+### 3. PR descriptions follow what-changed / why structure
+
+A PR description answers two questions: what changed and why. No boilerplate intros, no "In this PR we...", no summary conclusions.
+
+```
+# Wrong
+In this PR, we've made several improvements to the authentication system,
+making it more robust and comprehensive.
+
+# Right
+Add rate limiting to /api/login. Without this, the endpoint accepted
+unlimited attempts. Now returns 429 after 5 failures per minute per IP.
+```
+
+### 4. CHANGELOG entries are user-facing
+
+CHANGELOG entries should be clear to someone who did not write the code. Avoid internal jargon. State what changed from the user's perspective.
+
+```
+# Wrong
+- Refactored auth module for better separation of concerns
+
+# Right
+- Login now returns a specific error message when the account is locked
+```
+
+### 5. Do not break structured formats
+
+Never modify YAML frontmatter, JSON, conventional commit syntax, or any machine-readable format during humanization. These formats have exact syntax requirements that override style rules.
+
+### 6. Brevity over style
+
+Code artifacts have implicit length constraints. A commit message description should be under 72 characters. A code comment should be 1-2 lines. Do not expand terse-but-clear text to meet burstiness targets.
+
+### 7. No vocabulary blacklist in function names or identifiers
+
+`handleNavigate()`, `leverageCache()`, or `robustParser` are code identifiers, not prose. Never flag or rename code symbols during humanization. The blacklist applies to prose text only.
+
+### 8. Skip burstiness for short-form artifacts
+
+Commit messages, inline comments, and CHANGELOG entries are too short for burstiness analysis. The burstiness target (CV > 0.4) applies only to prose longer than ~10 sentences.

package/expertise/humanize/domain-rules-content.md

@@ -0,0 +1,67 @@
+# Domain Rules: User-Facing Content
+
+freshness_date: 2026-03-16
+
+Rules for humanizing microcopy, glossary entries, i18n values, notification templates, and seed content. This module is an additive layer on top of `expertise/content/foundations/editorial-standards.md`, not a replacement. Editorial standards govern voice, tone, and grammar baseline. This module adds AI-pattern detection on top.
+
+## Role Mappings
+
+- **content-author** -- microcopy tables, i18n keys, glossary, notification templates, seed content
+
+## Rules
+
+### 1. Editorial standards govern baseline
+
+All voice, tone, sentence case, and grammar rules from `expertise/content/foundations/editorial-standards.md` apply first. The humanizer adds AI-pattern removal as a second layer.
+
+### 2. Conversational tone for UI text
+
+Microcopy should sound like a knowledgeable colleague explaining something, not a press release. Replace formal AI phrasing with direct language.
+
+```
+# Wrong
+"An error has been encountered while processing your request."
+
+# Right
+"Something went wrong. Try again, or contact support if it keeps happening."
+```
+
+### 3. Microcopy is exempt from burstiness analysis
+
+UI strings are 3-8 words per item. Burstiness (sentence length variation) does not apply at this scale. Skip burstiness checks for individual microcopy entries. Burstiness may apply to longer content blocks like onboarding flows or help text.
+
+### 4. Notification templates should feel human
+
+Push notifications and email subjects have character limits. Write within those limits while avoiding AI tells.
+
+```
+# Wrong
+"Your comprehensive order has been successfully processed and is being prepared."
+
+# Right
+"Order confirmed. We're packing it now."
+```
+
+### 5. Glossary terms must be precise
+
+Do not apply synonym cycling to glossary definitions. A glossary exists to pin down meaning. If the term is "endpoint," every reference should say "endpoint" -- not "API surface," "service URL," or "access point."
+
+### 6. Seed data should be realistic
+
+Seed and fixture data should use plausible values, not "Lorem ipsum", "John Doe", or "test123". Use realistic names, addresses, and content that matches the product domain.
+
+### 7. No vocabulary blacklist overrides for established UX terms
+
+Some blacklisted words are established UX terminology. "User journey" is a legitimate UX mapping concept. "Ecosystem" may be the accepted term in a product's domain language. When a blacklisted word is the established term in the product glossary, keep it.
+
+### 8. Accessibility copy has its own constraints
+
+Screen reader text, ARIA labels, and alt text follow accessibility standards that override style preferences. Do not humanize alt text into conversational language -- keep it descriptive and functional per WCAG guidelines.
+
+### 9. i18n values must stay translatable
+
+Humanized strings must remain clean for translators. Avoid idioms that do not translate across languages. "Heads up" may work in English microcopy but breaks in Arabic or Japanese. Use direct phrasing that translates well.
+
+### 10. Content coverage comes first
+
+Every UI state needs copy. Missing microcopy for an error state, empty state, or loading state is a bigger failure than an AI tell in existing copy. Write the copy first, humanize second.

package/expertise/humanize/domain-rules-technical-docs.md

@@ -0,0 +1,56 @@
+# Domain Rules: Technical Documentation
+
+freshness_date: 2026-03-16
+
+Rules for humanizing specs, plans, architecture docs, API documentation, and review reports. These artifacts prioritize precision and clarity -- humanization must never add ambiguity.
+
+For voice and tone baseline, see `expertise/content/foundations/editorial-standards.md`.
+
+## Role Mappings
+
+- **specifier** -- specs, acceptance criteria, non-goals, assumptions
+- **planner** -- implementation plans, task lists, verification plans
+- **reviewer** -- findings with severity, rationale, verdicts
+- **learner** -- learning artifacts, experiment summaries
+
+## Rules
+
+### 1. Active voice preferred
+
+Write "the verifier runs all tests" not "all tests are run by the verifier." Passive voice is acceptable only when the actor is genuinely unknown or irrelevant.
+
+### 2. Imperative mood for instructions
+
+Write "run the test suite" not "the test suite should be run" or "you might want to consider running the test suite."
+
+### 3. Name the specific thing
+
+Write "use `pg_dump --format=custom`" not "use appropriate database backup tooling." Name the function, command, library, or version.
+
+### 4. No metaphors in technical descriptions
+
+Write "the service retries failed requests 3 times with exponential backoff" not "the service navigates through turbulent network conditions." Technical readers need mechanics, not imagery.
+
+### 5. Burstiness applies to prose sections only
+
+Do not measure or enforce burstiness on code blocks, tables, YAML frontmatter, acceptance criteria lists, or task definitions. Burstiness targets (CV > 0.4) apply only to flowing prose paragraphs.
+
+### 6. Preserve technical precision over style
+
+If replacing a blacklisted word would reduce precision, keep the original. "Robust to outliers" in a statistics context is precise. "Strong against outliers" loses the statistical meaning.
+
+### 7. Hedging is acceptable only for genuinely uncertain claims
+
+"This migration may take 2-4 hours depending on dataset size" is honest uncertainty. "It is worth noting that this could potentially have performance implications" is hedging padding -- state the specific concern or cut the sentence.
+
+### 8. Acceptance criteria must stay testable
+
+Never humanize an acceptance criterion into something that cannot be verified. "The system handles edge cases" is untestable. "The system returns HTTP 422 for input exceeding 10MB" is testable. Humanization must not cross this line.
+
+### 9. Findings must cite evidence
+
+Review findings must reference specific files, lines, or artifacts. "The code has issues" is vague. "Line 42 in `auth.ts` dereferences a potentially null token" is evidence-cited. Strip AI padding but keep the citations.
+
+### 10. Do not pad task descriptions
+
+Plan task descriptions must be unambiguous enough for execution without inventing missing steps. "Implement the authentication flow" is too vague. "Add JWT verification middleware to `src/middleware/auth.ts`, reading the secret from `AUTH_SECRET` env var" is actionable.

package/expertise/humanize/index.md

@@ -0,0 +1,35 @@
+# Directory Purpose
+
+The `humanize` directory provides expertise for detecting and removing AI writing patterns from generated text. It covers vocabulary blacklists, structural pattern detection, burstiness enforcement, domain-specific writing rules, and a two-pass self-audit process. This domain applies to all text-producing roles across 6 phases (specify, plan, execute, author, review, learn).
+
+# Key Concepts
+
+- AI vocabulary detection and replacement (61-item blacklist with domain exceptions)
+- Sentence length burstiness (CV > 0.4 target, 4-tier distribution)
+- Structural pattern taxonomy (24 patterns across 4 categories)
+- Domain-specific rule sets (technical docs, code artifacts, user-facing content)
+- Two-pass self-audit (pattern detection then meaning preservation)
+
+# File Map
+
+- `index.md` -- semantic map of the humanize directory
+- `vocabulary-blacklist.md` -- 61-item blacklist of AI vocabulary with replacements and domain exceptions
+- `sentence-patterns.md` -- 24-pattern taxonomy with burstiness targets and before/after examples
+- `domain-rules-technical-docs.md` -- rules for specs, plans, architecture docs, API docs
+- `domain-rules-code.md` -- rules for commit messages, code comments, PR descriptions
+- `domain-rules-content.md` -- rules for microcopy, glossary, notifications, seed content
+- `self-audit-checklist.md` -- two-pass verification checklist (detect then preserve)
+
+# Reading Guide
+
+If scanning text for AI vocabulary -> read `vocabulary-blacklist.md`
+If checking sentence structure and burstiness -> read `sentence-patterns.md`
+If writing specs, plans, or architecture docs -> read `domain-rules-technical-docs.md`
+If writing commit messages, code comments, or PR descriptions -> read `domain-rules-code.md`
+If writing microcopy, glossary entries, or notifications -> read `domain-rules-content.md`
+If running a post-generation quality check -> read `self-audit-checklist.md`
+
+# Relationship to Other Domains
+
+- **content** -- The `content` domain (`expertise/content/foundations/editorial-standards.md`) covers voice, tone, sentence case, and grammar baseline. This `humanize` domain is an additive layer that targets AI-specific patterns not addressed by editorial standards: vocabulary blacklists, structural pattern detection, burstiness enforcement, and the two-pass self-audit.
+- **antipatterns** -- The `antipatterns/process/ai-coding-antipatterns.md` module captures AI-coding failure modes in code. This `humanize` domain extends that concept to all text artifacts, not just code.

package/expertise/humanize/self-audit-checklist.md

@@ -0,0 +1,87 @@
+# Self-Audit Checklist
+
+freshness_date: 2026-03-16
+
+A two-pass verification process for text humanization. Run this checklist after producing any text artifact and before handing off to the next phase.
+
+## When to Run
+
+- After any text artifact is produced (spec, plan, code comments, content, review findings)
+- Before handoff to the next pipeline phase
+- When the `wz:humanize` skill is invoked on existing text
+- During the review phase, as part of writing quality assessment
+
+## Pass 1: Pattern Detection
+
+Scan the text for AI patterns. This pass identifies problems.
+
+### 1.1 Vocabulary scan
+- [ ] Cross-reference text against `vocabulary-blacklist.md`
+- [ ] Count blacklisted word occurrences per section
+- [ ] Flag clusters (3+ blacklisted words in one paragraph)
+- [ ] Note domain exceptions (words that are legitimate in this context)
+
+### 1.2 Structural pattern scan
+- [ ] Cross-reference text against `sentence-patterns.md`
+- [ ] Check for introduction boilerplate (patterns 1, 6)
+- [ ] Check for conclusion boilerplate (patterns 19, 24)
+- [ ] Check for excessive conjunctive phrases (pattern 21)
+- [ ] Check for promotional language (patterns 4, 22)
+- [ ] Check for synonym cycling (pattern 11)
+
+### 1.3 Burstiness check
+- [ ] Estimate sentence length distribution across prose sections
+- [ ] Compare against targets: 20% short, 50% medium, 25% long, 5% very long
+- [ ] Check CV is above 0.4 (or note if the text is too short for burstiness to apply)
+- [ ] Skip burstiness for code blocks, tables, lists, and short-form artifacts
+
+### 1.4 Banned openers check
+- [ ] Scan paragraph-opening words against the banned openers list
+- [ ] Flag any paragraph starting with Furthermore, Additionally, Moreover, In conclusion, Firstly, Secondly, Lastly, In summary
+
+### 1.5 Passive voice check
+- [ ] Scan for passive constructions
+- [ ] Flag sections with more than 30% passive voice (unless domain rules permit, e.g., scientific context)
+
+## Pass 2: Meaning Preservation
+
+Verify that fixes from Pass 1 did not break anything. This pass protects content.
+
+### 2.1 Re-read every rewritten sentence
+- [ ] Read each changed sentence in context (not in isolation)
+- [ ] Confirm the rewritten version conveys the same information
+
+### 2.2 Check technical precision
+- [ ] Verify no specific names, numbers, versions, or commands were lost
+- [ ] Verify acceptance criteria remain testable (for specs)
+- [ ] Verify task descriptions remain actionable (for plans)
+- [ ] Verify code references remain accurate (for review findings)
+
+### 2.3 Check domain-appropriate tone
+- [ ] Confirm the tone matches the domain rules file for this artifact type
+- [ ] Technical docs: precise and imperative
+- [ ] Code artifacts: brief and factual
+- [ ] User-facing content: conversational and clear
+
+### 2.4 Check format preservation
+- [ ] Verify YAML frontmatter, JSON, and structured formats are untouched
+- [ ] Verify conventional commit prefixes are untouched
+- [ ] Verify code blocks and inline code are untouched
+- [ ] Verify Markdown structure (headings, links, tables) is intact
+
+## Severity Guide
+
+When multiple issues are found, prioritize fixes in this order:
+
+1. **High severity** -- blacklisted vocabulary clusters, introduction/conclusion boilerplate, promotional language, generic superlatives. Fix these first.
+2. **Medium severity** -- copula avoidance, em dash overuse, synonym cycling, excessive hedging, banned openers. Fix these second.
+3. **Low severity** -- rule of three, negative parallelisms, boldface overuse, title case, curly quotes. Fix these if time permits.
+4. **Burstiness** -- adjust sentence lengths last, after vocabulary and structural fixes are in place. Vocabulary and structure changes often improve burstiness as a side effect.
+
+## Exit Criteria
+
+The audit is complete when:
+- All high-severity findings are resolved
+- Medium-severity findings are resolved or documented as acceptable
+- No meaning was lost in rewrites (Pass 2 confirms)
+- Structured formats are intact (Pass 2.4 confirms)

package/expertise/humanize/sentence-patterns.md

@@ -0,0 +1,218 @@
+# Sentence Patterns
+
+freshness_date: 2026-03-16
+
+This module documents 24 structural patterns that signal AI-generated text, organized into 4 categories. Each pattern includes a description, severity rating, and before/after examples.
+
+The problem is overuse and uniformity, not any single occurrence. One em dash in a document is fine. Em dashes in every paragraph is a tell.
+
+## Content Patterns (1-6)
+
+### 1. Inflated symbolism
+**Severity:** medium
+Phrases that add artificial meaning or gravitas where none exists.
+
+- **Before:** "This function serves as a testament to the team's commitment to clean architecture."
+- **After:** "This function separates validation from persistence."
+
+### 2. Balanced-argument boilerplate
+**Severity:** medium
+Forced "on one hand / on the other hand" structures that avoid taking a position.
+
+- **Before:** "On one hand, TypeScript adds type safety. On the other hand, it increases build complexity."
+- **After:** "TypeScript adds type safety at the cost of build complexity. For this project, the safety wins."
+
+### 3. Superficial -ing analyses
+**Severity:** low
+Dangling participle phrases used for fake analytical depth.
+
+- **Before:** "Leveraging modern frameworks while ensuring backward compatibility, the system achieves optimal performance."
+- **After:** "The system uses React 19 and supports browsers back to Chrome 90."
+
+### 4. Promotional language
+**Severity:** high
+Adjectives and phrases borrowed from marketing copy: "vibrant", "breathtaking", "nestled".
+
+- **Before:** "This groundbreaking approach revolutionizes how teams manage state."
+- **After:** "This approach reduces state bugs by centralizing updates in one store."
+
+### 5. Vague attributions
+**Severity:** medium
+"Experts say", "studies show", "research suggests" without citing what or who.
+
+- **Before:** "Studies show that test-driven development improves code quality."
+- **After:** "Nagappan et al. (2008) found TDD teams produced 60-90% fewer defects in an IBM/Microsoft study."
+
+### 6. Introduction boilerplate
+**Severity:** high
+Formulaic openers that delay the actual content.
+
+- **Before:** "In today's fast-paced world of software development, testing has become more important than ever."
+- **After:** "Write the test before the implementation."
+
+## Language and Grammar Patterns (7-12)
+
+### 7. Overused AI vocabulary
+**Severity:** high
+Words from the vocabulary blacklist appearing in clusters. Cross-reference `vocabulary-blacklist.md`.
+
+- **Before:** "We leverage a robust, comprehensive framework to streamline the development process."
+- **After:** "We use Express.js to handle routing and middleware."
+
+### 8. Copula avoidance
+**Severity:** medium
+Using "serves as", "functions as", "acts as" instead of "is".
+
+- **Before:** "This module serves as the primary entry point for authentication."
+- **After:** "This module is the authentication entry point."
+
+### 9. Negative parallelisms
+**Severity:** low
+"It's not just X, it's Y" structures used for artificial emphasis.
+
+- **Before:** "It's not just a linter -- it's a complete code quality platform."
+- **After:** "The tool lints, formats, and reports coverage in one pass."
+
+### 10. Rule of three overuse
+**Severity:** low
+Forcing ideas into groups of three when the natural count is different.
+
+- **Before:** "This brings clarity, efficiency, and reliability to the deployment process."
+- **After:** "This makes deployments faster and more predictable."
+
+### 11. Synonym cycling
+**Severity:** medium
+Substituting synonyms for the same concept to avoid repetition, creating confusion.
+
+- **Before:** "The component... the widget... the UI element... the interactive control..."
+- **After:** "The component" (repeat the clearest term consistently).
+
+### 12. False ranges
+**Severity:** low
+Claiming a span from one extreme to another for artificial scope.
+
+- **Before:** "From ancient database systems to modern distributed architectures..."
+- **After:** "Distributed databases handle partitioning differently from single-node systems."
+
+## Style Patterns (13-18)
+
+### 13. Em dash overuse
+**Severity:** medium
+Multiple em dashes per paragraph where commas or periods would work.
+
+- **Before:** "The system -- which handles authentication -- processes tokens -- both JWT and opaque -- before routing."
+- **After:** "The system handles authentication and processes JWT and opaque tokens before routing."
+
+### 14. Boldface overuse
+**Severity:** low
+Bolding terms that do not need emphasis, reducing the impact of actual emphasis.
+
+- **Before:** "The **executor** uses **conventional commits** for **all changes** to the **repository**."
+- **After:** "The executor uses conventional commits for all changes to the repository."
+
+### 15. Inline-header vertical lists
+**Severity:** low
+"**Term:** Definition" lists that should be prose or tables.
+
+- **Before:** "**Performance:** Improved by 40%. **Security:** No vulnerabilities found. **Coverage:** 95%."
+- **After:** "Performance improved by 40%, no security vulnerabilities were found, and test coverage reached 95%."
+
+### 16. Title case in headings
+**Severity:** low
+Title Case Every Word instead of sentence case.
+
+- **Before:** "Strategic Negotiations And Partnership Development"
+- **After:** "Strategic negotiations and partnership development"
+
+### 17. Emoji abuse
+**Severity:** medium
+Emojis used as section markers or emphasis in technical content.
+
+- **Before:** "Phase 1: Scan Phase 2: Rewrite Phase 3: Verify"
+- **After:** "Phase 1: Scan. Phase 2: Rewrite. Phase 3: Verify."
+
+### 18. Curly/smart quotes
+**Severity:** low
+Typographic quotes in contexts where straight quotes are standard (code, Markdown).
+
+- **Before:** He said "the project"
+- **After:** He said "the project"
+
+## Filler and Hedging (19-24)
+
+### 19. Summary/conclusion boilerplate
+**Severity:** high
+Formulaic closings that restate the introduction without adding value.
+
+- **Before:** "In conclusion, we have explored the various aspects of testing strategy and identified key areas for improvement."
+- **After:** [Cut entirely, or add a single concrete next step.]
+
+### 20. Excited/clickbait headings
+**Severity:** medium
+Headings with unnecessary superlatives or exclamation marks.
+
+- **Before:** "The Amazing Power of Reactive Programming!"
+- **After:** "Reactive programming"
+
+### 21. Excessive conjunctive phrases
+**Severity:** medium
+"Furthermore", "Additionally", "Moreover" padding between every point.
+
+- **Before:** "The API handles authentication. Furthermore, it manages rate limiting. Additionally, it logs all requests. Moreover, it validates input."
+- **After:** "The API handles authentication, rate limiting, request logging, and input validation."
+
+### 22. Generic superlatives
+**Severity:** high
+"Groundbreaking", "revolutionary", "transformative" without evidence.
+
+- **Before:** "This transformative approach to CI/CD is truly groundbreaking."
+- **After:** "This CI/CD setup cuts deploy time from 45 minutes to 8."
+
+### 23. Excessive hedging
+**Severity:** medium
+Stacking hedge phrases beyond what uncertainty warrants.
+
+- **Before:** "It is worth noting that it might be important to consider that this could potentially impact performance."
+- **After:** "This may slow queries on tables over 1M rows."
+
+### 24. Generic positive conclusions
+**Severity:** high
+Endings that express vague optimism without actionable content.
+
+- **Before:** "With these improvements, the future of our platform looks brighter than ever."
+- **After:** "Next: migrate the remaining 12 endpoints to the new auth middleware by March 30."
+
+## Burstiness
+
+Burstiness measures sentence length variation. AI text has low burstiness (uniform sentence lengths). Human text has high burstiness (mixed short and long sentences).
+
+### Target distribution
+
+| Length category | Word count | Target percentage |
+|----------------|------------|-------------------|
+| Short | 3-8 words | ~20% |
+| Medium | 9-20 words | ~50% |
+| Long | 21-40 words | ~25% |
+| Very long | 40+ words | ~5% |
+
+### Coefficient of variation target
+
+CV (standard deviation / mean of sentence lengths) should exceed **0.4** for humanized text. AI text typically scores 0.15-0.25.
+
+### How to improve burstiness
+
+- After a long technical sentence, follow with a short one. Two words is fine.
+- Use sentence fragments where contextually appropriate.
+- Do not mechanically alternate short-long-short -- that creates its own detectable pattern.
+- Burstiness applies to prose sections only. Skip code blocks, tables, and lists.
+
+## Pattern Frequency vs. Presence
+
+One instance of any pattern is not a problem. The signal comes from clustering and overuse:
+
+- 1 em dash in 500 words: normal
+- 5 em dashes in 500 words: AI tell
+- 1 "Furthermore" in a document: acceptable
+- "Furthermore" opening 3 consecutive paragraphs: AI tell
+
+When reviewing, count pattern instances per section rather than flagging individual occurrences.

package/expertise/humanize/vocabulary-blacklist.md

@@ -0,0 +1,105 @@
+# Vocabulary Blacklist
+
+freshness_date: 2026-03-16
+
+This module lists 61 words and phrases that statistically signal AI-generated text. Each entry includes the flagged item, why it signals AI, a suggested replacement, and domain exceptions where the word is legitimate.
+
+The problem is overuse and clustering, not any single occurrence. One "robust" in a 2,000-word document is fine. Three in the same paragraph is a tell.
+
+## Verbs (15)
+
+| Word | Why it signals AI | Replacement | Domain exceptions |
+|------|-------------------|-------------|-------------------|
+| delve | Overrepresented in LLM output by 10-50x vs. human text | dig into, examine, explore | None |
+| embark | Artificially formal for most contexts | start, begin | Historical or travel writing |
+| leverage | Corporate jargon amplified by training data | use, apply, build on | Finance (leveraged buyout) |
+| harness | Metaphor used as filler | use, apply, capture | Energy (harness solar power) |
+| bolster | Vague intensifier | strengthen, support, back | None |
+| foster | Overused in policy-adjacent text | encourage, build, grow | Childcare (foster care) |
+| facilitate | Bureaucratic padding | help, enable, run | Meeting facilitation (process term) |
+| navigate | Metaphor masking lack of specifics | handle, work through, manage | Actual navigation (maps, UI) |
+| underscore | Artificially emphatic | highlight, stress, show | None |
+| showcase | Promotional register | show, demonstrate, display | Trade show / portfolio context |
+| streamline | Vague process claim | simplify, speed up, cut steps from | None |
+| utilize | Longer synonym of "use" with no added meaning | use | None |
+| commence | Artificially formal | start, begin | Legal proceedings |
+| endeavor | Archaic formality | try, attempt, work toward | None |
+| operationalize | Jargon padding | implement, put into practice, run | None |
+
+## Adjectives (16)
+
+| Word | Why it signals AI | Replacement | Domain exceptions |
+|------|-------------------|-------------|-------------------|
+| robust | Most overrepresented adjective in LLM output | strong, reliable, thorough | Statistics (robust estimator), engineering (robust to failure) |
+| comprehensive | Padding that avoids specifics | complete, full, covering X and Y | None -- name what it covers instead |
+| multifaceted | Vague complexity claim | complex, with several parts | None |
+| nuanced | Used to avoid stating the actual nuance | specific, subtle, [state the nuance] | None |
+| holistic | Buzzword without content | whole-system, end-to-end, covering all of | Medical (holistic medicine -- field term) |
+| actionable | Business jargon amplified by LLMs | practical, something you can act on | None |
+| groundbreaking | Superlative without evidence | new, first, original | None -- show evidence instead |
+| revolutionary | Superlative without evidence | new, different, a departure from | Historical (French Revolutionary) |
+| transformative | Superlative without evidence | significant, changed how X works | None -- describe the change instead |
+| game-changing | Superlative without evidence | significant, shifts the approach | Sports commentary (literal use) |
+| crucial | Overused intensifier | important, required, necessary for X | None |
+| vital | Overused intensifier | important, necessary, required | Medical (vital signs -- field term) |
+| seamless | Masks real integration complexity | smooth, without interruption, invisible to users | None |
+| cutting-edge | Cliche superlative | latest, newest, current | None |
+| state-of-the-art | Cliche superlative | current best, latest, leading | Academic papers (field convention) |
+| innovative | Superlative without evidence | new, novel, different from X because Y | Patent filings (legal term) |
+
+## Nouns (8)
+
+| Word | Why it signals AI | Replacement | Domain exceptions |
+|------|-------------------|-------------|-------------------|
+| tapestry | Metaphor used for false depth | mix, combination, collection | Textile / art context |
+| testament | Artificially weighty | evidence, proof, sign | Legal (last will and testament) |
+| landscape | Metaphor masking lack of analysis | field, space, area, market | Geography, actual landscapes |
+| paradigm | Academic jargon used as filler | model, approach, pattern | Philosophy of science (Kuhn) |
+| synergy | Corporate jargon with no content | combined effect, working together | None |
+| ecosystem | Metaphor used loosely | system, community, set of tools | Biology (actual ecosystems), established tech usage (e.g., "npm ecosystem") |
+| framework | Vague when not naming a specific one | structure, approach, system | Software (React framework -- naming a specific one) |
+| journey | Metaphorical padding | process, experience, path | Travel, customer journey mapping (UX term) |
+
+## Phrases (14)
+
+| Phrase | Why it signals AI | Replacement |
+|--------|-------------------|-------------|
+| in today's world | Boilerplate opener | [delete -- start with the topic] |
+| in the realm of | Unnecessarily ornate | in, within, for |
+| at the end of the day | Filler cliche | ultimately, in practice |
+| it is worth noting | Hedging padding | [state the thing directly] |
+| it is important to note | Hedging padding | [state the thing directly] |
+| not only... but also | Parallel structure overused by LLMs | [state both points directly] |
+| on one hand... on the other hand | Balanced-argument boilerplate | [state your position, then the counterpoint] |
+| in conclusion | Summary boilerplate | [cut or compress] |
+| to summarize | Summary boilerplate | [cut or compress] |
+| in summary | Summary boilerplate | [cut or compress] |
+| a testament to | Artificially weighty | shows, proves, demonstrates |
+| in the fast-paced world of | Boilerplate opener | [delete -- start with the topic] |
+| it goes without saying | If it goes without saying, do not say it | [delete] |
+| needless to say | If it is needless, do not say it | [delete] |
+
+## Banned Sentence Openers (8)
+
+These words should not open a paragraph. They are acceptable mid-sentence or mid-paragraph.
+
+| Opener | Why it signals AI | Replacement |
+|--------|-------------------|-------------|
+| Furthermore | Mechanical transition padding | [start with the next point directly] |
+| Additionally | Mechanical transition padding | Also, [or just state the point] |
+| Moreover | Mechanical transition padding | [start with the next point directly] |
+| In conclusion | Summary boilerplate | [cut or compress] |
+| Firstly | Artificially formal enumeration | First, [or restructure] |
+| Secondly | Artificially formal enumeration | Second, [or restructure] |
+| Lastly | Artificially formal enumeration | Finally, [or restructure] |
+| In summary | Summary boilerplate | [cut or compress] |
+
+## Decay and Review
+
+AI vocabulary shifts with training data. Words that signal AI generation in 2025-2026 may become less distinctive as models improve, and new patterns will emerge.
+
+- Review this blacklist annually
+- Track which items are producing false positives in domain-specific contexts
+- Add new items when patterns emerge in model outputs
+- Remove items that no longer distinguish AI from human text
+- The `freshness_date` header tracks when this list was last validated