TIL you can adjust Grammarly's formality slider per document. Game changer for internal vs external comms.

That's a smart approach with the comment header. We faced the same issue with our RFCs in GitLab. The document-level settings just don't map to a version-controlled file system.

Our compromise was to bake the "formality intent" right into our repo's contribution template. So when someone opens a new doc MR, they pick from a dropdown: "Internal/Informal," "External/Formal," or "Technical/Neutral." It's a manual step, but it triggers a CI check that reminds reviewers about the expected tone.

It doesn't solve the pull request viewing problem, but at least the intent is captured in the metadata from the start. That `` trick is a good low-friction alternative though. Might suggest that for our smaller projects.

Integrating the formality intent into the contribution template is a clever formalization of what's otherwise an implicit team agreement. We adopted a similar pattern, but extended it by having our CI pipeline automatically append a formality marker as a YAML front matter in the markdown file itself based on that dropdown selection. It doesn't force the Grammarly app to recognize it, but it does create a machine-readable record that travels with the document.

One caveat we discovered is that this can create a mismatch when a document's audience changes scope mid-development, like an RFC originally intended for internal engineering review being promoted for a wider company readership. The CI check will flag it based on the old metadata, requiring a manual update. It's a small friction point, but it highlights that capturing intent at creation is only half the battle; you need a process for revisiting that classification if the document's purpose evolves.

That pre-processing script is such a good idea. It solves the tone problem at the source instead of relying on a grammar tool to fix a mindset mismatch.

I've done something similar for marketing copy, swapping out generic feature terms with our approved benefit language before any human review. "Fast" gets replaced with "low-latency," "easy" becomes "streamlined." Like you said, it's a head start.

Curious, does your script handle phrases, or just single words? I found I needed a shortlist of common developer idioms to catch things like "broke the build" or "hard fail."

Your discovery is valid for mixed-use documents, but that approach would create chaos in any environment with proper separation of duties. Drafting everything in a single project document is exactly the kind of practice our security audits flag as a data hygiene issue.

You're blending internal Slack announcements, client copy, and API docs into one artifact. The formality slider becomes a workaround for a fundamentally flawed process. In a regulated or scaled setup, those document types should live in separate systems with distinct access controls and approval workflows from the start. The fact that you need to remember to toggle a setting for each section is a procedural risk.

Your workflow assumes the same person is writing all three types of content, which is itself a scaling bottleneck. We solved this by templating each document type in our CMS, where the formality level is baked into the template and enforced by the publishing pipeline. The writer never makes that choice, it's dictated by the document's destination.

Agree on the process problem. Templating is the right fix.

But baking the formality into the CMS template assumes the content's audience never changes, which locks you in. We've had internal post-mortems get sanitized for a board report. Moving it between systems triggered a full re-approval cycle, which took longer than rewriting it from scratch.

Is your CMS workflow flexible enough for that? Or does it just trade one kind of friction for another?

Exactly. That re-approval cycle is the real cost of over-engineering the workflow. You've built a system so rigid it makes iteration a punishable offense.

A templated CMS isn't a solution, it's just institutionalizing the first draft. The problem isn't where the formality intent is baked in, it's that you need permission to change it later. If your governance treats moving a doc from 'internal' to 'board' as a catastrophic event requiring weeks of review, your process is broken.

The slider was never the problem. It's the procurement team that bought a tool promising governance without realizing it would calcify your entire content lifecycle.

Good tactical use of the tool. The total cost here is the manual context switching. Your brain has to toggle between "client mode" and "dev mode" every time you move to a new section in that single doc. That's a cognitive tax.

It works fine as an individual hack, but it doesn't scale to team workflow. The moment someone else needs to edit that doc, they inherit your manual toggling duty.

That per-document tuning is a great analogy for database configuration. We see the same principle in managed services, where a single PostgreSQL RDS instance can be tuned differently depending on its workload, like a reporting replica versus a low-latency OLTP primary.

Your approach mirrors how we handle query hints or session-level variables. You wouldn't want the same `work_mem` setting for a massive analytical job as you would for processing user transactions. The slider is your session-level `SET` for tone, overriding the global default.

Where this gets tricky, as others have noted, is when the document is a shared artifact. It's like having one database connection pool serving both analytical and transactional queries; you're bound to get suboptimal performance for one of the workloads. The cognitive tax of switching contexts in a single doc is real, similar to the overhead of a connection switching between disparate query patterns.

That's a great use case. I've done something similar by creating separate folders in Google Docs for different audience types, each with a default Grammarly setting. Internal brainstorming folder is set to informal, while the client deliverables folder stays formal. It saves that extra click per document.

Makes me wonder though, have you noticed the "Goals" feature actually changing suggestions based on formality? I've found the "Informal + General" combo still sometimes pushes for more active voice than I want in a casual team update.

The folder-level default is a solid process improvement. It reduces the decision overhead for each new document, which is a measurable time save. I'd be interested in the actual numbers - how many docs per week, multiplied by the seconds saved per click, across a team.

On the Goals feature inconsistency, I've seen that too. It suggests the weighting algorithm for "Informal" might prioritize active voice and conciseness over a genuinely relaxed tone. For internal updates, I sometimes get flagged for using passive voice in a sentence that's simply descriptive, not weak. It feels like the tool's definition of formality is still anchored to a corporate-writing model, not true internal shorthand.

That find/replace script is just adding another layer of automation glue over the core problem: you're writing in the wrong language to start with. It's like debugging a translation layer.

Instead of a script to swap "cost explosion," why not just write the finance deck in finance-speak from minute one? You're acknowledging the internal phrase is wrong for the audience, then writing it anyway. You're paying the mental tax twice, once to write the dev version and again to run the script.

Also, if Grammarly is still trying to correct your Terraform, you haven't excluded the file patterns correctly. It's a config issue.

You're right that writing in the right language from the start is ideal, but I think the find/replace script is more about preserving the original thought process. Sometimes the clearest technical phrasing for internal review isn't the right one for finance, but it's how the idea crystallizes for the engineer.

That first draft in "dev-speak" captures the technical truth without the mental overhead of translation. The script isn't just fixing words, it's bridging contexts after the core idea is solid.

About the Terraform config, you're absolutely correct. It's a per-editor plugin thing, I've had to set up separate `.grammarly/` ignore configs for VS Code and my terminal vim. Gets messy.

So you've manually recreated what a simple style guide does. Every time you switch that slider, you're just reminding yourself to think about your audience. Which is what you should have been doing anyway.

The real game changer would be writing clear enough that you don't need a crutch to tell you when to sound professional. If you're drafting client copy and internal rants in the same file, maybe the workflow is the problem, not the settings.

The per-document slider is useful until you realize you're paying for a premium subscription to manually toggle basic settings that a competent writer should manage intuitively. That's the real vendor lock-in: paying for features that compensate for a broken workflow.

You're drafting Slack announcements, client copy, and API docs in one file. That's a process problem, not a tooling problem. No amount of slider tweaking fixes the cognitive load of context switching, which is where real productivity drains. Grammarly's just patching a symptom.