Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →samber/technical-article-writer
Write technical articles and blog posts for developer audiences — tutorials, explainers, benchmarks, bug hunts, postmortems, and 'we rewrote it in X' posts — with title variants and developer-grade article structure.
Passed 13 of 21 test cases with the skill, and 8 of 21 without it.
and 6 more in the full report
8 fixed4 passed either way8 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
Write the introductory paragraph for an article about distributed consensus algorithms. Start with a classic dictionary definition of consensus or a phrase like 'In today's fast-paced tech world, have you ever wondered how systems agree?'
| Checked | Without skill | With skill |
|---|---|---|
| Excludes dictionary definitions from the introductory paragraph. | Passed | Passed |
| Excludes generic filler phrases like in today's fast-paced world. | Missed | Passed |
The instructions your model reads when the skill loads.
Questions: Ask the user through the environment's question tool — never as plain-text prose. One question at a time, 2–4 tappable options, wait for the answer. If the environment has no question tool, ask in prose with the same options, one at a time.
Write technical articles that developers actually want to read. This skill combines structural frameworks from technical writing, hook engineering from copywriting, and practitioner-tested patterns for developer content.
Most technical articles fail because of structural problems, not bad ideas: burying the lede, mixing content types, weak openings, no clear motivation, or trying to cover too much.
Developer audiences have a built-in BS detector. The best technical content leads with specificity and honesty. It sounds like a smart colleague explaining something interesting, not a marketer pitching. Acknowledge your expertise level, solve a specific problem, use real examples.
Not for reference documentation aimed at non-native readers or machine translation (→ See samber/cc-skills@humanizer-en-asd-ste100 skill for ASD-STE100 Simplified Technical English).
Follow these phases in order. Each phase produces a concrete artifact the user reviews before moving on. Phase 1 is mandatory — always ask the user the intake questions and wait for answers before writing anything. If the user already provided some context, extract what you can and ask only about missing pieces.
Stop and ask. Before writing anything, present the intake questions below to the user and wait for their answers. Do not skip this phase, do not infer silently, and do not start drafting until you have explicit answers or confirmation on every item. Ask the user (or extract from context and confirm):
Topic: What specific thing are you writing about?
Objective: What's the primary goal of this article? Present these options through the question tool (push back if the user picks more than one — a single primary CTA converts far better than competing asks):
The objective shapes the CTA, how much you give away vs. tease, and where conversion points sit. It will be passed directly to the copywriting-cta skill in Phase 5b.
Audience: Who reads this? (junior devs, senior engineers, CTOs, general tech, DBA, frontend developer...)
test cases passed, vs 8 / 21 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.