Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Suggest reusable routines when Michael notices repeated work

Open
  • Is something wrong?
#41 2 comments 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@agentvivekkumar is already working on this.

Since Oct 8, 2026.

Assessment

This issue has not been assessed yet.

Description

enhancement Require Customer
Problem / motivation

Small-business owners often repeat the same operational work without realising they can automate it.

For example, an owner might repeatedly ask Michael to check overdue invoices, draft customer follow-ups, and flag exceptions. The office can remember how the work was done, and recurring jobs can be created in Schedules, but the owner still has to recognise the repetition themselves and decide to turn it into a routine.

This creates a gap between work the office already knows how to do successfully and work that has actually been automated. For a nontechnical owner, that means some repetitive processes may continue manually simply because they never thought to configure a schedule for them.

The predefined starter jobs are useful for common workflows, but they are based on what a business type might need. They do not capture patterns that are specific to how an individual business actually operates

Proposed solution

Let Michael recognise recurring patterns in completed work and offer to turn them into a reusable routine.
A simple first version could work like this:

  1. Similar tasks are completed successfully multiple times.
  2. Michael recognises that the task intent is recurring.
  3. Michael asks the owner something like:
    "You've done this several times. Would you like me to make it a routine?"
  4. Michael pre-fills a proposed routine using the existing context:
    • task/job description
    • assigned employee
    • suggested trigger or schedule
    • apps, mailboxes, or files required
    • approval points
    • expected output
  5. The owner reviews or edits it.
  6. Nothing becomes recurring until the owner explicitly approves it.

For example:
Job: Follow up on overdue invoices
Assigned to: Finance
When: Every weekday at 9 AM
Uses: invoice data + finance mailbox
Approval: ask on unusual exceptions
Output: follow-ups completed + exceptions summarised

Recognising repeated task intent and using existing task/memory context to pre-fill a Schedule would already reduce a meaningful amount of setup. Longer term, repeated successful executions could make the suggested routine more specific, but the owner should remain the final approval point.

Screenshot, mockup or recording
Image
Alternatives considered

Predefined starter routines: These are useful for onboarding and common use cases, but they are generic. They cannot know which processes a particular owner repeatedly performs in their own business.

Require the owner to create a schedule manually: This works today, but assumes the owner notices the repetitive pattern and knows it is a good automation candidate. That is exactly the orchestration burden the product is trying to reduce.

Automatically create routines after repeated work: I would avoid this. Repetition does not always mean the owner wants permanent automation, and inferred triggers or permissions may be wrong. Suggesting the routine first keeps the owner in control.

Infer complete workflows from raw tool traces immediately: Potentially useful later, but probably unnecessary for a first version. Detecting repeated task intent and pre-filling an existing Schedule seems like a smaller, safer starting point.

Area

The hive (memory, routing, GOD agent)

Pre-flight
  • I attached a screenshot, mockup or recording above.
  • I searched existing issues and discussions, and this isn't a duplicate.
Dominant language
TypeScript
Stars
273
Forks
211
Avg merge
9h 17m
Merged PRs (30d)
162

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from agentvivekkumar/dontbemichael

All issues in agentvivekkumar/dontbemichael

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.