Turning a Manual AI Writing Workflow Into a Reusable Production Skill

My first complete AI-assisted Blog cycle worked, but it was not yet reusable.

The article reached production in English and Simplified Chinese. Research, briefing, drafting, audits, targeted revision, website implementation, metadata, structured data, responsive checks, publication, and live verification all happened. From the outside, the workflow looked complete.

Inside the process, too much depended on manual orchestration. Important rules lived in long task instructions. Approval decisions were spread across conversations. A later stage sometimes needed the owner to restate a boundary that an earlier stage had already discovered. The work could be repeated, but only by someone who remembered how every previous decision fit together.

That is the difference between a successful run and a reusable production Skill. A Skill has to preserve the operating judgment around the writing, not merely reproduce the writing steps.

This article explains how I converted the HuiyangXie.ca Blog workflow into that kind of system. It focuses on the production-Skill experiment, not the detailed keyword-research subsystem or a claim that content can publish itself.

A long prompt was evidence, not the final architecture

The manual cycle contained valuable instructions: validate the source artifacts, prepare a Content Brief, control claims, draft in English, audit the draft, revise surgically, freeze the approved source, create a native Chinese version, compare facts across languages, implement the site, and verify publication safety.

Copying all of that into one larger prompt would have preserved the sequence. It would not have solved the deeper problem. The next run still needed to know which instructions applied, what state already existed, and whether a failure should reopen research, drafting, translation, or implementation.

I treated the manual run as process evidence. Repeated decisions were candidates for a durable rule. One-off incidents remained examples unless they exposed a general boundary. Owner corrections carried more weight than convenient inferences because they showed where the workflow’s wording had allowed the wrong behavior.

The extraction questions were practical:

• Which decisions appeared in more than one stage?
• Which errors happened because a state or owner was unclear?
• Which checks could run consistently without changing editorial authority?
• Which failures needed a targeted repair path rather than a restart?
• Which facts had to survive between English, Chinese, and the website?
• Which actions required an explicit owner decision even when every audit passed?

The answers became modules and contracts. The original prompts remained provenance; they stopped being the runtime interface.

Modules formed around responsibilities, not chronology

The first reusable version separated portfolio research, topic readiness and briefing, English editorial work, Chinese native adaptation, website handoff, publication verification, and later observation.

This mattered because those responsibilities run on different rhythms. Keyword discovery is periodic. An article brief is per-article. English and Chinese have different editorial ownership. Website implementation introduces routing, metadata, schema, and publication-state behavior. Observation begins after production and should not reopen the draft merely because early performance evidence is thin.

A chronological “Step 1 through Step 20” design would have made every run look identical. Modules allowed the Skill to detect the current state and load only the relevant contract. A topic with valid research could move directly into briefing. A Chinese revision could begin from the exact locked English source without rerunning discovery. A website failure could return to implementation without paying for provider calls again.

The architecture also made ownership visible:

Clear responsibilities made the system easier to automate because each module had a smaller question to answer.

State replaced conversational assumptions

The most important change was explicit state.

In ordinary conversation, “approved,” “ready,” “final,” and “done” can sound interchangeable. In a production workflow, they authorize different actions. A topic in the backlog is not approved for production. A Content Brief can be approved for drafting without becoming immutable. An internally validated English candidate is not owner-approved. A website preview is not published. A successful build is not production verification.

The Skill therefore had to record both the artifact and what its state allowed next. Before final owner review, English and Chinese use candidate locks: exact paths and hashes for the versions that passed internal audits. The locks let downstream preparation use stable inputs. They do not create an owner freeze.

The owner later reviews one consolidated package containing the article, both languages, preview routes, evidence summary, audit results, and publication-readiness checks. An explicit approval can then ratify those exact candidate hashes, create freeze records, and authorize a separate publication handoff.

This distinction protects against subtle drift. If the owner requests a change, the workflow creates a new candidate and reruns the affected checks. It cannot silently claim that the old hash remains approved.

The same logic applies to completion. The “Define Done” article discusses the broader acceptance problem. Inside the Skill, the practical rule is that every state must name both what has been verified and what remains outside its authority.

Audits became internal transitions, not repeated meetings

The manual cycle asked the owner to review the brief, English draft, English revision, Chinese draft, Chinese revision, visual implementation, and publication decision. Some of those gates protected real editorial authority. Others compensated for a workflow that could not yet audit and repair itself reliably.

The low-touch version moved routine checks inside production. The Content Brief receives an internal strategy and evidence audit. English receives separate brief, claim, and humanization audits. Chinese receives native-language, AI-pattern, factual, brief, claim, evidence, and scope regressions. Website implementation receives source, build, render, accessibility, SEO, GEO/retrieval, schema, link, and draft-safety checks.

Passing those audits does not make the machine the editor. It allows the workflow to prepare a more complete candidate before asking for editorial attention.

Humanization is a useful example. A LOW pattern rating normally requires no automated revision unless a specific material problem exists. MEDIUM usually calls for a targeted change. HIGH may justify broader work, but facts, strategy, and approved evidence remain fixed. The score guides action; it does not reward rewriting for its own sake.

This is where the first Skill pilot was especially valuable. Automated checks could say LOW while an owner still found a passage too textbook-like, an example implausible, or a heading too slogan-like. Those corrections did not invalidate the audits. They showed the boundary between consistent diagnostics and editorial judgment.

Targeted repair needed a budget of its own

Once audits could run automatically, the next risk was an audit-repair loop. One revision could improve rhythm while weakening a claim. A factual correction could create a brief mismatch. A website transformation could fix rendering while altering visible meaning.

The workflow now treats each material blocker as a stable item with an audit signature, attempt count, and status. A repair changes only the smallest affected surface, then reruns every relevant regression. It does not regenerate the whole article when the strategy and most prose already pass.

Four rules keep repair bounded:

• one blocker receives at most two automated repair attempts;
• one normal article receives at most four material automated repair actions in total;
• repeated failure signatures or cross-audit ping-pong stop the loop;
• a downstream failure never replays completed paid research.

If the issue remains unresolved, the state becomes EXCEPTION_OWNER_DECISION_REQUIRED. That is not a workflow failure. It is the designed handoff for evidence ambiguity, strategic conflict, privacy risk, unexpected spend, or an exhausted repair budget.

The first two-article low-touch pilot stayed within those limits. Both articles reached final-review candidates without a mid-run owner exception. The website layer used one material repair for the first article and two for the second, covering table representation and safe treatment of an unpublished relationship. No paid research was replayed.

Those results are process evidence from a small pilot. They do not prove that every future topic will fit the normal path.

Evidence contracts kept originality from becoming invention

The manual workflow encouraged first-party evidence because it differentiated the Blog. The early Skill language risked turning that preference into a quota. A topic could be pushed to include another anecdote or reuse the same Case simply to look original.

The revised contract made evidence conditional on content mode. Search-led articles may use first-party material when it improves accuracy or usefulness. Authority-led articles normally include practitioner judgment without a fixed anecdote count. Experiment-led articles need first-party method, observation, or result evidence because the experiment itself is the subject.

Evidence also receives a claim state. A recorded process observation is different from a newly supplied owner-confirmed fact. A current external claim needs a suitable source. An unsupported or confidential claim is excluded. New owner evidence records provenance and disclosure limits instead of pretending it existed in an older Case artifact.

This approach made the writing more credible and less performative. Originality came from a real decision or observation, not from forcing personal detail into every section.

The same contract controlled bilingual work. The locked English candidate defined facts, thesis, examples, attributions, and claim boundaries. Chinese controlled native syntax, rhythm, terminology, and editorial fit. An EN↔ZH factual regression checked the relationship without requiring sentence-by-sentence translation.

Website implementation revealed rules the editorial module could not see

A document can be editorially complete and still be unsafe to ship.

In one pilot, a comparison table was valid content but the renderer displayed its Markdown syntax as text. The website layer converted it to supported semantic markup without changing visible meaning. In another case, an intended related Workflow was still unpublished. The relationship remained in structured handoff data, while the visitor-facing body degraded to safe text rather than creating a dead link.

Those cases became reusable rules:

• Blog, Work/Case, and Workflow relationships use separate typed fields.
• Unpublished destinations are filtered, hidden, or rendered as safe text.
• Empty related-content sections disappear cleanly.
• Semantic tables and lists preserve meaning even when the website changes representation.
• Site-owned values such as title suffixes and author formatting come from website configuration, not the editorial handoff.

The Blog Skill has standing authority to prepare published:false website drafts and run preview checks for an authorized queue item. It still cannot publish, stage Git changes, deploy, or absorb unrelated website work.

That final separation is deliberate. Publication is handled by an independent adapter using the exact owner-approved package. A Blog release cannot accidentally carry unrelated visual changes simply because both exist in one working tree.

What changed from the first Skill to the low-touch workflow

The first private Skill captured the modules and quality safeguards. The next pilot exposed ambiguous rules around topic approval, brief approval versus freeze, evidence provenance, humanization action, Chinese routes, semantic tables, and unpublished internal links. Those findings became a narrow patch rather than a redesign.

The low-touch version then changed the interaction model. Routine brief, draft, claim, language, and implementation gates became internal audits with bounded repairs. Candidate locks kept the exact files stable. One consolidated owner review replaced several normal mid-cycle interruptions. Exception rules remained available for decisions the workflow could not safely make.

The goal was not zero human involvement. It was to spend human attention where it changes meaning, authority, or release state.

A reusable Skill should therefore be evaluated on more than whether it generated similar prose twice. I now look for five properties:

• State clarity: every module can identify its canonical input and permitted next action.
• Evidence control: claims have provenance, disclosure limits, and explicit exclusions.
• Repair discipline: failures trigger bounded local changes instead of full regeneration.
• Ownership boundaries: editorial, bilingual, website, and publication responsibilities remain distinct.
• Review quality: the final owner package makes the important decisions visible without reconstructing the run.

These properties make the workflow inspectable. They also make exceptions easier to recognize.

Reuse means preserving judgment in an executable form

The manual cycle taught me what decisions mattered. The Skill became useful when those decisions moved out of conversational memory and into artifacts, states, audits, repair rules, and ownership boundaries.

Some parts remain intentionally human. The owner can reject a topic, challenge evidence, change the editorial direction, or refuse publication even when every automated check passes. The Skill’s job is to prepare a coherent, traceable candidate and surface the decisions that deserve that attention.

That is the standard I would use for any AI-assisted production workflow: do not ask only whether the instructions can be replayed. Ask whether the evidence, state, exceptions, and authority can survive the replay too.