I removed this sentence because I don't think it's accurate.

We have these review criteria:
https://docs.civicrm.org/extensions/lifecycle/#review-criteria

The criteria do say that you can't use PHP overrides. But there are
other interfaces (like BAO functions for example) that are not in the
"supported methods" list but also not prohibited based on the extension
review criteria.

No content edits here. Just a direct copy paste.

Per discussion in documentation channel I think we need to document what methods are considered supported / expected to be stable. The last 4 items in this list have not been previously documented as a supported way to interact with CiviCRM so may be subject to discussion

The purpose of the intro paragraph is to prep the reader to see several
different test types/tools.  So it...  should probably use the word "test"
somewhere.

Missing ; and .

If I disagree with using the "NFC" label, I'd like to be able to quickly
reference a link that explains the rationale and provides examples.

Minor tweaks, typos etc

"Security Doucmentation" --> "Security Documentation"

Some more details about creating a settings page for an extension.

Three changes here:
 * Sort criteria in the same order across all three templates.
 * For meta-instructions, use the Markdown/HTML comment notation.
 * For `r-run`, we really don't want boilerplate. Remove the boilerplate.

The DEL workflow produces more readable output.

This makes it easier to find for people who come to the page just
looking for this one thing, which should be a common use-case of this
content.

There was confusion in some docs about `r-user` vs `r-users`. Standardize on `r-user`.

The name `r-technical` was bit more verbose than all the other abbreviations. `r-tech` looks like it'll fit better.

style guide ref:
https://docs.civicrm.org/dev/en/latest/documentation/style-guide/#hackable-urls

Typo

Changed the line numer in the link of the example file for declaring the settings folder.