@rbbtsn0w/adg 0.1.0-beta.3 → 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +56 -0
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -67,6 +67,62 @@ install. To hack on the CLI itself, see [Developing from source](#developing-fro
|
|
|
67
67
|
|
|
68
68
|
---
|
|
69
69
|
|
|
70
|
+
# Works with existing ecosystems
|
|
71
|
+
|
|
72
|
+
ADG is **not** a new plugin format you have to migrate to. Any repo that already
|
|
73
|
+
ships `.claude-plugin/` or `.codex-plugin/` manifests is ingested as-is: on the
|
|
74
|
+
way in, `add` discovers each native manifest and **reverse-adapts** it into a
|
|
75
|
+
canonical `.agents/.plugin.json` (the inverse of `adapt`), then ADG manages and
|
|
76
|
+
re-projects it like any first-party plugin. No fork, no edits upstream.
|
|
77
|
+
|
|
78
|
+
The two examples below are real, popular repositories — neither is ADG-native.
|
|
79
|
+
|
|
80
|
+
### Example 1 — `anthropics/knowledge-work-plugins` (a category monorepo)
|
|
81
|
+
|
|
82
|
+
A marketplace monorepo where each top-level category (`engineering/`,
|
|
83
|
+
`marketing/`, `legal/`, …) is its own plugin with a `.claude-plugin/plugin.json`
|
|
84
|
+
and a `skills/` tree. Pull the whole thing, or sparse-checkout just the
|
|
85
|
+
categories you want:
|
|
86
|
+
|
|
87
|
+
```bash
|
|
88
|
+
# whole marketplace into the global store
|
|
89
|
+
adg plugins add anthropics/knowledge-work-plugins --ref main --global
|
|
90
|
+
|
|
91
|
+
# or fetch only one category from the large monorepo
|
|
92
|
+
adg plugins add anthropics/knowledge-work-plugins --ref main --sparse engineering --global
|
|
93
|
+
|
|
94
|
+
# each category's .claude-plugin manifest is reverse-adapted on import,
|
|
95
|
+
# then projected back onto the runtimes you use
|
|
96
|
+
adg plugins link --target claude --global # → ~/.claude/skills/<plugin>:<skill>
|
|
97
|
+
adg plugins link --target codex --global # native, zero-copy
|
|
98
|
+
adg plugins list --global
|
|
99
|
+
```
|
|
100
|
+
|
|
101
|
+
### Example 2 — `obra/superpowers` (a single multi-runtime plugin)
|
|
102
|
+
|
|
103
|
+
A single skills plugin that already ships `.claude-plugin/`, `.codex-plugin/` and
|
|
104
|
+
a `skills/` library. Because the native manifests are already present, ADG simply
|
|
105
|
+
adopts it — discovery picks up the existing manifest, records provenance and a
|
|
106
|
+
content hash in the lock, and from then on it updates like any ADG plugin:
|
|
107
|
+
|
|
108
|
+
```bash
|
|
109
|
+
adg plugins add obra/superpowers --ref main --global
|
|
110
|
+
|
|
111
|
+
# now under management — same lifecycle as a first-party plugin
|
|
112
|
+
adg plugins list --global
|
|
113
|
+
adg plugins update --global
|
|
114
|
+
adg plugins link --target claude --global
|
|
115
|
+
```
|
|
116
|
+
|
|
117
|
+
> Both repos are pulled by `owner/repo` shorthand over a shallow clone (sparse
|
|
118
|
+
> checkout when `--sparse` is given). Provenance — `{type:"github",repo,ref,path}`
|
|
119
|
+
> — plus a `sha256` integrity hash land in `.plugin-lock.json`, so the install is
|
|
120
|
+
> reproducible regardless of which ecosystem the plugin originally came from. See
|
|
121
|
+
> [Importing existing inventory (via `add`)](#importing-existing-inventory-via-add)
|
|
122
|
+
> for the discovery and reverse-adaptation details.
|
|
123
|
+
|
|
124
|
+
---
|
|
125
|
+
|
|
70
126
|
# Concepts (common)
|
|
71
127
|
|
|
72
128
|
These apply the same whether you run a released build or the source tree.
|