Scope your v1 to a local markdown file as input, enforce a CLI approval gate before any publish, store prompts separately from code, add a local fallback on remote failure, and drop any insight you can’t quote verbatim. These five decisions together define a minimal, trustworthy AI publishing pipeline.

Start With a Local File, Not a Hosted App

“I decided Gomny v1 should publish from a local markdown file, not from a hosted app.” — from the working session

Every publishing tool I’ve seen founders overbuild starts the same way: a database, a CMS, a hosted editor, user authentication, a deployment pipeline. By the time you’ve assembled all that, you haven’t published a single piece of content — you’ve built infrastructure.

For my first version, I made the opposite choice. A local markdown file is the publishing source. That’s it. You write in your editor, you run the pipeline, content moves. There’s no hosted surface to maintain, no database to migrate, no auth layer to debug at midnight.

This isn’t laziness. It’s a deliberate scoping decision. When you’re a solo founder, your v1 has one job: prove the workflow is worth continuing. A local file does that job. It removes every variable except the one that matters — does the AI-assisted pipeline actually produce something publishable?

The trap is thinking “minimal” means unserious. It doesn’t. A local file as input is the right tool for a single-user workflow. You can add a hosted app later, when you have real reasons to. Start with what completes the loop.

Define Your Product Boundary With a Human Approval Gate

“The human approval gate is the product boundary: nothing reaches GitHub until I type y.” — from the working session

Most founders treat a confirmation prompt as a safety check — a polite pause before the real action. I’ve started thinking about it differently. The approval gate isn’t just a guardrail. It’s the definition of where my product ends and where I begin.

Everything before that y is automated: drafting, formatting, structuring, outputting. Everything after that y is consequence: content is live, decisions are committed. The gate is exactly the line between those two things.

This framing changes how you scope the automation. The question stops being “how much can I automate?” and starts being “where do I want to be the last check?” For a publishing pipeline, that answer is clear — before anything reaches a public repository.

For your pipeline, the gate might look different. It might be a Slack message you approve, a file you rename, a flag you set. The mechanism matters less than the principle: draw a hard line between what the AI controls and what you control, make that line explicit, and never let the automation cross it without your input.

A simple CLI prompt achieves this cleanly. You see what’s about to happen, you confirm, and only then does the publish proceed. That’s not a minimal feature — it’s the core feature.

Keep Prompts in Markdown, Separate From Code

“Prompt files need to stay as markdown because I will iterate on prompts more often than code.” — from the working session

The first time I embedded a prompt directly in code, I understood the mistake immediately. Every prompt change meant touching the codebase. Every codebase touch meant treating a wording tweak like a software deployment. The cadences are completely different, and conflating them creates friction on the thing you need to be fast.

Prompts change constantly. You refine tone, tighten instructions, adjust output structure, respond to edge cases. Code changes infrequently by comparison — the plumbing stabilizes, the logic firms up, and you mostly leave it alone.

Keeping prompt files as separate markdown documents honors that difference. You open a markdown file, edit a sentence, save it. The next run picks up the change. No redeployment, no merge, no version ceremony.

This is an architectural principle, not just a file organization preference. If you’re building any AI-assisted tool, ask yourself which layer changes fastest. Whatever that layer is, give it its own home. Don’t couple fast-moving things to slow-moving things — the slower thing will always lose.

Separating prompts from code is also a gift to your future self. When something breaks, you can isolate whether the problem is in the logic or in the instruction. Those are different problems with different fixes.

Build a Local Fallback So Approved Drafts Are Never Lost

“A failed GitHub publish should never lose an approved draft; it should write a local copy and tell me where it is.” — from the working session

I’ve typed y to approve a draft and had the remote publish fail. When that happens, there are two possible outcomes: you lose the approved draft, or you don’t. The difference is whether you built a fallback.

The pattern is simple. When the remote publish fails, write the output to a local file and print the path. Don’t retry silently. Don’t swallow the error. Surface exactly where the content landed so you can handle it manually if you need to.

This matters because the approval gate and the publish step are not the same moment. You’ve made a human judgment call — this is ready — and that judgment shouldn’t be erased by a network timeout or an API failure. The approved state is valuable. Protect it.

The broader principle here applies to any pipeline with a consequential action at the end. If the remote action fails, don’t fail silently and don’t fail destructively. Persist locally, report clearly. Let the human decide what to do next with full information.

This is a reliability pattern you can copy directly. Before you wire up any remote publish step, ask: if this fails, what gets preserved and what gets lost? If the answer is “nothing is preserved,” build the fallback first.

Enforce Verbatim Sourcing to Build a Trustworthy Pipeline

“Verbatim receipts are non-negotiable; if a quote is not in the source session, the insight should be dropped.” — from the working session

This is the rule that feels like it costs the most and pays off the most.

When you’re extracting insights from working sessions, transcripts, or any source material, there’s a constant temptation to paraphrase. You almost have a quote. The meaning is close enough. You could reconstruct what was probably said. Every one of those moves is a step away from verifiability and a step toward content you can’t actually stand behind.

My rule is strict: if I can’t quote it verbatim from the source, I drop it. Not paraphrase it. Not approximate it. Drop it.

The tradeoff is real. You’ll produce fewer insights per session. Some things that felt important won’t make it through because you can’t pin them to an exact quote. Coverage goes down.

Trust goes up. And for an AI-assisted publishing pipeline, trust is the only thing that matters at scale. If every claim in every article traces back to a direct quote, you’ve built something auditable. You can answer “where did that come from?” for any line. That’s a different category of content tool than one that summarizes and infers.

Choosing verifiability over coverage is an editorial stance. It’s also an architectural commitment — your pipeline has to be built to enforce it, not just aspire to it. Surface the quote or drop the insight. Make that the rule the system follows, not a guideline you apply when convenient.

That’s how an AI publishing pipeline earns the right to be trusted.