diff --git a/enhancements/sig-architecture/82-addon-template/README.md b/enhancements/sig-architecture/82-addon-template/README.md
index d1725ab..e19312b 100644
--- a/enhancements/sig-architecture/82-addon-template/README.md
+++ b/enhancements/sig-architecture/82-addon-template/README.md
@@ -37,8 +37,8 @@ straightforward addon development way.
 - The addon agent image is still required.
 - The hosted mode addon is not supported.
 - For complicated addon which has special RBAC requirement etc would still need to use addon-framework.
-- For the agent runtime, only `Deployment` is fully supported, for `Daemonset`, `Statefulset`, and other runtime
-  resources can be deployed to the managed cluster, but will no volumes be injected, and can not be used to check the
+- For the agent runtime, only `Deployment` and `DaemonSet` are fully supported, for `Statefulset`, and other runtime
+  resources can be deployed to the managed cluster, but no volumes will be injected, and can not be used to check the
   health of the addon.
 
 ## Proposal
@@ -53,7 +53,7 @@ only need to define some configurations to deploy and register my addon agent.
 #### Story 2
 
 As an addon developer, when the installation and registration of the addon agent changes, I hope that the change can
-take effect by only modifying some configurations without changing the code
+take effect by only modifying some configurations without changing the code.
 
 ## Design Details
 
@@ -68,7 +68,7 @@ cluster to process the CRD in order to deploy and register the addon.
 ### API changes
 
 Introduce a new cluster-scoped API `AddonTemplate` which is used to describe how to deploy the addon agent and how to
-register the addon to the hub cluster. And it is needed to reference the `AddonTemplate` by the "spec.supportedConfigs"
+register the addon to the hub cluster. And it is needed to reference the `AddonTemplate` by the `spec.supportedConfigs`
 field of `ClusterManagementAddon` to indicate that this addon is using a template.
 
 ```golang
@@ -262,8 +262,8 @@ Environments, so developers can use them in their agent code.
 
 The volumes are generated based on the `addonTemplate.spec.registration` field.
 
-1. If there is a `KubeClient` type registration, the hub kubeconfig will be injected to the deployments defined in the
-addon template
+1. If there is a `KubeClient` type registration, the hub kubeconfig will be injected to the deployments and daemonsets
+defined in the addon template
 
 ```yaml
 ...
@@ -283,7 +283,7 @@ spec:
 ```
 
 2. If there is a `CustomSigner` type registration, the secret signed via the custom signer defined in the
-`CustomSignerRegistrationConfig` will be injected to the deployments defined in the addon template
+`CustomSignerRegistrationConfig` will be injected to the deployments and daemonsets defined in the addon template
 
 ```yaml
 ...
@@ -327,6 +327,9 @@ roles the agent will be bound.
 `CustomSignerRegistrationConfig` to configure how to issue the client certificate. For authorization of CustomSigner,
 users need to implement it themselves.
 
+With the registration configured, the credentials info used to access the hub cluster will be injected into all
+deployments and daemonsets as volumes. See [inject volumes](#inject-volumes) for more details.
+
 ### Example
 
 Here holds an [example](./examples), it contains:
@@ -339,9 +342,9 @@ The rendering output of the agent deployment will be like [this](./examples/agen
 
 ### Probe the health of addons
 
-Since we only support the Deployment resource as the agent runtime workload, we can inject a feedback rule to the
-agent deployment resource, the feedback rule will check if the deployment is available, if not, the addon will be
-considered as unhealthy.
+Since we only support the Deployment and DaemonSet resources as the agent runtime workload, we can inject a feedback
+rule to the agent deployment resource, the feedback rule will check if the deployment and daemonset are available, if
+not, the addon will be considered as unhealthy.
 
 ### Upgrade an addon template
 
@@ -427,4 +430,4 @@ TBD
 
 ### Version Skew Strategy
 
-N/A
\ No newline at end of file
+N/A
diff --git a/enhancements/sig-architecture/82-addon-template/metadata.yaml b/enhancements/sig-architecture/82-addon-template/metadata.yaml
index 447f92e..bb176ba 100644
--- a/enhancements/sig-architecture/82-addon-template/metadata.yaml
+++ b/enhancements/sig-architecture/82-addon-template/metadata.yaml
@@ -4,14 +4,12 @@ authors:
 reviewers:
   - "@qiujian16"
   - "haoqing0110"
-  - TBD
 approvers:
   - "@qiujian16"
-  - TBD
 creation-date: 2023-2-13
-last-updated: 2023-2-13
+last-updated: 2024-7-2
 status: provisional
 see-also:
   - "/enhancements/sig-architecture/58-addon-configuration"
   - "/enhancements/sig-architecture/76-addon-install-strategy"
-  - "/enhancements/sig-architecture/81-addon-lifecycle"
\ No newline at end of file
+  - "/enhancements/sig-architecture/81-addon-lifecycle"