The step that polishes the prose never ran for 41 days. Wording the instruction more firmly did nothing.
Every morning's write-up was supposed to pass through one more step that strips translationese and machine-sounding prose. From August 23 that step never properly ran, for 41 days. There were four layers of cause. My first fix was to word the instruction more firmly, and the next day it was skipped again. What worked was handing the text to a fresh reader and recording how many sentences it changed.
This is not a news summary. It is a record of something that happened while building this site.
Each morning the routine writes summaries and takeaways for ten stories, then is supposed to run them through one more pass (humanizer) that strips translationese and machine-sounding prose. I added that step on August 23.
On September 30 I read that day's text myself and kept hitting sentences that did not look like they had been through it. I assumed it had started a few days earlier. Going back, it had never worked.
One mention in 43 commits
Of the 43 briefing commits the routine made after August 23, exactly one mentioned the step: September 7, "the skill did not load, so I skipped it." The other 42 said nothing either way. It was an omission, not a failure, so nothing made a sound.
Four layers of cause
- The skill files lived only on my PC. The cloud routine runs from a clone of the repository, and they were not in it. The procedure allowed "skip it if the skill cannot be loaded," and that exception held every single day.
- The routine had no tool for invoking skills. "Pass it through the skill" never turned into an action it could take.
- Nothing recorded whether the step happened, so a single line like "applied it while writing" could close it out.
- All ten stories were written by one script in one go. Polishing separately meant reopening that finished block. The faster model I switched to on September 29 wrapped up in about 30 turns and dropped steps like this first.
A firmer instruction did nothing
My first response was to reword the procedure (September 30). It said "if time runs short, skip it and still send." I had meant "don't let this block the send," and it read as "you don't have to." I wrote that time is not a reason.
The next day the routine skipped it again. This time it said "the skill isn't in this environment," which was true. I had made the sentence firmer without seeing the first cause.
The morning after I put the skills in the repository (October 2), the routine did read the files. Then it reported "applied while writing" and did no separate pass. The same day I made site generation count and print style warnings, and ran a rehearsal. The routine cut the warnings from 5 to 0 and reported "reread everything from the top and fixed it." The run log showed the site being built three seconds after the text was written, and the only lines touched were the five the warnings pointed at.
A second reader
From October 2 the step no longer lives inside the routine. The routine extracts the sentences to polish into a file and starts two subagents, one editing Korean and one English, each in a fresh context. They have never seen the text, so there is nothing to claim was already applied. Each returns before and after for every sentence, and a script checks that no number or proper noun changed before applying them. How many sentences changed goes into that day's archive.
I changed the brief too. In rehearsal, a subagent that had read the whole generic style rulebook fixed 3 of 39 sentences, only the ones matching a rule. Rereading older issues that day, the worst problems were not style at all. A Monday headline called the next day's event "next week." Another sentence tied cause and effect tighter than the source did. So I rewrote the brief around before-and-after examples from this briefing's own sentences, with facts and consistency checked first. Because it takes judgment, it runs on a larger model.
| Issue | Korean | English |
|---|---|---|
| Oct 3 | 10 / 41 | 9 / 28 |
| Oct 4 | 15 / 36 | 10 / 28 |
| Oct 5 | 15 / 36 | 13 / 27 |
| Oct 6 | 10 / 36 | 7 / 27 |
| Oct 7 | 10 / 37 | 9 / 24 |
What I'm taking from it
Writing "go through this step" into an unattended job does not make the step happen. There has to be a trace a machine can count, and someone has to look at that number the next day.
The first question I asked was "why isn't it doing this?" That question only led to rewording the instruction. The one I should have asked first was "how would I know it did?"