Dogfood: enforce the house writing style with Taskless rules

[thecodedrift]

What

The prose in this repo should conform to Jakob's writing style guide. Enforcement should be Taskless rules running against this repo, so the check is automatic and covers every file. Manual editing passes don't scale here.

This is the natural first dogfooding case: Taskless enforcing a standard on Taskless.

Why now

As of 2026-08-14 the repo doesn't conform. Em dashes and the banned metaphor "load-bearing" show up in:

• packages/cli/src/help/*.txt, the agent-facing recipe text
• TypeScript code comments
• OpenSpec design docs

A manual sweep was considered and declined. It only covers whatever files someone happened to open, and it starts drifting the next day. A rule covers the whole repo and every file added later.

The rules to write

1. No em dashes or en dashes used as em dashes

Vale existence extension point. Match — and –. Straightforward, high signal, and it catches the single strongest AI tell in the guide.

extends: existence
message: "Don't use em dashes. Use a period, comma, colon, or parentheses."
level: error
tokens:
  - '—'
  - '–'

2. No blocklist phrases

Vale existence with the phrase list, case-insensitive. The full list from the guide:

• "You're absolutely right", plus reflexive agreement openers generally: "You're right", "Great point", "Exactly"
• "good catch"
• "it hits different"
• "the one thing I keep coming back to"
• "I found the smoking gun"
• "bottom line"
• "load-bearing" as a metaphor
• "belt and suspenders"
• "and honestly", plus "honestly" and "truly" as filler intensifiers
• "land" / "landed" for decisions or agreement: "what we landed", "the decision landed", "glad it landed"
• Performative candor: "the honest truth", "let's be honest", "to be honest", "the hard truth", "real talk", an "Honest assessment" heading

Two entries need care:

• "load-bearing" is banned as a metaphor. A literal structural use is fine. In this repo everything is metaphorical, so a flat match is probably safe, but the rule should say so in its message.
• "land" / "landed" is banned for decisions and agreement. The literal senses are fine: a plane lands, a PR lands, an intro lands. A bare token match will fire constantly on "the PR landed", which is exactly the phrasing this repo uses in its stacked-PR docs. Scope it to the decision collocations ("we landed", "the decision landed", "glad it landed", "landed on") instead of the bare word.

3. The "not X, Y" antithesis construction

The guide bans setting up a contrast inside one sentence for effect. Example from the guide: "Match optical weight, not bounding-box height."

Flagging this is the hard one. It probably can't be expressed as one Vale pattern. The construction varies in word order, punctuation, and clause length, and the same tokens appear in ordinary sentences that are fine. Options, roughly in order of how much I'd trust them:

1. Scope it down to the highest-confidence shape: a comma followed by not followed by a short noun phrase, at end of sentence. Narrow, low false-positive rate, misses plenty.
2. Split it into several rules, one per shape, each tuned separately.
3. Use an LLM-backed rule if Taskless supports one, since this is a judgment call about intent.

I'd rather start with option 1 and accept the misses than ship a noisy rule people learn to ignore. Whatever we pick, say plainly in the rule message that it's a heuristic.

Also note the guide's carve-outs: a labeled Right/Wrong pair in a reference table is fine, and three approved brand lines are exempt ("Actual code analysis, not prompt engineering.", "Markdown is a suggestion dressed up like a rule.", "Correct once. Enforced forever."). Those go in an ignore list.

Scope note

Exclude fixture files and test data under .tests/ directories. They hold deliberately wrong prose. Without the exclusion the rules will flag content nobody wrote as source, and the first run will look like a disaster.

Priority

Low. This is a follow-up we deferred on purpose. Nothing currently in flight depends on it.