Deepseek Automation

DeepSeek Automation

Use this project-local skill for the DeepSeek++ automation implementation. The feature goal is: create Codex-style automations that can run immediately in a new DeepSeek chat session and then continue in that same automation session on a cron/RRULE-like schedule.

Start Every Session

1. Read docs/progress/MASTER.md.
2. Confirm tracking mode. Current mode is GITHUB_STANDARD.
3. Query GitHub before starting work:

gh issue list -R zhu1090093659/deepseek-pp --label "spec-driven" --state open --json number,title,labels,milestone

4. Pick the next open issue in dependency order unless the user names a task.
5. Read the selected Issue body and linked local docs under docs/analysis/ and docs/plan/.
6. Update docs/progress/MASTER.md Current Status at session start and end.

Architecture Rules

• Keep scheduling in background code.
• Keep actual DeepSeek request execution in the DeepSeek page main-world context.
• Use content script only as a narrow bridge between background and main world.
• Do not add automation business logic directly into fetch-hook.ts unless the task is explicitly about hook compatibility.
• Prefer new focused files under core/automation/.
• Do not rely on background-only fetch('/api/v0/chat/completion') for MVP; DeepSeek web completion has challenge/proof-of-work behavior.
• Preserve existing memory, skill, preset, and tool-call behavior unless the Issue explicitly changes it.

DeepSeek Web Facts

Verified on 2026-05-21:

• Completion endpoint: /api/v0/chat/completion.
• History endpoint: /api/v0/chat/history_messages.
• Completion request fields include chat_session_id, parent_message_id, model_type, prompt, ref_file_ids, thinking_enabled, search_enabled, action, and preempt.
• New session and same-session continuation work from the web UI.
• Reload restores the automation test session from history.
• Persist the latest valid parent message id after every run and reconcile it against history.

S.U.P.E.R Principles

S - Single Purpose

From Unix philosophy.

• Each module, file, and function solves exactly one problem
• Prefer decomposition; power comes from composition
• One skill does one thing, one worker does one thing, one script does one thing

Litmus test: if you cannot describe a module's responsibility in a single sentence, it needs to be split.

Anti-pattern: a script that fetches data, computes metrics, renders charts, and sends notifications.

Correct approach:

fetch_data.py  -> data retrieval only, outputs JSON
compute.py     -> computation only, reads JSON writes JSON
render.py      -> rendering only, reads JSON generates HTML
notify.py      -> notification only, reads JSON calls webhook

U - Unidirectional Flow

From Clean Architecture.

• Data always flows in one direction: input -> processing -> output
• Dependencies always point inward: outer layers depend on inner layers, inner layers know nothing about outer layers
• No reverse dependencies, no circular calls

Layered model:

+-------------------------------+
|  Infrastructure (API, DB, UI) |  <- outermost, replaceable at will
+-------------------------------+
|  Adapters (transform, format) |
+-------------------------------+
|  Core business (pure logic)   |  <- innermost, zero external deps
+-------------------------------+

Litmus test: can the core logic run unit tests with zero external services? If not, the dependency direction is wrong.

P - Ports over Implementation

From Hexagonal Architecture.

• Define interface contracts (data structures, JSON Schema) before writing implementation
• Use intermediate formats (JSON files, standard data structures) to isolate upstream from downstream
• Swapping a data source, a rendering layer, or a notification channel requires zero changes to core logic

Practices:

1. Every module's input and output must be a serializable data structure
2. Module boundaries communicate via JSON files or standard data structures; in-process typed objects are fine, but cross-module interfaces must be serializable
3. Define explicit schemas - not "just read the code to figure out the format"

E - Environment-Agnostic

From 12-Factor App.

• Configuration injected via environment variables or config files, never hardcoded
• All dependencies explicitly declared (requirements.txt / package.json), no implicit reliance on global system packages
• Processes are stateless; all persistence delegated to external storage
• Logs go to stdout, not to files
• Same codebase runs on local machine, Cloudflare Workers, VPS, Docker

Configuration precedence:

Environment variables > .env file > config.json > in-code defaults

Checklist:

• All API keys and webhook URLs read from environment variables?
• All dependencies explicitly declared in a dependency file?
• No hardcoded file path assumptions?
• Can a different machine run this code with zero modifications?