> Before you start, make sure that your AWS credentials are correct. If they are not, S3 rejects the upload with a permission error.

Wouldn't it be better to write:

Before start, ensure AWS credentials are correct. Otherwise, S3 rejects uploads with permission error.

Ads-STE100: Simplified Technical English - https://news.ycombinator.com/item?id=49101215

ASD-STE100 Simplified Technical English for LLMs - https://news.ycombinator.com/item?id=49065956

ASD-STE100 Simplified Technical English [pdf] - https://news.ycombinator.com/item?id=49075687

Show HN: Claude Skill for ASD-STE100 – Simplified English - https://news.ycombinator.com/item?id=49108318

WTFs per prompt metric raised sharply for me :)

It's very taxing, especially since these are usually multi-paragraph texts. I noticed I've started doing a lot of "hey, you're talking gibberish again" a lot with 5.6 Sol.

I wonder if limiting them to a certain style like STE upfront would make them perform better/worse vs. applying the style after they’re done.

What I have found is that getting a model to rewrite a badly written passage is hard, because it seems to key off what it reads. It might swap some vocabulary around ok, but it doesn't fix structures very well. So getting it close to the preferred style in the first place is better.

To take this further, if you must fix existing bad prose, write a clean-prose skill which extracts the bare structure of the prose with none of the style, hands it to an author subagent who isn't poisoned with the original bad prose, then hands the output to a reviewer subagent.

Opus 5 writing is horrendous, so I have been experimenting with improving the output!

However, asking Claude to write a skill encoding ASD-STE100 after seeing it pop-up in your social feed is not doing much at all. It's certainly not worth a post on HN.

Having said that, this skill might have been the seed for the flurry of low-effort posts on the subject on various platforms this week. If that's the case, I take back the majority of my scorn.

You'll have to excuse me for becoming jaded by the diminishing levels of visible effort put into projects and products shared on here.

This is the first time I’m hearing about this, I think it’s nifty, and it’s precisely why I come to hackernews at least once a day.

Also what is wrong with using Claude to make a more polished post about something that’s being talked about already?

Pick one.

"Agent Skill to Enforce ASD-STE100 Simplified Technical English in Documents"

And I agree, maybe I should use this for my emails too

Not really a promising tell for a writing skill, IMO.

> Yes, this README breaks half of them. Marketing is explicitly out of STE scope. The skill knows that and stays in the docs.

> Where it refuses to go: marketing copy, blog voice, brand writing. Flat on purpose.

(Each sentence there has an emoji that HN cuts out)

Some of this may be perception rather than reality. I have never felt that ChatGPT was being smug or rude to me.

Tends to produce relatively well structured prose that’s easy to edit.

I like it, and I'll also try the Economist one on another thread here. I have global instructions on how Claude should try to write things like I do.

I generally avoid having lots of skills, security risk as I won't vet them all.

> Rewrite this using ASD-STE100 simplified technical English:

And you get a good-enough result, it seems? Maybe add another sentence or two for guidance, but what's with needing these giant skills, when ASD-STE100 was surely in the training material?

As an analogy, students learn a bunch of things during school, become more intelligent, but do not retain explicit knowledge like all of the details on the periodic table, or all of the exact formulas for things.

Oh lord.

Smells like today. I’ll take goose shit over this.

But did lead to me finding https://vale.sh and its various available linters. Might give that a try.

> AI slop dies as a side effect

> One folder, no dependencies, MIT.

https://github.com/woosal1337/blog/tree/main/videos/ep01-the...

[1] https://knowyourmeme.com/memes/thinking-quickly-dave-constru...

- Create a skill to perform some common task

- Watch the agent use it

- Wait until the agent makes a mistake

- Ask it to update the skill to warn it against making that mistake again

I think that, using that iterative process, I end up with something better than just asking it to perform the task plainly

One observation: ask an LLM to write a skill, it tends to make them overly verbose and prescriptive. Often, something briefer and human-written actually works better

Another: I generally let the LLM propose edits to the skill, but I review them carefully and often modify them, because I find it has a tendency to solve the current problem at the price of worsening the solution to a previous one

Yep! I have a canned prompt that basically boils down to "scroll up, read through and give me the top `n` things that were difficult..." and more often than not a small skill or change to `agents.md` comes out of that.

Why do you think it can answer that? It has zero clue.

But in practice it does produce fairly reasonable output fairly often, and if you've been there watching and correcting it you can probably validate the result quite easily. "Re-read everything before" and similar are definitely anthropomorphizing, but that doesn't mean they're ineffective.

Incredibly so. All too often a “hey, you shouldn’t have done that here” turns into “NEVER X”, without it actually understanding or making an effort to understand why the correction was made, though I would say usually the context to do so should suffice. I have a rule for it to reason this through and use nuanced language and would say the frontier GPTs (5.4 to 5.6 Sol) get it right around half of the time (very rough estimate). The conclusions are really dumb sometimes.

I’d be interested in an expertly crafted skill here, maybe there are things about it you can still improve. This is an area in which I still find LLMs to be quite lacking.

It also made me appreciate the complexity of the nuances and levels of indirection of what I want to teach it: “Upload to the remote host, which in this case is this but might be another one in another use case, only do this on the local system and this on the remote, do this to X unless Y …, prefer doing Z unless another rule overrides it …”

I sometimes feel like there could be a more expressive way to structure to structure these rules (bring the snark!).

But also development instructions focusing on how and what to research before implementing (some of the stuff I do ends up heavily influenced by papers and publications while the naïve implementation is often bad, old, or gets stuck.

It makes it kind of funny publishing skills online because by the time somebody knows they want the skill, they already have it.

[1] https://microsoft.github.io/SkillOpt/docs/guideline.html

But it's very useful and skills is a good way to share promots, so whatever.

Try the skill or the prompt. It will likely improve your experience interacting with agents

https://en.wikipedia.org/wiki/Simplified_Technical_English#M...

“Writing correctly in STE is not an easy task as it requires a good command of the English language together with a good knowledge of the matter of the writing.”

This is simply what is required for good writing (in English) in any domain with or without STE.

> "Test" is an approved noun, but not an approved verb.

> STE: Test B is an alternative to test A.

So much for clear - unless you know the STE specific rule, the sentence is unambiguously ambiguous.

Direct access btw since the official site gates downloads with a Google form: https://www.asd-ste100.org/assets/files/ASD-STE100_ISSUE9.pd...

could mean there's a Test B and a Test A, and they're interchangeable.

Or:

You can run Test B to confirm A works, that is "to test A".

Again the stated goal to clear documentation for non-native or limited-exposure speakers. This doesn't pass that test.

This video benchmarks slop-style indicators with different skill/prompt solutions including the STE skill vs. George Orwell's six rules of writing prompt: Orwell came out on top overall.

Additional bonus: it doesn't add much more tokens to input context. I have compared prose prompts with these rules and without and I am liking the results.

  1. Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
  2. Never use a long word where a short one will do.
  3. If it is possible to cut a word out, always cut it out.
  4. Never use the passive where you can use the active.
  5. Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
  6. Break any of these rules sooner than say anything outright barbarous.

    "now the honesty - those translation gains were real but small"
    "and here is the honest part"
    "same disease but with different symptom"
    "so that brutal 3% number was a Claude quirk, not a law of nature"

“Output tokens are precious, be succinct in your responses. Use ASD-STE100 simplified technical english”

At this point I'd do anything to get claude to dumb down and simplify it's explanations in my code, so I'm looking forward to giving this a try and seeing how it goes.

I've added the same thing to the system prompt of the internal agent I wrote for work, which talks to claude models. I have not gone into the details on whether it adheres to the format exactly, but i do see visibly less slop and less marketing nonsense in the Assistant messages.

Clause is a token torment machine that licks your balls while stealing your wallet

Claude is so friggin wordy and has no idea how place comments iff they actually matter.

> your AI writes like a LinkedIn post. make it write like a Boeing manual.

> An agent skill that forces LLMs to write docs in ASD-STE100 Simplified Technical English: the controlled language aerospace has used since 1983 so a tired mechanic cannot misread an instruction. AI slop dies as a side effect.

AI slop doesn't die at all.

THE SYNTHETIC LUBRICATING OIL USED IN THIS ENGINE CONTAINS ADDITIVES WHICH, IF ALLOWED TO COME INTO CONTACT WITH THE SKIN FOR PROLONGED PERIODS, CAN BE TOXIC THROUGH ABSORPTION.

In STE this sentence appears as below:

DO NOT GET THE ENGINE OIL ON YOUR SKIN. THE OIL IS POISONOUS. IT CAN GO THROUGH YOUR SKIN AND INTO YOUR BODY.

Consider if you translated those phrases into a foreign language you’re basically familiar with. You can be awake as you want and mis-interpret the first one.

I heard about it from a friend, and posted its "spec" here a few days ago:

https://asd-web-be-prod.azurewebsites.net/media/wunhmi5y/asd...

Ironically?, you're not allowed to copy from the pdf (yes, trivially defeatable - but why).

I guess we'd need a linter (ruff, but for English) that gates whether you're using any non-ASD-STE100 word? Otherwise, yeah, any agent will almost certainly forget this (one line) instruction.

https://x.com/geogristle/status/2078492579511906771

If you want to take things further you can use linters to enforce the whatever style you want, but just naming it is a good start.

"When writing plans or documentation use:

ASD-STE100 Simplified Technical English (STE for short)"

I mean generally this wouldn't be considered a bad response, but it is deeply problematic if an LLM tasked to just simplify language added both internals and promises to your customers without your knowledge.

I tried to solve this in a rather opposite way.

https://github.com/computerreinvention/trie

The documentation is updated and recording the intent behind all changes is enforced by a commit-gate. At the symbol level.

Sorry. A missing hyphen!

I'll add ASD-STE100 to my list of decorposlopification strategies.

In contrast if you ask GPT 5.5/5.6 to speak directly/plainly, it will just straight up tell you the content "X is right, Y is wrong". Much preferable.