Added a note about the prefix

text/0000-static-lifecycle-methods.md

@@ -193,21 +193,21 @@ React does not call this method before the intial render/mount and so it is not
 
 ### `componentWillMount`
 
-This method will log a deprecation warning in development mode recommending that users use the new static `prefetch` method instead. It will be removed entirely in version 17.
+This method will log a deprecation warning in development mode recommending that users either rename to `unsafe_componentWillMount` or use the new static `prefetch` method instead. It will be removed entirely in version 17.
 
 ### `componentWillUpdate`
 
-This method will log a deprecation warning in development mode recommending that users use the new static `prefetch` method instead. It will be removed entirely in version 17.
+This method will log a deprecation warning in development mode recommending that users either rename to `unsafe_componentWillUpdate` or use the new static `prefetch` method instead. It will be removed entirely in version 17.
 
 ### `componentWillReceiveProps`
 
-This method will log a deprecation warning in development mode recommending that users use the new static `deriveStateFromProps` method instead. It will be removed entirely in version 17.
+This method will log a deprecation warning in development mode recommending that users either rename to `unsafe_componentWillReceiveProps` or use the new static `deriveStateFromProps` method instead. It will be removed entirely in version 17.
 
 # Drawbacks
 
 The current component lifecycle hooks are familiar and used widely. This proposed change will introduce a lot of churn within the ecosystem. I hope that we can reduce the impact of this change through the use of codemods, but it will still require a manual review process and testing.
 
-This change is **not backwards compatible**. It will require library maintainers to drop support for older versions of React in order to support the future component API. Unfortunately, I believe this is unavoidable in order to safely transition to an async-compatible world.
+This change is **not fully backwards compatible**. Libraries will need to drop support for older versions of React n order to use the new, static API. Unfortunately, I believe this is unavoidable in order to safely transition to an async-compatible world.
 
 # Alternatives
 
@@ -229,7 +229,9 @@ Begin by reaching out to prominent third-party library maintainers to make sure
 
 Assuming we move forward with the proposal, release (at least one) minor 16.x update to add deprecation warnings for the legacy lifecycles and inform users to use the new static methods instead. We'll then cordinate with library authors to ensure they have enough time to migrate to the new API in advance of the major release that drops support for the legacy lifecycles.
 
-We will also provide codemods to assist with the migration, although given the nature of the change, codemods will be insufficient to handle all cases. Manual verification will be required.
+We will provide a codemod to rename the deprecated lifecycle hooks with the new `unsafe_` prefix.
+
+We will also provide codemods to assist with the migration to static methods, although given the nature of the change, codemods will be insufficient to handle all cases. Manual verification will be required.
 
 # How we teach this