Docs: Update 'docs-writer' skill for relative links (#21463)

.gemini/skills/docs-writer/SKILL.md

@@ -65,8 +65,6 @@ accessible.
 - **UI and code:** Use **bold** for UI elements and `code font` for filenames,
   snippets, commands, and API elements. Focus on the task when discussing
   interaction.
-- **Links:** Use descriptive anchor text; avoid "click here." Ensure the link
-  makes sense out of context.
 - **Accessibility:** Use semantic HTML elements correctly (headings, lists, 
   tables).
 - **Media:** Use lowercase hyphenated filenames. Provide descriptive alt text
@@ -100,6 +98,18 @@ accessible.
 > This is an example of a multi-line note that will be preserved
 > by Prettier.
 
+### Links
+- **Accessibility:** Use descriptive anchor text; avoid "click here." Ensure the
+  link makes sense out of context, such as when being read by a screen reader.
+- **Use relative links in docs:** Use relative links in documentation (`/docs/`)
+  to ensure portability. Use paths relative to the current file's directory
+  (for example, `../tools/` from `docs/cli/`). Do not include the `/docs/`
+  section of a path, but do verify that the resulting relative link exists. This
+  does not apply to meta files such as README.MD and CONTRIBUTING.MD.
+- **When changing headings, check for deep links:** If a user is changing a
+  heading, check for deep links to that heading in other pages and update
+  accordingly.
+
 ### Structure
 - **BLUF:** Start with an introduction explaining what to expect.
 - **Experimental features:** If a feature is clearly noted as experimental,
@@ -157,7 +167,6 @@ documentation.
 - **Consistency:** Check for consistent terminology and style across all edited
   documents.
 
-
 ## Phase 4: Verification and finalization
 Perform a final quality check to ensure that all changes are correctly formatted
 and that all links are functional.