agent-plugins 0.2.2__tar.gz → 0.2.4__tar.gz
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.
- agent_plugins-0.2.4/.agent-plugin/skills/agent-plugins/SKILL.md +132 -0
- agent_plugins-0.2.4/.agent-plugin/skills/agent-plugins/agents/openai.yaml +4 -0
- agent_plugins-0.2.4/.agent-plugin/skills/package-agent-plugin/SKILL.md +150 -0
- agent_plugins-0.2.4/.agent-plugin/skills/package-agent-plugin/agents/openai.yaml +4 -0
- agent_plugins-0.2.4/.agent-plugin/skills/package-agent-plugin/references/briefings.md +143 -0
- agent_plugins-0.2.4/.agent-plugin/skills/package-agent-plugin/references/build-variants.md +77 -0
- agent_plugins-0.2.4/.agent-plugin/skills/package-agent-plugin/references/verify-artifacts.md +42 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/PKG-INFO +30 -8
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/README.md +28 -7
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/pyproject.toml +2 -1
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/pyproject.toml.orig +2 -1
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/__init__.py +2 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_cli.py +20 -3
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_discovery.py +5 -1
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_files.py +53 -29
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_plugin.py +16 -36
- agent_plugins-0.2.4/src/agent_plugins/_read.py +212 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_schema/errors.py +3 -2
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_skill.py +24 -8
- agent_plugins-0.2.2/.agent-plugin/skills/agent-plugins/SKILL.md +0 -250
- agent_plugins-0.2.2/.agent-plugin/skills/agent-plugins/agents/openai.yaml +0 -4
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/.agent-plugin/plugin.json +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/LICENSE +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/__main__.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_build/__init__.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_build/backend.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_build/plan.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_build/sdist.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_build/wheel.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_build/wheel_archive.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_errors.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_marker.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_mcp.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_schema/__init__.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_schema/json.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_schema/lazy.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_schema/manifest.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_schema/mcp.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_schema/models.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_schema/skill.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_schema/v1/__init__.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_schema/v1/manifest.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_schema/v1/mcp.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/_tree.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/build/__init__.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/build/hatchling.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/build/uv_build.py +0 -0
- {agent_plugins-0.2.2 → agent_plugins-0.2.4}/src/agent_plugins/py.typed +0 -0
|
@@ -0,0 +1,132 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: agent-plugins
|
|
3
|
+
description: Read version-matched agent briefings and resources from installed Python distributions. Use when a package README points to agent-plugins, a Python host exposes packaged guidance, or a task needs plugin discovery, linked resources, or installation diagnostics. For adding Agent Plugin packaging to a project, use package-agent-plugin.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Read installed Agent Plugins
|
|
7
|
+
|
|
8
|
+
Read the instructions shipped with the Python installation that will execute
|
|
9
|
+
the task. A briefing combines distribution identity, environment guidance,
|
|
10
|
+
plugin inventory, and complete skill instructions. The host supplies execution
|
|
11
|
+
tools, dependency management, and runtime connections.
|
|
12
|
+
|
|
13
|
+
## Choose the entrypoint
|
|
14
|
+
|
|
15
|
+
If the package is already installed, read its briefing in that Python
|
|
16
|
+
environment:
|
|
17
|
+
|
|
18
|
+
```python
|
|
19
|
+
import agent_plugins as ap
|
|
20
|
+
|
|
21
|
+
print(ap.read("my-package"))
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
`ap.read()` returns a string and selects the skill whose directory name matches
|
|
25
|
+
the distribution argument exactly. Pass `skill="use-my-package"` when the
|
|
26
|
+
workflow has another name. An unavailable skill raises `AgentPluginError` and
|
|
27
|
+
lists the available names. Use the host's captured `help(module)` output when
|
|
28
|
+
a package exposes the same briefing through an agent module.
|
|
29
|
+
|
|
30
|
+
When starting from a README before setting up an execution environment, run:
|
|
31
|
+
|
|
32
|
+
```console
|
|
33
|
+
uvx --with my-package agent-plugins read my-package
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
The requirement after `--with` selects what uv installs. The final argument
|
|
37
|
+
identifies the installed distribution to inspect. Pin the requirement, such as
|
|
38
|
+
`'my-package==1.2.3'`, when the task requires a particular release.
|
|
39
|
+
|
|
40
|
+
The CLI includes every packaged skill by default. Select one with
|
|
41
|
+
`--skill NAME`. Follow the workflows applicable to the request. Running
|
|
42
|
+
`uvx agent-plugins` with no arguments reads this package's consumer and
|
|
43
|
+
packaging skills.
|
|
44
|
+
|
|
45
|
+
## Use the execution environment
|
|
46
|
+
|
|
47
|
+
Check the briefing's distribution version and interpreter before using its
|
|
48
|
+
examples. `uvx` uses an isolated, disposable tool environment. Its resource
|
|
49
|
+
paths can remain readable while cached, but the project or notebook may have
|
|
50
|
+
a different installation or filesystem.
|
|
51
|
+
|
|
52
|
+
Install dependencies through the target project's or host's package manager,
|
|
53
|
+
preserving its version policy. Then read that installation's briefing. From a
|
|
54
|
+
terminal, bind the CLI to the intended interpreter:
|
|
55
|
+
|
|
56
|
+
```console
|
|
57
|
+
/path/to/environment/bin/python -m agent_plugins read my-package
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
In a remote kernel or service, execute `ap.read()` there. Reuse the briefing
|
|
61
|
+
while that environment and installation remain unchanged. If a package's
|
|
62
|
+
module help already supplied the applicable skill, continue with its workflow.
|
|
63
|
+
Rediscover after switching environments or installations. Restart a process
|
|
64
|
+
that still holds imports from a replaced package.
|
|
65
|
+
|
|
66
|
+
Package availability and runtime readiness are separate. Follow the selected
|
|
67
|
+
workflow's connection, activation, and verification steps before treating a
|
|
68
|
+
browser, service, device, or other host as ready.
|
|
69
|
+
|
|
70
|
+
## Read linked resources
|
|
71
|
+
|
|
72
|
+
Relative links are resolved from the skill directory. When the agent cannot
|
|
73
|
+
read that filesystem directly, retrieve the text through Python in its owning
|
|
74
|
+
environment:
|
|
75
|
+
|
|
76
|
+
```python
|
|
77
|
+
import agent_plugins as ap
|
|
78
|
+
|
|
79
|
+
plugin = ap.locate("my-package")
|
|
80
|
+
skill = plugin.skill("my-package")
|
|
81
|
+
print(skill.tree())
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
Choose a resource named by the skill. For a packaged `references/api.md`:
|
|
85
|
+
|
|
86
|
+
```python
|
|
87
|
+
print(skill.file("references/api.md").read_text(encoding="utf-8"))
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
`skill.file()` checks selected-file membership and containment. Reacquire the
|
|
91
|
+
handle in each execution if the host discards local bindings between calls.
|
|
92
|
+
Read additional resources at the decision points specified by the workflow.
|
|
93
|
+
`skill.source` returns the full instruction file, and `skill.body` omits its
|
|
94
|
+
frontmatter when raw text is needed instead of a briefing.
|
|
95
|
+
|
|
96
|
+
Use published documentation and its `llms.txt` index for broader examples and
|
|
97
|
+
reference. Check that an online API matches the active installation. A source
|
|
98
|
+
checkout describes that checkout and may differ from an installed release.
|
|
99
|
+
|
|
100
|
+
## Inspect or recover
|
|
101
|
+
|
|
102
|
+
| Task | Operation |
|
|
103
|
+
| --- | --- |
|
|
104
|
+
| Find plugins in this interpreter | `ap.installed()` |
|
|
105
|
+
| Inspect one plugin's selected files | `ap.locate("my-package").tree()` |
|
|
106
|
+
| Discover its skill names | `[skill.name for skill in plugin.skills]` |
|
|
107
|
+
| Inspect plugin metadata | `plugin.manifest` |
|
|
108
|
+
| Inspect MCP configuration | `plugin.mcp` |
|
|
109
|
+
| List installed plugins from a terminal | `agent-plugins list --json` |
|
|
110
|
+
| Print one installed plugin root | `agent-plugins locate my-package` |
|
|
111
|
+
|
|
112
|
+
Pass the Python distribution name to `read()` and `locate()`. The manifest
|
|
113
|
+
plugin name and Python import name can differ from it.
|
|
114
|
+
|
|
115
|
+
For an absent distribution or unusable plugin, correct the target installation
|
|
116
|
+
before retrying. For an unavailable skill, select a listed structural name.
|
|
117
|
+
`ValidationError` identifies an invalid plugin document. Preserve that
|
|
118
|
+
diagnostic when the packaged files need repair.
|
|
119
|
+
|
|
120
|
+
Briefings summarize MCP names and transports while leaving configured commands,
|
|
121
|
+
arguments, environment values, URLs, and headers out of the output. The host
|
|
122
|
+
owns component activation and execution permissions.
|
|
123
|
+
|
|
124
|
+
Use `agent-plugins --help` or `agent-plugins COMMAND --help` for CLI syntax.
|
|
125
|
+
Success writes to stdout. Expected operational failures return status `1`
|
|
126
|
+
with a diagnostic on stderr. Argument errors return status `2`.
|
|
127
|
+
|
|
128
|
+
For project packaging, build planning, or wheel attachment, read the
|
|
129
|
+
`package-agent-plugin` skill.
|
|
130
|
+
|
|
131
|
+
Use the [documentation index](https://peter-gy.github.io/agent-plugins/llms.txt)
|
|
132
|
+
for additional API and integration guidance.
|
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: package-agent-plugin
|
|
3
|
+
description: Package version-matched agent briefings with a Python project. Use when authoring core skills and references, exposing guidance through Python module help, configuring a build adapter, attaching a plugin to a wheel, or verifying installed handoffs. For consuming an installed package's instructions, use agent-plugins.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Package an Agent Plugin
|
|
7
|
+
|
|
8
|
+
Package instructions beside the Python code they describe so the library and
|
|
9
|
+
its Agent Plugin share one release. Author one compact core skill that works
|
|
10
|
+
from a CLI briefing, Python module help, or a directly loaded skill file.
|
|
11
|
+
|
|
12
|
+
## Design the briefing
|
|
13
|
+
|
|
14
|
+
Start from a fresh agent's task: what the package enables, which host or extras
|
|
15
|
+
it requires, the first complete action, how to verify success, and where to
|
|
16
|
+
read more. Include every import and binding needed by the first example.
|
|
17
|
+
|
|
18
|
+
Keep package concepts, workflow choices, essential invariants, and verification
|
|
19
|
+
in the core skill. Put substantial setup variants and specialized workflows in
|
|
20
|
+
linked references, with a condition explaining when each is needed. Let the
|
|
21
|
+
generated briefing supply installation identity and resource-access guidance.
|
|
22
|
+
Rereading the current skill should not be a prerequisite for following it.
|
|
23
|
+
|
|
24
|
+
Read [briefing design](references/briefings.md) when authoring the skill or
|
|
25
|
+
adding a Python help entrypoint. It covers ownership, a reusable skill shape,
|
|
26
|
+
documentation links, and fresh-agent acceptance scenarios.
|
|
27
|
+
|
|
28
|
+
## Build the smallest complete integration
|
|
29
|
+
|
|
30
|
+
For a single-package project, keep the plugin at the project root:
|
|
31
|
+
|
|
32
|
+
```text
|
|
33
|
+
my-package/
|
|
34
|
+
|-- plugin.json
|
|
35
|
+
|-- pyproject.toml
|
|
36
|
+
|-- skills/
|
|
37
|
+
| `-- my-package/
|
|
38
|
+
| `-- SKILL.md
|
|
39
|
+
`-- src/
|
|
40
|
+
`-- my_package/
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
Create `plugin.json`:
|
|
44
|
+
|
|
45
|
+
```json
|
|
46
|
+
{
|
|
47
|
+
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
|
|
48
|
+
"name": "my-package",
|
|
49
|
+
"description": "Use My Package from Python."
|
|
50
|
+
}
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
Name the core skill `my-package` to match `[project].name`. This lets
|
|
54
|
+
`ap.read("my-package")` select it by default. A task-specific skill can use
|
|
55
|
+
another name and be selected explicitly.
|
|
56
|
+
|
|
57
|
+
Create `skills/my-package/SKILL.md` with `name` and a discriminating
|
|
58
|
+
`description` in YAML frontmatter, followed by the package's shortest complete
|
|
59
|
+
workflow. Use real public APIs and expected results from the project.
|
|
60
|
+
|
|
61
|
+
Configure an existing uv_build project in `pyproject.toml`:
|
|
62
|
+
|
|
63
|
+
```toml
|
|
64
|
+
[build-system]
|
|
65
|
+
requires = ["agent-plugins", "uv_build"]
|
|
66
|
+
build-backend = "agent_plugins.build.uv_build"
|
|
67
|
+
|
|
68
|
+
[tool.agent-plugins]
|
|
69
|
+
root = "."
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
Preview the exact selection, then build:
|
|
73
|
+
|
|
74
|
+
```console
|
|
75
|
+
uv run --with agent-plugins agent-plugins plan .
|
|
76
|
+
uv build
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
The plan must contain `plugin.json`, every intended file under `skills/`, and
|
|
80
|
+
`mcp.json` when configured. Add root-relative client extension files or other
|
|
81
|
+
plugin resources through `[tool.agent-plugins].include`.
|
|
82
|
+
|
|
83
|
+
## Verify the installed handoff
|
|
84
|
+
|
|
85
|
+
Read the wheel in an isolated environment, using the Python distribution name
|
|
86
|
+
from `[project].name`:
|
|
87
|
+
|
|
88
|
+
```console
|
|
89
|
+
uvx --with dist/my_package-0.1.0-py3-none-any.whl \
|
|
90
|
+
agent-plugins read my-package
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
Confirm the reported distribution version, plugin metadata, bounded inventory,
|
|
94
|
+
and skill instructions. Use
|
|
95
|
+
[artifact verification](references/verify-artifacts.md) for exhaustive inventory
|
|
96
|
+
comparison. Put the public bootstrap in the package README:
|
|
97
|
+
|
|
98
|
+
```console
|
|
99
|
+
uvx --with my-package agent-plugins read my-package
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
Keep `agent-plugins` in `[build-system].requires` for packaging. Add it to
|
|
103
|
+
`[project].dependencies` when installed Python code calls `agent_plugins`
|
|
104
|
+
directly at runtime, with a lower bound that includes the APIs used.
|
|
105
|
+
|
|
106
|
+
## Expose the same briefing in Python
|
|
107
|
+
|
|
108
|
+
Use `ap.read()` in the package's agent module to deliver its core skill through
|
|
109
|
+
standard Python help:
|
|
110
|
+
|
|
111
|
+
```python
|
|
112
|
+
# src/my_package/agent.py
|
|
113
|
+
import agent_plugins as _ap
|
|
114
|
+
|
|
115
|
+
__doc__ = _ap.read("my-package")
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
The caller runs `import my_package.agent` followed by `help(my_package.agent)`.
|
|
119
|
+
`help()` prints the briefing and returns `None`. Use `print(ap.read(...))` when
|
|
120
|
+
the host needs explicit text output. Pass `skill="task-name"` for a differently
|
|
121
|
+
named core skill. Host capability registration remains the host's contract.
|
|
122
|
+
|
|
123
|
+
Keep ordinary package imports independent of this optional help module. Give
|
|
124
|
+
the agent module a small introspection surface and inspect its actual
|
|
125
|
+
`help()` output, since exported classes can add extensive API documentation.
|
|
126
|
+
Keep detailed signatures on the corresponding API objects. See
|
|
127
|
+
[briefing design](references/briefings.md#python-module-help) for runtime access
|
|
128
|
+
and documentation ownership.
|
|
129
|
+
|
|
130
|
+
Verify both the CLI and Python briefing from the installed wheel. A successful
|
|
131
|
+
read establishes access to instructions. Exercise the first workflow in its
|
|
132
|
+
required host to establish runtime readiness and a verified result.
|
|
133
|
+
|
|
134
|
+
## Choose a different build path
|
|
135
|
+
|
|
136
|
+
- For Hatchling, monorepo roots, include patterns, custom backends, or an
|
|
137
|
+
externally built wheel, read
|
|
138
|
+
[build variants](references/build-variants.md).
|
|
139
|
+
- For wheel, source distribution, editable, document, and Agent Skills checks,
|
|
140
|
+
read [artifact verification](references/verify-artifacts.md).
|
|
141
|
+
- For `mcp.json`, read the
|
|
142
|
+
[MCP integration guide](https://peter-gy.github.io/agent-plugins/integrations/mcp-servers).
|
|
143
|
+
- For reverse-domain client directories, read the
|
|
144
|
+
[client extension guide](https://peter-gy.github.io/agent-plugins/integrations/client-extensions).
|
|
145
|
+
|
|
146
|
+
Use the `agent-plugins` skill when the repository work is complete and the task
|
|
147
|
+
becomes consuming an installed package's instructions or resources.
|
|
148
|
+
|
|
149
|
+
Use the [documentation index](https://peter-gy.github.io/agent-plugins/llms.txt)
|
|
150
|
+
for additional packaging and integration guidance.
|
|
@@ -0,0 +1,143 @@
|
|
|
1
|
+
# Design package briefings
|
|
2
|
+
|
|
3
|
+
An independently loaded skill must give a fresh agent enough information to
|
|
4
|
+
choose a workflow, execute its first action, verify the result, and find the
|
|
5
|
+
next relevant resource. CLI and Python help should present the same authored
|
|
6
|
+
core, with environment context supplied by `agent-plugins`.
|
|
7
|
+
|
|
8
|
+
## Assign each surface an owner
|
|
9
|
+
|
|
10
|
+
| Surface | Content |
|
|
11
|
+
| --- | --- |
|
|
12
|
+
| Package README | Bootstrap command and the already-installed Python route |
|
|
13
|
+
| Generated briefing | Distribution version, interpreter, resource location, documentation links, and selected skill source |
|
|
14
|
+
| Core skill | Applicability, package concepts, prerequisites, workflow, and verification |
|
|
15
|
+
| Skill references | Conditional setup, specialized workflows, and detailed recovery |
|
|
16
|
+
| API docstrings | Signatures, inputs, returns, side effects, and operation semantics |
|
|
17
|
+
| Project instructions | Repository or authored-project conventions |
|
|
18
|
+
| Published docs | Broader guides, examples, and reference pages |
|
|
19
|
+
|
|
20
|
+
Package-specific host requirements and optional extras belong with the
|
|
21
|
+
workflow that needs them. The execution host or project manager owns dependency
|
|
22
|
+
installation and version policy. An importable agent module already has its
|
|
23
|
+
base package installed, so its help should route to additional setup only when
|
|
24
|
+
the selected operation requires it.
|
|
25
|
+
|
|
26
|
+
Distinguish instructions being available, a package being installed in the
|
|
27
|
+
execution environment, and the required runtime being connected and ready.
|
|
28
|
+
Describe the check that establishes each relevant transition.
|
|
29
|
+
|
|
30
|
+
## Shape the core skill
|
|
31
|
+
|
|
32
|
+
Use this outline when the package has several workflows. Collapse sections
|
|
33
|
+
when a smaller skill can convey the same contract:
|
|
34
|
+
|
|
35
|
+
```text
|
|
36
|
+
Frontmatter: name and concrete activation conditions
|
|
37
|
+
Purpose: outcome, essential objects, and their ownership
|
|
38
|
+
Choose: task-to-workflow routes and their prerequisites
|
|
39
|
+
Start: smallest complete example, including imports and bindings
|
|
40
|
+
Verify: observable success and the main misleading success signal
|
|
41
|
+
Continue: conditional references, recovery, and published documentation
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
Prefer a compact core, often around 100–200 lines. Length follows the complete
|
|
45
|
+
workflow rather than a quota. Move substantial conditional material into
|
|
46
|
+
focused `references/` files and link it at the decision point where it is
|
|
47
|
+
needed. Keep essential correctness constraints beside the example they govern.
|
|
48
|
+
|
|
49
|
+
Write the core for direct loading as well as generated briefings. A first
|
|
50
|
+
example must not depend on a variable created by module help, a prior task, or
|
|
51
|
+
another execution call. Repeat short imports where they make an example
|
|
52
|
+
independent. For hosts that discard scratch bindings, explain how to reacquire
|
|
53
|
+
handles and which identities or results must survive between calls.
|
|
54
|
+
|
|
55
|
+
Do not require the agent to read the skill it is already following. Reuse
|
|
56
|
+
loaded instructions for the same environment and installation. Route back to
|
|
57
|
+
discovery when the environment or installation changes or an API mismatch
|
|
58
|
+
requires checking the source of the instructions.
|
|
59
|
+
|
|
60
|
+
Use relative links beneath the skill root and resolve packaged resources with
|
|
61
|
+
`Skill.file()`. Absolute paths in a briefing describe its owning installation.
|
|
62
|
+
They can be inaccessible from another host or disappear with a disposable
|
|
63
|
+
environment. Provide a Python resource-access route for remote execution.
|
|
64
|
+
|
|
65
|
+
Keep additional task skills independently selectable when their activation
|
|
66
|
+
conditions differ. A general package capability should route to a specialized
|
|
67
|
+
workflow only when the user's request calls for it.
|
|
68
|
+
|
|
69
|
+
## Python module help
|
|
70
|
+
|
|
71
|
+
The packaging skill's minimal `agent.py` example sets `__doc__` from
|
|
72
|
+
`ap.read("my-package")`. It reads the installed core when that module is
|
|
73
|
+
imported. Keep it out of the package's ordinary import path. Restart the host
|
|
74
|
+
after replacing an already imported installation.
|
|
75
|
+
|
|
76
|
+
`ap.read()` returns one Markdown string. Omitted `skill` uses the distribution
|
|
77
|
+
argument exactly. An explicit `skill` selects a structural directory name.
|
|
78
|
+
The CLI uses the same renderer but includes all skills unless `--skill` is
|
|
79
|
+
provided. Both entrypoints preserve the selected instruction source.
|
|
80
|
+
|
|
81
|
+
If callers need resource handles, expose small accessors over the public API:
|
|
82
|
+
|
|
83
|
+
```python
|
|
84
|
+
import agent_plugins as _ap
|
|
85
|
+
|
|
86
|
+
|
|
87
|
+
def agent_plugin() -> _ap.Plugin:
|
|
88
|
+
return _ap.locate("my-package")
|
|
89
|
+
|
|
90
|
+
|
|
91
|
+
def agent_skill() -> _ap.Skill:
|
|
92
|
+
return agent_plugin().skill("my-package")
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
Callers can then read a linked file inside the execution host with
|
|
96
|
+
`agent_skill().file("references/setup.md").read_text(encoding="utf-8")`, when
|
|
97
|
+
that resource is packaged. Add accessors when consumers need them, and retain
|
|
98
|
+
host adapters that implement package-specific operations.
|
|
99
|
+
|
|
100
|
+
Inspect actual `help(module)` output. Python can append documentation for
|
|
101
|
+
exported functions and classes, even when the module docstring is short.
|
|
102
|
+
Keep initial help focused and route detailed introspection to the relevant
|
|
103
|
+
objects or submodules. Check that help reads instructions without connecting
|
|
104
|
+
services, mounting components, or performing the example's operations.
|
|
105
|
+
|
|
106
|
+
## Publish documentation links
|
|
107
|
+
|
|
108
|
+
Declare documentation URLs in Python package metadata:
|
|
109
|
+
|
|
110
|
+
```toml
|
|
111
|
+
[project.urls]
|
|
112
|
+
Documentation = "https://example.org/my-package/"
|
|
113
|
+
"Documentation Index" = "https://example.org/my-package/llms.txt"
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
`agent-plugins` includes these two labels in generated briefings. The
|
|
117
|
+
`Documentation Index` label is a package-authoring convention. Use the actual
|
|
118
|
+
index URL when one is published, and verify its linked destinations as part of
|
|
119
|
+
the documentation build. A new manifest property is unnecessary.
|
|
120
|
+
|
|
121
|
+
Keep a short documentation link in the core skill too, so it works when loaded
|
|
122
|
+
independently of Python metadata. Load specific linked pages as needed. Check
|
|
123
|
+
online APIs against the installed version. A development checkout describes
|
|
124
|
+
that checkout and may differ from a released installation.
|
|
125
|
+
|
|
126
|
+
## Verify the handoff
|
|
127
|
+
|
|
128
|
+
Exercise the entrypoints an agent will actually use:
|
|
129
|
+
|
|
130
|
+
1. From a README, run the isolated CLI bootstrap and follow one linked resource.
|
|
131
|
+
Confirm the output distinguishes that installation from the execution host.
|
|
132
|
+
2. In a project with an existing installation, read through its interpreter and
|
|
133
|
+
verify the reported version and resource origin.
|
|
134
|
+
3. Through the intended Python host, read module help and retrieve a reference
|
|
135
|
+
using Python when direct filesystem access is unavailable.
|
|
136
|
+
4. Load `SKILL.md` directly and follow its first example using fresh bindings.
|
|
137
|
+
5. Continue a related task in the same environment and verify that the routing
|
|
138
|
+
advances to relevant work instead of requiring repeated discovery.
|
|
139
|
+
|
|
140
|
+
Test required runtime readiness and the example's expected result separately
|
|
141
|
+
from successful imports and resource reads. Keep failures actionable: an absent
|
|
142
|
+
package requires installation, an unknown skill requires selecting an available
|
|
143
|
+
name, and an unavailable runtime requires its host's connection workflow.
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
# Build variants
|
|
2
|
+
|
|
3
|
+
## Hatchling
|
|
4
|
+
|
|
5
|
+
Wrap an existing Hatchling project with the bundled adapter:
|
|
6
|
+
|
|
7
|
+
```toml
|
|
8
|
+
[build-system]
|
|
9
|
+
requires = ["agent-plugins", "hatchling"]
|
|
10
|
+
build-backend = "agent_plugins.build.hatchling"
|
|
11
|
+
|
|
12
|
+
[tool.agent-plugins]
|
|
13
|
+
root = "."
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
The adapter preserves the delegate's wheel, source distribution, and editable
|
|
17
|
+
behavior while adding the selected Agent Plugin and installation marker.
|
|
18
|
+
|
|
19
|
+
## Monorepo roots
|
|
20
|
+
|
|
21
|
+
Resolve `root` relative to the `pyproject.toml` that owns the build. For this
|
|
22
|
+
layout, the Python package points back to the repository plugin root:
|
|
23
|
+
|
|
24
|
+
```text
|
|
25
|
+
repository/
|
|
26
|
+
|-- plugin.json
|
|
27
|
+
|-- skills/
|
|
28
|
+
`-- packages/
|
|
29
|
+
`-- python/
|
|
30
|
+
`-- pyproject.toml
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
```toml
|
|
34
|
+
[tool.agent-plugins]
|
|
35
|
+
root = "../.."
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
## Additional selected files
|
|
39
|
+
|
|
40
|
+
The build always selects `plugin.json`, the complete `skills/` tree, and
|
|
41
|
+
`mcp.json` when present. Select other root-relative files explicitly:
|
|
42
|
+
|
|
43
|
+
```toml
|
|
44
|
+
[tool.agent-plugins]
|
|
45
|
+
root = "."
|
|
46
|
+
include = ["bin/**", "com.example.client/**"]
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
Every include pattern must remain inside the plugin root and match at least one
|
|
50
|
+
filesystem entry. A matched directory contributes its regular files.
|
|
51
|
+
|
|
52
|
+
## Prebuilt wheels
|
|
53
|
+
|
|
54
|
+
When another backend owns the wheel, attach the configured Agent Plugin after
|
|
55
|
+
that build:
|
|
56
|
+
|
|
57
|
+
```console
|
|
58
|
+
agent-plugins attach-wheel dist/my_package-0.1.0-py3-none-any.whl \
|
|
59
|
+
--project .
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
The command atomically replaces the input wheel after the complete attached
|
|
63
|
+
artifact succeeds. Use `--output-dir` to preserve the source wheel. The Python
|
|
64
|
+
API exposes the same operation:
|
|
65
|
+
|
|
66
|
+
```python
|
|
67
|
+
import agent_plugins as ap
|
|
68
|
+
|
|
69
|
+
result = ap.attach_wheel(
|
|
70
|
+
"dist/my_package-0.1.0-py3-none-any.whl",
|
|
71
|
+
project=".",
|
|
72
|
+
)
|
|
73
|
+
print(result.output)
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
A custom delegate must expose wheel, source distribution, and editable build
|
|
77
|
+
hooks together with their corresponding `get_requires_for_build_*` hooks.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
# Verify package artifacts
|
|
2
|
+
|
|
3
|
+
Treat source and installed inspection as two views of the same selected plugin:
|
|
4
|
+
|
|
5
|
+
```python
|
|
6
|
+
import agent_plugins as ap
|
|
7
|
+
|
|
8
|
+
source = ap.Plugin.from_project(".")
|
|
9
|
+
installed = ap.locate("my-package")
|
|
10
|
+
|
|
11
|
+
assert source.manifest.name == installed.manifest.name
|
|
12
|
+
assert [path.relative_to(source.path) for path in source.files] == [
|
|
13
|
+
path.relative_to(installed.path) for path in installed.files
|
|
14
|
+
]
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
Verify every release boundary:
|
|
18
|
+
|
|
19
|
+
1. Run `agent-plugins plan PROJECT` and inspect every selected path.
|
|
20
|
+
2. Build a wheel and source distribution through the configured adapter, or
|
|
21
|
+
attach the plugin to the externally built wheel.
|
|
22
|
+
3. Rebuild a wheel from the source distribution.
|
|
23
|
+
4. Install the direct and rebuilt wheels in clean environments.
|
|
24
|
+
5. Run `agent-plugins read my-package` and `ap.read("my-package")` against both
|
|
25
|
+
installed wheels. Pass an explicit skill name when it differs from the
|
|
26
|
+
distribution name. Compare the Python briefing with CLI `--skill` output.
|
|
27
|
+
6. Install the project as editable and confirm `locate()` resolves the authored
|
|
28
|
+
plugin root.
|
|
29
|
+
7. Compare source and installed file inventories and bytes.
|
|
30
|
+
8. Access `manifest.name`, every `skill.source`, and `mcp.servers` when present
|
|
31
|
+
to execute supported document validation.
|
|
32
|
+
9. Confirm each `skill.file("SKILL.md")` and referenced resource is selected.
|
|
33
|
+
10. Run an Agent Skills validator against every authored skill directory.
|
|
34
|
+
|
|
35
|
+
Let `AgentPluginError` fail missing configuration, unusable paths, or discovery.
|
|
36
|
+
Let `ValidationError` fail invalid manifest, MCP, or skill documents. Artifact
|
|
37
|
+
verification should exercise the CLI through the installed console script as
|
|
38
|
+
well as the Python API.
|
|
39
|
+
|
|
40
|
+
When the package exposes module help, inspect its captured output and follow
|
|
41
|
+
the [briefing handoff scenarios](briefings.md#verify-the-handoff). Confirm that
|
|
42
|
+
each referenced setup or workflow file is available in the installed inventory.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
Metadata-Version: 2.4
|
|
2
2
|
Name: agent-plugins
|
|
3
|
-
Version: 0.2.
|
|
3
|
+
Version: 0.2.4
|
|
4
4
|
Summary: Ship Agent Plugins with Python packages and inspect their installed files
|
|
5
5
|
Author: Péter Ferenc Gyarmati
|
|
6
6
|
Author-email: Péter Ferenc Gyarmati <dev.petergy@gmail.com>
|
|
@@ -15,6 +15,7 @@ Classifier: Typing :: Typed
|
|
|
15
15
|
Requires-Dist: tomli>=1.0.3 ; python_full_version < '3.11'
|
|
16
16
|
Requires-Python: >=3.10, <3.15
|
|
17
17
|
Project-URL: Documentation, https://peter-gy.github.io/agent-plugins/
|
|
18
|
+
Project-URL: Documentation Index, https://peter-gy.github.io/agent-plugins/llms.txt
|
|
18
19
|
Project-URL: Issues, https://github.com/peter-gy/agent-plugins/issues
|
|
19
20
|
Project-URL: Source, https://github.com/peter-gy/agent-plugins
|
|
20
21
|
Description-Content-Type: text/markdown
|
|
@@ -48,6 +49,19 @@ Description-Content-Type: text/markdown
|
|
|
48
49
|
|
|
49
50
|
The [Agent Plugins format](https://agent-plugins.org/) defines the directory: a manifest, [Agent Skills](https://agentskills.io/specification) for instructions and resources, [Model Context Protocol (MCP)](https://modelcontextprotocol.io/specification) server configuration for tools, and client extensions. This library packages that directory and makes it discoverable through Python metadata. Agent clients choose which components to activate.
|
|
50
51
|
|
|
52
|
+
## Read the bundled guidance
|
|
53
|
+
|
|
54
|
+
Run `agent-plugins` without arguments to read its own installed plugin:
|
|
55
|
+
|
|
56
|
+
```console
|
|
57
|
+
uvx agent-plugins
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
The output contains two version-matched skills. `agent-plugins` explains how to
|
|
61
|
+
read instructions from Python packages that already ship an Agent Plugin.
|
|
62
|
+
`package-agent-plugin` explains how to add Agent Plugin packaging to a Python
|
|
63
|
+
project.
|
|
64
|
+
|
|
51
65
|
## Package your plugin
|
|
52
66
|
|
|
53
67
|
Keep `plugin.json` and `skills/` beside your code. For a project using the [uv build backend](https://docs.astral.sh/uv/concepts/build-backend/), configure `pyproject.toml`:
|
|
@@ -77,22 +91,30 @@ Attachment updates the wheel in place. Pass `--output-dir` to preserve the input
|
|
|
77
91
|
|
|
78
92
|
## Inspect an installed plugin
|
|
79
93
|
|
|
80
|
-
|
|
94
|
+
Load the complete version-matched guidance shipped by a package:
|
|
81
95
|
|
|
82
96
|
```console
|
|
83
|
-
|
|
97
|
+
uvx --with my-package agent-plugins read my-package
|
|
84
98
|
```
|
|
85
99
|
|
|
100
|
+
The first `my-package` tells uv which distribution to install. The second
|
|
101
|
+
identifies the installed Agent Plugin to read.
|
|
102
|
+
|
|
103
|
+
Use the Python API when the package is already installed in the current
|
|
104
|
+
environment:
|
|
105
|
+
|
|
86
106
|
```python
|
|
87
107
|
import agent_plugins as ap
|
|
88
108
|
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
print(skill.source)
|
|
93
|
-
print(skill.file("SKILL.md"))
|
|
109
|
+
print(ap.read("agent-plugins"))
|
|
110
|
+
print(ap.read("agent-plugins", skill="package-agent-plugin"))
|
|
94
111
|
```
|
|
95
112
|
|
|
113
|
+
`read()` returns a briefing for the same-name skill by default. Pass `skill=`
|
|
114
|
+
for another workflow. The CLI reads all packaged skills unless `--skill` is
|
|
115
|
+
provided. `uvx` uses an isolated tool environment, so read through the target
|
|
116
|
+
interpreter when working with an existing installation.
|
|
117
|
+
|
|
96
118
|
Pass your library's distribution name to `locate()` to inspect its plugin. Use [`Plugin.from_project()`](https://peter-gy.github.io/agent-plugins/guide/inspect-project) to inspect the selected source files before building.
|
|
97
119
|
|
|
98
120
|
## Documentation
|