add-plugin

name

add-plugin

description

Use this skill when the user wants to add, refactor, or generalize a `agentpay <plugin>` integration like Bitrefill. Follow the shared plugin registration path under `src/plugins`, keep plugin-specific API or scraping code under `src/lib/<plugin>` or `src/lib/<plugin>/`, reuse the existing Rust daemon signing and policy path through the shared CLI plugin context instead of reimplementing signing, and add focused CLI tests for the new plugin.

Add Plugin

Use this skill when the task is "add another plugin like Bitrefill" or "make plugin onboarding more reusable."

Ground Truth

• src/cli.ts is the main CLI entrypoint, but plugin-specific command trees should not be wired inline there.
• src/plugins/types.ts defines the shared CliPluginContext and the generic plugin registrar shape.
• src/plugins/index.ts is the registry for built-in plugins.
• src/plugins/bitrefill.ts is the reference implementation for a plugin that owns its own command tree.
• Plugin-specific HTTP or browser/bootstrap code belongs in src/lib/<plugin>.ts or src/lib/<plugin>/.
• Signing, policy checks, manual approval handling, and raw transaction broadcast plumbing stay on the existing AgentPay path exposed through CliPluginContext.

Default Architecture

1. Create src/plugins/<plugin>.ts.
2. Register the plugin in src/plugins/index.ts.
3. Keep plugin-local API normalization, transports, cookies, scraping, or challenge handling in src/lib/<plugin>*.
4. Keep src/cli.ts responsible only for assembling shared dependencies and calling registerBuiltinCliPlugins(...).
5. Reuse plus for any payment flow that reaches the daemon.