Turn a lesson, an article, or a code change into posts.
The hard part is not length, because a post can be as long as it needs to be. The hard part is that a lesson builds context first and then makes a point that only lands because of that context. Pull the point out on its own and it becomes a truism.
So this skill looks for the two or three situations in the lesson that carry their own context. A situation with real details in it explains itself. A conclusion without them reads as generic advice, and the timeline is already full of generic advice.
Steps
- [ ] 1. Find the source
- [ ] 2. Extract standalone claims
- [ ] 3. Pick platforms
- [ ] 4. Write
- [ ] 5. Hand it back
1. Find the source
Look for a lesson in docs/lessons/ or an article in docs/articles/. If neither exists, run from the change using references/shared/change-analysis.md and references/shared/prompt-recovery.md.
2. Extract standalone claims
Read the source and pull every claim that could be true and interesting to someone who has not read it.
Then cut each one that fails this test. Hand it to a stranger with no context. Do they learn something specific, or do they nod at something they already believed?
"Be specific in your prompts" fails, because everyone agrees and nothing changes.
"I asked for replies and never said how to store them, so it built a second table with its own id, timestamps, and author column" passes. It is a situation rather than a conclusion, and the reader can picture it happening to them.
Prefer the ones where you were wrong, or where the agent was reasonable and still wrong. Those carry a position, and a post without a position is a summary.
Most lessons yield two or three that pass. If you find eight, the bar has slipped. If you find none, say so rather than shipping filler.
Nothing in this lesson stands alone well. The useful parts all depend on seeing the diff. Want me to post the code screenshot with a short caption instead, or wait for a lesson with a more portable idea in it?
3. Pick platforms
Ask, unless the user already said. Do not write for all of them by default, because a post shaped for nothing in particular performs on nothing in particular.
Read references/platform-shapes.md for what each one wants.
4. Write
Read references/platform-shapes.md and references/shared/voice.md.
The house rules apply here with more pressure than anywhere else, because the whole genre runs on the vocabulary they ban. No "this changes everything". No thread that opens with a number and a rocket. No manufactured stakes. The claim is either interesting or it is not, and dressing it up is how a technical audience learns to scroll past you.
One thing this medium adds. The post has to be true on its own, without the article's qualifications sitting underneath it. A claim that needed three caveats in the lesson needs them in the post too, or it needs to not be the post.
5. Hand it back
Output the posts inline in chat, not as a file. They get pasted into a compose box within the minute, and a file is friction with no payoff.
Include the character count for anything with a limit.
Reference files
references/platform-shapes.md: what each platform wants and what it punishesreferences/shared/simplified-english.md: ASD-STE100, the sentence and vocabulary rulesreferences/shared/voice.md: house style, all mediumsreferences/shared/change-analysis.md: scoping a diff, reading it, verifying claimsreferences/shared/prompt-recovery.md: finding the prompt in any agent's history