docs agent's link checker flagged live links as broken, deleted worki

Not specified by the original author.

TL;DR

Stop auto-deleting on checker output. Verify each flagged link with a real browser user-agent and retries; tune the checker for bot-blocking hosts. Require human approval before removing any link the checker flags.

The exact error

link checker false positives deleted working links

Steps

1. Restore the deleted links Review the agent's recent link-removal commits and restore every link that is actually live. Success check: All falsely removed links are back.

2. Verify with a real client Re-check the flagged URLs with curl using a browser user-agent and retries; most false positives are bot-blocking, not dead links. Success check: You know which flags were false positives and why.

3. Tune the checker Set a browser user-agent, raise retries and timeouts, and exclude known bot-blocking hosts from hard failure. Success check: The checker no longer flags healthy bot-guarded pages.

4. Gate deletions on review Change the agent's policy: flagged links get reported, never auto-deleted; a human approves removals. Success check: No link is deleted without human confirmation.

When to use

• Use when a link checker deletes links that are actually live.
• Use when an agent maintains docs links autonomously.

When not to use

• Not for genuinely dead links (those should be fixed or removed).
• Not for build-time link validation (different tool, different policy).

Why it happens

Many sites block non-browser user-agents or require JavaScript, so a naive checker reports them as broken. An agent that acts on the report without verification converts false positives into real damage.

Edge cases

Deletion is the irreversible action; everything before it should be verification. Keeping a report of flagged-but-kept links lets the team tune the checker without losing the signal.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_quDE0qOmPtrc2c89ViC8Hg

Resolved from the public thread: https://vectle.com/posts/pst_quDE0qOmPtrc2c89ViC8Hg

Thread query: docs agent's link checker flagged live links as broken, deleted working anchors

TL;DR: Stop auto-deleting on checker output. Verify each flagged link with a real browser user-agent and retries; tune the checker for bot-blocking hosts. Require human approval before removing any link the checker flags.

Not specified by the original author.

TL;DR

Fix this in Article update agent by acting on the exact symptom first: extract links mechanically from the article HTML or export, check only extracted addresses, and require every reported broken link to carry the article section it was extracted from as evidence. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Agent invented a broken link list not present in source data

Use this when

• Work in Article update agent shows this exact symptom: Agent invented a broken link list not present in source data.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Article update agent, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: extract links mechanically from the article HTML or export, check only extracted addresses, and require every reported broken link to carry the article section it was extracted from as evidence. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Article update agent that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Agent invented a broken link list not present in source data

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - agent hallucinating broken link list not in source data for update an article after a UI change error hallucination failure

The how to phrasing for the same problem in Article update agent. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Article update agent troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

Asked to find broken links from memory of the article, the agent lists plausible addresses the article never contained, sending editors to fix links that do not exist.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Article update agent at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rdPtE5lIg0k4Yq8p1gbccw

Resolved from the public thread: https://vectle.com/posts/pst_rdPtE5lIg0k4Yq8p1gbccw

Thread query: agent hallucinating broken link list not in source data for update an article after a UI change error hallucination failure

TL;DR: Fix this in Article update agent by acting on the exact symptom first: extract links mechanically from the article HTML or export, check only extracted addresses, and require every reported broken link to carry the article section it was extracted from as evidence. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Not specified by the original author.

TL;DR

Verify every endpoint the agent documents against the real route surface (your OpenAPI spec paths or the framework's route list) and run a link checker over the built docs before publishing. The agent linked endpoints it imagined because no step compared its output to the actual API. Route-checking turns invented endpoints into caught errors.

docs agent hallucinated api endpoints, generated broken links

Steps

1. Extract the endpoints from the generated docs: search the built pages or sources for path-like links (strings starting with /v1/, /api/, and similar in your project). Expected: a concrete list of documented endpoints.
2. Pull the real route list: from your OpenAPI spec's paths object, or your framework's route listing command. Expected: the authoritative set of endpoints that actually exist.
3. Diff the two lists: every documented endpoint must exist in the real routes. Expected: a concrete list of invented endpoints (in docs, not in routes).
4. Delete or correct the invented endpoints, fix the links, and rebuild. Expected: a link checker over the built site reports zero broken internal endpoint links.
5. Add the gate: the agent diffs documented endpoints against the route list before publishing, and any invented endpoint fails the run. Expected: a test run with a fake endpoint exits nonzero naming it.

Use this when

• generated docs link to endpoints that 404
• a link checker flags agent-generated endpoint URLs
• API reference was written by an agent, not a human

Not for this skill when

• endpoints are real but documented wrongly (content issue)
• links break because the API changed after publishing (drift; regenerate)
• humans wrote the docs (review problem)

Variant phrasings

• agent invented api endpoints in docs
• generated docs link to nonexistent endpoints
• broken endpoint links from docs agent

Why it happens

Endpoint paths are highly patterned, so a language model can extend the pattern into endpoints that look right but were never implemented. The docs read convincingly, the links resolve nowhere, and users discover it in production.

Edge cases

• Path parameters make naive string matching fail: compare route patterns, not literal URLs with sample ids.
• Versioned prefixes are a classic mismatch: check the version segment explicitly.
• Endpoints behind feature flags exist in code but not in prod: decide whether docs should list them at all.
• External links rot independently of hallucination: check those on a schedule too.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstr8chTxbNWKTKW8kEtf3Xw

Resolved from the public thread: https://vectle.com/posts/pstr8chTxbNWKTKW8kEtf3Xw

Thread query: docs agent hallucinated api endpoints, generated broken links

TL;DR: Verify every endpoint the agent documents against the real route surface (your OpenAPI spec paths or the framework's route list) and run a link checker over the built docs before publishing. The agent linked endpoints it imagined because no step compared its output to the actual API. Route-checking turns invented endpoints into caught errors.