| name | browser-form-workflows |
| description | Assist users through browser-based form workflows: account signup, onboarding, checkout-style forms, and multi-step web forms. |
| version | 1.0.0 |
| author | Hermes Agent |
| license | MIT |
| platforms | ["linux","macos","windows"] |
| metadata | {"hermes":{"tags":["browser","forms","signup","onboarding","web-automation"]}} |
Browser Form Workflows
Use this skill when helping a user complete a multi-step web form in the browser: account creation, onboarding, signup flows, profile setup, preference forms, or checkout-like forms.
Core workflow
- Open the target page and inspect the current step with the browser snapshot.
- Ask only for fields that are actually on screen. Do not gather a full dossier upfront.
- Enter low-risk data for the user when they provide it, then advance the form.
- Pause for sensitive steps: passwords, SMS/email verification codes, recovery phone/email, payment details, CAPTCHA, government IDs, or consent/legal confirmations.
- After every submit/next click, take a fresh snapshot before acting again. DOM refs are step-local and can become stale after navigation.
- Give short progress updates on long or fragile flows: “ввожу данные”, “перешёл к следующему шагу”, “нужен код/подтверждение”.
- Finish with the concrete state reached: account created, verification blocked, waiting for user input, or provider rejected the flow.
Handling changing DOM refs and blank snapshots
Browser form pages often re-render between steps. If a browser_type or browser_click fails with an unknown ref, or a snapshot is unexpectedly empty:
- First call
browser_snapshot again to refresh refs.
- If the page is visually blank, use
browser_vision to distinguish a rendering issue from a real empty page.
- If the DOM is empty but vision shows the form, check
browser_console(expression="location.href") before assuming state still exists; sometimes the active page is actually about:blank while the screenshot cache still shows the prior page.
- If the form state is lost, navigate back to the flow’s stable entry URL and replay only the non-sensitive fields the user already provided.
- Do not conclude that the browser is broken; treat it as a transient page/rendering issue and retry with fresh refs.
Provider anti-abuse / automated signup rejection
High-friction account creation sites (especially Google/Gmail) may allow early form steps but reject the flow after password submission with a generic Error or trigger phone/CAPTCHA/device-trust checks. Handle this as provider anti-abuse, not as a reason to fabricate progress.
- One careful retry is reasonable if a password shape, stale DOM ref, or username collision could explain the failure.
- Do not loop repeated full signup attempts after the same generic provider error; that can worsen risk scoring and wastes the user's time.
- If the default Hermes browser gets a generic provider error, try one stronger backend before giving up when the user wants maximum autonomy: Browserbase with project/proxy credentials, Camofox/Camoufox if available, or CDP into a user-owned browser if the user consents.
- When a challenge changes from generic
Error to QR/SMS/CAPTCHA/device verification, stop automation and hand that step to the user. Continue only after they confirm completion.
- State exactly how far the flow got, which address/username was selected, and what error or verification challenge appeared.
- Recommend completing the signup from the user's own normal browser/device/IP when provider anti-abuse blocks automated browser completion.
- See
references/gmail-account-signup-antiabuse.md for the Gmail-specific pattern and the Camofox REST workflow observed in real sessions.
Sensitive-data boundaries
The assistant may type user-provided public/profile data (name, date of birth, username choice) into the form. For secrets and identity checks:
- Ask the user to type passwords directly, or provide an explicit password if they choose.
- If the user explicitly asks for a temporary password, generate it locally, type it once, tell the user it is temporary, and do not save it to memory or skills.
- Never invent a recovery email, phone number, verification code, or CAPTCHA answer.
- Let the user complete CAPTCHA/anti-bot challenges manually.
- For legal/terms/privacy acceptance, summarize what the button does and ask for confirmation before clicking if the action creates an account or commits to terms.
Username/address selection
When the site offers generated usernames or addresses:
- Present the exact choices as bullets.
- Ask the user which to choose, unless they already gave a clear preference.
- If “create your own” is available, include it as an option.
Communication style
Keep form-flow updates terse and direct. For COMANDOS club users, Russian is usually the right default unless the user writes in English. Avoid explaining obvious UI details. Prefer:
- “Открыл регистрацию. Нужны имя и фамилия.”
- “Готово, перешёл к дате рождения.”
- “Здесь нужен код из SMS — введи сам и скажи «дальше».”
Avoid long caveats unless the next step is sensitive or irreversible.
Verification checklist
Before final reply:
- Did every user-provided field get entered correctly?
- Is the current screen known from a fresh snapshot or visual check?
- Are we waiting for user input, blocked by verification/CAPTCHA, or actually finished?
- Did we avoid storing or inventing sensitive information?
