added disposable email skill

[powerstone666]

Summary

Adds a disposable_email skill using Mail.tm for live disposable inbox workflows.

Changes

• Adds a new disposable_email skill
• Documents the Mail.tm API workflow for creating temporary inboxes
• Covers authentication, message polling, message reading, and raw source retrieval
• Includes examples for Python and cURL
• Adds guidance for extracting verification links, OTP codes, tokens, and headers
• Documents rate limits, temporary mailbox constraints, and basic error handling

Use Cases

This skill helps test email-based authentication workflows, including:

• Magic link authentication
• Email verification
• Password reset flows
• OTP-based login
• Authenticated endpoint testing that requires a real inbox

Related Issue

Closes #559

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a new “disposable_email” skill document to guide using Mail.tm as a live disposable inbox for workflows like signups, OTPs, password resets, and magic links.

Changes:

• Introduces a reusable workflow for creating/authenticating Mail.tm accounts and reading messages
• Documents key Mail.tm endpoints with example Python/cURL requests
• Provides sample response shapes plus snippets for extracting URLs/OTPs

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[greptile-apps]

Greptile Summary

Adds a disposable_email skill that documents the full Mail.tm workflow for creating temporary inboxes within agent sessions. The PR addresses previously flagged issues: random domain selection via GET /domains, DELETE /accounts/{id} in the endpoint table, correct html array shape in the response schema, and a proper array-aware extraction snippet.

• The Python example discards resp after account creation, so the documented account_id needed by DELETE /accounts/{id} is lost — agents following the example cannot perform the explicitly required cleanup.
• Both Python and cURL examples use the static password \"secret\", making every generated account trivially guessable; a random password (same approach as the local-part) would prevent credential collisions across concurrent runs.

Confidence Score: 4/5

Safe to merge with the caveat that agents following the Python example verbatim cannot clean up created accounts.

The Python example captures resp from account creation but discards it without extracting resp[id], making it impossible for a reading agent to supply the account ID to the DELETE /accounts/{id} endpoint that the Constraints section explicitly requires.

strix/skills/custom/disposable_email.md — specifically the Python example block around account creation and cleanup.

Important Files Changed

Filename	Overview
strix/skills/custom/disposable_email.md	New disposable email skill using Mail.tm. Domain selection, html-array handling, and DELETE endpoint are all correctly documented, but the Python example discards the account ID from POST /accounts, leaving the explicitly documented cleanup step (DELETE /accounts/{id}) unreachable for agents following the example.

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
strix/skills/custom/disposable_email.md:69-72
**Account ID silently discarded — cleanup step is unreachable**

`resp` is assigned but never used, so `resp["id"]` (the account ID required by `DELETE /accounts/{id}`) is immediately lost. The Constraints section explicitly instructs agents to clean up with `DELETE /accounts/{id}`, but an agent following the example code has no value to substitute for `{id}`. The variable should capture `account_id = resp["id"]` immediately after creation, and a corresponding delete call should be shown at the end of the example — ideally in a `finally` block — to make the documented cleanup step executable.

_{Reviews (2): Last reviewed commit: "Enhance disposable email skill documenta..." | Re-trigger Greptile}

[greptile-apps]

Hardcoded email address will cause 422 conflicts and the hardcoded domain may not be available

The examples fix the address to user@web-library.net, but Mail.tm rejects account creation with 422 if that address is already registered — which is almost certain across repeated test runs. Separately, Mail.tm's available domains rotate over time; web-library.net may no longer be listed when an agent reads this skill. The workflow already documents GET /domains as the first step; the example should actually call it, pick a domain from hydra:member, and combine it with a randomly generated local-part before calling POST /accounts. Without that, the account-creation step will fail silently in most automated runs.

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/skills/custom/disposable_email.md
Line: 63-70

Comment:
**Hardcoded email address will cause 422 conflicts and the hardcoded domain may not be available**

The examples fix the address to `user@web-library.net`, but Mail.tm rejects account creation with `422` if that address is already registered — which is almost certain across repeated test runs. Separately, Mail.tm's available domains rotate over time; `web-library.net` may no longer be listed when an agent reads this skill. The workflow already documents `GET /domains` as the first step; the example should actually call it, pick a domain from `hydra:member`, and combine it with a randomly generated local-part before calling `POST /accounts`. Without that, the account-creation step will fail silently in most automated runs.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

DELETE /accounts/{id} endpoint is absent from the API table

Mail.tm exposes DELETE /accounts/{id} for removing a mailbox. Without it, agents have no way to clean up accounts between test runs, which matters for quota exhaustion and for keeping a test environment tidy. Adding it to the endpoint table and noting it in the constraints section would complete the lifecycle coverage.

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/skills/custom/disposable_email.md
Line: 30-38

Comment:
**`DELETE /accounts/{id}` endpoint is absent from the API table**

Mail.tm exposes `DELETE /accounts/{id}` for removing a mailbox. Without it, agents have no way to clean up accounts between test runs, which matters for quota exhaustion and for keeping a test environment tidy. Adding it to the endpoint table and noting it in the constraints section would complete the lifecycle coverage.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

html field in the message response is an array, not a plain string

Mail.tm's GET /messages/{id} response returns html as an array of strings (e.g. ["<html>...</html>"]), not a bare string. The example shows "html": "<html>...</html>", which will mislead agents that index or iterate the field. The extraction snippet in the "Extracting Useful Data" section concatenates message.get("html", "") as a string, which would also silently produce "['<html>...']" instead of the actual HTML if the field is an array. Both the response schema and the extraction example should reflect the array shape.

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/skills/custom/disposable_email.md
Line: 196-210

Comment:
**`html` field in the message response is an array, not a plain string**

Mail.tm's `GET /messages/{id}` response returns `html` as an array of strings (e.g. `["<html>...</html>"]`), not a bare string. The example shows `"html": "<html>...</html>"`, which will mislead agents that index or iterate the field. The extraction snippet in the "Extracting Useful Data" section concatenates `message.get("html", "")` as a string, which would also silently produce `"['<html>...']"` instead of the actual HTML if the field is an array. Both the response schema and the extraction example should reflect the array shape.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Account ID silently discarded — cleanup step is unreachable

resp is assigned but never used, so resp["id"] (the account ID required by DELETE /accounts/{id}) is immediately lost. The Constraints section explicitly instructs agents to clean up with DELETE /accounts/{id}, but an agent following the example code has no value to substitute for {id}. The variable should capture account_id = resp["id"] immediately after creation, and a corresponding delete call should be shown at the end of the example — ideally in a finally block — to make the documented cleanup step executable.

Prompt To Fix With AI

This is a comment left during a code review.
Path: strix/skills/custom/disposable_email.md
Line: 69-72

Comment:
**Account ID silently discarded — cleanup step is unreachable**

`resp` is assigned but never used, so `resp["id"]` (the account ID required by `DELETE /accounts/{id}`) is immediately lost. The Constraints section explicitly instructs agents to clean up with `DELETE /accounts/{id}`, but an agent following the example code has no value to substitute for `{id}`. The variable should capture `account_id = resp["id"]` immediately after creation, and a corresponding delete call should be shown at the end of the example — ideally in a `finally` block — to make the documented cleanup step executable.

How can I resolve this? If you propose a fix, please make it concise.