feat(skills): add optional payments skills (Stripe Link, MPP, Projects) - #31343
Merged
Conversation
Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill>
alt-glitch
added
type/feature
…n other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars.
Comment on lines
+28
to
+29
| | Tool | When | Setup | | ||
| |---|---|---| |
There was a problem hiding this comment.
Maybe add the link cli as the client when either a) the user already has it set up b) the MPP method="stripe"
Comment on lines
+34
to
+36
| - A Link account at https://app.link.com (US only) | ||
| - At least one payment method added at https://app.link.com/wallet | ||
| - The Link mobile/web app open to approve spend requests |
There was a problem hiding this comment.
these can be configured during first run (they don't need to be true before Hermes attempts to pay)
- mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages
teknium1
enabled auto-merge (squash)
June 15, 2026 17:55
teknium1
disabled auto-merge
June 15, 2026 22:28
zapabob
pushed a commit
to zapabob/hermes-agent
that referenced
this pull request
Jun 15, 2026
…s) (NousResearch#31343) * feat(skills): add optional payments skills (Stripe Link, MPP, Projects) Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill> * chore(skills/payments): drop router skill — skills shouldn't depend on other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars. * feat(skills/payments): fold in danhill-stripe review feedback - mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages (cherry picked from commit 5bfed0f)
sakshamzip2-sys
added a commit
to sakshamzip2-sys/hermes-agent
that referenced
this pull request
Jun 15, 2026
Brings main fully current with NousResearch upstream (0 behind). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
rdnot
added a commit
to rdnot/hermes-agent-medical-research
that referenced
this pull request
Jun 15, 2026
…kfile-fix.yml) Upstream advanced from 5bfed0f (Jun 15) to 3e7e9b2 (Jun 16). Major upstream changes since last merge: - feat(skills): add optional payments skills (Stripe Link, MPP, Projects) NousResearch#31343 - feat(delegation): async background subagents via delegate_task(background=true) NousResearch#40946 - fix(desktop): read HERMES_HOME from Windows registry when env is stale NousResearch#46772 - fix(desktop): let explicit model switches escape broken config providers NousResearch#46796 - fix(dump): report effective terminal backend in hermes debug - fix(inventory): deduplicate models between user-defined and aggregator providers - fix(doctor): recognize nvidia as vendor-slug-accepting provider - fix(discord): cap slash commands at Discord's 100-command limit - fix(teams): package Microsoft Teams SDK as an installable extra NousResearch#46764 - fix(dashboard): scope chat sidebar model card to selected profile NousResearch#46665 - fix(deps): declare websockets as core dep + relax dev setuptools pin NousResearch#46744 - fix(desktop): pin @assistant-ui/store so the cluster shares one tap - fix(install): make npm install -g packages reachable on PATH - feat(honcho-setup): replace deployment-shape prompt with gateway-gated identity tree - refactor(honcho): canonicalize identity-mapping on pinUserPeer, migrate legacy key - mattermost: preserve thread-local delivery hygiene - ci: rip out nix ci for now - ...plus desktop Electron changes, web UI updates, website docs, honcho docs Fork customizations preserved (all 22 verified intact): - run_agent.py: max_iterations: int = 200 - agent/conversation_loop.py: _force_final_threshold, _build_tools_summary, _current_turn_tool_calls, _pending_tool_summary, tool_summary flow - agent/turn_finalizer.py: 'tool_summary' key in result dict - tools/web_tools.py: tiered fetcher (curl_cffi→scrapling→httpx), MAX_OUTPUT_SIZE=10000, _get_extract_backend, max_result_size_chars=500_000, LLM-summarization disabled, NCBI/PubMed/PMC hardening - tools/budget_config.py: 400_000 / 500_000 - gateway/run.py: HERMES_MAX_ITERATIONS, "200" - hermes_cli/config.py: max_turns: 200 - cli.py: result.get('tool_summary') display - gateway/config.py: Platform.LINE = "line" - gateway/authz_mixin.py: Platform.LINE: "LINE_ALLOWED_GROUPS" - plugins/platforms/line/adapter.py: reply_only_mention, build_source Conflict resolution: - .github/workflows/nix-lockfile-fix.yml: removed by upstream. Was fork-only (disabled with if:false, requires APP_ID/APP_PRIVATE_KEY secrets the fork does not have). Upstream deletion is correct. Backup branch: backup-main-pre-merge-20260616-063126
This was referenced Jun 16, 2026
alanbratu
pushed a commit
to alanbratu/hermes-agent
that referenced
this pull request
Jun 17, 2026
…s) (NousResearch#31343) * feat(skills): add optional payments skills (Stripe Link, MPP, Projects) Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill> * chore(skills/payments): drop router skill — skills shouldn't depend on other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars. * feat(skills/payments): fold in danhill-stripe review feedback - mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages
zmlgit
pushed a commit
to zmlgit/hermes-agent
that referenced
this pull request
Jun 17, 2026
…s) (NousResearch#31343) * feat(skills): add optional payments skills (Stripe Link, MPP, Projects) Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill> * chore(skills/payments): drop router skill — skills shouldn't depend on other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars. * feat(skills/payments): fold in danhill-stripe review feedback - mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages
al3xar
pushed a commit
to al3xar/hermes-agent
that referenced
this pull request
Jun 17, 2026
…s) (NousResearch#31343) * feat(skills): add optional payments skills (Stripe Link, MPP, Projects) Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill> * chore(skills/payments): drop router skill — skills shouldn't depend on other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars. * feat(skills/payments): fold in danhill-stripe review feedback - mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages
T02200059
pushed a commit
to T02200059/hermes-agent
that referenced
this pull request
Jun 18, 2026
…s) (NousResearch#31343) * feat(skills): add optional payments skills (Stripe Link, MPP, Projects) Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill> * chore(skills/payments): drop router skill — skills shouldn't depend on other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars. * feat(skills/payments): fold in danhill-stripe review feedback - mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages
1 task
waefrebeorn
pushed a commit
to waefrebeorn/slermes
that referenced
this pull request
Jul 2, 2026
…s) (NousResearch#31343) * feat(skills): add optional payments skills (Stripe Link, MPP, Projects) Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill> * chore(skills/payments): drop router skill — skills shouldn't depend on other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars. * feat(skills/payments): fold in danhill-stripe review feedback - mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages
Methodician
added a commit
to Methodician/hermes-agent
that referenced
this pull request
Jul 4, 2026
…s) (NousResearch#31343) * feat(skills): add optional payments skills (Stripe Link, MPP, Projects) Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill> * chore(skills/payments): drop router skill — skills shouldn't depend on other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars. * feat(skills/payments): fold in danhill-stripe review feedback - mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages
habarmc1223-sudo
pushed a commit
to habarmc1223-sudo/hermes-agent-fluxmem
that referenced
this pull request
Jul 8, 2026
…s) (NousResearch#31343) * feat(skills): add optional payments skills (Stripe Link, MPP, Projects) Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill> * chore(skills/payments): drop router skill — skills shouldn't depend on other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars. * feat(skills/payments): fold in danhill-stripe review feedback - mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages
santhreal
pushed a commit
to santhreal/hermes-agent
that referenced
this pull request
Jul 13, 2026
…s) (NousResearch#31343) * feat(skills): add optional payments skills (Stripe Link, MPP, Projects) Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill> * chore(skills/payments): drop router skill — skills shouldn't depend on other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars. * feat(skills/payments): fold in danhill-stripe review feedback - mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages
Closed
Gravezzz
pushed a commit
to Gravezzz/hermes-agent
that referenced
this pull request
Jul 21, 2026
…s) (NousResearch#31343) * feat(skills): add optional payments skills (Stripe Link, MPP, Projects) Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill> * chore(skills/payments): drop router skill — skills shouldn't depend on other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars. * feat(skills/payments): fold in danhill-stripe review feedback - mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages
leewenjie
pushed a commit
to leewenjie/hermes-agent
that referenced
this pull request
Aug 7, 2026
…s) (NousResearch#31343) * feat(skills): add optional payments skills (Stripe Link, MPP, Projects) Adds four optional skills under optional-skills/payments/ wrapping the Stripe Link CLI, the Machine Payments Protocol (MPP) clients, and the Stripe Projects CLI plugin. Plus a router skill (payments) that picks between them based on user intent. All four are gated [linux, macos] — Stripe's Link CLI does not yet support Windows. The other CLIs (mppx, stripe projects) are cross-platform on paper but the payments cluster moves as a unit until Link CLI gains Windows support. Skills: - stripe-link-cli - one-time virtual cards + Shared Payment Tokens - mpp-agent - HTTP 402 payments via mppx/Tempo/Privy/AgentCash - stripe-projects - provision SaaS services + credential sync - payments - router/index skill for the cluster Hard invariants encoded in every skill: - Card PANs/wallet keys never enter agent transcripts, logs, or memory - Spend approvals are not self-bypassable (Link app / wallet UI / CLI prompt) - Final totals confirmed with user before any --request-approval call - Credential output files cleaned up after one-time use Zero core touches. Skills install via: hermes skills install official/payments/<skill> * chore(skills/payments): drop router skill — skills shouldn't depend on other skills Removed optional-skills/payments/payments/ — the router skill that existed to hand off between stripe-link-cli, mpp-agent, and stripe-projects. Per project convention: skills should be independently loadable; a router is a footgun because (a) it assumes the loader will follow its recommendation rather than just loading what the user asked for, and (b) it duplicates the trigger logic that already lives in each sub-skill's '## When to Use' section. The three remaining skills declare their own triggers and routing hints. The optional-skills catalog still groups them under '## payments', which is the appropriate place for cluster-level discoverability. Also drops 'payments' from each remaining skill's 'related_skills' list and removes the corresponding entries from the docs catalog + sidebars. * feat(skills/payments): fold in danhill-stripe review feedback - mpp-agent: add link-cli as a client option (when Link is already set up, or the 402 challenge advertises method="stripe") - stripe-link-cli: reframe Link account / payment method / approval app as first-run setup, not hard preconditions (CLI configures them on first run) - regenerate the two affected optional-skills docs pages
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Hermes can now buy things, pay HTTP 402 APIs, and provision SaaS — via three optional skills wrapping Stripe Link, MPP, and Stripe Projects. Zero core changes; no new model tools; no new env vars.
This is Phase 1 of the Stripe Link / MPP / Projects integration cluster. Phase 2 (MCP server registration helper) and Phase 3 (check_fn-gated plugin tools) will follow once we've validated the skills-only path end-to-end.
Skills added
stripe-link-cliofficial/payments/stripe-link-cli@stripe/link-cli— one-time virtual cards + Shared Payment Tokensmpp-agentofficial/payments/mpp-agentmppx/ Tempo Wallet / Privy / AgentCash — HTTP 402 client flowsstripe-projectsofficial/payments/stripe-projectsstripe projectsCLI plugin — provision SaaS + credential syncInstall via:
Each skill is independently loadable and declares its own triggers in
## When to Use. The optional-skills catalog groups them under## paymentsfor cluster-level discoverability.Platform gating
All three skills are gated
platforms: [linux, macos]. Per the team meeting:@stripe/link-clidoes not currently work on Windows. The other CLIs (mppx,stripe projects) are nominally cross-platform, but the payments cluster moves as a unit until the Link CLI gains Windows support. Documented in the PR body so we can revisit later without trawling git log.Hard invariants encoded in every skill
link-cli ... --output-file /tmp/...jsonwith0600perms and explicitly tell the agent not tocat/read_filethe credential file.stripe projectsconfirmation prompts all sit between the agent and any real spend.--request-approvalcall. Amounts are in cents; misplaced decimals are an explicit pitfall.Why skills, not new tools
Per the project's design framework (AGENTS.md, "Design Decision: New Tool vs CLI Command + Skill vs Plugin"): skills are the smallest-footprint approach when the capability is shell-driven. Every new core tool inflates the schema sent on every API call; payments capabilities only matter to a subset of users who've installed and authenticated the underlying CLIs. The check_fn-gated plugin tool path (Phase 3) is the right escalation if a structured tool surface turns out to be necessary — but we should validate the skills-only path first.
Files changed
Zero touches to
run_agent.py,cli.py,model_tools.py,gateway/, or any other core file.Validation
platforms: [linux, macos]on all 3Teknium (teknium1), Hermes Agent)OptionalSkillSource.search()returns all 3OptionalSkillSource.fetch()returns valid bundleswebsite/docs/user-guide/skills/optional/payments/payments-*.md)Slack thread context
External thread
stripe-link-nouswith Dan Hill, Rami, Jen Lee, et al. Phase 1 (this PR) ships the skills. Subsequent phases:hermes mcp add stripe-linkshortcut for the Link CLI's MCP server (small PR, no new tools).plugins/payments/stripe-link/) with two thincheck_fn-gated tools (payment_request_spend,payment_retrieve_card) for structured I/O, only if needed.Update — router skill dropped
Initial revision had a fourth
paymentsrouter skill that handed off between the others. Removed per project convention: skills should be independently loadable; a router skill is a footgun because it (a) assumes the loader will follow its recommendation, and (b) duplicates the trigger logic each sub-skill already declares in its own## When to Usesection.Infographic