{edoc_opts, [
    {includes, ["src"]},
    {preprocess, true}
]}.

The last option is especially interesting when macros (@elbrujohalcon's favourite Erlang component) are present. The includes I'd have to check (can't remember of the top of my head) but I know it was important for us at a point in time.

Used -spec success(list()) -> ok | no_return()..
Expected -spec success(ct_suite:ct_config()) -> ok | no_return().

Not really sure having that there makes a difference.

It's always good to have one in any software project, IMO.
I usually go for something like

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).

If this is a rebar3 plugin for rebar3 plugins, why ignore stuff that's not generated by the plugin instance?

Also, to start, I think .gitignore can be as easy as

.rebar3
_build
erl_crash.dump
log
rebar3.crashdump

I'm also not fond of ignoring _checkouts/. If it's there, it's changing behaviour, so whatever gets pushed might be different from what is excepted. (and again, _checkouts isn't generated, but put there on purpose)

I usually go with something like

[{elvis, [
    {config, [
        #{ dirs => ["src/**"],
           filter => "*.erl",
           ruleset => erl_files },
        #{ dirs => ["test/**"],
           filter => "*.erl",
           ruleset => erl_files },
        #{ dirs => ["."],
           filter => "rebar.config",
           ruleset => rebar_config },
        #{ dirs => ["."],
           filter => "elvis.config",
           ruleset => elvis_config }
    ]},
    {verbose, false}
]}].

to start.

rebar3_lint implements its own default, but it's a more reduced version of the above. Also, some people do prefer to not include tests in their analysis, but this is a template that can be stripped somewhat, right?

rebar3_edoc_extensions

In README used link https://rebar3.readme.io but should be https://www.rebar3.org.

no_return is on by default, so having it there is redundant.

rebar3_plugin version

0.1.0

OTP version

23.3/24.1

Description

• Motivation
  Extension CLI bootstrap for more flexibility since not for all plugins are suitable the basic set of functionality and configuration that is present in the version 0.1.0.
• Proposal
  Extension CLI bootstrap for parse clean argument for build plugin template without additional tools like dialyzer, xref, hank etc.

Current behavior

CLI bootstrap working without additional arguments and build plugin template with additional tools like dialyzer, xref, hanketc.

Expected behavior

CLI bootstrap should accept additional argument clean for build plugin template without additional arguments and build plugin template with additional tools like dialyzer, xref, hank etc.

I usually use the following

{xref_checks, [
    deprecated_function_calls,
    exports_not_used,
    locals_not_used,
    undefined_function_calls
]}.

though some might issue unwanted warnings for lack of context (eg. calling rebar3_ functions)

I'm used to having this as simple as

{erl_opts, [
    debug_info,
    warn_export_vars,
    warn_missing_spec_all,
    warn_unused_import,
    warnings_as_errors,
    {i, "src"}
]}.

because most other options are already there, by default, but one would've to parse the existing list.

Issue in src/{{ repo-name }}_prv.erl
Currently used hardcode -define(PROVIDER, rebar3_plugin).
Expected -define(PROVIDER, {{ repo-name }}).