SDK language pages duplicate the content from the sidebar

[Duncanma]

But aren't automated, so they drift often

We should either automate this or possibly remove the duplication (should it just be intros to each subsection?)

[DABH]

@Duncanma I looked into this and opened #5179 as a draft. Summary of what I found, since a couple of things argue against my own first instinct.

The clearest example is four days old

#5118 added 19 Serverless Workers pages across seven SDKs. Landing-page links to that feature afterwards:

SDK	pages	landing-page links
go	3	1
java, python, typescript, dotnet	3 each	0
ruby, rust	2 each	0

A documented feature was unreachable from six of seven SDK landing pages. That is a better argument for this issue than any count of duplicated links.

On your fork: automate or remove?

I researched both, deliberately including a pass whose brief was to argue against automating. It still came out for automating, on three pieces of evidence:

• docusaurus.config.js sets onBrokenLinks: 'throw', so every one of the 319 bullet links on those pages is machine-checked. Replacing them with prose moves that content into the unchecked category — and every frontmatter defect I found this week (four wrong description/title values, fixed in Fix copy-pasted titles and labels on SDK section index pages #5155) was in exactly that unchecked category.
• docs/develop/go/index.mdx has a 16-line hand-written prose block (### Where are SDK-specific code examples?) that exists on Go and no other SDK, 4.5 months on.
• A tracked correctness sweep added "This timeout is non-retryable by design" to activities/timeouts.mdx across the SDKs and landed on 7 of 8 — Ruby missed. Of 117 commits touching an SDK landing page in the last 18 months, 52 touched exactly one page and 3 touched all eight.

So "one descriptive sentence per section" means 72 strings maintained in parallel across 8 SDKs, and the history says parallel maintenance is the thing that does not happen here. Prose is still the right answer for the section index pages, 52 of which are a banner and a bullet list with no prose at all — but that is a separate change.

What #5179 does

Wraps each ## [Section](url) list on the 8 landing pages in markers and fills it from sidebars.js. It adds 11 missing links, including Serverless Workers to all six SDKs that lacked it.

Insert-only, deliberately. I built full generation first and measured it: on the section index pages it would have deleted 7 links — including an external learn.temporal.io tutorial living inside a section list — and rewritten 37 labels, several against the sentence-case rule in STYLE.md (Feature guide → Feature Guide). The sidebar also contradicts itself across SDKs on the same page. So the sidebar decides which pages appear; the prose keeps its own text and order. Net diff is 125 insertions, 0 deletions.

It generates text rather than rendering a component because DocCardList is registered strip-block in scripts/mdx-to-md.mjs. A component would blank these links in llms-full.txt and the per-page .md unless someone also maintained a handler. Not hypothetical: GuidesGrid was never wired in, so build/guides.md is 225 bytes with zero guide links today.

Three things I would rather you decide

1. Is generating the direction you want, or do you prefer removing these lists? The mechanism works either way and I have not assumed.
2. Should check:sidebar-links block CI or just advise? No workflow is wired yet.
3. 116 of the 125 added lines are markers, for 12 link lines. A marker-free variant could infer the region from the ## [Section](url) heading and delete all 116, at the cost of a page losing any way to say "this list is deliberately hand-written." I did not build it — if you would prefer that shape, it is a small change and better decided before this lands than after.

Also worth separating out: the This section explains how to implement <X> with the <Y> SDK template is on ~68 pages at 67-73 characters, which is under the 120-155 target you documented in #5160. That is independent of this issue and looks like it belongs in the follow-up you mentioned there.