The catalog
Every plugin in the marketplace, what it carries, and how to install it
Plugins are grouped by domain (what the capability is about), not by how it is invoked. Each is self-contained: its own manifest, its own skills, its own bundled resources. Nothing is shared between them, and installing one never pulls in another.
openspec
2 skillsPersonal engineering standard: OpenSpec (proposal/specs/design/tasks) extended with optional ADRs for durable, hard-to-reverse decisions, plus LikeC4 for living architecture diagrams.
git
2 skillsPersonal git workflow conventions: a Conventional Commits skill and a pull/merge request skill (gitflow branches, conventional titles).
tui
1 skillTerminal UI media - starting with a record skill that generates a demo video from a spec: one file says what the video shows and how to rebuild the sandbox it was recorded in.
Every skill
| Skill | Invoked by | What it does |
|---|---|---|
| openspec:adr | model + user | Record an Architecture Decision Record (ADR) under docs/adr/ - proactively, when a decision made during other work clears the bar (a new external dependency, a technology/pattern choice with long-term consequences, a boundary expensive to move later), not only when explicitly asked via the `adr` skill. |
| openspec:init | user only | Apply the personal engineering standard to this project - OpenSpec (with ADRs formalized at archive time) + LikeC4 architecture diagrams. |
| git:commit | model + user | Commit (and push) changes using Conventional Commits. |
| git:pr | model + user | Open, name and describe a pull/merge request (GitHub PR, GitLab MR) and its branch. |
| tui:record | model + user | Record a terminal UI as a demo video worth publishing - an asciinema cast driven by a scripted, verified take, then cut and rendered to a GIF. |
What is deliberately not split out
Premature separation is easy to regret, so a few things stay folded into an existing plugin until they earn their own:
architecture/specificationsplit ofopenspec: OpenSpec and ADR/LikeC4 are one coupled workflow today. Split them when one needs to evolve independently of the other, not before.- A standalone
projectplugin: there is exactly one bootstrap entry point,openspec:init. A second, non-OpenSpec bootstrap concern is what would justify the split. - An
adapters/layer for per-harness translation: UZE already detects and provisions claude-code, codex, opencode and antigravity. Confirm it doesn't already cover the case before duplicating it here.
Install
Machine-wide, from any project:
uze plugin install openspec@ai
uze plugin install git@ai
uze plugin install tui@aiOr scoped to one project, written into its agents.lock:
uze openspec@ai