diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 651e2925a..e3c0d50fc 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -53,7 +53,8 @@
 - [Walkthrough: a typical contribution](./walkthrough.md)
 - [Implementing new language features](./implementing_new_features.md)
 - [Stability attributes](./stability.md)
-- [Stabilizing Features](./stabilization_guide.md)
+- [Stabilizing language features](./stabilization_guide.md)
+    - [Stabilization report template](./stabilization_report_template.md)
 - [Feature Gates](./feature-gates.md)
 - [Coding conventions](./conventions.md)
 - [Procedures for breaking changes](./bug-fix-procedure.md)
diff --git a/src/implementing_new_features.md b/src/implementing_new_features.md
index 5d0e875cb..76cf2386c 100644
--- a/src/implementing_new_features.md
+++ b/src/implementing_new_features.md
@@ -2,145 +2,91 @@
 
 <!-- toc -->
 
-When you want to implement a new significant feature in the compiler,
-you need to go through this process to make sure everything goes
-smoothly.
+When you want to implement a new significant feature in the compiler, you need to go through this process to make sure everything goes smoothly.
 
-**NOTE: this section is for *language* features, not *library* features,
-which use [a different process].**
+**NOTE: This section is for *language* features, not *library* features, which use [a different process].**
 
-See also [the Rust Language Design Team's procedures][lang-propose] for
-proposing changes to the language.
+See also [the Rust Language Design Team's procedures][lang-propose] for proposing changes to the language.
 
 [a different process]: ./stability.md
 [lang-propose]: https://lang-team.rust-lang.org/how_to/propose.html
 
 ## The @rfcbot FCP process
 
-When the change is small and uncontroversial, then it can be done
-with just writing a PR and getting an r+ from someone who knows that
-part of the code. However, if the change is potentially controversial,
-it would be a bad idea to push it without consensus from the rest
-of the team (both in the "distributed system" sense to make sure
-you don't break anything you don't know about, and in the social
-sense to avoid PR fights).
-
-If such a change seems to be too small to require a full formal RFC process
-(e.g., a small standard library addition, a big refactoring of the code, a
-"technically-breaking" change, or a "big bugfix" that basically amounts to a
-small feature) but is still too controversial or big to get by with a single r+,
-you can propose a final comment period (FCP). Or, if you're not on the relevant
-team (and thus don't have @rfcbot permissions), ask someone who is to start one;
-unless they have a concern themselves, they should.
-
-Again, the FCP process is only needed if you need consensus – if you
-don't think anyone would have a problem with your change, it's OK to
-get by with only an r+. For example, it is OK to add or modify
-unstable command-line flags or attributes without an FCP for
-compiler development or standard library use, as long as you don't
-expect them to be in wide use in the nightly ecosystem.
-Some teams have lighter weight processes that they use in scenarios
-like this; for example, the compiler team recommends
-filing a Major Change Proposal ([MCP][mcp]) as a lightweight way to
-garner support and feedback without requiring full consensus.
+When the change is small, uncontroversial, non-breaking, and does not affect the stable language in any user-observable ways or add any new unstable features, then it can be done with just writing a PR and getting an r+ from someone who knows that part of the code. However, if not, more must be done. Even for compiler-internal work, it would be a bad idea to push a controversial change without consensus from the rest of the team (both in the "distributed system" sense to make sure you don't break anything you don't know about, and in the social sense to avoid PR fights).
+
+For changes that need the consensus of a team, we us the process of proposing a final comment period (FCP). If you're not on the relevant team (and thus don't have @rfcbot permissions), ask someone who is to start one; unless they have a concern themselves, they should.
+
+The FCP process is only needed if you need consensus – if no processes require consensus for your change and you don't think anyone would have a problem with it, it's OK to rely on only an r+. For example, it is OK to add or modify unstable command-line flags or attributes in the reserved compiler-internal `rustc_` namespace without an FCP for compiler development or standard library use, as long as you don't expect them to be in wide use in the nightly ecosystem. Some teams have lighter weight processes that they use in scenarios like this; for example, the compiler team recommends filing a Major Change Proposal ([MCP][mcp]) as a lightweight way to garner support and feedback without requiring full consensus.
 
 [mcp]: https://forge.rust-lang.org/compiler/proposals-and-stabilization.html#how-do-i-submit-an-mcp
 
-You don't need to have the implementation fully ready for r+ to propose an FCP,
-but it is generally a good idea to have at least a proof
-of concept so that people can see what you are talking about.
+You don't need to have the implementation fully ready for r+ to propose an FCP, but it is generally a good idea to have at least a proof of concept so that people can see what you are talking about.
 
-When an FCP is proposed, it requires all members of the team to sign off the
-FCP. After they all do so, there's a 10-day-long "final comment period" (hence
-the name) where everybody can comment, and if no concerns are raised, the
-PR/issue gets FCP approval.
+When an FCP is proposed, it requires all members of the team to sign off on the FCP. After they all do so, there's a 10-day-long "final comment period" (hence the name) where everybody can comment, and if no concerns are raised, the PR/issue gets FCP approval.
 
 ## The logistics of writing features
 
-There are a few "logistic" hoops you might need to go through in
-order to implement a feature in a working way.
+There are a few "logistical" hoops you might need to go through in order to implement a feature in a working way.
 
 ### Warning Cycles
 
-In some cases, a feature or bugfix might break some existing programs
-in some edge cases. In that case, you might want to do a crater run
-to assess the impact and possibly add a future-compatibility lint,
-similar to those used for
-[edition-gated lints](diagnostics.md#edition-gated-lints).
+In some cases, a feature or bugfix might break some existing programs in some edge cases. In that case, you'll want to do a crater run to assess the impact and possibly add a future-compatibility lint, similar to those used for [edition-gated lints](diagnostics.md#edition-gated-lints).
 
 ### Stability
 
-We [value the stability of Rust]. Code that works and runs on stable
-should (mostly) not break. Because of that, we don't want to release
-a feature to the world with only team consensus and code review -
-we want to gain real-world experience on using that feature on nightly,
-and we might want to change the feature based on that experience.
-
-To allow for that, we must make sure users don't accidentally depend
-on that new feature - otherwise, especially if experimentation takes
-time or is delayed and the feature takes the trains to stable,
-it would end up de facto stable and we'll not be able to make changes
-in it without breaking people's code.
-
-The way we do that is that we make sure all new features are feature
-gated - they can't be used without enabling a feature gate
-(`#[feature(foo)]`), which can't be done in a stable/beta compiler.
-See the [stability in code] section for the technical details.
-
-Eventually, after we gain enough experience using the feature,
-make the necessary changes, and are satisfied, we expose it to
-the world using the stabilization process described [here].
-Until then, the feature is not set in stone: every part of the
-feature can be changed, or the feature might be completely
-rewritten or removed. Features are not supposed to gain tenure
-by being unstable and unchanged for a year.
+We [value the stability of Rust]. Code that works and runs on stable should (mostly) not break. Because of that, we don't want to release a feature to the world with only team consensus and code review - we want to gain real-world experience on using that feature on nightly, and we might want to change the feature based on that experience.
+
+To allow for that, we must make sure users don't accidentally depend on that new feature - otherwise, especially if experimentation takes time or is delayed and the feature takes the trains to stable, it would end up de facto stable and we'll not be able to make changes in it without breaking people's code.
+
+The way we do that is that we make sure all new features are feature gated - they can't be used without enabling a feature gate (`#[feature(foo)]`), which can't be done in a stable/beta compiler. See the [stability in code] section for the technical details.
+
+Eventually, after we gain enough experience using the feature, make the necessary changes, and are satisfied, we expose it to the world using the stabilization process described [here]. Until then, the feature is not set in stone: every part of the feature can be changed, or the feature might be completely rewritten or removed. Features do not gain tenure by being unstable and unchanged for long periods of time.
 
 ###  Tracking Issues
 
-To keep track of the status of an unstable feature, the
-experience we get while using it on nightly, and of the
-concerns that block its stabilization, every feature-gate
-needs a tracking issue. General discussions about the feature should be done on the tracking issue.
+To keep track of the status of an unstable feature, the experience we get while using it on
+nightly, and of the concerns that block its stabilization, every feature-gate needs a tracking
+issue. When creating issues and PRs related to the feature, reference this tracking issue, and when there are updates about the feature's progress, post those to the tracking issue.
 
-For features that have an RFC, you should use the RFC's
-tracking issue for the feature.
+For features that are part of an accept RFC or approved lang experiment, use the tracking issue for that.
 
-For other features, you'll have to make a tracking issue
-for that feature. The issue title should be "Tracking issue
-for YOUR FEATURE". Use the ["Tracking Issue" issue template][template].
+For other features, create a tracking issue for that feature. The issue title should be "Tracking issue for YOUR FEATURE". Use the ["Tracking Issue" issue template][template].
 
 [template]: https://github.com/rust-lang/rust/issues/new?template=tracking_issue.md
 
+### Lang experiments
+
+To land in the compiler, features that have user-visible effects on the language (even unstable ones) must either be part of an accepted RFC or an approved [lang experiment].
+
+To propose a new lang experiment, open an issue in `rust-lang/rust` that describes the motivation and the intended solution. If it's accepted, this issue will become the tracking issue for the experiment, so use the tracking issue [template] while also including these other details. Nominate the issue for the lang team and CC `@rust-lang/lang` and `@rust-lang/lang-advisors`. When the experiment is approved, the tracking issue will be marked as `B-experimental`.
+
+Feature flags related to a lang experiment must be marked as `incomplete` until an RFC is accepted for the feature.
+
+[lang experiment]: https://lang-team.rust-lang.org/how_to/experiment.html
+
 ##  Stability in code
 
-The below steps needs to be followed in order to implement
-a new unstable feature:
+The below steps needs to be followed in order to implement a new unstable feature:
 
-1. Open a [tracking issue] -
-   if you have an RFC, you can use the tracking issue for the RFC.
+1. Open or identify the [tracking issue]. For features that are part of an accept RFC or approved lang experiment, use the tracking issue for that.
 
-   The tracking issue should be labeled with at least `C-tracking-issue`.
-   For a language feature, a label `F-feature_name` should be added as well.
+   Label the tracking issue with `C-tracking-issue` and the relevant `F-feature_name` label (adding that label if needed).
 
-1. Pick a name for the feature gate (for RFCs, use the name
-   in the RFC).
+1. Pick a name for the feature gate (for RFCs, use the name in the RFC).
 
 1. Add the feature name to `rustc_span/src/symbol.rs` in the `Symbols {...}` block.
 
    Note that this block must be in alphabetical order.
 
-1. Add a feature gate declaration to `rustc_feature/src/unstable.rs` in the unstable
-   `declare_features` block.
+1. Add a feature gate declaration to `rustc_feature/src/unstable.rs` in the unstable `declare_features` block.
 
    ```rust ignore
    /// description of feature
    (unstable, $feature_name, "CURRENT_RUSTC_VERSION", Some($tracking_issue_number))
    ```
 
-   If you haven't yet
-   opened a tracking issue (e.g. because you want initial feedback on whether the feature is likely
-   to be accepted), you can temporarily use `None` - but make sure to update it before the PR is
-   merged!
+   If you haven't yet opened a tracking issue (e.g. because you want initial feedback on whether the feature is likely to be accepted), you can temporarily use `None` - but make sure to update it before the PR is merged!
 
    For example:
 
@@ -149,9 +95,7 @@ a new unstable feature:
    (unstable, non_ascii_idents, "CURRENT_RUSTC_VERSION", Some(55467), None),
    ```
 
-   Features can be marked as incomplete, and trigger the warn-by-default [`incomplete_features`
-   lint]
-   by setting their type to `incomplete`:
+   Features can be marked as incomplete, and trigger the warn-by-default [`incomplete_features` lint] by setting their type to `incomplete`:
 
    [`incomplete_features` lint]: https://doc.rust-lang.org/rustc/lints/listing/warn-by-default.html#incomplete-features
 
@@ -160,42 +104,27 @@ a new unstable feature:
    (incomplete, deref_patterns, "CURRENT_RUSTC_VERSION", Some(87121), None),
    ```
 
-   To avoid [semantic merge conflicts], please use `CURRENT_RUSTC_VERSION` instead of `1.70` or
-   another explicit version number.
+   Feature flags related to a lang experiment must be marked as `incomplete` until an RFC is accepted for the feature.
+
+   To avoid [semantic merge conflicts], use `CURRENT_RUSTC_VERSION` instead of `1.70` or another explicit version number.
 
    [semantic merge conflicts]: https://bors.tech/essay/2017/02/02/pitch/
 
-1. Prevent usage of the new feature unless the feature gate is set.
-   You can check it in most places in the compiler using the
-   expression `tcx.features().$feature_name()`
+1. Prevent usage of the new feature unless the feature gate is set. You can check it in most places in the compiler using the expression `tcx.features().$feature_name()`.
+
+    If the feature gate is not set, you should either maintain the pre-feature behavior or raise an error, depending on what makes sense. Errors should generally use [`rustc_session::parse::feature_err`]. For an example of adding an error, see [#81015].
 
-    If the feature gate is not set, you should either maintain
-    the pre-feature behavior or raise an error, depending on
-    what makes sense. Errors should generally use [`rustc_session::parse::feature_err`].
-    For an example of adding an error, see [#81015].
+   For features introducing new syntax, pre-expansion gating should be used instead. During parsing, when the new syntax is parsed, the symbol must be inserted to the current crate's [`GatedSpans`] via `self.sess.gated_span.gate(sym::my_feature, span)`.
 
-   For features introducing new syntax, pre-expansion gating should be used instead.
-   During parsing, when the new syntax is parsed, the symbol must be inserted to the
-   current crate's [`GatedSpans`] via `self.sess.gated_span.gate(sym::my_feature, span)`. 
-   
-   After being inserted to the gated spans, the span must be checked in the 
-   [`rustc_ast_passes::feature_gate::check_crate`] function, which actually denies
-   features. Exactly how it is gated depends on the exact type of feature, but most 
-   likely will use the `gate_all!()` macro. 
+   After being inserted to the gated spans, the span must be checked in the [`rustc_ast_passes::feature_gate::check_crate`] function, which actually denies features. Exactly how it is gated depends on the exact type of feature, but most likely will use the `gate_all!()` macro.
 
-1. Add a test to ensure the feature cannot be used without
-   a feature gate, by creating `tests/ui/feature-gates/feature-gate-$feature_name.rs`.
-   You can generate the corresponding `.stderr` file by running `./x test 
-tests/ui/feature-gates/ --bless`.
+1. Add a test to ensure the feature cannot be used without a feature gate, by creating `tests/ui/feature-gates/feature-gate-$feature_name.rs`. You can generate the corresponding `.stderr` file by running `./x test tests/ui/feature-gates/ --bless`.
 
-1. Add a section to the unstable book, in
-   `src/doc/unstable-book/src/language-features/$feature_name.md`.
+1. Add a section to the unstable book, in `src/doc/unstable-book/src/language-features/$feature_name.md`.
 
-1. Write a lot of tests for the new feature, preferably in `tests/ui/$feature_name/`.
-   PRs without tests will not be accepted!
+1. Write a lot of tests for the new feature, preferably in `tests/ui/$feature_name/`. PRs without tests will not be accepted!
 
-1. Get your PR reviewed and land it. You have now successfully
-   implemented a feature in Rust!
+1. Get your PR reviewed and land it. You have now successfully implemented a feature in Rust!
 
 [`GatedSpans`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_session/parse/struct.GatedSpans.html
 [#81015]: https://github.com/rust-lang/rust/pull/81015
@@ -206,3 +135,42 @@ tests/ui/feature-gates/ --bless`.
 [here]: ./stabilization_guide.md
 [tracking issue]: #tracking-issues
 [add-feature-gate]: ./feature-gates.md#adding-a-feature-gate
+
+## Call for testing
+
+Once the implementation is complete, the feature will be available to nightly users but not yet part of stable Rust. This is a good time to write a blog post on [the main Rust blog][rust-blog] and issue a "call for testing".
+
+Some earlier such blog posts include:
+
+1. [The push for GATs stabilization](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push/)
+2. [Changes to `impl Trait` in Rust 2024](https://blog.rust-lang.org/2024/09/05/impl-trait-capture-rules.html)
+3. [Async Closures MVP: Call for Testing!](https://blog.rust-lang.org/inside-rust/2024/08/09/async-closures-call-for-testing/)
+
+Alternatively, [*This Week in Rust*][twir] has a [section][twir-cft] for this. One example of this having been used is:
+
+- [Call for testing on boolean literals as cfg predicates](https://github.com/rust-lang/rust/issues/131204#issuecomment-2569314526)
+
+Which option to choose might depend on how significant the language change is, though note that the [*This Week in Rust*][twir] section might be less visible than a dedicated post on the main Rust blog.
+
+## Polishing
+
+Giving users a polished experience means more than just implementing the feature in rustc. We need to think about all of the tools and resources that we ship. This work includes:
+
+- Documenting the language feature in the [Rust Reference][reference].
+- Extending [`rustfmt`] to format any new syntax (if applicable).
+- Extending [`rust-analyzer`] (if applicable). The extent of this work can depend on the nature of the language feature, as some features don't need to be blocked on *full* support.
+   - When a language feature degrades the user experience simply by existing before support is implemented in [`rust-analyzer`], that may lead the lang team to raise a blocking concern.
+   - Examples of such might include new syntax that [`rust-analyzer`] can't parse or type inference changes it doesn't understand when those lead to bogus diagnostics.
+
+## Stabilization
+
+The final step in the feature lifecycle is [stabilization][stab], which is when the feature becomes available to all Rust users. At this point, backward incompatible changes are generally no longer permitted (see the lang team's [defined semver policies](https://rust-lang.github.io/rfcs/1122-language-semver.html) for details). To learn more about stabilization, see the [stabilization guide][stab].
+
+
+[stab]: ./stabilization_guide.md
+[rust-blog]: https://github.com/rust-lang/blog.rust-lang.org/
+[twir]: https://github.com/rust-lang/this-week-in-rust
+[twir-cft]: https://this-week-in-rust.org/blog/2025/01/22/this-week-in-rust-583/#calls-for-testing
+[`rustfmt`]: https://github.com/rust-lang/rustfmt
+[`rust-analyzer`]: https://github.com/rust-lang/rust-analyzer
+[reference]: https://github.com/rust-lang/reference
diff --git a/src/stabilization_guide.md b/src/stabilization_guide.md
index f875c6874..f155272e5 100644
--- a/src/stabilization_guide.md
+++ b/src/stabilization_guide.md
@@ -1,120 +1,66 @@
 # Request for stabilization
 
-**NOTE**: this page is about stabilizing *language* features.
-For stabilizing *library* features, see [Stabilizing a library feature].
+**NOTE**: This page is about stabilizing *language* features. For stabilizing *library* features, see [Stabilizing a library feature].
 
 [Stabilizing a library feature]: ./stability.md#stabilizing-a-library-feature
 
-Once an unstable feature has been well-tested with no outstanding
-concern, anyone may push for its stabilization. It involves the
-following steps:
+Once an unstable feature has been well-tested with no outstanding concerns, anyone may push for its stabilization, though involving the people who have worked on it is prudent. Follow these steps:
 
 <!-- toc -->
 
-## Documentation PRs
+## Write an RFC, if needed
 
-<a id="updating-documentation"></a>
+If the feature was part of a [lang experiment], the lang team generally will want to first accept an RFC before stabilization.
 
-If any documentation for this feature exists, it should be
-in the [`Unstable Book`], located at [`src/doc/unstable-book`].
-If it exists, the page for the feature gate should be removed.
+[lang experiment]: https://lang-team.rust-lang.org/how_to/experiment.html
+
+## Documentation PRs
 
-If there was documentation there, integrating it into the
-existing documentation is needed.
+<a id="updating-documentation"></a>
 
-If there wasn't documentation there, it needs to be added.
+The feature might be documented in the [`Unstable Book`], located at [`src/doc/unstable-book`]. Remove the page for the feature gate if it exists. Integrate any useful parts of that documentation in other places.
 
-Places that may need updated documentation:
+Places that may need updated documentation include:
 
-- [The Reference]: This must be updated, in full detail.
-- [The Book]: This may or may not need updating, depends.
-    If you're not sure, please open an issue on this repository
-    and it can be discussed.
-- standard library documentation: As needed. Language features
-    often don't need this, but if it's a feature that changes
-    how good examples are written, such as when `?` was added
-    to the language, updating examples is important.
-- [Rust by Example]: As needed.
+- [The Reference]: This must be updated, in full detail, and a member of the lang-docs team must review and approve the PR before the stabilization can be merged.
+- [The Book]: This is updated as needed. If you're not sure, please open an issue on this repository and it can be discussed.
+- Standard library documentation: This is updated as needed. Language features often don't need this, but if it's a feature that changes how idiomatic examples are written, such as when `?` was added to the language, updating these in the library documentation is important. Review also the keyword documentation and ABI documentation in the standard library, as these sometimes needs updates for language changes.
+- [Rust by Example]: This is updated as needed.
 
-Prepare PRs to update documentation involving this new feature
-for repositories mentioned above. Maintainers of these repositories
-will keep these PRs open until the whole stabilization process
-has completed. Meanwhile, we can proceed to the next step.
+Prepare PRs to update documentation involving this new feature for the repositories mentioned above. Maintainers of these repositories will keep these PRs open until the whole stabilization process has completed. Meanwhile, we can proceed to the next step.
 
 ## Write a stabilization report
 
-Find the tracking issue of the feature, and create a short
-stabilization report. Essentially this would be a brief summary
-of the feature plus some links to test cases showing it works
-as expected, along with a list of edge cases that came up
-and were considered. This is a minimal "due diligence" that
-we do before stabilizing.
-
-The report should contain:
+Author a stabilization report using the [template found in this repository][srt].
 
-- A summary, showing examples (e.g. code snippets) what is
-  enabled by this feature.
-- Links to test cases in our test suite regarding this feature
-  and describe the feature's behavior on encountering edge cases.
-- Links to the documentations (the PRs we have made in the
-  previous steps).
-- Any other relevant information.
-- The resolutions of any unresolved questions if the stabilization
-  is for an RFC.
+The stabilization reports summarizes:
 
-Examples of stabilization reports can be found in
-[rust-lang/rust#44494][report1] and [rust-lang/rust#28237][report2] (these links
-will bring you directly to the comment containing the stabilization report).
+- The main design decisions and deviations since the RFC was accepted, including both decisions that were FCP'd or otherwise accepted by the language team as well as those being presented to the lang team for the first time.
+    - Often, the final stabilized language feature has significant design deviations from the original RFC. That's OK, but these deviations must be highlighted and explained carefully.
+- The work that has been done since the RFC was accepted, acknowledging the main contributors that helped drive the language feature forward.
 
-[report1]: https://github.com/rust-lang/rust/issues/44494#issuecomment-360191474
-[report2]: https://github.com/rust-lang/rust/issues/28237#issuecomment-363374130
+The [*Stabilization Template*][srt] includes a series of questions that aim to surface connections between this feature and lang's subteams (e.g. types, opsem, lang-docs, etc.) and to identify items that are commonly overlooked.
 
-## FCP
+[srt]: ./stabilization_report_template.md
 
-If any member of the team responsible for tracking this
-feature agrees with stabilizing this feature, they will
-start the FCP (final-comment-period) process by commenting
-
-```text
-@rfcbot fcp merge
-```
-
-The rest of the team members will review the proposal. If the final
-decision is to stabilize, we proceed to do the actual code modification.
+The stabilization report is typically posted as the main comment on the stabilization PR (see the next section).
 
 ## Stabilization PR
 
-*This is for stabilizing language features.  If you are stabilizing a library
-feature, see [the stabilization chapter of the std dev guide][std-guide-stabilization] instead.*
-
-Once we have decided to stabilize a feature, we need to have
-a PR that actually makes that stabilization happen. These kinds
-of PRs are a great way to get involved in Rust, as they take
-you on a little tour through the source code.
+Every feature is different, and some may require steps beyond what this guide discusses.
 
-Here is a general guide to how to stabilize a feature --
-every feature is different, of course, so some features may
-require steps beyond what this guide talks about.
-
-Note: Before we stabilize any feature, it's the rule that it
-should appear in the documentation.
+Before the stabilization will be considered by the lang team, there must be a complete PR to the Reference describing the feature, and before the stabilization PR will be merged, this PR must have been reviewed and approved by the lang-docs team.
 
 ### Updating the feature-gate listing
 
-There is a central listing of unstable feature-gates in
-[`compiler/rustc_feature/src/unstable.rs`]. Search for the `declare_features!`
-macro. There should be an entry for the feature you are aiming
-to stabilize, something like (this example is taken from
-[rust-lang/rust#32409]:
+There is a central listing of unstable feature-gates in [`compiler/rustc_feature/src/unstable.rs`]. Search for the `declare_features!`  macro. There should be an entry for the feature you are aiming to stabilize, something like (this example is taken from [rust-lang/rust#32409]:
 
 ```rust,ignore
 // pub(restricted) visibilities (RFC 1422)
 (unstable, pub_restricted, "CURRENT_RUSTC_VERSION", Some(32409)),
 ```
 
-The above line should be moved to [`compiler/rustc_feature/src/accepted.rs`].
-Entries in the `declare_features!` call are sorted, so find the correct place.
-When it is done, it should look like:
+The above line should be moved to [`compiler/rustc_feature/src/accepted.rs`]. Entries in the `declare_features!` call are sorted, so find the correct place. When it is done, it should look like:
 
 ```rust,ignore
 // pub(restricted) visibilities (RFC 1422)
@@ -122,54 +68,31 @@ When it is done, it should look like:
 // note that we changed this
 ```
 
-(Even though you will encounter version numbers in the file of past changes,
-you should not put the rustc version you expect your stabilization to happen in,
-but instead `CURRENT_RUSTC_VERSION`)
+(Even though you will encounter version numbers in the file of past changes, you should not put the rustc version you expect your stabilization to happen in, but instead use `CURRENT_RUSTC_VERSION`.)
 
 ### Removing existing uses of the feature-gate
 
-Next search for the feature string (in this case, `pub_restricted`)
-in the codebase to find where it appears. Change uses of
-`#![feature(XXX)]` from the `std` and any rustc crates (this includes test folders
-under `library/` and `compiler/` but not the toplevel `tests/` one) to be
-`#![cfg_attr(bootstrap, feature(XXX))]`. This includes the feature-gate
-only for stage0, which is built using the current beta (this is
-needed because the feature is still unstable in the current beta).
+Next, search for the feature string (in this case, `pub_restricted`) in the codebase to find where it appears. Change uses of `#![feature(XXX)]` from the `std` and any rustc crates (this includes test folders under `library/` and `compiler/` but not the toplevel `tests/` one) to be `#![cfg_attr(bootstrap, feature(XXX))]`. This includes the feature-gate only for stage0, which is built using the current beta (this is needed because the feature is still unstable in the current beta).
 
-Also, remove those strings from any tests (e.g. under `tests/`). If there are tests
-specifically targeting the feature-gate (i.e., testing that the
-feature-gate is required to use the feature, but nothing else),
-simply remove the test.
+Also, remove those strings from any tests (e.g. under `tests/`). If there are tests specifically targeting the feature-gate (i.e., testing that the feature-gate is required to use the feature, but nothing else), simply remove the test.
 
 ### Do not require the feature-gate to use the feature
 
-Most importantly, remove the code which flags an error if the
-feature-gate is not present (since the feature is now considered
-stable). If the feature can be detected because it employs some
-new syntax, then a common place for that code to be is in the
-same `compiler/rustc_ast_passes/src/feature_gate.rs`.
-For example, you might see code like this:
+Most importantly, remove the code which flags an error if the feature-gate is not present (since the feature is now considered stable). If the feature can be detected because it employs some new syntax, then a common place for that code to be is in `compiler/rustc_ast_passes/src/feature_gate.rs`. For example, you might see code like this:
 
 ```rust,ignore
-gate_feature_post!(&self, pub_restricted, span,
- "`pub(restricted)` syntax is experimental");
+gate_all!(pub_restricted, "`pub(restricted)` syntax is experimental");
 ```
 
-This `gate_feature_post!` macro prints an error if the
-`pub_restricted` feature is not enabled. It is not needed
-now that `#[pub_restricted]` is stable.
+This `gate_feature_post!` macro prints an error if the `pub_restricted` feature is not enabled. It is not needed now that `#[pub_restricted]` is stable.
 
 For more subtle features, you may find code like this:
 
 ```rust,ignore
-if self.tcx.sess.features.borrow().pub_restricted { /* XXX */ }
+if self.tcx.features().async_fn_in_dyn_trait() { /* XXX */ }
 ```
 
-This `pub_restricted` field (obviously named after the feature)
-would ordinarily be false if the feature flag is not present
-and true if it is. So transform the code to assume that the field
-is true. In this case, that would mean removing the `if` and
-leaving just the `/* XXX */`.
+This `pub_restricted` field (named after the feature) would ordinarily be false if the feature flag is not present and true if it is. So transform the code to assume that the field is true. In this case, that would mean removing the `if` and leaving just the `/* XXX */`.
 
 ```rust,ignore
 if self.tcx.sess.features.borrow().pub_restricted { /* XXX */ }
@@ -194,3 +117,40 @@ if something { /* XXX */ }
 [Rust by Example]: https://github.com/rust-lang/rust-by-example
 [`Unstable Book`]: https://doc.rust-lang.org/unstable-book/index.html
 [`src/doc/unstable-book`]: https://github.com/rust-lang/rust/tree/master/src/doc/unstable-book
+
+## Team nominations
+
+When opening the stabilization PR, CC the lang team and its advisors (`@rust-lang/lang @rust-lang/lang-advisors`) and any other teams to whom the feature is relevant, e.g.:
+
+- `@rust-lang/types`, for type system interactions.
+- `@rust-lang/opsem`, for interactions with unsafe code.
+- `@rust-lang/compiler`, for implementation robustness.
+- `@rust-lang/libs-api`, for changes to the standard library API or its guarantees.
+- `@rust-lang/lang-docs`, for questions about how this should be documented in the Reference.
+
+After the stabilization PR is opened with the stabilization report, wait a bit for any immediate comments. When such comments "simmer down" and you feel the PR is ready for consideration by the lang team, [nominate the PR](https://lang-team.rust-lang.org/how_to/nominate.html) to get it on the agenda for consideration in an upcoming lang meeting.
+
+If you are not a `rust-lang` organization member, you can ask your assigned reviewer to CC the relevant teams on your behalf.
+
+## Propose FCP on the PR
+
+After the lang team and other relevant teams review the stabilization, and after you have answered any questions they may have had, a member of one of the teams may propose to accept the stabilization by commenting:
+
+```text
+@rfcbot fcp merge
+```
+
+Once enough team members have reviewed, the PR will move into a "final comment period" (FCP). If no new concerns are raised, this period will complete and the PR can be merged after implementation review in the usual way.
+
+## Reviewing and merging stabilizations
+
+On a stabilization, before giving it the `r+`, ensure that the PR:
+
+- Matches what the team proposed for stabilization and what is documented in the Reference PR.
+- Includes any changes the team decided to request along the way in order to resolve or avoid concerns.
+- Is otherwise exactly what is described in the stabilization report and in any relevant RFCs or prior lang FCPs.
+- Does not expose on stable behaviors other than those specified, accepted for stabilization, and documented in the Reference.
+- Has sufficient tests to convincingly demonstrate these things.
+- Is accompanied by a PR to the Reference than has been reviewed and approved by a member of lang-docs.
+
+In particular, when reviewing the PR, keep an eye out for any user-visible details that the lang team failed to consider and specify. If you find one, describe it and nominate the PR for the lang team.
diff --git a/src/stabilization_report_template.md b/src/stabilization_report_template.md
new file mode 100644
index 000000000..793f7d7e4
--- /dev/null
+++ b/src/stabilization_report_template.md
@@ -0,0 +1,277 @@
+# Stabilization report template
+
+## What is this?
+
+This is a template for [stabilization reports](./stabilization_guide.md) of **language features**. The questions aim to solicit the details most often needed. These details help reviewers to identify potential problems upfront. Not all parts of the template will apply to every stabilization. If a question doesn't apply, explain briefly why.
+
+Copy everything after the separator and edit it as Markdown. Replace each *TODO* with your answer.
+
+---
+
+# Stabilization report
+
+## Summary
+
+> Remind us what this feature is and what value it provides. Tell the story of what led up to this stabilization.
+>
+> E.g., see:
+>
+> - [Stabilize AFIT/RPITIT](https://web.archive.org/web/20250329190642/https://github.com/rust-lang/rust/pull/115822)
+> - [Stabilize RTN](https://web.archive.org/web/20250321214601/https://github.com/rust-lang/rust/pull/138424)
+> - [Stabilize ATPIT](https://web.archive.org/web/20250124214256/https://github.com/rust-lang/rust/pull/120700)
+> - [Stabilize opaque type precise capturing](https://web.archive.org/web/20250312173538/https://github.com/rust-lang/rust/pull/127672)
+
+*TODO*
+
+Tracking:
+
+- *TODO* (Link to tracking issue.)
+
+Reference PRs:
+
+- *TODO* (Link to Reference PRs.)
+
+cc @rust-lang/lang @rust-lang/lang-advisors
+
+### What is stabilized
+
+> Describe each behavior being stabilized and give a short example of code that will now be accepted.
+
+```rust
+todo!()
+```
+
+### What isn't stabilized
+
+> Describe any parts of the feature not being stabilized. Talk about what we might want to do later and what doors are being left open for that. If what we're not stabilizing might lead to surprises for users, talk about that in particular.
+
+## Design
+
+### Reference
+
+> What updates are needed to the Reference? Link to each PR. If the Reference is missing content needed for describing this feature, discuss that.
+
+- *TODO*
+
+### RFC history
+
+> What RFCs have been accepted for this feature?
+
+- *TODO*
+
+### Answers to unresolved questions
+
+> What questions were left unresolved by the RFC? How have they been answered? Link to any relevant lang decisions.
+
+*TODO*
+
+### Post-RFC changes
+
+> What other user-visible changes have occurred since the RFC was accepted? Describe both changes that the lang team accepted (and link to those decisions) as well as changes that are being presented to the team for the first time in this stabilization report.
+
+*TODO*
+
+### Key points
+
+> What decisions have been most difficult and what behaviors to be stabilized have proved most contentious? Summarize the major arguments on all sides and link to earlier documents and discussions.
+
+*TODO*
+
+### Nightly extensions
+
+> Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?
+
+*TODO*
+
+### Doors closed
+
+> What doors does this stabilization close for later changes to the language? E.g., does this stabilization make any other RFCs, lang experiments, or known in-flight proposals more difficult or impossible to do later?
+
+## Feedback
+
+### Call for testing
+
+> Has a "call for testing" been done? If so, what feedback was received?
+
+*TODO*
+
+### Nightly use
+
+> Do any known nightly users use this feature? Counting instances of `#![feature(FEATURE_NAME)]` on GitHub with grep might be informative.
+
+*TODO*
+
+## Implementation
+
+### Major parts
+
+> Summarize the major parts of the implementation and provide links into the code and to relevant PRs.
+>
+> See, e.g., this breakdown of the major parts of async closures:
+>
+> - <https://rustc-dev-guide.rust-lang.org/coroutine-closures.html>
+
+*TODO*
+
+### Coverage
+
+> Summarize the test coverage of this feature.
+>
+> Consider what the "edges" of this feature are. We're particularly interested in seeing tests that assure us about exactly what nearby things we're not stabilizing. Tests should of course comprehensively demonstrate that the feature works. Think too about demonstrating the diagnostics seen when common mistakes are made and the feature is used incorrectly.
+>
+> Within each test, include a comment at the top describing the purpose of the test and what set of invariants it intends to demonstrate. This is a great help to our review.
+>
+> Describe any known or intentional gaps in test coverage.
+>
+> Contextualize and link to test folders and individual tests.
+
+*TODO*
+
+### Outstanding bugs
+
+> What outstanding bugs involve this feature? List them. Should any block the stabilization? Discuss why or why not.
+
+*TODO*
+
+- *TODO*
+- *TODO*
+- *TODO*
+
+### Outstanding FIXMEs
+
+> What FIXMEs are still in the code for that feature and why is it OK to leave them there?
+
+*TODO*
+
+### Tool changes
+
+> What changes must be made to our other tools to support this feature. Has this work been done? Link to any relevant PRs and issues.
+
+- [ ] rustfmt
+  - *TODO*
+- [ ] rust-analyzer
+  - *TODO*
+- [ ] rustdoc (both JSON and HTML)
+  - *TODO*
+- [ ] cargo
+  - *TODO*
+- [ ] clippy
+  - *TODO*
+- [ ] rustup
+  - *TODO*
+- [ ] docs.rs
+  - *TODO*
+
+*TODO*
+
+### Breaking changes
+
+> If this stabilization represents a known breaking change, link to the crater report, the analysis of the crater report, and to all PRs we've made to ecosystem projects affected by this breakage. Discuss any limitations of what we're able to know about or to fix.
+
+*TODO*
+
+Crater report:
+
+- *TODO*
+
+Crater analysis:
+
+- *TODO*
+
+PRs to affected crates:
+
+- *TODO*
+- *TODO*
+- *TODO*
+
+## Type system, opsem
+
+### Compile-time checks
+
+> What compilation-time checks are done that are needed to prevent undefined behavior?
+>
+> Link to tests demonstrating that these checks are being done.
+
+*TODO*
+
+- *TODO*
+- *TODO*
+- *TODO*
+
+### Type system rules
+
+> What type system rules are enforced for this feature and what is the purpose of each?
+
+*TODO*
+
+### Sound by default?
+
+> Does the feature's implementation need specific checks to prevent UB, or is it sound by default and need specific opt-in to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale?
+
+*TODO*
+
+### Breaks the AM?
+
+> Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? Describe this if so.
+
+*TODO*
+
+## Common interactions
+
+### Temporaries
+
+> Does this feature introduce new expressions that can produce temporaries? What are the scopes of those temporaries?
+
+*TODO*
+
+### Drop order
+
+> Does this feature raise questions about the order in which we should drop values? Talk about the decisions made here and how they're consistent with our earlier decisions.
+
+*TODO*
+
+### Pre-expansion / post-expansion
+
+> Does this feature raise questions about what should be accepted pre-expansion (e.g. in code covered by `#[cfg(false)]`) versus what should be accepted post-expansion? What decisions were made about this?
+
+*TODO*
+
+### Edition hygiene
+
+> If this feature is gated on an edition, how do we decide, in the context of the edition hygiene of tokens, whether to accept or reject code. E.g., what token do we use to decide?
+
+*TODO*
+
+### SemVer implications
+
+> Does this feature create any new ways in which library authors must take care to prevent breaking downstreams when making minor-version releases? Describe these. Are these new hazards "major" or "minor" according to [RFC 1105](https://rust-lang.github.io/rfcs/1105-api-evolution.html)?
+
+*TODO*
+
+### Exposing other features
+
+> Are there any other unstable features whose behavior may be exposed by this feature in any way? What features present the highest risk of that?
+
+*TODO*
+
+## History
+
+> List issues and PRs that are important for understanding how we got here.
+
+- *TODO*
+- *TODO*
+- *TODO*
+
+## Acknowledgments
+
+> Summarize contributors to the feature by name for recognition and so that those people are notified about the stabilization. Does anyone who worked on this *not* think it should be stabilized right now? We'd like to hear about that if so.
+
+*TODO*
+
+## Open items
+
+> List any known items that have not yet been completed and that should be before this is stabilized.
+
+- [ ] *TODO*
+- [ ] *TODO*
+- [ ] *TODO*