A guide that runs past a couple of thousand words needs a way to jump around, but adding anchor ids to every heading and hand-building the “in this article” list is fiddly, easy to get wrong, and the sort of thing you put off. So the long post stays a wall with no shortcuts, and readers bounce before they reach the section they came for.
This hands the mechanical part to the agent and keeps you as the one who says go.
I want to add jump links to [this long post: https://example.com/my-guide/].Read the post first and change nothing yet. Find the section headings, andfor each one work out a clean anchor id from the heading text. Then hand meback a plan: the list of headings you found, the anchor id you would giveeach, and the "jump to section" list you would add near the top that linksdown to them.
Wait for my yes. Only after I approve, add the anchor ids to the headingsand insert the jump list, editing the post body and nothing else. Leave thestatus alone so it does not republish, and keep it reversible through thepost's revisions. When you are done, give me the before-and-after for everyheading you touched.Why this is safe to run
The whole first pass is a read. Pulling the post and mapping out the headings writes nothing, so you see the full plan, every heading and every id, before a single character is saved.
The write half only edits the post body. It never changes the status, so it cannot publish a draft or take a live post down, and every edit lands as an ordinary revision you can roll back from the editor. On top of that the content write ability is off until you switch it on, each call is checked against the capability of the user you bound the agent to, and every write shows up in the Activity Log with the post it changed.
Already connected? You do not have to paste this at all. Ask your agent for the “turn plain links into on-page jump anchors” recipe, or just describe the job, and it runs the same read-plan-approve flow on your own site.