---
title: Atlas Discord Telegram Workflow
area: projects
tags: [assistant, atlas, discord, telegram, workflow]
created: 2026-05-14
updated: 2026-05-14
status: draft
related: [[Atlas Capability Upgrade Program]], [[Ops Home]], [[Projects Home]]
---

# Atlas Discord Telegram Workflow

## Purpose

This note defines where to talk to Atlas across Telegram and Discord, what message patterns mean, how background work reports back, and what platform limits to expect.

Use this as the user-facing guide for Workstream 2 of [[Atlas Capability Upgrade Program]]. Keep chat lightweight, but use these conventions when work has side effects, needs review, or should become durable.

## Quick rule

- Telegram is the personal, low-friction command channel.
- Discord is the shared/project coordination channel.
- Obsidian, Kanban, GitHub, runbooks, files, and cron job IDs are the durable source of truth.
- Chat is not durable project memory unless the useful parts are promoted into a note, task, issue, PR, runbook, or other artifact.

## Platform roles

### Telegram

Use Telegram for direct operational interaction with Atlas.

Best for:
- Quick one-off asks.
- Personal status checks.
- Mobile or voice follow-ups.
- Approving or denying pending actions.
- Short cron/kanban notifications.
- Small follow-ups to already-scoped work.

Avoid using Telegram for:
- Large project planning threads.
- Multi-person review conversations.
- Long context dumps that should become durable notes.
- Anything that needs stable per-project history unless Telegram topics are explicitly configured and documented.

Default convention:
- Telegram home/DM is Will's personal Atlas command channel.
- Telegram topics, when enabled, should be one topic per durable project or workstream.
- Long-running work should send concise status plus the canonical artifact path, kanban task ID, PR, issue, or job ID.

### Discord

Use Discord for shared visibility and team/project coordination.

Best for:
- Brainstorming with other people.
- Project-specific discussion.
- Review requests and decisions.
- Ops alerts that need human visibility.
- Status reporting from Kanban, cron, GitHub, n8n, or other automation.

Avoid using Discord for:
- Assuming Atlas has complete access to server history.
- Treating channel messages as durable project memory.
- Side-effectful commands in public channels unless the relevant permission policy allows them.

Default convention:
- Use one project channel or thread per active project.
- Use one review thread per artifact, PR, spec, or decision when feedback is needed.
- Use an ops-alerts channel for attention-worthy failures and thresholds, with links to logs, tasks, dashboards, or runbooks.
- Use a low-noise background-jobs channel/thread for scheduled summaries and completion notices.

## Channel and topic map

Actual connected Discord/Telegram destinations were not discoverable from this worker run: `send_message(action="list")` returned `No messaging platforms connected or no channels discovered yet.`

Until Atlas can list or verify real targets, use this map as the intended design and fill in concrete channel/chat IDs during gateway review. Do not invent channel names or IDs.

| Destination | Purpose | Audience | Allowed task types | Side effects | Artifact destination |
|---|---|---|---|---|---|
| Telegram home/DM | Personal Atlas command channel | Will + Atlas | quick ask, status, approve/deny, small follow-up | Low-risk only unless explicitly approved | Obsidian note, kanban task, GitHub PR/issue, cron job ID |
| Telegram project topic, if configured | Project-specific mobile thread | Will + Atlas | scoped project follow-up, status, approvals | Same as project policy | Project note or kanban board |
| Discord project channel/thread | Shared project coordination | Project participants + Atlas | brainstorm, plan, execute request, status, review coordination | Read-only or low-risk by default; higher risk requires explicit approval | Project note, kanban task, GitHub PR/issue |
| Discord review thread | Review of one artifact/PR/spec | Reviewer(s), owner, Atlas | review, critique, approve/block | No merge/destructive action unless approved | PR comments, kanban reviewer task, decision note |
| Discord ops-alerts channel | Human-visible failures and thresholds | Operators + Atlas | alert, investigate, summarize incident | Investigation only by default; remediation needs policy/approval | Runbook, incident note, logs/dashboard link |
| Discord background-jobs channel/thread | Low-noise scheduled/async updates | Interested project watchers | cron completion, kanban completion, periodic summary | None unless explicitly requested | Job ID, task ID, status note |

## Message vocabulary

These are plain-language request patterns, not necessarily slash commands. They should work in either Telegram or Discord.

Recommended shape:

```text
<prefix>: <goal>
context: <links, files, task ids, pasted excerpts>
constraints: <deadline, risk tolerance, destination, tone>
deliverable: <expected output>
```

| Prefix | Use it for | Expected Atlas behavior | Example |
|---|---|---|---|
| `capture:` | Save a thought, link, or loose note for triage | Put it in the right durable place or ask where if destination matters | `capture: this n8n failure pattern should become a runbook` |
| `brainstorm:` | Explore options before work is structured | Return options, tradeoffs, and a recommended next step | `brainstorm: ways to reduce noisy cron notifications` |
| `plan:` | Produce a concrete plan/spec without executing code | Create a plan/spec and identify verification steps | `plan: make Atlas handle n8n failure alerts better` |
| `execute:` | Carry out already-scoped work | Do the work using tools; report artifacts and verification | `execute: update the workflow note with the approved channel map` |
| `work kanban task <task_id>` | Run a durable board task | Open the task, follow the Kanban lifecycle, and hand off/block/complete | `work kanban task t_06edd200` |
| `review:` | Inspect a PR, artifact, plan, or handoff | Separate blockers from suggestions and cite concrete references | `review: Projects/Atlas Discord Telegram Workflow.md` |
| `schedule:` | Create/update a recurring or one-shot job | Create a self-contained cron job and report its ID/delivery | `schedule: daily 9am status summary to Telegram` |
| `watch:` | Alert when a condition happens | Create a quiet watchdog or monitoring task with clear threshold | `watch: disk usage and alert when over 85%` |
| `summarize:` | Condense supplied context or linked artifacts | Summarize only the provided/retrieved context; do not invent history | `summarize: this review thread into action items` |
| `status:` | Report current state | Check the relevant source of truth and return concise status | `status: Atlas capability upgrade board` |
| `debug:` | Investigate a symptom | Understand root cause before fixing; show evidence | `debug: gateway stopped sending Telegram messages` |
| `ask:` / `research:` | Answer a question, using tools for current facts | Retrieve needed facts and cite sources/artifacts | `research: current Hermes cron docs and summarize changes` |
| `approve:` | Explicitly approve a proposed side effect | Proceed only within the approved scope | `approve: send the review summary to the Discord project thread` |
| `block:` / `cancel:` | Stop, pause, or mark work blocked | Stop work and record a specific blocker/cancellation reason | `block: pause this until channel owners decide alert routing` |

## Workflow conventions

### Brainstorming

Recommended location:
- Discord project channel/thread for collaborative brainstorming.
- Telegram DM for quick personal capture.

Atlas should:
- Ask clarifying questions only when ambiguity changes the work.
- Produce a short options list, tradeoffs, and a recommended next action.
- Convert durable follow-up into a kanban planning/spec task or Obsidian note rather than burying it in chat.

### Dev work

Recommended location:
- Discord project/dev thread for shared coordination.
- Kanban board for durable multi-step work.
- GitHub issue/PR for code review and merge state.

Atlas should:
- Use Kanban for multi-step or multi-agent work.
- Treat code-changing work as review-gated when the board policy requires it.
- Report artifact paths, PR links, tests run, and blocking/review status.

### Ops alerts

Recommended location:
- Discord ops-alerts channel for shared visibility.
- Telegram DM/home only for urgent personal pings or approvals.

Atlas should keep alerts concise:
- Severity.
- System.
- Observed condition.
- Likely impact.
- Evidence link.
- Suggested next action.

Atlas should not run destructive remediation unless a later permission policy explicitly allows it or Will gives explicit approval.

### Reviews

Recommended location:
- Discord review thread tied to the artifact/PR/spec.
- Kanban reviewer task for formal review gates.

Atlas should:
- Separate blocking issues from suggestions.
- Include file/path references and concrete requested changes.
- Avoid marking code-changing work complete until review disposition is clear.

### Background jobs

Recommended location:
- Discord background-jobs or a project-specific status thread for non-urgent notices.
- Telegram DM/home for personal high-signal summaries.

Atlas should:
- Create cron jobs with self-contained prompts.
- Avoid noisy streams.
- Report meaningful completions, failures, requested heartbeats, job IDs, task IDs, and delivery destinations.

## Platform limits

Read this section before asking Atlas to rely on chat history.

1. Discord history is not a reliable memory source from this context.
   - Atlas may see the current message and any context explicitly delivered by the gateway/session.
   - Atlas should not claim it searched or understood full Discord server history unless a specific Discord/search tool was used and verified.

2. Discord server state is not automatically available.
   - Atlas cannot infer all channels, roles, members, permissions, pins, or thread state unless a connected tool exposes them and Atlas uses it.

3. Telegram context is conversation/session scoped.
   - Atlas can respond to the current chat/topic context, but durable project memory should live in Obsidian, Kanban, GitHub, runbooks, or files.

4. Chat is not the source of truth for durable work.
   - Use Kanban tasks for multi-agent work.
   - Use Obsidian/project docs for durable decisions and runbooks.
   - Use GitHub for code review and merge state.
   - Use cron job IDs for scheduled automation.

5. Side effects need explicit scope.
   - Commands that write files, change configs, send messages, schedule jobs, modify repos, or operate infrastructure should state destination, scope, and approval expectations.

## Examples

### Brainstorm

```text
brainstorm: better ways to route n8n failure alerts
context: Atlas Capability Upgrade Program workstream 6
constraints: keep Telegram high-signal; avoid noisy Discord spam
deliverable: 3 options with tradeoffs and a recommended default
```

### Plan

```text
plan: define the first safe webhook route for n8n failures
context: Projects/Atlas Capability Upgrade Program.md
constraints: no secrets in notes; review-gated changes only
deliverable: kanban task graph and verification checklist
```

### Execute

```text
execute: update the Atlas workflow guide with the approved channel map
context: Projects/Atlas Discord Telegram Workflow.md
constraints: edit Obsidian only; do not change gateway config
deliverable: changed file path and validation notes
```

### Review

```text
review: Projects/Atlas Discord Telegram Workflow.md
context: check clarity, missing limits, and unsafe side-effect assumptions
deliverable: blockers first, then suggestions
```

### Schedule

```text
schedule: every weekday at 9am, summarize open Atlas capability upgrade blockers
context: kanban board atlas-capability-upgrades
deliverable: cron job ID and delivery destination
```

### Status

```text
status: Atlas capability upgrade program
context: Projects/Atlas Capability Upgrade Program.md and board atlas-capability-upgrades
deliverable: concise status, blockers, next review gate
```

## Verification checklist

Before this workflow is considered adopted:

- [ ] This note is linked from [[Atlas Capability Upgrade Program]].
- [ ] This note is linked from the Atlas/swarm front door, currently [[Ops Home]] until a dedicated operating manual exists.
- [ ] Telegram and Discord roles are clear and distinct.
- [ ] Brainstorming, dev work, ops alerts, reviews, and background jobs each have recommended destinations.
- [ ] Every command prefix has a purpose and at least one example.
- [ ] Platform limits are prominent and explicit.
- [ ] Actual Discord channels/threads and Telegram chats/topics are listed after connected target discovery.
- [ ] Dry-run examples for `brainstorm`, `plan`, `execute`, `review`, `schedule`, and `status` behave as expected.
- [ ] Named-target sends use target discovery before sending.
- [ ] Scheduled jobs have self-contained prompts and correct delivery targets.
- [ ] Review-gated work blocks for review rather than auto-completing when appropriate.

## Open follow-ups

- Fill in the concrete Discord/Telegram target map when gateway/channel discovery is available.
- Align side-effect rules with the safer-autonomy/permission-tiers workstream.
- Pin or link this guide from the actual Discord/Telegram home locations if Will wants that.
