Write an instruction once, and Hamster runs it automatically — whenever the right thing happens in your workspace, or whenever the clock says it should.
Every product team has work that should happen every single time — summarise a new Brief so the team has shared context, check a completed Task against the Brief's acceptance criteria, flag when a Plan changes scope. Without automation, this relies on someone remembering to do it. Sometimes they do. Often they don't.
Routines take those recurring jobs off your team's plate. You write the instruction once, attach it to the events or schedule that should trigger it, and it runs without anyone thinking about it.
A Routine has two parts:
When a trigger fires, Hamster reads your instructions, gathers the full context, and executes. The output lands in the run history, and any changes it makes to Briefs, Tasks, or documents appear in the normal activity feed.
When the work is editing a document, a Routine can propose a change to a Blueprint and you accept it inline.
Open Methods from the workspace sidebar, go to Routines in the header, and select New routine.
The editor is a single form: give the routine a name, write its Instructions, and add Triggers or a schedule. Triggers are optional at save time — you can write and test your instructions before attaching any. Once saved, a routine opens with two tabs: Overview for the form and Run History for every execution, with the input it received and the output it produced.
When Hamster recognizes the same multi-step request being repeated in chat, it can offer to save that work as a Routine.
Instructions are plain-language prompts. Hamster receives the full context of the triggering event — the Brief content, the Task details, the Initiative it belongs to — so you can reference entities directly rather than describing them abstractly.
A few patterns that work:
When this brief is created, write a two-paragraph research summary based on
the description and add it to the brief as a context document.
When a task is marked complete, check that the task title and description
match the acceptance criteria in the parent brief. If they don't align,
post a note in the task thread with the specific discrepancy.
When this blueprint is updated, compare the new version against the previous
version and summarise what changed in three bullet points.
When an initiative status changes to "delivering", scan the attached briefs
for any tasks that are still in draft state and flag them in a comment on
the initiative.
When a brief is approved, write a one-paragraph summary of what was agreed
and the key decisions made, and attach it to the brief as a handover note.
When an initiative is marked at risk, review the attached briefs and list
the specific blockers or open questions that could be contributing.
Instructions can be as long as you need. Routines support full markdown, so you can include examples, formatting rules, or multi-step logic.
Use Test run to check your instructions before enabling the routine for unattended execution.
Select Test run from the Routine modal, and Hamster executes what you've written in the editor right now — including edits you haven't saved yet.
Hamster uses the selected enabled event trigger, the first enabled event trigger, or the first enabled schedule in that order. If neither an enabled event trigger nor an enabled schedule exists, attach and enable one before testing.
The result appears in the Run History tab. Each test-run entry shows the exact instructions that ran, so you can compare iterations side by side. Test runs are marked Test run in the run history and don't count toward the Last run column on the Routines list.
The test-run button is disabled when:
When a trigger fires, Hamster executes your instructions using the same AI that runs your conversations. It has access to the full workspace context — Briefs, Tasks, documents, Initiatives — and can use the same tools available in chat: reading and writing Briefs, adding context documents, posting notes, and more.
Routine executions run in the background and don't appear among your recent chats. A Routine you create under Methods > Routines gets its own isolated thread for each run, so your chat list stays focused on your actual conversations.
A Routine you set up by asking Hamster in chat belongs to that conversation instead. Every run works in one ongoing thread and posts its result back into the conversation under the routine's name, and a run with nothing new to report stays quiet. Routines set up in chat can't start from code events such as a pull request. They don't appear in the Routines list; manage them from the Routines button in that chat's header. See Follow-Ups and Background Work.
A Routine can propose a change to a Blueprint, where you review and accept or reject the inline diff. For example, a Blueprint-sync Routine can fire when a Brief moves to Delivered, review the linked Blueprints against the shipped work, and post its result in the Brief chat.
A Routine can be triggered in two ways: by workspace events, or by a schedule.
Event triggers fire when something happens in your workspace. Add one or more with Add trigger in the Triggers section. A single Routine can respond to multiple events — for example, both Brief created and Brief status changed to Delivered.
The picker groups events like this:
| Group | Events |
|---|---|
| Brief | Created, status changed to Draft, Refining, Shipping, Delivered, Done, or Archived, review requested, alignment vote submitted, approved, Plan generation started/completed/failed, edits accepted |
| Initiative | Created, shipped, blocked, archived, health at risk, health off track, focus changed, focus set to Now/Next/Later, edits accepted |
| Blueprint | Proposal merged, proposal abandoned, edits accepted |
| Note | Edits accepted |
| Goal | Edits accepted |
| Task | Created, moved to To Do, moved to In Progress, marked Done |
| Plan | Created, updated, state changed |
| Method | Created, updated, deleted, skill added to method, skill removed from method |
| Skill | Created, updated, deleted |
| Routine | Deleted |
| GitHub | Pull request opened, pull request merged, pull request review submitted, push to branch |
| Delivery | Completed, failed, blocked on questions |
Changing an Initiative's focus fires both Initiative focus changed and the trigger for the new value, such as Initiative focus set to Now.
Each trigger can be enabled or disabled individually — toggle the switch next to a trigger to pause it without removing the configuration.
For example, a Routine with a Pull request merged trigger can check the Blueprints a merged change affects and propose edits for you to accept.
GitHub triggers watch the repository you choose, or Any repository, and can be limited to a Branch (for pull request and review triggers, the pull request's source branch). Pull request opened can also filter by PR state, and Pull request review submitted by Review outcome. Push to branch only fires for pushes to the branch Hamster tracks for that repository.
Connected GitLab projects fire the same triggers and appear in the same repository list: a merge request opening or merging fires Pull request opened or Pull request merged, a reviewer's approval fires Pull request review submitted, and a push to the project's tracked branch fires Push to branch. Connected Cursor Origin repositories fire Push to branch only.
Scheduled triggers fire at a time you set — daily, weekly, on weekdays, hourly, or on a custom interval. Useful for recurring work that has nothing to do with a particular workspace event: weekly summaries, daily standups, monthly reviews.
See Scheduled Triggers for setup and configuration.
A Routine's instructions can tell Hamster to post a message directly into a Brief's or Blueprint's chat thread — not just record output in the run history, but make it visible to your team in context.
This is useful when a Routine is watching one thing but its output belongs somewhere else. For example, a Routine that monitors Initiative status changes can post a summary of what changed directly into the Initiative's attached Briefs so the people working on them see it without going to the Routines page.
To use this in your instructions, describe what you want posted and where:
When the initiative status changes to "delivering", post a message to the
initiative's primary brief chat summarising what changed and listing any
tasks still in draft state.
Hamster finds the target thread, posts the message as an automated entry, and marks it so it's clear it came from a Routine rather than a team member.
When a Routine fires and is actively executing, a status indicator appears on the relevant thread entry point. This shows the Routine is in progress — you do not need to refresh or check the Run History tab to know it's working. The indicator clears when the run completes.
If a Routine fails, the run is logged with the error. You can open the run from the Run History tab to see what went wrong — the full input the Routine received and the error message are both visible.
If a Routine fails five times in a row, Hamster disables it automatically. This prevents a misconfigured Routine from continuing to fire against events it cannot handle. To re-enable it, fix the instructions and toggle its Active switch back on in the Routines list.
Single failures do not disable a routine. The consecutive-failure threshold exists to catch Routines that are broken in a way that will keep failing, not to disable Routines that occasionally hit a transient error.
The Runs feed tracks the execution lifecycle separately from what the AI says it accomplished. Runtime statuses — Pending, Running, Completed, Cycle completed, Failed, Skipped, Skipped — another run is active, Cancelled, Terminated, and Paused — describe whether Hamster processed the run; a completed run does not by itself prove that every requested action succeeded.
For unattended runs, the AI is instructed to end its final response with STATUS: COMPLETE only when every required step verifiably ran, or STATUS: INCOMPLETE — <reason> when a required step failed or was blocked. This marker is the agent's own report, not the run's runtime status.
Hamster records the last marker as complete, incomplete, or unknown for analytics. It is not shown as a separate run-history field, does not gate the runtime result, and does not change Briefs or other workspace entities.
Every execution is logged. Open the Run History tab inside a Routine to see its history, or select Runs at the top of your Routines list to see every execution across your workspace in one feed.
The feed updates in real time as runs complete. Use the Triggers filter on the Runs feed to narrow down to specific event types.
Each run shows:
Click any run to open the full thread view — the complete AI execution with tool calls, reasoning, and output, the same as any other Hamster conversation.
Opening a past run from the history is how you trace what a Routine actually produced.
Creating, editing, and running Routines requires the Manage Routines permission. Members without this permission can view Routines and their run history, but can't create, edit, or trigger them.
Routines are account-level — they apply to your whole team workspace, not just the person who created them.
If you are new to Routines, the Routines Library is the fastest way to get started. It ships pre-built automations from Hamster that you can enable with a single toggle — no instructions to write, no triggers to configure. Open Methods from the workspace sidebar to reach the Library, then select the Routines tab to read what each one does before investing in a custom automation.
You can fork any library Routine into a copy your team owns and edit it freely.