Anarlog Workflow

Anarlog workflow

Apply to Anarlog repository or Anarlog desktop, web, mobile, and API work. Apply the same workflow in other checkouts and worktrees.

Use Linear for work tracking and facts worth remembering. Keep implementation and verification details in commits, PRs, and CI.

Write everything you log or edit in English, even when the conversation is in another language: Linear issues, comments, and documents; Slack updates; commits, PRs, and review replies; code comments and docs. Only replies to the user in the conversation follow the user's language, and localized product content such as translation catalogs keeps its target language.

Do not read, create, edit, or comment in Notion for Anarlog work. Anarlog does not use Notion; keep its decisions and durable context in Linear.

• Team: Anarlog (ANLG).
• Workspace: fastrepl-inc.
• Agent lessons.

Start work immediately

1. Default to execution. When the user requests a change, reports a bug, or scopes work, start investigating and implementing immediately and carry it through to completion. Document only when the criteria below are met; documentation is not a prerequisite or the deliverable.
2. Only use a discussion-first workflow when the user explicitly asks for brainstorming, exploration of ideas, or planning without implementation. Answer informational questions directly.
3. Search Linear issues, documents, and comments for the topic, IDs (ANLG-123), and nearby decisions alongside execution. Read matching issues/docs and the team's Agent lessons early enough to inform relevant implementation decisions. Do not make this pass a prerequisite for starting useful work.
4. Reuse an existing issue when one fits. Create one for work that needs tracking, such as a feature, substantial behavior change, or unresolved bug; do not create an issue just to log a small completed edit. Use the right team and existing project. Update status when it changes without adding a routine progress comment.
5. If Linear is unavailable, continue authorized work and report a recording gap only when there is useful context to preserve. Existing approval requirements for external actions and shared history still apply.

Record facts worth remembering

Before writing a comment or document, ask: will this help someone make a future decision or avoid rediscovering something non-obvious, and is it missing from the existing record? If not, do not post.

• Preserve consequential decisions and their rationale, surprising findings, non-obvious constraints, corrected assumptions, and failed approaches with a reusable lesson.
• Record a blocker or handoff only when someone needs to act, including the missing context and required next step.
• Skip investigation-start announcements, step-by-step progress, change summaries, commit/push notices, test counts, formatting results, and routine verification caveats. These belong in the task response, PR, or CI, not another Linear comment.
• Do not copy information already captured in an issue, document, or PR. Link to the source when it supports a new fact; include only the context needed to understand that fact.
• Keep each note short: what we learned, why it matters, and what it changes next time. No required headings or per-turn documentation quota. If nothing worth remembering emerged, write nothing.
• Link the issue in commits/PRs when one exists (ANLG-123).