Plugins

ansible-core defines 17 plugin types. Each is a Python class hierarchy with a base under lib/ansible/plugins/<type>/__init__.py and concrete plugin files in the same directory (or in a collection).

Quick reference

Type	Where ansible-core ships them	Page	Examples in tree
Action	lib/ansible/plugins/action/ (28 files)	action.md	copy, template, set_fact, debug, pause, script, fetch
Become	lib/ansible/plugins/become/ (3 files)	become.md	sudo, su, runas
Cache	lib/ansible/plugins/cache/	cache-and-vars.md	memory, jsonfile
Callback	lib/ansible/plugins/callback/ (5 files)	callback.md	default, minimal, oneline, junit, tree
Cliconf	lib/ansible/plugins/cliconf/ (empty in core)	(collections only)	—
Connection	lib/ansible/plugins/connection/ (4 files)	connection.md	ssh, local, winrm, psrp
Doc fragments	lib/ansible/plugins/doc_fragments/ (large)	(covered in Modules and actions)	Reusable doc snippets
Filter	lib/ansible/plugins/filter/ (large)	filter.md	to_json, to_yaml, combine, regex_search
HttpAPI	lib/ansible/plugins/httpapi/ (empty in core)	(collections only)	—
Inventory	lib/ansible/plugins/inventory/ (9 files)	inventory.md	ini, yaml, script, host_list, constructed
Lookup	lib/ansible/plugins/lookup/ (~40 files)	lookup.md	file, env, pipe, password, template, dict
Netconf	lib/ansible/plugins/netconf/ (empty in core)	(collections only)	—
Shell	lib/ansible/plugins/shell/	shell-and-strategy.md	sh, cmd, powershell, csh, fish
Strategy	lib/ansible/plugins/strategy/ (4 files)	strategy.md	linear, free, host_pinned, debug
Terminal	lib/ansible/plugins/terminal/ (empty in core)	(collections only)	—
Test	lib/ansible/plugins/test/ (large)	test.md	defined, succeeded, match, version
Vars	lib/ansible/plugins/vars/	cache-and-vars.md	host_group_vars

How they're loaded

Every plugin type is paired with a PluginLoader instance in lib/ansible/plugins/loader.py. Loaders resolve names through fully-qualified collection names (FQCN), the redirect map at lib/ansible/config/ansible_builtin_runtime.yml, and finally the built-in directory. See Systems → Plugin loader.

How they're declared

Every plugin file starts with a top-level DOCUMENTATION = """...""" YAML block describing:

• name, short_description, description.
• options: — settable from vars/env/ini/keyword. Auto-wired into self.get_option(name).
• version_added, author, notes.

The same pattern is used by modules, hence the same sanity tests apply to both.

Sub-pages

• Action plugins — controller-side task handlers
• Become plugins — privilege escalation
• Cache and vars plugins — caching backends and variable sources
• Callback plugins — event consumers
• Connection plugins — transport to remote hosts
• Filter plugins — Jinja {{ x | filter }}
• Inventory plugins — host discovery
• Lookup plugins — {{ lookup('name', ...) }}
• Shell and strategy plugins — remote shell quoting and task scheduling (combined: small surfaces)
• Strategy plugins — task scheduling (deeper coverage on its own)
• Test plugins — Jinja {{ x is testname }}

Cross-links

• Systems → Plugin loader — name resolution.
• Features → Collections — where most non-built-in plugins live.