Create an AI task from a prompt: write it, check it, change it
Describe a job in plain words and Mono sets it up as a task. Write a request you can check, read what Mono built, check the first run, and change one thing at a time.
A useful automation starts with a small, checkable job. “Organize my work” leaves too many decisions open. “Every weekday at 8:00, put the three newest headlines from one news site in my notes” gives you a result you can check.
In Mono, you describe a job like that in plain words and Mono sets it up as a task: something it does on a schedule, or when you press Play. This guide covers writing the request, checking what Mono built, and changing it safely. To add an ability someone else built, install and test a skill from the store instead. Mono is currently on a waitlist; the exact controls can change between versions.
1. Write a request you can check
Say what Mono should do, where the result goes, and how often. Name the source if there is one, and say what should happen when there’s nothing to report. Don’t put passwords, keys, or real customer information in the request.
Use this as a small practice exercise:
Every weekday at 8:00, read the newest posts from one news site I name.
Put the three newest headlines in my notes, each with its link.
Keep the headlines as they are written; don't summarize them.
If the site has no posts from today, write No new headlines today.
Don't send messages or email, and don't post anywhere.The point is that you can check it: you know what a correct result looks like before Mono builds anything. If you leave out the time, the task runs only when you press Play, which is a good way to start.
2. Create the task and follow the steps
Open Tasks and press +, or ask Mono in chat to make the task. Typing /create-task followed by your request does the same. Mono works through four steps: understanding your idea, finding what it needs, putting it together, and giving it a test run. It usually takes around a minute, so keep the app open while it works.
If Mono finds a skill in the store that does part of the job, it asks before adding it. A skill is usually more dependable than a website that might need a key or change its layout, but the choice is yours. To build the steps by hand instead, choose “Set up the steps yourself”.
When something stops the task, Mono says so and keeps what you wrote. “I can’t do this on my own yet” comes with Mono’s reason, for example an account that isn’t connected. “It didn’t work when I tried it” means no task was created: try again, or describe the job differently, usually more narrowly.
3. Read what Mono built
When the task is ready, its page opens. Compare it with your request before you rely on it.
| Check | Where to look | Expected result |
|---|---|---|
| Trigger | First line of How it works | Weekdays at 8:00, or Play if you gave no time |
| Steps | The rest of How it works | Read the site, pick three headlines, write to notes |
| Notes | Good to know, and the notes at the top of the page | Nothing unexpected, such as an account Mono still needs |
| External effects | Every step | No messages, email, or posts |
A step you didn’t ask for is a reason to change the task, even when the result looks right. Check that the source is the site you named and not a similar one.
4. Check the first real run
While Mono builds the steps, it tries them without side effects. Once the task is saved, it runs once for real: anything it writes or sends happens right away, and the run goes into the task’s history. That’s why the practice request writes only to your notes.
Open the result and compare it with your request: three headlines, each with its link, in their original wording. Over the next few days, press Play again, including on a day with no new posts, and check the empty-day message. Keep a small record: date, expected result, actual result, and anything unexpected.
If a later version will write to another service, test it first with a harmless destination you can check yourself. A run marked “Worked” means the steps finished. It doesn’t prove that the right record changed.
5. Change one thing at a time
To change a task in words, ask Mono in chat, for example: “Change my headlines task: add the publication time after each headline. Keep the schedule, the source, and the empty-day message.” Mono rebuilds the task’s steps in place. The change is saved only once the rebuilt task works, and the task keeps its schedule unless you ask for a new one. If you close the screen before it finishes, nothing changes.
A changed task also runs once for real, so read How it works again and check the result. To adjust a single step by hand, press Edit task on the task’s page. If a change adds network access or a connected account, decide on that access separately. Don’t accept it only because the original task was simple.
6. Decide whether it is ready to run on its own
A task is ready for a schedule when its trigger is right, it handles an empty day predictably, and you can check its result. Keep its purpose narrow enough that you can tell at a glance whether a run worked.
When it passes your checks, write those examples down next to the task’s purpose. The automation guide covers choosing a schedule, and diagnosing a scheduled task helps when a run doesn’t happen. The skills, MCP, and ACP comparison helps when the next step needs an external tool or a coding agent.
