diff --git a/website/docs/docs/build/metricflow-commands.md b/website/docs/docs/build/metricflow-commands.md
index 2386dab4ba2..fd120591900 100644
--- a/website/docs/docs/build/metricflow-commands.md
+++ b/website/docs/docs/build/metricflow-commands.md
@@ -180,9 +180,9 @@ Options:
 ### Validate-configs
 
 This command performs validations against the defined semantic model configurations:
+<!--dbt sl validate-configs # In dbt Cloud-->
 
 ```bash
-dbt sl validate-configs # In dbt Cloud
 
 mf validate-configs # In dbt Core
 
@@ -206,20 +206,18 @@ Options:
 ### Health checks
 
 This command performs a health check against the data platform you provided in the configs:
+<!--dbt sl health-checks # In dbt Cloud-->
 
 ```bash
-dbt sl health-checks #in dbt Cloud
-
 mf health-checks #in dbt Core
 ```
 
 ### Tutorial
 
 Follow the dedicated MetricFlow tutorial to help you get started:
+<!--dbt sl tutorial # In dbt Cloud-->
 
 ```bash
-dbt sl tutorial # In dbt Cloud
-
 mf tutorial # In dbt Core
 ```
 
@@ -522,7 +520,7 @@ mf query --metrics revenue --group-by metric_time__month # In dbt Core
 
 To add a dimension filter to a where filter, you have to indicate that the filter item is part of your model and use a template wrapper: <code>{{Dimension('primary_entity__dimension_name')}}</code>. 
 
-Here's an example query: <code>dbt sl query --metrics order_total --group-by metric_time --where "{{Dimension('order_id__is_food_order')}} = True"</code>.<br /><br /> Before using the template wrapper, however, you will need to set up your terminal to escape curly braces for the filter template to work. 
+Here's an example query: <code>dbt sl query --metrics order_total --group-by metric_time --where "{{Dimension('order_id__is_food_order')}} = True"</code>.<br /><br /> Before using the template wrapper, however, set up your terminal to escape curly braces for the filter template to work. 
 
 <details> 
 <summary>How to set up your terminal to escape curly braces? </summary>
diff --git a/website/docs/guides/best-practices/how-we-build-our-metrics/semantic-layer-4-build-metrics.md b/website/docs/guides/best-practices/how-we-build-our-metrics/semantic-layer-4-build-metrics.md
index cd0efdc9e64..8b112f2f828 100644
--- a/website/docs/guides/best-practices/how-we-build-our-metrics/semantic-layer-4-build-metrics.md
+++ b/website/docs/guides/best-practices/how-we-build-our-metrics/semantic-layer-4-build-metrics.md
@@ -34,8 +34,15 @@ metrics:
 
 ## Query your metric
 
-- It's best practice any time we're updating our semantic layer code to run a `dbt parse && mf validate-configs`.
+Use [MetricFlow commands](/docs/build/metricflow-commands#metricflow) for metric validation or queries during development, and apply the following conventions based on your environment:
+
+- For dbt Cloud, use the `dbt sl` prefix before the command (such as, `dbt sl parse` or `dbt sl query`).
+- For dbt Core, use the `mf` prefix (such as `mf validate-configs` or `mf query)`.
+
+Follow these best practices when updating your semantic layer code, using the `mf` command as an example (replace `mf` with `dbt sl` if you're using dbt Cloud):
+
+- It's best practice any time we're updating our semantic layer code to run `dbt parse` if using dbt Cloud or `dbt parse && mf validate-configs` if using dbt Core, to validate your configs.
 - If everything passes, we can start querying this metric with `mf query`!
 - `mf query` is not how you would use the tool in production, that's handled by the dbt Cloud Semantic Layer's features. It's available for testing results of various metric queries in development, exactly as we're using it now.
 - Try `mf query --metrics revenue --group-by metric_time__day` and see a preview of the data come back.
-- Note the structure of the above query. We select the metric(s) we want and the dimensions to group them by — we use dunders (double underscores e.g.`metric_time__[time bucket]`) to designate time dimensions or other non-unique dimensions that need a specified entity path to resolve (e.g. if you have a orders location dimension and a employee location dimension both named 'location' you would need dunders to specify `orders__location` or `employee__location`).
+- Note the structure of the above query. We select the metric(s) we want and the dimensions to group them by — we use dunders (double underscores e.g.`metric_time__[time bucket]`) to designate time dimensions or other non-unique dimensions that need a specified entity path to resolve (e.g. if you have an orders location dimension and an employee location dimension both named 'location' you would need dunders to specify `orders__location` or `employee__location`).