What a plugin is
Three kinds of plugin
Plugins add skills, steps, guidance, and requirements without changing core. Each one declares its kind in its manifest.
Tech-stack packs
A language, framework, or platform. How a .NET project runs its linters through MSBuild, how it publishes website artifacts, how a Blazor app differs from a server app when it is tested.
Tool packs
A tool the life cycle uses. A formatter with opinions per language, a browser-test tool, a load-testing tool such as k6, a pipeline system such as Azure Pipelines, GitHub Actions, or GitLab CI.
Process packs
An extra step or gate an organisation needs, such as a change-advisory review or a compliance check, added to a process without changing the steps core defines.
The admission rule
Every plugin skill attaches to the life cycle
A skill belongs in a plugin when it names the core step or process it serves, or the core requirement it satisfies. That is what makes it part of the SDLC rather than a skill that happens to be installed next to it. The command line refuses a plugin skill that names neither.
---
name: load
description: "Load and soak tests with k6 against the stated performance targets."
aa:
attaches_to: [performance-test] # core steps or processes
satisfies: [] # core requirements, such as R-09 (a formatter)
---| Skill | Attaches to | Plugin? |
|---|---|---|
| Prettier, with opinions per language | R-09, a formatter for each language; finish-branch | Yes, a tool pack |
| Playwright for a Blazor app versus a server app | e2e-tests | Yes, a tool pack |
| Load tests with k6 | performance-test | Yes, a tool pack |
| MSBuild lint commands | R-35, lint in the build | Yes, a tech-stack pack |
| Publishing website artifacts from .NET | release; R-20, a pack script | Yes, a tech-stack pack |
| Azure, GitHub, or GitLab pipelines | setup-pipeline | Yes, a tool pack |
| Writing C# well | Nothing: it is how to write code, not how a step is carried out | No |
| Generating scripts | Nothing | No |
| An organisation's general practices | Nothing: it belongs in the organisation's own configuration | No |
| Image generation | Nothing: it is not a step of the life cycle | No |
The skills in the last four rows are useful and expected to exist. Load them into your agent as ordinary skills; they are simply not part of the SDLC.
Boundaries
What a plugin may and may not do
A plugin may name tools
Core guidance never names a tool, so it reads the same on any stack. Plugins exist to be specific: the command to run, the configuration to commit, the flags that matter, the opinions a team would otherwise argue about.
A plugin never changes core
A plugin adds skills under its own name. It cannot redefine a core step, and it cannot use a name that would look like a core skill. The command line refuses a plugin that tries.
A plugin never wraps your systems
The agent reaches your ticket system, knowledge base, and source control through whatever connector it already has. A pipeline pack covers pipeline definitions and runs, never the tickets, merge requests, or wiki of the same system.
A plugin declares what it needs
Every tool a plugin depends on is a requirement in the plugin's own numbered range, so /aa-fw-health can check it alongside core's requirements and report what is met.
The command line
Managing plugins
The aa plugin verb manages plugins at project scope inside an initialised repository, or at user scope with -scope user.
aa plugin install <name|path> # install, and record its version and source in aa.config.yaml
aa plugin update [<name>] # reinstall from the recorded source; report the version change and the files
aa plugin list # installed plugins by scope, and the ones available to install
aa plugin remove <name> # remove its skills and commands; core is untouchedThe config records each plugin's version and where it came from, so aa plugin update knows where to look and aa update brings plugins up to date alongside core:
plugins:
- name: k6-sdlc
version: 0.2.0
source: ../aa-sdlc-plugins/src/k6-sdlcWhere plugins live
The aa-sdlc-plugins repository
aa plugin verb exists and installs from a path or an organisation repository today. The aa-sdlc-plugins repository exists and lists the plugins planned below; none is written yet, and installing one by name comes with the release and update work.
Tech-stack and tool packs are named for their stack or tool with -sdlc on the end, so a pack for .NET is dotnet-sdlc, never dotnet: it says how a .NET project carries out the life-cycle steps, not how to write C#. Process packs keep a plain name.
| First | Kind | Attaches to |
|---|---|---|
dotnet-sdlc | tech‑stack | build, test, lint, format, package, and publish; R‑09, R‑10, R‑11, R‑12, R‑35, R‑36, R‑38 |
powershell-sdlc | tech‑stack | formatting, analysis, Pester tiers, packaging; R‑09, R‑11, R‑12, R‑20, R‑35 |
reqnroll-sdlc | tool | executing feature files; R‑17; generate-tests, uat |
playwright-sdlc | tool | e2e-tests, review-ux, explore |
prettier-sdlc | tool | R‑09, R‑35; finish-branch |
gitlab-ci-sdlc, github-actions-sdlc, azure-pipelines-sdlc | tool | setup-pipeline; R‑24, R‑38 |
release-hygiene | process | the deployment process, before prepare-release |
After those: android-sdlc, node-sdlc, and go-sdlc; feature-file runners for Go and JavaScript; docker-compose-sdlc for the local environment; k6-sdlc for load; gitleaks-sdlc, trivy-sdlc, semgrep-sdlc, and zap-sdlc for security; bicep-sdlc and terraform-sdlc for infrastructure; opentelemetry-sdlc; cloudflare-pages-sdlc, nuget-publish-sdlc, and npm-publish-sdlc for release; commitlint-sdlc, stryker-sdlc, and renovate-sdlc; and the process packs change-advisory, accessibility-review, privacy-review, and licence-compliance.
The core package ships no plugins, so a plugin can be released on its own schedule. The plugins repository follows the same layout as every DevPossible repository, with the plugins themselves under src/:
src/
index.yaml # every plugin (name, kind, version, folder, summary), and the planned ones
k6-sdlc/
README.md
plugin.yaml # name, version, kind, requirements
skills/ # one folder per skill, each attached to a step or requirement
features/ # the plugin's own scenarios, in GherkinAn organisation can keep its own plugins in its configuration repository, and aa plugin install finds them by name once aa setup -org <repository> has pointed at it.
Your own
Writing a plugin
Inside your agent, /aa-fw-extend walks you from "the framework should know about X" to a valid plugin. It picks the kind with you, writes the feature file first, scaffolds the manifest and the skills with what each one attaches to, declares the requirements, and validates the result before it installs anything. If what you describe attaches to no step of the life cycle, it says so and suggests keeping it as an ordinary skill.