Running a small service business from lead to payment with owner-approved skills

Who built it

GitHub user hewi333, who built the skills at the NVIDIA x Stripe x Nous Research hackathon in June 2026. The public repo (MIT licensed) is a sanitized version with placeholder names and data, aimed at trades and services such as HVAC, cleaning, landscaping and consulting.

How it works

The repository is a set of 16 skills, each a SKILL.md file with YAML frontmatter and a Markdown body, following the Hermes skill format. They fall into groups: core operations (lead-to-payment, crm-lite, estimator-engine, stripe-payments), marketing, finance (CSV analysis and QuickBooks Online), communications through Microsoft 365, a trades-specific construction agent, production operations, and onboarding/reference skills.

The center of the system is a lead-to-payment orchestrator skill that chains the others. An inbound message by email, Telegram or a web form becomes a lead record in a small local SQLite CRM. The estimator skill drafts a price for the owner to review, the Stripe skill then creates a payment link for review, and only after the owner approves sending does the agent send it, update the CRM and give the owner a summary.

The author describes one rule running through every skill that touches money, customer messages or accounting: the agent drafts, the owner approves, then the agent executes. Eight of the 16 skills are marked as requiring owner approval, including the payment, QuickBooks, Mailchimp, Outlook and construction skills. In the repo's words, "Nothing risky happens without a yes."

That approval step is part of the skill design, not something Hermes adds on its own. The built-in Hermes approval system covers dangerous shell commands (with a configurable timeout and Telegram reply prompts). Sending an invoice or an email is not a shell command, so the 'ask the owner first' behavior has to be written into each skill's instructions and kept in the conversation with the owner.

Some skills run in the background. A voicemail monitor reads voicemail-transcript emails over IMAP on a schedule and turns them into leads, which feed the same approval-gated pipeline. Credentials for each service are supplied through environment variables rather than pasted into chat.

Lessons you can use

• Split a business process into small single-purpose skills (CRM, estimate, payment link) and add one orchestrator skill that chains them, so each piece can be tested on its own.
• Decide which actions are irreversible or customer-facing (charging, sending, booking) and write an explicit 'draft, show the owner, wait for yes' step into those skills.
• A local SQLite file is enough for a lightweight CRM the agent can read and update; you do not need a hosted CRM to start.
• Keep API keys in environment variables declared by the skill, not in prompts or chat history.
• Expect operational problems the author lists from the hackathon: model reasoning leaking into chat, card declines, scraping loops on single-page-app sites, and approvals timing out before the owner replied.
• Treat published business skills as reference designs. Adapt rates, prompts, edge cases and credentials to your own business before relying on them.

Try a smaller version

1. 1

   Set up the Telegram gateway with only your own user ID allowed, so you are the single approver the agent talks to.

2. 2

   Write one skill that turns a pasted inquiry into a lead row in a local SQLite file, and a second skill that drafts a quote from your own price list without sending anything.

3. 3

   Add an explicit approval step to the quote skill: it must post the draft to you and wait for a yes before taking any outbound action. Test it by saying no and confirming nothing was sent.

4. 4

   Only after that works, connect a payment provider in test mode and have the skill create (not send) a payment link for review, with the key declared under required_environment_variables.

5. 5

   If you add a scheduled lead check (for example from an inbox), attach the skill to a cron job and keep approvals.cron_mode at deny so unattended runs cannot take risky actions.

Caveats

• The real-business results come from the authors and are not verified; the public repo contains only sanitized placeholder data.
• The authors state the skills are reference quality and were not audited for compliance; payment, privacy and tax obligations (PCI, GDPR, local tax rules) remain the operator's responsibility.
• The repo does not say which models were used, so behavior and cost with your own model may differ.

Spotted something wrong or out of date? Tell us on X at @HermesWatcher↗ (opens in a new tab) and we will fix it.