How we use Emargen

Emargen is where we shape initiatives and, since ACM-247, where we build them. This page is for engineers: what lives where, how slices and tasks work, and how agents take part. Product's side is in their space; customer success has their own page.

What lives where

Thing	Where
A customer question, an idea, research, an incident review	an Emargen topic
An initiative: brief, requirements, approaches, kickoff	Emargen
Building an approved initiative	Emargen slices and tasks (since ACM-247)
Initiatives approved before mid-August	their Jira epic (ENG-1418 … ENG-1601)
Bugs from production, chores, dependency bumps	Jira ENG
Incidents and production changes	Jira OPS, and an incident review topic in Emargen
Architecture decisions for everyone	an ADR in this space

From May to mid-August, product shaped initiatives in Emargen and handed them to us as Jira epics. ACM-247 (Depot managers approve their own people) was the first we built in Emargen. A few urgent or already-planned pieces stayed in Jira after that: lockout and rate limits after OPS-41 (ENG-1702), merge duplicate people (ENG-1688) and Vossberg's depot import (ENG-1710).

Slices and tasks

• An approved initiative arrives as slices. Each slice ends in something you can show: its demo is its acceptance.
• Each slice has tasks, usually one per repository. A task says what to change and which part of the kickoff it comes from.
• Claim a task before you start, person or agent. One claim per task; a claimed task shows who has it.
• A task can wait on another's output (the portal task usually waits on the identity-service task).
• Found work that isn't on the slice? Add a task to it, don't do it quietly.
• Close a task with its merge request. The review happens in GitHub as usual.
• If what you build can't meet what was shaped, propose a change on the initiative. The owner decides. Don't change the meaning of a requirement in code.
• Questions only the initiative's people can answer: ask on the initiative, not in Slack.

Agents

Agents claim and close tasks the same way we do, through the personal token of the engineer running them:

• Codex in the portal (Aiko).
• Claude Code in identity-service and notifier (Jonas, since September).

How to set one up and the rules: Claude Code and Codex with personal tokens. An agent's merge request is reviewed like anyone's, and the person whose token ran it is the author.

Agents leave notes for their person: a decision taken in the session, a trap, a todo, an idea. Read yours before stand-up. A trap worth everyone's time becomes a topic: ACM-313 came from one of Jonas's notes.

Planning

• The Engineering board in Emargen shows initiatives that are approved or in delivery, by owner. It is what we look at in Thursday planning.
• Jira ENG still holds the bug and chore backlog; Lukas pulls from it into the same planning.
• Estimates are per slice, in days, written on the slice when we pick it up.

What we learned on ACM-247

• Three slices, five tasks over three repositories. Shipped on 1 October.
• Agent notes caught two things before review: requests are routed to the person's home depot, and requests nobody approves close after 14 days without a word. Both went to Lena.
• Slices that end in a demo were easier to review than our old Jira stories.

Change history

Version	Date	Who	What
1	2 Sep 2026	Lukas	First version, during ACM-247
3	21 Sep 2026	Jonas	Link to the personal tokens page
5	2 Oct 2026	Lukas	What we learned on ACM-247
6	8 Oct 2026	Lukas	ACM-313 from an agent note
7	14 Oct 2026	Lukas	ACM-320 approved on 13 October; its first task claimed by Jonas's Claude Code; Marek joins Emargen