diff --git a/.agents/skills/openclaw-docs/SKILL.md b/.agents/skills/openclaw-docs/SKILL.md
deleted file mode 100644
index dbf37921e346..000000000000
--- a/.agents/skills/openclaw-docs/SKILL.md
+++ /dev/null
@@ -1,238 +0,0 @@
----
-name: openclaw-docs
-description: Write or review high-quality OpenClaw developer documentation.
-dependencies: []
----
-
-# OpenClaw Docs
-
-## Overview
-
-Use this skill when writing, editing, or reviewing OpenClaw developer documentation for APIs, SDKs, CLI tools, integrations, quickstarts, platform guides, or technical product docs.
-
-Write documentation that is concise, helpful, and comprehensive: fast for first success, precise for production, and easy to scan when debugging.
-
-## Core Model
-
-Use an OpenClaw documentation model, strengthened by Write the Docs principles:
-
-- Lead with what the developer is trying to do.
-- Give one recommended path before alternatives.
-- Make examples runnable and realistic.
-- Keep guides task-oriented and references exhaustive.
-- Explain production risks exactly where developers can make mistakes.
-- Link concepts, guides, API references, SDKs, testing, and troubleshooting so readers can move between them without rereading.
-- Treat docs as part of the product lifecycle: draft them before or alongside implementation, review them with code, and keep them current.
-- Make each page discoverable, addressable, cumulative, complete within its stated scope, and easy to skim.
-
-## Structure
-
-Choose the page type before writing:
-
-- Overview: route readers to the right product, integration path, or guide.
-- Quickstart: get a new user to a working result with the fewest safe steps.
-- Topic page: give an end-to-end overview of a major domain entity, with setup,
-  key subtopics, troubleshooting, and links to deeper references.
-- Guide: explain one workflow from prerequisites to production readiness.
-- API reference: define every object, endpoint, parameter, enum, response, error, and version rule.
-- SDK or CLI reference: document install, auth, commands or methods, options, examples, and failure modes.
-- Testing guide: show sandbox setup, fixtures, test data, simulated failures, and live-mode differences.
-- Troubleshooting guide: map symptoms to checks, causes, and fixes.
-
-Use this default topic page structure:
-
-1. Title: name the major entity or surface.
-2. Opening overview: start with a few unheaded sentences that explain what it
-   is, what it owns, and what it does not own. Do not add a `## Overview`
-   heading unless the page is itself an overview index.
-3. Requirements: include only when setup needs specific accounts, versions,
-   permissions, plugins, operating systems, or credentials.
-4. Quickstart: show the recommended setup path and smallest reliable verification.
-5. Configuration: show the minimum configuration needed to use the surface,
-   common variants users must choose between, and where each option is set:
-   CLI, config file, environment variable, plugin manifest, dashboard, or API.
-6. Major subtopics: organize the entity's major concepts, workflows, and
-   decisions by reader intent. Put each major subtopic under its own heading;
-   do not wrap them in a generic `## Subtopics` section.
-7. Troubleshooting: diagnose common observable failures under an explicit
-   `## Troubleshooting` heading.
-8. Related: link to guides, references, commands, concepts, and adjacent topics.
-
-Topic pages may be longer than quickstarts, but they should not become exhaustive
-references. Move field tables, API contracts, narrow internals, legacy details,
-and rare debugging workflows to linked reference or troubleshooting pages when
-they interrupt the end-to-end overview.
-
-For configuration, keep task-critical options inline. Link to reference docs for
-full option lists, defaults, enums, generated schemas, and advanced settings. Do
-not duplicate exhaustive config reference tables in topic pages unless the topic
-page is itself the reference.
-
-Use this default guide structure:
-
-1. Title: name the outcome, not the implementation detail.
-2. Opening: state what the reader can accomplish in one or two sentences.
-3. Before you begin: list accounts, keys, permissions, versions, tools, and assumptions.
-4. Choose a path: compare options only when the reader must decide.
-5. Steps: use verb-led headings with code, expected output, and checks.
-6. Test: show the smallest reliable proof that the integration works.
-7. Production readiness: cover security, idempotency, retries, limits, observability, migrations, and cleanup.
-8. Troubleshooting: include common errors near the workflow that causes them.
-9. See also: link to concepts, API references, SDK docs, and adjacent guides.
-
-Keep navigation user-intent based. Do not force readers to understand internal product taxonomy before they can pick a task.
-
-## Documentation Lifecycle
-
-Write and maintain docs with the same discipline as code:
-
-- Draft docs early enough to expose unclear product, API, CLI, or config design.
-- Keep docs source near the code, config, command, plugin, or protocol it describes when the repo layout allows it.
-- Avoid duplicate truth. If the same contract appears in multiple places, pick the canonical page and link to it.
-- Update docs in the same change as behavior, config, API, CLI, plugin, or troubleshooting changes.
-- Remove, redirect, or clearly mark stale docs. Incorrect docs are worse than missing docs.
-- Involve the right reviewers: code owners for behavior, support or QA for user failure modes, and docs maintainers for structure and style.
-- Preserve older-version guidance only when users need it; otherwise document the current supported behavior.
-
-Do not use FAQs as a dumping ground for unrelated material. Promote recurring questions into task, concept, troubleshooting, or reference pages.
-
-## Writing Style
-
-Write in a direct, practical voice:
-
-- Use present tense and active voice.
-- Address the reader as "you" when giving instructions.
-- Prefer short paragraphs and scannable lists.
-- Use concrete nouns: "agent profile", "Gateway webhook", "plugin manifest", "session state".
-- Put caveats exactly where they affect the step.
-- Avoid marketing language, hype, generic benefits, and vague claims.
-- Avoid long conceptual lead-ins before the first actionable step.
-- Do not over-explain common developer concepts unless the product has a nonstandard contract.
-- Define OpenClaw-specific jargon and abbreviations before first use.
-- Use sentence case for headings unless an OpenClaw product name, command, or identifier requires capitalization.
-- Use descriptive link text that names the destination or action; avoid vague links such as "this page" or "click here".
-- Avoid culturally specific idioms, violent idioms, and jokes that make docs harder to translate or scan.
-- Write accessible prose: do not rely on color, screenshots, or visual position as the only way to understand an instruction.
-
-Use headings that describe actions or reference surfaces:
-
-- Good: "Create an agent", "Configure a Slack channel", "Repair plugin installation"
-- Avoid: "How it works", "Under the hood", "Important notes" unless the section truly needs that shape
-
-Use precise modal language:
-
-- Use "must" for required behavior.
-- Use "can" for optional capability.
-- Use "recommended" for the default path.
-- Use "avoid" for known footguns.
-- Explain "why" only when it changes a developer decision.
-
-## Detail Level
-
-Vary detail by page type:
-
-- Overview pages: be brief; help readers choose.
-- Quickstarts: be procedural; include only what is needed for first success.
-- Guides: be complete for one workflow; include decisions, side effects, and failure handling.
-- References: be exhaustive; document every field, default, enum, nullable value, constraint, response, and error.
-- Troubleshooting: be explicit; assume the reader is blocked and needs observable checks.
-
-Go deep where mistakes are expensive:
-
-- Authentication and secret handling
-- Money movement, billing, permissions, and irreversible actions
-- Webhooks, retries, duplicate events, and ordering
-- Idempotency and concurrency
-- Sandbox versus production differences
-- Versioning, migrations, and backwards compatibility
-- Limits, rate limits, quotas, and timeouts
-- Error codes and recovery paths
-- Data retention, privacy, and compliance-sensitive behavior
-
-Do not bury this detail in a distant reference if developers need it to complete the task safely.
-
-## Examples
-
-Make examples production-shaped, even when using test data:
-
-- Prefer complete copy-pasteable commands or snippets.
-- Use realistic variable names and values.
-- Mark placeholders clearly with angle-bracket names such as `<API_KEY>` or `<CUSTOMER_ID>`.
-- Show expected success output after commands.
-- Show full request and response examples for API references when response shape matters.
-- Keep one conceptual unit per code block.
-- Use language-specific code fences.
-- Avoid toy examples that hide required setup, auth, error handling, or cleanup.
-
-When multiple languages are useful, keep the same scenario across languages so readers can compare equivalents.
-
-## Discoverability and Navigation
-
-Design every page so readers can find it, link to it, and decide quickly whether it answers their question:
-
-- Use goal-oriented titles and headings that match likely search terms.
-- Start each page with a concise answer to "what can I do here?"
-- Include metadata or frontmatter required by the OpenClaw docs index.
-- Add "Read when" hints for docs-list routing when creating or changing OpenClaw docs pages that participate in the docs index.
-- Link from likely entry points, not only from nearby internal taxonomy pages.
-- Keep section headings stable enough for links from issues, PRs, support replies, and chat answers.
-- Order tutorials and examples from prerequisites to advanced tasks; order reference pages alphabetically or topically when that helps lookup.
-- State scope up front when a page is intentionally partial.
-
-## API Reference Pattern
-
-For endpoints, methods, objects, or commands, include:
-
-1. Short purpose statement.
-2. Auth or permission requirements.
-3. Request shape, including path, query, headers, and body fields.
-4. Parameter table with type, requiredness, default, constraints, enum values, and side effects.
-5. Return shape with object lifecycle states.
-6. Error cases with codes, causes, and recovery guidance.
-7. Runnable example request.
-8. Representative successful response.
-9. Related guides and adjacent reference pages.
-
-For nested objects, document child fields near their parent. Do not make readers jump across pages to understand the shape of a single request.
-
-## Verification
-
-Verify docs changes like product changes:
-
-- Run the relevant docs build, docs index, formatter, link checker, or generated-doc check when available.
-- Run commands, snippets, and examples that the page tells users to run whenever feasible.
-- Confirm screenshots, UI labels, CLI output, config keys, flags, defaults, errors, and file paths match current behavior.
-- Prefer executable checks over prose-only review for API, CLI, config, generated reference, and troubleshooting docs.
-- If a verification step is not feasible, say what was not verified and why.
-
-## Completeness Checks
-
-Before finalizing a page, verify:
-
-- The first screen tells readers what they can accomplish.
-- The recommended path is obvious.
-- Prerequisites are explicit and testable.
-- Examples can run with documented inputs.
-- The page has a clear audience: user, operator, plugin author, contributor, or maintainer.
-- Test-mode and production-mode behavior are separated.
-- Security-sensitive values are never exposed in examples.
-- Every warning is attached to the step where it matters.
-- Edge cases are documented where they affect implementation.
-- API fields include types, defaults, constraints, and errors.
-- Troubleshooting starts from observable symptoms.
-- Related links help the reader continue without duplicating the page.
-- The page says where to get support, file issues, or contribute when that is relevant to the reader's next step.
-- The page is complete for the scope it claims, or the limitation is stated up front.
-
-## Review Pass
-
-Edit in this order:
-
-1. Remove repetition and generic explanation.
-2. Move conceptual background below the first useful action unless it is required to choose correctly.
-3. Replace passive or abstract wording with concrete instructions.
-4. Tighten headings until the outline reads like a task map.
-5. Add missing operational details for production safety.
-6. Check examples for copy-paste accuracy.
-7. Add links between guide, reference, SDK, testing, and troubleshooting surfaces.
-8. Check discoverability, addressability, accessibility, and docs-as-code verification.
diff --git a/.agents/skills/technical-documentation/SKILL.md b/.agents/skills/technical-documentation/SKILL.md
new file mode 100644
index 000000000000..82c59c785c31
--- /dev/null
+++ b/.agents/skills/technical-documentation/SKILL.md
@@ -0,0 +1,79 @@
+---
+name: technical-documentation
+description: Build and review high-quality technical docs as well as agent instruction files in your repository.
+license: MIT
+metadata:
+  source: "https://github.com/vincentkoc/dotskills"
+---
+
+# Technical Documentation
+
+## Purpose
+
+Produce and review technical documentation that is clear, actionable, and maintainable for both humans and agents, including contributor-governance files and agent instruction files.
+
+## When to use
+
+- Creating or overhauling docs in an existing product/codebase (brownfield).
+- Building evergreen docs meant to stay accurate and reusable over time.
+- Reviewing doc diffs for structure, clarity, and operational correctness.
+- Running full-repo documentation audits that must include both governance files and product docs surfaces (`docs/`, `README*`, `.md/.mdx/.mdc`, Fern/Sphinx/Mintlify-style sources).
+- Updating or reviewing AGENTS.md and/or CONTRIBUTING.md to keep agent and contributor workflows aligned with current repo practices.
+- Improving repository onboarding/docs that include contribution instructions, issue templates, PR flow, and review gates.
+- Designing governance documentation strategy for repos with alias instruction files (for example `CLAUDE.md`, `AGENT.md`, `.cursorrules`, `.cursor/rules/*`, `.agent/`, `.agents/`, `.pi/`) where `AGENTS.md` is treated as canonical when present and aliases should be kept as compatibility surfaces.
+- Diagnosing agent-file drift where teams had to prompt iteratively to surface missing files, broken commands, or policy conflicts.
+- Applying repository-specific documentation overlays, including OpenClaw page-type, docs IA, preservation, and validation rules when present.
+
+## Workflow
+
+1. Classify task: `build` or `review`; context: `brownfield` or `evergreen`.
+2. Inventory full documentation scope early (governance + product docs): AGENTS/CONTRIBUTING/aliases plus docs directories, framework sources, and root/module READMEs.
+3. Detect multilingual scope (README/docs in multiple languages) and define required parity level.
+4. Read `references/agent-and-contributing.md` for agent instruction and `CONTRIBUTING.md` workflow rules (inventory, canonical/alias mapping, dual-mode balance, deliverable standards, and precedence/conflict handling).
+5. Read `references/principles.md` for the governing ruleset (Matt Palmer & OpenAI).
+6. For OpenClaw docs work, read `references/openclaw.md` before the build/review playbook.
+7. For build tasks, follow `references/build.md`.
+8. For review tasks, follow `references/review.md` and proactively detect issues without waiting for repeated prompts.
+9. For complex or high-risk tasks (build or review), it is acceptable to run longer, deeper, and more exhaustive investigations when needed for confidence.
+10. When available, use sub-agents for bounded parallel discovery/review work, then merge outputs into one coherent final deliverable.
+11. Use `references/tooling.md` when platform/tooling choices affect recommendations.
+12. Run a proactive issue sweep for both governance and docs-content surfaces, and fix high-confidence defects in the same pass unless explicitly asked for report-only mode.
+13. In brownfield mode, prioritize compatibility with current docs IA, tooling, and release state.
+14. In evergreen mode, prioritize timeless wording, update strategy, and durable structure.
+15. Return deliverables plus validation notes, parity status, and remaining gaps.
+
+## Sub-agent orchestration guidance
+
+Prefer sub-agents when the repo is large or the requested change set is broad; use them by default for repo-wide, multi-framework, or high-conflict work.
+
+- `inventory-agent` -> `agents/inventory-agent.md` (`fast` / Claude `haiku`): file/config discovery, coverage map, and missing-path checks.
+- `governance-agent` -> `agents/governance-agent.md` (`thinking` / Claude `sonnet`): AGENTS/CONTRIBUTING/alias precedence, conflicts, and policy drift.
+- `docs-framework-agent` -> `agents/docs-framework-agent.md` (`thinking` / Claude `sonnet`): framework config, relative path base, and file-path vs URL-path mapping checks.
+- `synthesis-agent` -> `agents/synthesis-agent.md` (`long` / Claude `opus`): merge sub-agent outputs into one prioritized fix plan and unified precedence model.
+
+## Inputs
+
+- Doc type (tutorial, how-to, reference, explanation) and audience.
+- File scope or diff scope.
+- Docs framework/tooling constraints (Fern, Mintlify, Sphinx, etc.).
+- Build/review mode and brownfield/evergreen intent.
+- Target agent and human compatibility intent.
+- Docs framework surfaces in scope (for example Fern, Sphinx, Mintlify, Markdown/MDX/MDC/RST/RSC files).
+- Desired investigation depth/time budget (quick pass vs exhaustive review).
+- Execution mode (`single-agent` or `sub-agent-assisted` when available).
+- Remediation mode (`apply-fixes` by default, or `report-only` when requested).
+- Multilingual scope: source-of-truth language, target locales, and parity expectations.
+- Repository-specific overlay constraints, if any.
+
+## Outputs
+
+- Updated draft or review findings with clear next actions.
+- Validation notes (what was checked, what remains).
+- Navigation/maintenance recommendations for long-term quality.
+- Governance-doc alignment summary when AGENTS/CONTRIBUTING were touched.
+- Agent instruction-surface map (primary file, alias files, Codex/Claude/Cursor handling plan).
+- Documentation-surface coverage map (what was reviewed under `/docs`, README hierarchy, and framework-specific source trees).
+- Autodetected issue list with applied fixes (or explicit report-only findings).
+- Delegation notes when sub-agents were used (scope delegated and how findings were merged).
+- Multilingual parity note (in-sync, partial with rationale, or intentionally divergent).
+- Repository-specific overlay notes when one was used.
diff --git a/.agents/skills/technical-documentation/agents/docs-framework-agent.md b/.agents/skills/technical-documentation/agents/docs-framework-agent.md
new file mode 100644
index 000000000000..a36eabe5a87b
--- /dev/null
+++ b/.agents/skills/technical-documentation/agents/docs-framework-agent.md
@@ -0,0 +1,32 @@
+---
+name: docs-framework-agent
+description: Thinking-focused docs framework checker for config-relative paths and route/file mapping consistency.
+model: sonnet
+tools:
+  - Read
+  - Glob
+  - Grep
+permissionMode: default
+maxTurns: 10
+---
+
+You are the docs-framework sub-agent for technical documentation.
+
+Goals:
+
+- validate framework config-driven docs behavior
+- prevent path-mapping drift between source files and published routes
+
+Tasks:
+
+- detect and read framework config first (Fern/Sphinx/Mintlify/custom)
+- resolve paths relative to the declaring file/config
+- validate both maps:
+  - config -> file exists
+  - config/nav/routing -> URL path is valid and consistent
+
+Return:
+
+- config files reviewed
+- path assumptions made
+- mismatches (`missing file`, `stale route`, `wrong base path`)
diff --git a/.agents/skills/technical-documentation/agents/governance-agent.md b/.agents/skills/technical-documentation/agents/governance-agent.md
new file mode 100644
index 000000000000..32ff6f41e50c
--- /dev/null
+++ b/.agents/skills/technical-documentation/agents/governance-agent.md
@@ -0,0 +1,30 @@
+---
+name: governance-agent
+description: Thinking-focused governance reviewer for AGENTS/CONTRIBUTING/alias precedence, conflict detection, and policy drift analysis.
+model: sonnet
+tools:
+  - Read
+  - Glob
+  - Grep
+permissionMode: default
+maxTurns: 10
+---
+
+You are the governance sub-agent for technical documentation.
+
+Goals:
+
+- validate AGENTS/CONTRIBUTING/alias alignment and precedence
+- identify policy drift and conflicting instructions
+
+Tasks:
+
+- determine canonical instruction source and alias compatibility mapping
+- detect conflicts across nested scope files and tool-specific rule consumers
+- validate command examples against stated governance expectations
+
+Return:
+
+- precedence model
+- conflict list with severity
+- recommended low-risk remediations
diff --git a/.agents/skills/technical-documentation/agents/inventory-agent.md b/.agents/skills/technical-documentation/agents/inventory-agent.md
new file mode 100644
index 000000000000..d461851a7eb4
--- /dev/null
+++ b/.agents/skills/technical-documentation/agents/inventory-agent.md
@@ -0,0 +1,31 @@
+---
+name: inventory-agent
+description: Fast repo-surface discovery for technical documentation audits. Use for coverage mapping and missing-path detection before deeper review.
+model: haiku
+tools:
+  - Read
+  - Glob
+  - Grep
+  - LS
+permissionMode: default
+maxTurns: 6
+---
+
+You are the inventory sub-agent for technical documentation.
+
+Goals:
+
+- enumerate governance and docs-content surfaces in scope
+- detect missing files, broken references, and obvious command/path failures
+
+Tasks:
+
+- map `AGENTS.md`/`CONTRIBUTING.md`/aliases and docs surfaces (`docs/**`, README hierarchy, `.md/.mdx/.mdc/.rst/.rsc`)
+- list framework config files discovered (Fern/Sphinx/Mintlify or equivalent)
+- report hard failures only, with exact file paths
+
+Return:
+
+- coverage map
+- missing/broken path list
+- unresolved blockers
diff --git a/.agents/skills/technical-documentation/agents/openai.yaml b/.agents/skills/technical-documentation/agents/openai.yaml
new file mode 100644
index 000000000000..903f204ac4dd
--- /dev/null
+++ b/.agents/skills/technical-documentation/agents/openai.yaml
@@ -0,0 +1,10 @@
+interface:
+  display_name: "Technical Documentation"
+  short_description: "Build and review technical documentation for brownfield and evergreen systems."
+  icon_small: "./assets/icon.jpg"
+  icon_large: "./assets/icon.jpg"
+  brand_color: "#111827"
+  default_prompt: "Build or review technical documentation with a clear, maintainable, and production-ready workflow."
+
+policy:
+  allow_implicit_invocation: true
diff --git a/.agents/skills/technical-documentation/agents/synthesis-agent.md b/.agents/skills/technical-documentation/agents/synthesis-agent.md
new file mode 100644
index 000000000000..a5a428a51ee7
--- /dev/null
+++ b/.agents/skills/technical-documentation/agents/synthesis-agent.md
@@ -0,0 +1,28 @@
+---
+name: synthesis-agent
+description: Long-context synthesis agent that merges sub-agent outputs into one prioritized and deduplicated documentation action plan.
+model: opus
+tools:
+  - Read
+permissionMode: default
+maxTurns: 12
+---
+
+You are the synthesis sub-agent for technical documentation.
+
+Goal:
+
+- merge sub-agent outputs into one coherent, non-duplicated action plan
+
+Tasks:
+
+- prioritize blockers first, then non-blocking improvements
+- normalize to one precedence model for governance decisions
+- remove duplicated recommendations and contradictory fixes
+- keep final output concise and execution-ready
+
+Return:
+
+- prioritized fix plan
+- validation summary (done vs pending)
+- explicit remaining gaps/blockers
diff --git a/.agents/skills/technical-documentation/assets/icon.jpg b/.agents/skills/technical-documentation/assets/icon.jpg
new file mode 100644
index 000000000000..8c8b22a372b8
Binary files /dev/null and b/.agents/skills/technical-documentation/assets/icon.jpg differ
diff --git a/.agents/skills/technical-documentation/references/agent-and-contributing.md b/.agents/skills/technical-documentation/references/agent-and-contributing.md
new file mode 100644
index 000000000000..f8b7c81b754c
--- /dev/null
+++ b/.agents/skills/technical-documentation/references/agent-and-contributing.md
@@ -0,0 +1,145 @@
+# AGENT and CONTRIBUTING Principles
+
+This reference consolidates the core rules for agent-policy and contributor-governance docs.
+
+You must:
+
+1. Discover repo-level and nested instruction files with:
+   `rg --files -g 'AGENTS.md' -g 'CONTRIBUTING.md' -g 'CLAUDE.md' -g 'AGENT.md' -g '.cursor/rules/*' -g '.cursorrules' -g '.agent/**' -g '.agents/**' -g '.pi/**' -g 'AGENTS.*.md'`
+2. Read the root and nearest-scope `AGENTS.md`/`CONTRIBUTING.md` pair before editing.
+3. If alias files exist, normalize to one canonical source (`AGENTS.md` preferred when present; otherwise nearest alias), plus compatibility pointers or explicit symlink notes.
+4. Document conflicting instructions and precedence decisions.
+
+## GitHub + AGENTS baseline
+
+Source: https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors
+Source: https://agents.md/
+Source: https://github.blog/ai-and-ml/github-copilot/how-to-write-a-great-agents-md-lessons-from-over-2500-repositories/
+Source: https://cobusgreyling.substack.com/p/what-is-agentsmd
+Source: https://www.infoq.com/news/2025/08/agents-md/
+
+Use these as default operating principles:
+
+1. Keep `CONTRIBUTING.md` discoverable and actionable (`.github`, root, or `docs`).
+2. Keep agent instructions concrete: real commands, real paths, clear boundaries.
+3. Use explicit behavior boundaries for agents: `Always`, `Ask first`, `Never`.
+4. Keep contributor and agent rules aligned with actual repository workflows.
+5. Ensure clear guidance is provided to agents on if, when and how to raise issues and pull requests.
+
+## Canonical and alias policy
+
+Source: https://agents.md/
+Source: https://github.blog/ai-and-ml/github-copilot/how-to-write-a-great-agents-md-lessons-from-over-2500-repositories/
+
+1. Treat `AGENTS.md` as canonical when present.
+2. If `AGENTS.md` is absent, treat the nearest alias file as canonical.
+3. Keep compatibility surfaces explicit: `AGENTS.md`, `AGENT.md`, `.cursorrules`, `.cursor/rules/*`, `.agent/`, `.agents/`, `.pi/`.
+4. If aliases are used, document how they map back to canonical policy (or symlink when supported).
+5. When repos use `.agents/` as canonical rule storage, keep `.cursor` as a compatibility symlink to `.agents` for Cursor rule auto-loading.
+6. Keep policy DRY: store one shared policy core and expose it via aliases/symlinks instead of duplicating rule text.
+
+## Context-awareness by agent platform
+
+Source: https://github.com/vercel-labs/agent-skills/blob/main/AGENTS.md
+Source: https://github.com/openai/codex/blob/main/AGENTS.md
+
+1. For Cursor and Claude-style glob consumers, keep rule files narrow and bounded.
+2. Avoid over-referencing large path sets that inflate context for glob-based agents.
+3. For Codex-style workflows, prefer explicit file references and deterministic commands.
+4. Keep long runbooks outside top-level policy files; link to scoped docs.
+5. Ensure all agents have a happy path regardless so ensuring everything works across Codex, Claude and other coding agents.
+
+## Symlink and compatibility operations
+
+1. Preferred layout for multi-agent compatibility:
+   - canonical rule directory: `.agents/`
+   - Cursor compatibility path: `.cursor -> .agents` symlink
+   - canonical policy doc: `AGENTS.md` pointing to `.agents` paths where relevant
+2. Validate symlink state before finalizing changes:
+   - if `.agents/` exists and `.cursor` is missing, create `.cursor` symlink to `.agents`
+   - if `.cursor` is a symlink to another target, fix target or document why it must differ
+   - if `.cursor` is a real directory/file, treat as migration conflict and ask before replacement
+3. Validate rule payload through the canonical directory:
+   - rules: `.agents/rules/*.mdc` with valid frontmatter (`description`, `globs`, `alwaysApply` as needed)
+   - commands: `.agents/commands/*.md` when command routing is used
+   - MCP config: `.agents/mcp.json` when MCP is in scope
+4. Keep Codex behavior explicit:
+   - `AGENTS.md` is primary for Codex repository instructions
+   - `.cursor` compatibility is for Cursor auto-loading and does not replace canonical AGENTS policy
+5. Record applied symlink fixes and unresolved compatibility gaps in validation notes.
+
+## Dual-mode and deliverable standards
+
+Source: https://github.blog/ai-and-ml/github-copilot/how-to-write-a-great-agents-md-lessons-from-over-2500-repositories/
+Source: https://agents.md/
+Source: https://github.com/openai/codex/blob/main/AGENTS.md
+Source: https://github.com/vercel-labs/agent-skills/blob/main/AGENTS.md
+
+1. Author one shared policy core (same commands, boundaries, and precedence) for all agents.
+2. For Cursor/Claude-style agents, expose that core through glob-driven and bounded files (small `AGENTS.md`/rule surface).
+3. For Codex, expose that same core through explicit file references with precise scope.
+4. Where styles diverge, prefer the smallest common structure that satisfies both and avoid duplicating policy text.
+5. Treat AGENTS/CONTRIBUTING as first-class deliverables when in scope.
+6. Preserve required structure, constraints, and examples from existing files.
+7. Align wording and commands with active repository instructions.
+
+## Proactive issue discovery and remediation
+
+Source: https://github.blog/ai-and-ml/github-copilot/how-to-write-a-great-agents-md-lessons-from-over-2500-repositories/
+Source: https://github.com/openai/codex/blob/main/AGENTS.md
+Source: https://github.com/vercel-labs/agent-skills/blob/main/AGENTS.md
+
+1. Run a conflict matrix review across AGENTS/aliases/CONTRIBUTING and related command/rule docs before finalizing.
+2. Treat the following as high-priority defects: missing referenced files, non-existent setup commands, command scope mismatches, and branch/commit policy conflicts.
+3. Do not stop at caveat-only notes when a low-risk fix is clear; apply the fix in the same pass.
+4. If a canonical entry file is missing (for example a directory `README.md` that docs depend on), create a minimal actionable file and update references.
+5. Long-running investigations are acceptable when needed to uncover cross-file drift, especially in agent-instruction ecosystems.
+
+## Discovery
+
+1. Agents prefer simple terminal commands so having a well defined `make *` or `npm run *` is ideal
+2. Agents can discover terminal commands through shell completion so providing shell completion helps
+
+## CONTRIBUTING size and scope control
+
+Source: https://contributing.md/how-to-build-contributing-md/
+Source: https://blog.codacy.com/best-practices-to-manage-an-open-source-project
+Source: https://mozillascience.github.io/working-open-workshop/contributing/
+Source: https://github.com/openclaw/openclaw/blob/main/CONTRIBUTING.md
+
+1. Keep root `CONTRIBUTING.md` focused on setup, issue flow, PR flow, testing, and review gates.
+2. Use issue/PR template links instead of embedding every process detail inline.
+3. When the file grows too large, split by domain and link from root.
+4. Move any large content into docs if avalible (for example Mintlify/Fern/Sphinx workflows) to avoid large contributor guide.
+5. Optimize for agent/machine readability as well as humans.
+
+## Example repos to emulate
+
+Source: https://github.com/openclaw/openclaw/blob/main/AGENTS.md
+Source: https://github.com/openclaw/openclaw/blob/main/CONTRIBUTING.md
+Source: https://github.com/openclaw/openclaw/blob/main/VISION.md
+Source: https://github.com/openai/codex/blob/main/AGENTS.md
+Source: https://github.com/processing/p5.js/blob/main/AGENTS.md
+Source: https://github.com/vercel-labs/agent-skills/blob/main/AGENTS.md
+Source: https://github.com/agentsmd/agents.md/blob/main/AGENTS.md
+Source: https://github.com/rails/rails/blob/main/CONTRIBUTING.md
+Source: https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md
+Source: https://github.com/atom/atom/blob/master/CONTRIBUTING.md
+Source: https://github.com/github/docs/blob/main/CONTRIBUTING.md
+Source: https://github.com/facebook/react/blob/main/CONTRIBUTING.md
+
+1. OpenClaw: strong real-world alias policy and AGENTS/CONTRIBUTING/VISION cohesion.
+2. OpenAI Codex: strict command discipline and explicit scope control.
+3. p5.js: explicit AI-policy guardrails in agent instructions.
+4. Vercel + agentsmd spec: compact, context-efficient AGENTS patterns.
+5. Rails/Kubernetes/Atom/GitHub Docs/React: contributor guidance patterns at different project scales.
+
+## Practical merge policy
+
+When these rules conflict:
+
+1. Preserve contributor and reader task success first.
+2. Preserve instruction clarity and unambiguous boundaries second.
+3. Preserve long-term maintainability and context-efficiency third.
+4. Add extra agent optimization only if it does not reduce human clarity or there is explict need.
+5. Use your judgement as the expert.
diff --git a/.agents/skills/technical-documentation/references/build.md b/.agents/skills/technical-documentation/references/build.md
new file mode 100644
index 000000000000..d0686485b98a
--- /dev/null
+++ b/.agents/skills/technical-documentation/references/build.md
@@ -0,0 +1,116 @@
+# Build Docs Playbook
+
+Read `principles.md` first, then follow this execution flow.
+
+## 1. Detect and align agent instruction and governance instructions
+
+- Use `references/agent-and-contributing.md` as the source of truth for inventory, canonical/alias mapping, and precedence/conflict handling.
+- Apply the symlink compatibility policy when in scope (`.agents` canonical directory with `.cursor` compatibility symlink when required by tooling).
+- Long-running and extensive build investigations are acceptable when needed to resolve ambiguous or conflicting documentation sources.
+- When available, use sub-agents for bounded parallel inventory/cross-check tasks and merge results into one canonical decision set.
+- Capture required constraints before writing:
+  - nested-agent rules, command/test requirements, PR workflow, and style checks.
+- Use the same command and validation expectations in proposed snippets and examples.
+
+## 2. Inventory product documentation surfaces (not governance only)
+
+- For repo-wide builds, include docs content surfaces in addition to AGENTS/CONTRIBUTING.
+- Inventory docs files and frameworks in scope (examples): `README*.md`, `docs/**`, `**/*.md`, `**/*.mdx`, `**/*.mdc`, `**/*.rst`, `**/*.rsc`, Fern/Mintlify config, Sphinx `conf.py`.
+- Build a coverage map before drafting so governance and product docs are both represented.
+- If scope is ambiguous, default to broader docs discovery first, then narrow intentionally.
+
+## 3. Framework config and path mapping rules
+
+- Detect framework/config first (for example Fern config, Sphinx `conf.py`, Mintlify config, or equivalent).
+- Resolve every referenced path relative to the file/config that declares it, not assumed repo root.
+- Treat filesystem paths and published URL routes as separate mappings; do not infer one from the other without config evidence.
+- Validate both layers:
+  - config -> file exists on disk
+  - config/nav/routing -> URL path is consistent and reachable
+- Record path-mapping assumptions and mismatches in handoff (`missing file`, `stale route`, `wrong base path`).
+
+## 4. Define intent and success
+
+- Audience, prerequisites, and job-to-be-done.
+- Expected reader outcome immediately after completion.
+- Doc type: tutorial, how-to, reference, explanation.
+- Success criteria: what must be true after publish.
+
+## 5. Build structure before prose
+
+- Follow the funnel: what/why, quickstart, next steps.
+- Keep headings informative and scannable.
+- Open each section with the takeaway sentence.
+- Add decision points with concrete branch guidance.
+- For OpenClaw docs work, choose a page type from `references/openclaw.md` before drafting.
+- Keep task-critical OpenClaw configuration inline; link exhaustive defaults, enums, schemas, generated references, and rare debugging workflows.
+
+## 6. Build AGENTS.md and CONTRIBUTING.md intentionally
+
+- Keep AGENTS.md structure consistent with `agents.md` ecosystem patterns:
+  - include YAML frontmatter when present in repo style (`name`, `description`).
+  - state persona scope and explicit instruction boundaries: `Always`, `Ask first`, `Never`.
+  - include concrete commands and representative code examples.
+- For CONTRIBUTING.md, prioritize issue triage flow, PR expectations, setup/test commands, and review gates.
+- Add `Code of Conduct`, `Testing`, `Local checks`, and `PR expectations` sections when missing but required by the repo.
+- If CONTRIBUTING.md is becoming too large, split by scope into linked docs (for example, framework/tool-specific setup and release workflows) and keep the root file as a concise entry point.
+- Keep cross-file consistency: links from CONTRIBUTING.md to AGENTS.md (and vice versa) should be accurate and non-circular.
+- If multiple AGENTS.md files exist, document the directory-level scope and avoid conflicting advice.
+- If a required canonical entry file is missing (for example referenced `README.md` under a major directory), create the file in the same pass instead of adding a caveat-only note.
+- For new entry files, keep them minimal and actionable: purpose, prerequisites, concrete run commands, and pointers to deeper docs.
+
+## 7. Keep agent context tight
+
+- Author once, expose twice:
+  - keep one shared policy core and avoid duplicating guidance in separate agent-specific files.
+  - publish that core through bounded glob-friendly files for Cursor/Claude plus explicit path references for Codex.
+- For Cursor and Claude-style agents, avoid broad references. Use minimal globbing and narrow rule files that each serve one concern (for example, repo-wide setup, test rules, security checks).
+- Keep AGENTS and alias files short-to-medium; move detailed runbooks to linked docs.
+- For Codex, prefer explicit file references and concrete paths for exact reuse.
+- Avoid adding unrelated historical or process details to avoid token/context drift during future tool reads.
+
+## 8. Brownfield build mode
+
+- Match existing terminology, navigation, and component patterns.
+- Preserve existing IA unless there is a documented migration plan.
+- For rewrites, include a migration note from old to new paths.
+- Prefer smallest safe change set that improves utility.
+
+## 9. Evergreen build mode
+
+- Prefer stable concepts over release-tied narrative.
+- Isolate volatile details under clearly marked version sections.
+- Include maintenance signals: owners, refresh triggers, stale criteria.
+- Include lifecycle notes: deprecation and replacement paths.
+
+## 10. Writing constraints
+
+- Use precise language and short, imperative instructions.
+- Keep code examples copy-ready and self-contained.
+- Include common failure modes and safe defaults.
+- Avoid placeholder guidance that cannot be executed.
+
+## 11. Agent and automation readiness
+
+- Keep key facts in text (not image-only).
+- Prefer structured lists/tables when choices matter.
+- Add links and anchors that allow deterministic navigation.
+- Document what can be checked automatically in CI.
+
+## 12. Build validation
+
+- Validate commands and snippets where possible.
+- Verify links and references in changed sections.
+- Run a reference existence sweep for every path/command you introduced.
+- Verify docs-framework consistency when in scope (for example Sphinx/Fern config and referenced doc paths).
+- For OpenClaw docs work, apply the validation checklist in `references/openclaw.md`.
+
+## 13. Multilingual parity mode (when applicable)
+
+- Pick one source-of-truth language for technical accuracy and release timing.
+- Define parity target: full parity, staged parity, or intentional divergence per section.
+- Keep structure aligned across locales (headings, anchors, section order) when possible.
+- Preserve command/code correctness first; localize explanatory text second.
+- If parity is not feasible, add a visible note with missing scope and expected sync window.
+- Run a locale parity check for changed sections (added/removed steps, warnings, prerequisites).
+- Record unresolved checks explicitly in handoff.
diff --git a/.agents/skills/technical-documentation/references/openclaw.md b/.agents/skills/technical-documentation/references/openclaw.md
new file mode 100644
index 000000000000..8683930df1e4
--- /dev/null
+++ b/.agents/skills/technical-documentation/references/openclaw.md
@@ -0,0 +1,128 @@
+# OpenClaw Documentation Overlay
+
+Use this reference only for OpenClaw docs work. It layers OpenClaw-specific page
+types, navigation, preservation, and validation rules on top of the general
+technical-documentation skill.
+
+## Reader Model
+
+- Lead with the task the reader is trying to complete.
+- Give one recommended path before alternatives.
+- Keep main docs focused on the common path; move dense contracts and rare
+  debugging detail to linked reference or troubleshooting pages.
+- Explain production risks exactly where the reader can make the mistake.
+- Link concepts, guides, references, CLI pages, SDK docs, testing, and
+  troubleshooting so readers can continue without rereading.
+
+## Page Types
+
+Choose the page type before writing or reviewing:
+
+- Overview: route readers to the right product area, integration path, or guide.
+- Quickstart: get a new user to a working result with the fewest safe steps.
+- Topic page: explain a major OpenClaw entity or surface end to end.
+- Guide: walk through one workflow from prerequisites to production readiness.
+- API/SDK/CLI reference: define every object, method, command, option, response,
+  error, enum, default, and version rule in scope.
+- Testing guide: show sandbox setup, fixtures, simulated failures, and live-mode
+  differences.
+- Troubleshooting guide: map observable symptoms to checks, causes, and fixes.
+- Governance file: keep agent/contributor policy concrete, scoped, and aligned
+  with current OpenClaw repo behavior.
+
+## Topic Pages
+
+Use this shape for major-entity pages:
+
+1. Title naming the entity or surface.
+2. Unheaded opening that says what it is, what it owns, and what it does not own.
+3. Requirements, only when setup needs accounts, versions, permissions, plugins,
+   operating systems, or credentials.
+4. Quickstart with the recommended path and smallest reliable verification.
+5. Configuration with task-critical options inline and exhaustive details linked
+   to reference docs.
+6. Major subtopics organized by reader intent, not under a generic "Subtopics"
+   heading.
+7. Troubleshooting with observable failures and concrete checks.
+8. Related links to guides, references, commands, concepts, and adjacent topics.
+
+## Guides
+
+Use this shape for workflow pages:
+
+1. Title naming the outcome, not the implementation detail.
+2. Opening that states what the reader can accomplish.
+3. Before you begin: accounts, keys, permissions, versions, tools, and
+   assumptions.
+4. Choose a path, only when the reader must decide.
+5. Steps with verb-led headings, commands, expected output, and checks.
+6. Test with the smallest reliable proof that the workflow works.
+7. Production readiness: security, retries, limits, observability, migrations,
+   and cleanup.
+8. Troubleshooting near the workflow that causes the failures.
+9. See also links to concepts, references, SDK docs, and adjacent guides.
+
+## Docs IA And Navigation
+
+- Read `docs/docs.json` before navigation changes.
+- Keep topic pages and common workflows on the main reader path.
+- Put exhaustive contracts, generated references, maintainer-only detail, and
+  support material under `Reference` or another clearly scoped support page.
+- Keep generated `plugins/reference/*` children and redirect-only pages out of
+  visible navigation unless explicitly required.
+- For moved pages, include a keep/drop/move/destination matrix in the handoff.
+- Add "Read when" hints for docs-list routing when creating or changing pages
+  that participate in the docs index.
+
+## Source-Backed Content
+
+- CLI docs must match current flags, output, errors, and examples.
+- API/SDK docs must include fields, defaults, enum values, constraints, nullable
+  behavior, lifecycle states, errors, and recovery guidance.
+- Config docs must align exported types, schema/help output, metadata, baselines,
+  and current docs.
+- Dependency-backed behavior must be verified from upstream docs, source, or
+  types before documenting defaults, timing, errors, or API behavior.
+- Separate current behavior, shipped behavior, planned behavior, and maintainer
+  intent.
+
+## Examples
+
+- Prefer complete copy-pasteable commands and snippets.
+- Use realistic variable names and values.
+- Mark placeholders with angle-bracket names such as `<API_KEY>`.
+- Show expected success output when it helps verification.
+- Keep one conceptual unit per code block and use language-specific fences.
+- Avoid examples that hide setup, auth, error handling, or cleanup.
+- Never expose real secrets, live config, phone numbers, private videos, or
+  credentials.
+
+## Preservation Reviews
+
+For rewrites or splits:
+
+- Identify source units before rewriting: headings, paragraphs, tables, examples,
+  CLI/API contracts, warnings, and troubleshooting facts.
+- Map each retained unit to a destination page or section.
+- Do not treat a broad "covered" row as proof for dense source material; use
+  line- or claim-level evidence when the source unit is dense.
+- For dropped content, state whether it is obsolete, duplicated elsewhere,
+  unsupported, or moved to a reference/support page.
+- When a docs-audit artifact is used, verify it is mapped audit data with
+  non-empty `mappings[]`, not only inventory or reindexed JSON.
+
+## Validation
+
+Choose the narrowest proof that covers the touched surface:
+
+- `pnpm docs:list`
+- `pnpm docs:check-mdx`
+- `pnpm docs:check-links`
+- `pnpm docs:check-i18n-glossary`
+- `pnpm format:docs:check` or `pnpm lint:docs`
+- `git diff --check`
+- generated-doc or inventory checks when generated references, plugin catalogs,
+  labeler, or docs scripts changed
+- behavior tests or command probes when docs claim runtime behavior
+
+If proof is blocked, say exactly which command was not run and why.
diff --git a/.agents/skills/technical-documentation/references/principles.md b/.agents/skills/technical-documentation/references/principles.md
new file mode 100644
index 000000000000..eee3c1e9d37d
--- /dev/null
+++ b/.agents/skills/technical-documentation/references/principles.md
@@ -0,0 +1,54 @@
+# Documentation Principles
+
+This reference consolidates the core rules used by this skill.
+
+## Matt Palmer: 8 rules for better docs
+
+Source: https://mattpalmer.io/posts/2025/10/8-rules-for-better-docs/
+
+Use these as default operating principles:
+
+1. Write for humans, optimize for agents.
+2. Start with a funnel: what/why, quickstart, next steps.
+3. Use Diataxis to scaffold content.
+4. Write with AI, but structure for agents.
+5. Offload routine docs operations to background agents.
+6. Automate quality with CI.
+7. Automate scaffolding and repetitive workflow tasks.
+8. Make contribution easy and visible.
+
+## OpenAI cookbook: what makes documentation good
+
+Source: https://cookbook.openai.com/articles/what_makes_documentation_good
+
+Key quality constraints:
+
+- Prefer specific and accurate terminology over niche jargon.
+- Keep examples self-contained and minimize dependencies.
+- Prioritize high-value topics over edge-case depth.
+- Do not teach unsafe patterns (for example, exposed secrets).
+- Open with context that helps readers orient quickly.
+- Apply empathy and override rigid rules when it clearly improves outcomes.
+
+## Practical merge policy
+
+When these rules conflict:
+
+1. Preserve reader task success first.
+2. Preserve structural clarity second.
+3. Preserve long-term maintainability third.
+4. Add agent optimization only if it does not reduce human clarity.
+
+For agent-instructions and contributor-governance specifics (AGENTS/aliases/CONTRIBUTING), use `references/agent-and-contributing.md` as the detailed additional source of truth.
+
+When the target repo or request is OpenClaw-specific, layer `references/openclaw.md` on top of these general rules. Otherwise ignore that repo-specific overlay.
+
+## Execution policy for this skill
+
+- Long-running and extensive investigations are allowed for both build and review work when needed to resolve ambiguity or cross-file drift.
+- Use sub-agents when available for bounded parallel discovery, verification, or cross-source comparison.
+- Keep one merged outcome: sub-agent outputs must be normalized into a single consistent recommendation/fix set.
+
+## Multilingual parity rule
+
+When docs exist in multiple languages, target cross-locale parity for task-critical content (steps, warnings, prerequisites, and limits). If full parity is not possible, publish explicit parity status and sync intent.
diff --git a/.agents/skills/technical-documentation/references/review.md b/.agents/skills/technical-documentation/references/review.md
new file mode 100644
index 000000000000..faf6db15aa5b
--- /dev/null
+++ b/.agents/skills/technical-documentation/references/review.md
@@ -0,0 +1,121 @@
+# Review Docs Playbook
+
+Read `principles.md` first, then apply this checklist.
+
+## 1. Scope and classification
+
+- Identify doc type and target audience.
+- Confirm brownfield vs evergreen intent.
+- Confirm expected outcome for the reader.
+- For full-repo reviews, explicitly include both governance surfaces and product-doc surfaces (`docs/`, README trees, `.md/.mdx/.mdc`, `.rst/.rsc`, framework docs configs).
+- For OpenClaw docs reviews, apply `references/openclaw.md` for page type, docs IA, preservation, examples, and validation checks.
+
+## 2. Investigation behavior
+
+- Proactively find issues and risks without waiting for repeated prompts.
+- If there are signals of deeper problems, continue investigation beyond the first pass.
+- Long-running and extensive investigations are acceptable when needed for confidence and correctness.
+- When available, use sub-agents for bounded parallel discovery (for example file-inventory, command validation, or cross-doc consistency checks), then merge to one final issue set.
+- When no issues are found, state that explicitly and call out residual risks or validation gaps.
+- Default to `apply-fixes` for high-confidence documentation defects unless the user explicitly requests `report-only`.
+- Do not stop at AGENTS/CONTRIBUTING checks when the task is documentation-wide; continue into docs-content and docs-framework surfaces.
+
+## 3. Governance surface review
+
+- Use `references/agent-and-contributing.md` as the source of truth for inventory, canonical/alias mapping, and precedence/conflict handling.
+  For AGENTS.md:
+
+- confirm persona intent, scope, and command/tool boundaries are explicit.
+- check frontmatter style matches repo conventions when present.
+- ensure `Always`, `Ask first`, and `Never` boundaries are present when expected.
+- require concrete command examples and repo-specific paths to avoid ambiguity.
+
+For CONTRIBUTING.md:
+
+- verify issue/PR workflow is complete and actionable.
+- ensure local setup, lint/test commands, and review criteria are accurate.
+- ensure governance does not conflict with nested AGENTS instructions.
+- flag oversized files that should be split into linked section docs (for example tool-specific setup and release docs).
+
+For agent-platform awareness:
+
+- confirm references are minimal and scoped for Cursor/Claude glob behavior.
+- confirm Codex-facing guidance uses explicit file references.
+- confirm both surfaces represent the same shared policy core (commands, boundaries, and precedence), not divergent guidance.
+- audit `.agents`/`.cursor` compatibility behavior:
+  - verify canonical rule directory and symlink state match repo policy
+  - verify symlink target integrity and platform/tooling expectations
+  - verify AGENTS policy references remain canonical for Codex even when `.cursor` compatibility exists
+- check for context bloat from duplicated policy statements across agent and contributor files.
+- check for conflicting rules, skills and agent instructions
+- check for conflicting information in agent instructions vs codebase
+- check for broken or missing referenced files (for example README/index files named as canonical entry points).
+- check for setup/command drift (for example non-existent install commands, root-level commands that should be module-scoped).
+
+## 4. Product documentation surface review
+
+- Verify docs IA coverage across root/module `README*` files and `docs/**` trees.
+- Review framework-native docs sources in scope (for example Fern, Mintlify, Sphinx, MkDocs) and ensure guidance matches actual source-of-truth files.
+- Check `.md/.mdx/.mdc/.rst/.rsc` for stale commands, missing prerequisites, and broken cross-links.
+- Confirm referenced doc paths and anchors exist.
+- Flag docs that should be split/merged to improve discoverability and maintenance.
+- For OpenClaw docs, check `docs/docs.json`, docs-list routing hints, main path versus `Reference` placement, and generated-reference visibility.
+- For OpenClaw rewrites or page splits, require source-backed keep/drop/move/destination coverage for important claims, warnings, examples, commands, fields, and troubleshooting facts.
+
+## 5. Framework config and path mapping checks
+
+- Detect and read framework config first (for example Fern config, Sphinx `conf.py`, Mintlify config, or equivalent).
+- Resolve path references relative to the declaring file/config.
+- Treat filesystem paths and published URL routes as separate maps; verify both.
+- Flag path-map drift explicitly (`missing file`, `stale route`, `wrong base path`).
+
+## 6. Structural review
+
+- Funnel check: what/why, quickstart, next steps.
+- Validate heading flow and navigation discoverability.
+- Flag critical content trapped in images or buried sections.
+- Check Diataxis alignment and split mixed-purpose sections.
+- For OpenClaw docs, confirm the content matches an explicit page type from `references/openclaw.md`.
+
+## 7. Writing quality review
+
+- Check for concise, scannable paragraphs.
+- Remove ambiguous pronouns and undefined terms.
+- Verify examples are executable and scoped correctly.
+- Verify tone is directive, technical, and non-hand-wavy.
+
+## 8. Brownfield review mode
+
+- Verify compatibility with existing docs IA and conventions.
+- Verify anchors, redirects, and cross-doc links remain valid.
+- Flag regressions in onboarding and task completion paths.
+- Ensure changed terminology is intentionally propagated.
+
+## 9. Evergreen review mode
+
+- Flag date-stamped or brittle wording without version scope.
+- Check ownership and refresh signals are present.
+- Ensure recommendations remain valid after routine product evolution.
+- Flag missing deprecation/migration guidance.
+
+## 10. Tooling and platform review
+
+Read `tooling.md` if platform fit is uncertain.
+
+- Check whether content uses platform primitives effectively.
+- Flag structure that fights the chosen docs platform.
+- Recommend targeted platform-aware improvements.
+
+## 11. Multilingual parity review (when applicable)
+
+- Confirm declared source-of-truth language and expected parity policy.
+- Compare changed sections across locales for step/order/warning drift.
+- Flag missing updates to prerequisites, version notes, limits, and safety guidance.
+- Allow intentional divergence only when rationale is explicit and user-impact is low.
+- Require a reader-visible status note when locale parity is partial.
+
+## 12. Output format
+
+1. Blocking issues (file + required fix)
+2. Non-blocking improvements
+3. Validation notes (done vs pending)
diff --git a/.agents/skills/technical-documentation/references/tooling.md b/.agents/skills/technical-documentation/references/tooling.md
new file mode 100644
index 000000000000..a3a8705c7bf8
--- /dev/null
+++ b/.agents/skills/technical-documentation/references/tooling.md
@@ -0,0 +1,32 @@
+# Documentation Tooling Guide
+
+Source: https://www.mintlify.com/blog/top-7-api-documentation-tools-of-2025
+
+Use this file when deciding build/review expectations for doc platforms.
+
+## Tool-selection checkpoints
+
+- Existing stack lock-in: do not force migration for minor gains.
+- API workflow depth: generated references, OpenAPI support, testability.
+- Collaboration model: docs-as-code, review workflow, versioning.
+- Runtime quality: search, navigation, and copy-ready code snippets.
+- AI readiness: structured content, stable URLs, machine-friendly layout yet human readable.
+- Human readiness: reading complexity, reading UX, navigation depth, minimize jargon.
+
+## Apply in brownfield mode
+
+- Prioritize compatibility with the current platform.
+- Use available components and style conventions before introducing new patterns.
+- Propose migration only when current constraints block critical outcomes.
+
+## Apply in evergreen mode
+
+- Favor platforms and templates that make routine updates low-friction.
+- Standardize section templates to reduce drift.
+- Capture ownership, update cadence, and stale-content detection rules.
+
+## Review implications
+
+- Check whether content uses platform primitives correctly (tabs, callouts, endpoint blocks).
+- Flag docs that are technically correct but hard to scan in the chosen platform.
+- Recommend platform-specific improvements only when they reduce cognitive load.
diff --git a/.gitignore b/.gitignore
index 8245c1ea6253..dd5ef22526b1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -128,7 +128,8 @@ mantis/
 !.agents/skills/control-ui-e2e/**
 !.agents/skills/gitcrawl/
 !.agents/skills/gitcrawl/**
-!.agents/skills/openclaw-docs/**
+!.agents/skills/technical-documentation/
+!.agents/skills/technical-documentation/**
 !.agents/skills/openclaw-refactor-docs/
 !.agents/skills/openclaw-refactor-docs/**
 !.agents/skills/openclaw-debugging/
diff --git a/AGENTS.md b/AGENTS.md
index eecb5ffa7701..e15ee240d994 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -163,7 +163,7 @@ Skills own workflows; root owns hard policy and routing.
 
 ## Docs / Changelog
 
-- Use `$openclaw-docs` for docs writing/review. Docs change with behavior/API.
+- Use `$technical-documentation` for docs writing/review. Docs change with behavior/API.
 - Codex harness upgrade (`extensions/codex/package.json` `@openai/codex`): refresh `docs/plugins/codex-harness.md` model snapshot from the new harness `model/list`.
 - Docs final answers: include relevant full `https://docs.openclaw.ai/...` URL(s). If issue/PR work too, GitHub URL last.
 - Changelog entries: active version `### Changes`/`### Fixes`; single-line bullets only.
diff --git a/docs/docs.json b/docs/docs.json
index 41f9935422fd..41f3c4d79ba2 100644
--- a/docs/docs.json
+++ b/docs/docs.json
@@ -1232,6 +1232,7 @@
                   "plugins/sdk-provider-plugins",
                   "plugins/cli-backend-plugins",
                   "plugins/hooks",
+                  "plugins/plugin-permission-requests",
                   "plugins/adding-capabilities"
                 ]
               },
diff --git a/docs/plugins/building-plugins.md b/docs/plugins/building-plugins.md
index 7da952fb752a..2600ea7a67f2 100644
--- a/docs/plugins/building-plugins.md
+++ b/docs/plugins/building-plugins.md
@@ -230,6 +230,11 @@ Users opt in with `tools.allow`:
 }
 ```
 
+Optional tools control whether a tool is exposed to the model. Use
+[plugin permission requests](/plugins/plugin-permission-requests) when a tool
+or hook should ask for approval after the model selects it and before the
+action runs.
+
 Use optional tools for side effects, unusual binaries, or capabilities that
 should not be exposed by default. Tool names must not conflict with core tools;
 conflicts are skipped and reported in plugin diagnostics. Malformed
diff --git a/docs/plugins/codex-harness-runtime.md b/docs/plugins/codex-harness-runtime.md
index 5fc9caec64f8..973b945f2eda 100644
--- a/docs/plugins/codex-harness-runtime.md
+++ b/docs/plugins/codex-harness-runtime.md
@@ -163,6 +163,9 @@ originating chat, and the next queued follow-up message answers that native
 server request instead of being steered as extra context. Other MCP elicitation
 requests fail closed.
 
+For the general plugin approval flow that carries these prompts, see
+[Plugin permission requests](/plugins/plugin-permission-requests).
+
 ## Queue steering
 
 Active-run queue steering maps onto Codex app-server `turn/steer`. With the
diff --git a/docs/plugins/hooks.md b/docs/plugins/hooks.md
index 6f2a63a561f3..41309a43a2b1 100644
--- a/docs/plugins/hooks.md
+++ b/docs/plugins/hooks.md
@@ -195,6 +195,7 @@ type BeforeToolCallResult = {
     severity?: "info" | "warning" | "critical";
     timeoutMs?: number;
     timeoutBehavior?: "allow" | "deny";
+    allowedDecisions?: Array<"allow-once" | "allow-always" | "deny">;
     pluginId?: string;
     onResolution?: (
       decision: "allow-once" | "allow-always" | "deny" | "timeout" | "cancelled",
@@ -215,6 +216,10 @@ Hook guard behavior for typed lifecycle hooks:
 - `onResolution` receives the resolved approval decision - `allow-once`,
   `allow-always`, `deny`, `timeout`, or `cancelled`.
 
+See [Plugin permission requests](/plugins/plugin-permission-requests) for
+approval routing, decision behavior, and when to use `requireApproval` instead
+of optional tools or exec approvals.
+
 Bundled plugins that need host-level policy can register trusted tool policies
 with `api.registerTrustedToolPolicy(...)`. These run before ordinary
 `before_tool_call` hooks and before external plugin decisions. Use them only
diff --git a/docs/plugins/plugin-permission-requests.md b/docs/plugins/plugin-permission-requests.md
new file mode 100644
index 000000000000..80846d7ab9b3
--- /dev/null
+++ b/docs/plugins/plugin-permission-requests.md
@@ -0,0 +1,193 @@
+---
+summary: "Ask users to approve plugin tool calls and plugin-owned permission prompts"
+title: "Plugin permission requests"
+sidebarTitle: "Permission requests"
+read_when:
+  - You need a plugin hook or tool to ask before a side effect runs
+  - You need to configure where plugin approval prompts are delivered
+  - You are deciding between optional tools, exec approvals, and plugin approvals
+---
+
+Plugin permission requests let plugin code pause a tool call or plugin-owned
+operation until a user approves or denies it. They use the Gateway
+`plugin.approval.*` flow and the same approval UI surfaces that handle chat
+approval buttons and `/approve` commands.
+
+Use plugin permission requests for plugin/app permissions. They do not replace
+host exec approvals, optional tool allowlists, or Codex's native permission
+review.
+
+## Choose the right gate
+
+Pick the gate that matches the decision point you need:
+
+| Gate                             | Use it when                                                              | What it controls                                                                                                  |
+| -------------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- |
+| Optional tools                   | A tool should not be visible to the model until the user opts in.        | Tool exposure through `tools.allow`.                                                                              |
+| Plugin permission requests       | A plugin hook or plugin-owned operation must ask before one action runs. | Runtime approval through `plugin.approval.*`.                                                                     |
+| Exec approvals                   | A host command or shell-like tool needs operator approval.               | Host exec policy and durable exec allowlists.                                                                     |
+| Codex native permission requests | Codex asks before native shell, file, MCP, or app-server actions.        | Codex app-server or native hook approval handling, routed through plugin approvals when OpenClaw owns the prompt. |
+| MCP approval elicitations        | A Codex MCP server requests approval for a tool call.                    | MCP approval responses bridged through OpenClaw plugin approvals.                                                 |
+
+Optional tools are a discovery-time gate. Plugin permission requests are a
+per-call gate. Use both when a sensitive tool should require explicit opt-in
+before the model can see it and approval before the action runs.
+
+## Request approval before a tool call
+
+Most plugin-authored prompts should start in a `before_tool_call` hook. The hook
+runs after the model selects a tool and before OpenClaw executes it:
+
+```typescript
+import { definePluginEntry } from "openclaw/plugin-sdk/plugin-entry";
+
+export default definePluginEntry({
+  id: "deploy-policy",
+  name: "Deploy Policy",
+  register(api) {
+    api.on("before_tool_call", async (event) => {
+      if (event.toolName !== "deploy_service") {
+        return;
+      }
+
+      const environment =
+        typeof event.params.environment === "string" ? event.params.environment : "unknown";
+
+      return {
+        requireApproval: {
+          title: "Deploy service",
+          description: `Deploy service to ${environment}.`,
+          severity: environment === "production" ? "critical" : "warning",
+          allowedDecisions:
+            environment === "production"
+              ? ["allow-once", "deny"]
+              : ["allow-once", "allow-always", "deny"],
+          timeoutMs: 120_000,
+          timeoutBehavior: "deny",
+          onResolution(decision) {
+            console.log(`deploy approval resolved: ${decision}`);
+          },
+        },
+      };
+    });
+  },
+});
+```
+
+Write prompt text for the person who will approve the action:
+
+- Keep `title` short and action-focused. The Gateway accepts up to 80
+  characters.
+- Keep `description` specific and bounded. The Gateway accepts up to 256
+  characters.
+- Include the action, target, and risk. Do not include secrets, tokens, or
+  private payloads that should not appear in chat approval surfaces.
+- Use `severity: "critical"` only for actions where the wrong decision could
+  cause production damage or data loss.
+- Use `allowedDecisions: ["allow-once", "deny"]` when persistent trust is
+  unsafe for that action.
+
+## Decision behavior
+
+OpenClaw creates a pending approval with a `plugin:` ID, delivers it to the
+available approval surfaces, and waits for a decision.
+
+| Decision          | Result                                                                    |
+| ----------------- | ------------------------------------------------------------------------- |
+| `allow-once`      | The current call continues.                                               |
+| `allow-always`    | The current call continues and the decision is passed to the plugin.      |
+| `deny`            | The call is blocked with a denied tool result.                            |
+| Timeout           | The call is blocked unless `timeoutBehavior` is `"allow"`.                |
+| Cancellation      | The call is blocked when the run is aborted.                              |
+| No approval route | The call is blocked because no connected approval surface can resolve it. |
+
+`allow-always` is only durable when the requesting plugin or runtime implements
+that persistence. For ordinary `before_tool_call.requireApproval` hooks,
+OpenClaw treats `allow-once` and `allow-always` as approval decisions for the
+current call and passes the resolved value to `onResolution`. If your plugin
+offers `allow-always`, document and implement exactly what future calls it
+trusts.
+
+If the hook also returns `params`, OpenClaw applies those parameter changes only
+after the approval succeeds. A lower-priority hook can still block after a
+higher-priority hook requested approval.
+
+`allowedDecisions` limits the buttons and commands shown to the user. The
+Gateway rejects a resolve attempt for any decision the request did not offer.
+
+## Route approval prompts
+
+Approval prompts can resolve in local UI surfaces or in chat channels that
+support approval handling. To forward plugin approval prompts to explicit chat
+targets, configure `approvals.plugin`:
+
+```json5
+{
+  approvals: {
+    plugin: {
+      enabled: true,
+      mode: "targets",
+      agentFilter: ["main"],
+      targets: [{ channel: "slack", to: "U12345678" }],
+    },
+  },
+}
+```
+
+`approvals.plugin` is independent from `approvals.exec`. Enabling exec approval
+forwarding does not route plugin approval prompts, and enabling plugin approval
+forwarding does not change host exec policy.
+
+When a prompt includes manual approval text, resolve it with one of the offered
+decisions:
+
+```text
+/approve <id> allow-once
+/approve <id> allow-always
+/approve <id> deny
+```
+
+See [Advanced exec approvals](/tools/exec-approvals-advanced#plugin-approval-forwarding)
+for the full forwarding model, same-chat approval behavior, native channel
+delivery, and channel-specific approver rules.
+
+## Codex native permissions
+
+Codex native permission prompts can also travel through plugin approvals, but
+they have different ownership than plugin-authored hooks.
+
+- Codex app-server approval requests route through OpenClaw after Codex review.
+- The native hook `permission_request` relay can ask through
+  `plugin.approval.request` when that relay is enabled.
+- MCP tool approval elicitations route through plugin approvals when Codex marks
+  `_meta.codex_approval_kind` as `"mcp_tool_call"`.
+
+See [Codex harness runtime](/plugins/codex-harness-runtime#native-permissions-and-mcp-elicitations)
+for the Codex-specific behavior and fallback rules.
+
+## Troubleshooting
+
+**The tool says plugin approvals are unavailable.** No approval UI or configured
+approval route accepted the request. Connect an approval-capable client, use a
+channel that supports same-chat `/approve`, or configure `approvals.plugin`.
+
+**`allow-always` appears but the next call prompts again.** The generic plugin
+approval flow does not automatically persist trust for arbitrary hooks. Persist
+plugin-owned trust in your plugin after `onResolution("allow-always")`, or
+offer only `allow-once` and `deny`.
+
+**`/approve` rejects the decision.** The request restricted
+`allowedDecisions`. Use one of the decisions printed in the prompt.
+
+**A Slack, Discord, Telegram, or Matrix prompt routes differently from exec
+approvals.** Plugin approvals and exec approvals use separate config and may use
+different authorization checks. Verify `approvals.plugin` and the channel's
+plugin approval support instead of only checking `approvals.exec`.
+
+## Related
+
+- [Plugin hooks](/plugins/hooks#tool-call-policy)
+- [Building plugins](/plugins/building-plugins#registering-agent-tools)
+- [Advanced exec approvals](/tools/exec-approvals-advanced#plugin-approval-forwarding)
+- [Gateway protocol](/gateway/protocol)
+- [Codex harness runtime](/plugins/codex-harness-runtime#native-permissions-and-mcp-elicitations)
diff --git a/docs/tools/exec-approvals-advanced.md b/docs/tools/exec-approvals-advanced.md
index 65bcc7c7e1c6..1e725f62aacc 100644
--- a/docs/tools/exec-approvals-advanced.md
+++ b/docs/tools/exec-approvals-advanced.md
@@ -211,6 +211,8 @@ The `/approve` command handles both exec approvals and plugin approvals. If the
 
 Plugin approval forwarding uses the same delivery pipeline as exec approvals but has its own
 independent config under `approvals.plugin`. Enabling or disabling one does not affect the other.
+For plugin-authoring behavior, request fields, and decision semantics, see
+[Plugin permission requests](/plugins/plugin-permission-requests).
 
 ```json5
 {