gitstalk
Install the plugin Sign up
Docs: Automation builder and templates

Automation builder and templates beta

Build an automation in the browser: a form beside the file's YAML (tabs on a phone), always in sync. Start from a template, or from a blank page.

Walkthrough

  1. Open the builder

    On the repository's Automations tab, press New automation and pick a template. Edit on an existing automation opens it.

  2. Edit the form or the YAML

    Change a field and only that line of the YAML changes, with your comments and layout kept. Edit the YAML and the form follows. If the YAML does not parse, the form pauses and points at the line.

  3. Fix problems where they are

    Every change is checked by the same rules Gitstalk uses when it reads the file. Problems show at their field and at their line. Compatibility notes, such as a capped timeout, show beside the file.

  4. Save as a bean

    Add an optional commit message and press Save as bean. Nothing is pushed to main.

New automation

.gitstalk/automations/fix-red.yml · saves as a bean: pre-land check, then live when the stalk takes it

NameFile name: lowercase letters, digits, - and _.
Fix red beans
TriggersGitstalk events, with beans, authors and paths filters.
bean_red
On a schedule (UTC)Every Monday at 09:00. Next: Mon 19 Oct, Mon 26 Oct.
0 9 * * 1
HarnessPrompt runs an agent. Shell runs a script.
Prompt · kimi-k2.7-code
LimitsTimeout, max turns, max cost.
30 · 40 · $0.50
# .gitstalk/automations/fix-red.yml
name: Fix red beans
on:
  bean_red:
  schedule: [{ cron: "0 9 * * 1" }]
permissions:
  beans: write
max-cost-usd: 0.50
Save as bean Test run
The form has sections for Name, Triggers, Harness, Permissions, Secrets, Limits and Memory. Schedules show in words with their next run times.

Templates

Template What it does
Fix red beans When a bean goes red, an agent reads why, fixes it in a new bean and notes what it learned.
Weekly dependency bump Every Monday, updates dependencies one at a time and pushes a bean for each that passes.
Summarize landed work Every Friday, writes a short summary of what landed this week to the repository.
Triage decision cards When a decision card opens, compares the beans and leaves a recommendation in memory.
Shell heartbeat A tiny shell hook every hour: no model, just a script with the workspace and memory.
Area watcher Reviews every landing in one area of the code. See below.
Blank An agent you run by hand, with a prompt to fill in.

Area watcher, step by step

An area watcher is a reviewer that knows one part of the code well. When a bean lands and changes files under the area's paths, an agent reviews the landing against the area's intent and recent history. It reviews and never merges.

  1. It wakes on a landing in the area

    bean_landed with a paths filter. A landing that changes nothing under src/billing/ never starts it.

    .gitstalk/automations/billing-watcher.yml
    name: Area watcher (billing)
on:
  bean_landed:
    paths: ['src/billing/**']   # the area
permissions:
  beans: write                  # only to push an evidence bean
max-cost-usd: 0.5
prompt: |
  You watch one area: src/billing/. Its intent: what it must always do.
  Review the landing against that intent and write a verdict to memory.

    The template's real prompt is longer. This is the file in short, and it is valid as written.

  2. It reads its memory, then the landing

    It opens area.md (what it knows about the area) and reviews/ in its memory. Then it reads the landing's intent and diff, with the Gitstalk MCP tools when they are in its tool list, or plain git otherwise.

  3. It checks the landing against the area's intent and last 20 landings

    It looks for behaviour that changed without the intent saying so, a reverted fix coming back, a test or check removed, or an invariant in area.md that no longer holds.

  4. It writes a verdict to memory

    reviews/<bean>.md holds the verdict (fine, drift or regression), the evidence and what to watch next time. area.md gains what it learned.

  5. On a regression it opens an evidence bean

    Only when it can show the problem, it pushes one bean with a failing test that proves it. It does not fix it, and it changes nothing outside src/billing/ and its tests. That bean goes through the pre-land check like any other, and a failing test stays red. Landing stays the engine's job.

Saving, editing and deleting

  • Saving is a bean you author. Gitstalk commits the file in your name on the latest landed version and pushes it as bean/automation-<name>-<id>. It goes through the pre-land check and is live when the stalk takes it.
  • You need the write role, or the maintain role if .gitstalk/checks.yml lists the file in protected-paths. A reader can still edit and copy the YAML, but cannot save it, and the page says why.
  • Delete is a bean that removes the file, after you confirm.
bean/automation-fix-red-k3f9 Saved: checking checking
bean/automation-fix-red-k3f9 Saved. Landed as 8be40d7; live when the stalk takes it. saved
bean/automation-fix-red-k3f9 red: the reason, and each failing check red
The builder follows the bean: checking, then saved with a link to the commit, or red with the reason. These are the same bean as three moments, not three beans.

When someone else edits at the same time

If the file changed on the stalk while you edited, the builder merges field by field.

  • Different fields: they merge, and the builder shows the result before you save: "Merged with @dana's change to the schedule. Your change to the prompt is kept."
  • The same field: it shows theirs and yours side by side. Pick one, or edit a value of your own.
  • Deleted meanwhile: recreate it with your version, or keep it deleted.
  • Your draft is kept in the browser until it is saved. Reopening the builder offers to restore it or discard it.

Test run

Test run is for maintainers and the owner. It runs the draft once by hand without saving it, and it never writes the automation's memory, because the test job has no save-memory step. The builder then links to the run.

Sources