add-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 context.agent.runJson(...) plus context.broadcast.* for any payment flow that reaches the daemon.

Implementation Rules

• Do not add another large inline .command('<plugin>') block to src/cli.ts.
• Do not reimplement signing, nonce management, or policy logic in the plugin.
• If the plugin needs onchain payment, default to preview-first behavior and make live payment explicit with --broadcast.
• If the plugin only needs a quote plus an optional live payment path, prefer one buy-style command over a redundant separate price command.
• Keep plugin-specific error handling inside the plugin module when possible.
• If a remote API needs browser bootstrap, Cloudflare handling, or cookies, isolate that behind the plugin's transport/client layer instead of leaking it into the shared CLI.
• Pass only shared helpers through CliPluginContext; keep plugin business logic inside the plugin module.