consistent wording

Author: sentrivana

develop-docs/sdk/processes/breaking_changes.mdx

@@ -96,11 +96,11 @@ Fortunately, there is always a lot you can do (and not do) to make the upgrade p
 
 ### Ways to Lessen Friction
 
-- Call-outs in relevant places in the docs and in the changelog.
-- Deprecation warnings that a breaking change is coming.
+- Add call-outs in relevant places in the docs and in the changelog.
+- Add deprecation warnings that a breaking change is coming.
 - Support an intermediate period where both the old and the new way of doing things works.
 - Maintain deprecated APIs, if possible, for another major version.
 - Add an SDK option that acts as a feature flag to enable users to switch between the old and the new behavior.
-- A polished migration guide with a lot of easily copy-pastable before-and-after examples.
+- Write a polished migration guide with a lot of easily copy-pastable before-and-after examples.
 - Try to do the upgrade yourself on a test app. Instruct an LLM to do the update using your migration guide and see how well it works.
 - Provide a tool that helps with the upgrade, for example using codemods. (Caveat: This is tricky to get right so that it covers all possible usages of the SDK.)