# Atlas Skill Backlog

Last updated: 2026-05-14
Owner: ops profile
Source workstream: Atlas Capability Upgrade Program — Workstream 10

## Policy

Create or patch a skill only after the workflow is verified. If a workflow depends on a policy decision, another workstream, unverified endpoint behavior, or missing owner input, keep it in this backlog until the dependency is resolved.

Backlog items should graduate to a skill when there is a solved recurring workflow, clear trigger conditions, safe commands/API calls, pitfalls, and verification steps.

## Backlog

### 1. `atlas-discord-telegram-workflows`

- Proposed category: `devops` or `productivity`
- Owner profile: ops, with Atlas/project-lead review
- Dependency: Workstream 2 Discord/Telegram workflow design
- Scope: channel/thread conventions, gateway commands, topic/session behavior, notification expectations, review/approval paths.
- Ready when: channel/thread vocabulary and gateway limitations are documented and at least one end-to-end message workflow has been verified.
- Acceptance: agents can decide where to respond, when to use home channel vs topic/thread, and how to route background job/review notifications without guessing.

### 2. `atlas-obsidian-project-memory`

- Proposed category: `note-taking`
- Owner profile: writer / ops
- Dependency: Workstreams 1 and 8
- Scope: Atlas front-door note, project context index, session-to-note promotion, durable artifact destination conventions, specialist context packs.
- Ready when: Workstream 1 chooses the project memory structure and Workstream 8 chooses templates/destinations.
- Acceptance: a specialist can orient from Obsidian notes without rereading old chats and knows where to write durable state.

### 3. `atlas-local-services`

- Proposed category: `devops`
- Owner profile: ops
- Dependency: Workstream 3 custom tools/infrastructure inventory
- Scope: safe health/use patterns for SearXNG/Brave search, n8n, Ollama embeddings, Kokoro, Whisper, Obsidian Local REST API, and host-side service checks.
- Ready when: endpoints, auth boundaries, health checks, and safe wrappers are confirmed without exposing secrets.
- Acceptance: repeated shell/API sequences are represented as safe wrappers, commands, or tool usage patterns with verification steps.

### 4. `atlas-kanban-project-playbook`

- Proposed category: `devops`
- Owner profile: ops / atlas
- Dependency: Workstream 4 stronger Kanban-driven multi-agent work
- Scope: Will-specific board templates, default task graph patterns, reviewer gates, blocked/crashed worker recovery, synthesis handoffs.
- Ready when: the program-level Kanban workflow is accepted and at least one implementation/review cycle is complete.
- Acceptance: future durable projects can be decomposed, reviewed, and synthesized consistently without single-chat state loss.

### 5. `atlas-evaluation-loop`

- Proposed category: `software-development` or `devops`
- Owner profile: reviewer / ops
- Dependency: Workstream 9 evaluation loops
- Scope: mapping eval failures and smoke-test results into skill patches, new backlog items, or tool/config fixes.
- Ready when: repeatable evaluation scenarios and result logs exist.
- Acceptance: agent quality regressions produce actionable skill/tool/config follow-up instead of informal observations.

## Review rules

- Do not promote a backlog item into a skill until dependencies are met and the workflow is verified.
- If promotion requires code/config changes or production gateway behavior changes, use a review-required Kanban handoff.
- Keep secrets, raw auth tokens, and runtime state out of this note.
