Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/Hainrixz/agente-pagokitWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/hainrixz/agente-pagokit/add)<a href="https://agentmods.dev/commands/hainrixz/agente-pagokit/add"><img src="https://agentmods.dev/badge/commands/hainrixz/agente-pagokit/add/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/hainrixz/agente-pagokit/add"><img src="https://agentmods.dev/badge/commands/hainrixz/agente-pagokit/add.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00017 | $0.00563 |
| Opus 5 | $0.00009 | $0.00282 |
| Sonnet 5 | $0.00003 | $0.00113 |
| Haiku 4.5 | $0.00002 | $0.00056 |
Grade A, and why
add scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 6d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 47 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/pagokit:add
Real projects end up with more than one provider: a local one for domestic buyers and a
cross-border one for everyone else, or a card processor plus a wallet. PagoKit has assumed
this since v0.1 — every webhook route is namespaced /api/webhook/<provider> precisely so a
second one can land without a collision.
- Read
PAGOKIT_INTEGRATION.mdto learn what already exists: provider, routes, tables, env vars. If it is missing, detect the existing integration by globbing for webhook routes and payment SDK imports, and say you are working from inference. - If no provider was named, run
payment-advisorfor the new requirement — not the one already solved. Ask what the existing provider does not cover: a country, a rail, a billing mode. - Plan the addition, and be explicit about what is shared and what is not:
| Shared | Duplicated per provider |
|---|---|
payments, customers, webhook_events_processed tables (add a provider column if absent) |
The webhook route, namespaced |
lib/payments/errors.ts — extend the taxonomy |
The SDK client and its env vars |
| The checkout entry point, which now routes by provider | The provider-specific checkout call |
- Delegate to
integration-specialistwith an explicit instruction: do not modify the existing provider's files. Additive changes only.
Before you write anything
- Confirm the
providercolumn exists on the shared tables. Without it, a webhook from the new provider can update a payment created by the old one. - Confirm the new webhook route does not collide. The
existing-webhook-checkvalidator will block it if it does, but catching it here is cheaper than a blocked write. - Decide how the checkout picks a provider — buyer country, currency, or an explicit choice —
and write it down in
PAGOKIT_INTEGRATION.md. This is the part that gets forgotten and becomes unexplainable six months later.
Anti-patterns
- Do not refactor the existing integration "while you are in there". Adding a provider must not risk the one currently taking money.
- Do not share an idempotency key namespace across providers.
- Do not merge the two webhook handlers into one route with a switch. Separate routes are what let you disable one provider without touching the other.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 6d ago First seen · 47 lines · 17 tokens per session scan A 0b80afeae295
add is a command published in the GitHub repository Hainrixz/agente-pagokit (48 stars, last pushed 10d ago), licensed MIT. It adds 17 tokens to every session and 563 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-04.
Other commands, from other repositories
add-checkout
Create comprehensive shopping cart and checkout flow. Implement cart state management with Context API or Zustand. Create cart UI component with item list, quantity controls, and remove buttons. Calculate totals including subtotal, tax, shipping, and discounts. Add shipping address form with validation. Implement…
add-stripe
Integrate Stripe payment processing. Set up Stripe account and obtain API keys. Implement checkout flow using Stripe Checkout or Payment Element. Create payment API endpoints in Azure Functions or Express. Add webhook handling for payment events: succeeded, failed, refunded. Implement subscription billing with…
add-checkout
Create comprehensive shopping cart and checkout flow. Implement cart state management with Context API or Zustand. Create cart UI component with item list, quantity controls, and remove buttons. Calculate totals including subtotal, tax, shipping, and discounts. Add shipping address form with validation. Implement…
add-stripe
Integrate Stripe payment processing. Set up Stripe account and obtain API keys. Implement checkout flow using Stripe Checkout or Payment Element. Create payment API endpoints in Azure Functions or Express. Add webhook handling for payment events: succeeded, failed, refunded. Implement subscription billing with…
financial-model
Generate a 6-year ecommerce financial model without writing the narrative business plan.
research
Professional equity research analysis with institutional-grade formatting.