improve cross refs

Author: waruqi

docs/api/description/builtin-policies.md

@@ -5,6 +5,8 @@ Xmake incorporates many default behaviors, such as automatically detecting and m
 Therefore, xmake provides a way to override its default build policies, giving users a higher degree of control.
 This is primarily achieved through the [set_policy](/api/description/project-target#set-policy) API, which can be used to modify the default behavior of targets, packages, or the entire project.
 
+Policies are configured via [set_policy()](/api/description/project-target#set-policy) and can be used in [target()](/api/description/project-target#target), [package()](/api/description/package-dependencies#package), or at the global scope.
+
 ## Usage
 
 ::: tip NOTE

docs/api/description/builtin-rules.md

@@ -9,6 +9,8 @@ We can view the complete list of built-in rules by running the following command
 $ xmake show -l rules
 ```
 
+Built-in rules are applied to targets via [add_rules()](/api/description/project-target#add-rules). To create custom rules, see [Custom Rule API](/api/description/custom-rule). For related policy configurations, see [Built-in Policies](/api/description/builtin-policies).
+
 ## mode.debug
 
 Add the configuration rules for the debug compilation mode for the current project xmake.lua, for example:

docs/api/description/builtin-variables.md

@@ -47,6 +47,8 @@ What are the specific parameters, you can check it out by `xmake f -h`.
 Since the support is directly obtained from the configuration options, it is of course convenient to extend the custom options to get the custom variables.
 For details on how to customize the options, see: [option](/api/description/configuration-option)
 
+Built-in variables can be used in most string parameters in the description domain. For related conditional APIs, see [Conditions](/api/description/conditions) such as [is_os()](/api/description/conditions#is-os), [is_arch()](/api/description/conditions#is-arch), etc. In the script domain, use [vformat()](/api/scripts/builtin-modules/vformat) to expand built-in variables.
+
 ## var.$(os)
 
 - Get the operating system of the current build platform

docs/api/description/conditions.md

@@ -2,6 +2,8 @@
 
 Conditions are generally used to handle some special compilation platforms.
 
+These conditional APIs are typically used with [if-then](/guide/project-configuration/syntax-description) statements. For related built-in variables, see [Built-in Variables](/api/description/builtin-variables).
+
 ## is_os
 
 ### Is the current compilation target system

docs/api/description/configuration-option.md

@@ -26,6 +26,8 @@ option("test2")
 The `option` field can be repeatedly entered to implement separate settings. If you want to display the scope settings away from the current option, you can manually call the [option_end](#option-end) interface.
 :::
 
+Option values can be checked via [has_config()](/api/description/conditions#has-config) and [get_config()](/api/description/conditions#get-config) in conditional logic. Xmake also provides [helper detection interfaces](/api/description/helper-interfaces) for auto-detecting compiler features. For a guide on defining options, see [Define Options Guide](/guide/project-configuration/define-options).
+
 ## option
 
 ### Defining options

docs/api/description/custom-toolchain.md

@@ -73,6 +73,8 @@ Before customizing the tool, we can run the following command to view the comple
 $ xmake show -l toolchains
 ```
 
+Custom toolchains are applied to targets via [set_toolchains()](/api/description/project-target#set-toolchains). For a getting started tutorial, see the [Toolchain Configuration Guide](/guide/project-configuration/toolchain-configuration).
+
 ## toolchain
 
 - Define toolchain

docs/api/description/helper-interfaces.md

@@ -8,6 +8,8 @@ Among them, we provide two types of interfaces, `check_xxx` and `configvar_check
 
 And `check_xxx` only defines related macros to participate in compilation, but it will not be persisted in `config.h.in`.
 
+Helper interfaces are imported via [includes()](/api/description/global-interfaces#includes). Detection results can be checked with [has_config()](/api/description/conditions#has-config) and can also be used with [option()](/api/description/configuration-option).
+
 For related issues, see:
 
 -[#342](https://github.com/xmake-io/xmake/issues/342)

docs/api/description/plugin-and-task.md

@@ -2,6 +2,8 @@
 
 Xmake can implement custom tasks or plugins. The core of both is the `task` task. The two are actually the same. The xmake plugins are implemented with `task`.
 
+To extend the build process rather than define standalone tasks, see [Custom Rules](/api/description/custom-rule). For a plugin development tutorial, see the [Plugin Development Guide](/guide/extensions/plugin-development).
+
 ## task
 
 - Defining plugins or tasks

docs/api/scripts/builtin-modules/hash.md

@@ -3,6 +3,8 @@
 
 The hash module provides hash value calculation and UUID generation functions. It is a built-in module of xmake.
 
+For string operations, see the [string module](/api/scripts/builtin-modules/string). For file operations, see the [io module](/api/scripts/builtin-modules/io).
+
 ## hash.md5
 
 - Calculate the MD5 hash value of a file or binary data

docs/api/scripts/builtin-modules/io.md

@@ -3,6 +3,8 @@
 
 The io operation module extends lua's built-in io module to provide more easy-to-use interfaces.
 
+For file and directory management (copy, move, delete, etc.), see the [os module](/api/scripts/builtin-modules/os). For path joining and parsing, see the [path module](/api/scripts/builtin-modules/path). For serialization, see [string.serialize](/api/scripts/builtin-modules/string#string-serialize).
+
 ## io.open
 
 - Open file for reading and writing