proposal: custom rule for speciesist language detection in markdown

[samtuckerdavis]

Proposal

Create a custom markdownlint rule for detecting speciesist language in markdown documentation, suggesting clearer alternatives.

Context

markdownlint's custom rule system is well-suited for this kind of content-level check. Several similar tools already have speciesist language rules:

• woke — YAML config
• alex/retext-equality — YAML patterns
• Vale — style package
• ESLint — plugin for JS/TS

A markdownlint rule would complement these by integrating directly into the markdown-specific linting pipeline that many projects already use.

Examples

Phrase in Docs	Suggested Alternative
"kill two birds with one stone"	"accomplish two things at once"
"beat a dead horse"	"belabor the point"
"guinea pig" (metaphor)	"test subject"
"cattle vs. pets"	"ephemeral vs. persistent"

Implementation

This would work well as a custom rule (MD900-range) or a published npm package (markdownlint-rule-speciesism) that users can opt into. The rule would scan text content (not code blocks) for phrases and suggest alternatives.

Happy to contribute an implementation if the concept is welcome.

Academic Foundation

• Hagendorff et al. (2023). "Speciesist bias in AI." AI and Ethics.
• Leach et al. (2023). "Speciesism in everyday language." British Journal of Social Psychology.

[DavidAnson]

I have no objection to the principle of this, but what you describe is much more about WHAT you write than HOW it is written and I don't think it fits with the spirit of markdownlint - much the same way I have no plans to incorporate spelling or grammar checking.

I have not used it, but was going to recommend alex if you were looking for an existing tool to do this. If you wish to implement this behavior as a custom rule, that is why custom rules exist [ :) ], but I do not expect to add this logic to the core library.

[paulthanson082-glitch]

nice

[samtuckerdavis]

Thanks for the thoughtful response and the pointer to alex — that's exactly the kind of tool I was looking for.

You're right that this is fundamentally a content concern rather than a formatting one, and the scoping distinction makes sense. markdownlint is the wrong layer for this.

I'll explore alex and the custom rule API. Appreciate the clear explanation.