Introduction

blog.exiguus on  main [$✘?] is 📦 v1.0.0 via  v24.13.1 took 5s
❯ ./validation/scripts/check.sh -v apps/blog/content/posts/how-i-hacked-my-writing-process/index.md
Validating: How I Hacked My Writing Process: A Developer’s Guide to Quality Gates
----------------------------------------

=== Gate A: Blocking Failures ===
✓ [A1] Format: All required frontmatter fields present.
✓ [A1] Format: Date format is valid (YYYY-MM-DD).
✓ [A1] Format: TOML delimiters are valid.
o [A2] Fact-Checking: Source verification (manual validation required)
✓ [A3] Links: No dead links found.
✓ [A4] Images: No images to validate (none in frontmatter).
✓ [A5] Structure: All footnotes have matching references and definitions.
o [A6] Link Relevance: Ensure all links are relevant and add value (manual validation required)
✓ [A7] Links: No bare URLs found in body text.

=== Gate B: Major Quality Checks ===
⚠ [B1] Structure: Missing Conclusion section (should be H2: ## Conclusion or similar).
✓ [B2] Structure: No H1 headings in body; hierarchy looks correct.
o [B3] Evidence Quality: Verify claims are supported by evidence (manual validation required)
✓ [B4] Format: All code blocks have language fences.
⚠ [B5] Structure: Core sections count is 8 (expected 3-6).
✓ [B6] Structure: No duplicate section headings found.
o [B7] Quote Accuracy: Verify quotes are accurate and properly attributed (manual validation required)
o [B8] Conclusion Quality: Assess conclusion effectiveness and synthesis (manual validation required)

=== Gate C: Accessibility & Style ===
✓ [C1] Format: No hero image present (valid if none is needed).
✓ [C2] Format: Description length is appropriate.
⚠ [C3] Links: Found '1' instances of 'click here' link text. Use descriptive text instead.
✓ [C4] Tables: Tables have headers.
o [C5] Originality Check: Verify content is original, not plagiarized (manual validation required)
o [C6] Argument Balance: Ensure fair and balanced presentation (manual validation required)
o [C7] Writing Quality: Assess tone, readability, and style (manual validation required)

----------------------------------------
Validation Summary:
  Gate A (Blocking):      0 failure(s)
  Gate B (Quality):       0 failure(s)
  Gate C (Accessibility): 0 failure(s)
  Warnings:               3 warning(s)
  Automated:              14/22 gates (63%)
  Manual:                 8/22 gates (A2 A6 B3 B7 B8 C5 C6 C7)
----------------------------------------
Note: To get help with manual validation, run: ./scripts/assisted_checks.sh --help

Result: PASSED

I’m a software developer by trade, not a writer. When I sit down to draft a blog post, I don’t feel like a wordsmith—I feel like an imposter. My natural habitat is the terminal ¹, where logic is clear, feedback is immediate, and problems are solved with syntax, not prose. But writing? Writing feels like stepping into the unknown, where the rules are fuzzy, and the compiler (in this case, my own self-doubt) throws warnings I don’t know how to fix.

That’s why I built a quality gates system for my writing. It’s my way of bringing the structure, automation, and clarity I love in programming to the chaotic world of content creation. And it works. Not because it turns me into a great writer overnight, but because it gives me a process I can trust—one that turns my insecurities into actionable tasks and my self-doubt into confidence.

From Terminal to Text Editor: Why a Programmatic Approach Fits

As a developer, I’m used to environments where:

• Feedback is immediate: A compiler tells me exactly what’s wrong and where.
• Standards are enforceable: Linters catch style violations before they become problems.
• Processes are repeatable: CI/CD pipelines ensure consistency across every build.

Writing, by contrast, often feels like the opposite. Without clear rules or automated checks, every post is a gamble. My quality gates system changes that by borrowing the best parts of software development:

• Automated gates act like linters and compilers, catching objective issues (broken links, missing metadata, wrong formats, and syntax errors).
• Assisted gates function like code reviews, guiding me through subjective but critical evaluations (argument balance, source credibility, writing quality).

This approach doesn’t just improve my writing—it makes the process feel familiar and safe. I’m not a writer lost in the wilderness; I’m a developer running my work through a pipeline I understand.

The Psychology: Turning Self-Doubt into Debugging

The Problem: Vague Fear

As a developer, I know how to debug code. But how do you debug confidence? The biggest barrier to my writing wasn’t a lack of ideas—it was uncertainty. Without clear standards, every post felt like a leap of faith. Was it good enough? Did I miss something? Would anyone care?

My quality gates system solves this by turning subjective fears into objective checks. Instead of wondering, "Is this any good?" I can ask, "Does it pass the gates?" That’s a question I know how to answer.

The Solution: Constraints as Liberation

In programming, constraints aren’t limitations—they’re the foundation of creativity. A function’s signature forces you to think clearly about inputs and outputs. A linter’s rules ensure your code is readable and maintainable. My quality gates work the same way:

• Automated gates enforce the "syntax" of writing: proper formatting, functional links, complete metadata.
• Assisted gates guide the "architecture": clear arguments, credible sources, engaging style.

By defining what "good enough" looks like, the system gives me permission to ship. If a post passes the gates, it’s ready—even if my inner critic is still noisy. This is how I turn perfectionism from a blocker into a non-issue.

How the System Works: a Developer’s Workflow

Phase 1: Write Freely (Like a First Draft of Code)

I start by writing without overthinking—just like I’d sketch out a rough draft of a feature. Like a prototype, an architectural draft, or a proof of concept. At this stage, the goal isn’t perfection; it’s getting the logic down. The gates come later.

Phase 2: Run the Automated Gates (Compile and Lint)

Before I even think about the bigger picture, I run the automated checks. These are the "compiler errors" of writing:

Check	Analogy	Purpose
Markdown syntax	Syntax errors	Ensures proper formatting (headings, lists, code blocks)
Link validation	Broken imports	Verifies all links are functional
Image existence	Missing assets	Confirms all image files exist
Metadata	Missing config	Enforces required frontmatter fields
Accessibility	Code style violations	Checks for alt text, descriptive link text

These checks run automatically, often as part of my CI/CD pipeline or pre-commit hooks. They’re my safety net, catching the kinds of mistakes that would undermine my credibility or readability. Just like a linter, they ensure I’m not shipping broken code—or in this case, a broken post.

Phase 3: Assisted Gates (Code Review for Prose)

Once the automated checks pass, I move to the assisted gates. This is where the system acts like a code review, but for writing. The prompts guide me through a structured evaluation:

Prompt	Analogy	Focus Area
A2: Source Verification	Dependency checks	Are all sources credible and properly cited?
A6: Link Relevance	Unused imports	Do all links add value and fit the context?
B3: Evidence Quality	Logic validation	Is the evidence supporting my claims robust?
B7: Quote Accuracy	Input validation	Are all quotes correctly attributed?
B8: Conclusion Quality	Function completeness	Does the conclusion synthesize the main points?
C5: Originality Check	Duplicate Code	Is the content unique?
C6: Argument Balance	Edge case testing	Does the post consider diverse perspectives?
C7: Writing Quality	Code readability	Is the tone, style, and readability engaging?

These prompts don’t just catch problems—they teach me how to think about writing like a developer. For example, the "Argument Balance" prompt (C6) is like testing edge cases: it forces me to consider perspectives I might have overlooked. The "Source Verification" prompt (A2) is like checking dependencies: it ensures my post is built on a solid foundation.

Phase 4: Iterate and Ship (Like Deploying Code)

Just like in software development, the goal isn’t to create something perfect on the first try—it’s to ship something that works and improve it over time. The gates help me do that by:

1. Catching critical issues early (automated gates).
2. Guiding refinements (assisted gates).
3. Giving me confidence to publish (trust in the process).

For example, my post "Perfect is the Enemy of Good" went through this exact workflow. The Quality Gate Report flagged a few issues:

• Automated: The hero image alt text was too short (21 words instead of 30-45).
• Assisted: The conclusion could better synthesize the main points (B8).

Neither of these were blockers, but they gave me clear, actionable feedback—just like a code review. I addressed the issues, ran the gates again, and shipped with confidence.

The Biggest Win: Trust in the Process

The most valuable outcome of this system isn’t just better writing—it’s trust. Trust in two directions:

1. Trust in Myself

As a developer, I trust my code because I’ve tested it. Similarly, I trust my writing because I’ve run it through my gates. The system doesn’t lie: if the checks are green, the post meets a defined standard of quality. That’s a powerful antidote to imposter syndrome.

2. Trust from Readers

Consistency is key to building an audience. My gates ensure that every post on my blog adheres to the same standards for structure, sourcing, and style. Readers may not notice the alt text length or the balance of arguments, but they do notice when a blog feels reliable—like a well-maintained codebase. That reliability builds trust over time.

The Result: More Output, Less Paralysis

Before I implemented this system, I’d often get stuck in a cycle of drafting, second-guessing, and endlessly tweaking—like an infinite loop with no exit condition. Now, my workflow is structured and predictable:

1. Write the first draft (no overthinking).
2. Run the automated gates (catch the low-hanging fruit).
3. Apply the assisted gates (refine the nuances).
4. Iterate based on feedback (improve, don’t perfect).
5. Ship it (confidence in the process).

The gates don’t just improve my writing—they unblock me. By externalizing the criticism, they free me up to focus on what matters: getting my ideas out into the world.

And here’s the best part: The more I use the system, the better I get at writing without it. The prompts and checks have become part of my mental model. Or the other way around: I free my mind to focus on the content, while the system handles the rest.

I now notice issues like weak conclusions or unbalanced arguments as I’m writing, not just during review. The system isn’t just a crutch—it’s a training wheel that’s teaching me to ride on my own.

Try It Yourself: Build Your Own Writing Pipeline

If you’re a developer (or anyone who thrives on structure), I’d encourage you to build your own quality gates system. Start small:

1. Automate the basics: Use tools like markdownlint for formatting, lychee for link checking, or a custom script for metadata validation that fits your workflow and makes you less likely to forget something.
2. Add assisted checks gradually: Pick 2-3 prompts from my markdown.post.validate repository and apply them to your next post.
3. Iterate: Refine your gates based on what’s most helpful for your writing.

You don’t need to be a great writer to start. You just need a process you can trust—one that turns writing from a vague, intimidating task into something as familiar as debugging code.

Final Thought: Writing Like a Developer

I’m still a developer at heart, and I’ll probably always feel more at home in a terminal than in a text editor ². But my quality gates system has given me a way to bring my strengths to writing. It’s not about becoming a different person—it’s about applying the same principles that make me good at my job to a new challenge.

The system doesn’t erase my doubts, but it gives me a way to move forward despite them. And that’s the real power of quality gates: they don’t just make your writing better. They make you better—one check at a time.

For a deeper dive, explore the implementation at markdown.post.validate and see how the gates worked for my post "Perfect is the Enemy of Good" or take a look at the Quality Gate Report for this post to see the gates in action.

Notes