delegate-deepseek-tasks

Delegate Tasks to DeepSeek

Use the primary GPT/Sol model as planner, integrator, and final authority. Use DeepSeek agents as isolated implementation workers. Never treat a worker result as trusted merely because its task completed or its internal tests passed.

Follow the workflow

1. Establish the local baseline

Inspect the repository and user request before delegating. Confirm:

• the requested outcome and acceptance criteria;
• the current Git state and relevant project instructions;
• the files or modules that may change;
• required tests and commands;
• whether the task is read-only or authorizes implementation.

Do not submit secrets, credentials, private keys, environment files, customer data, or unrelated proprietary context to DeepSeek. Do not clean, reset, stash, or overwrite user changes to satisfy the worker's clean-worktree requirement.

Call the DeepSeek MCP capability and health tools when availability, limits, or Bridge compatibility are uncertain. Require a phase-2 Bridge with thinking/tool round-trip support for Agent Jobs.

2. Decompose the task in GPT/Sol

Create a small dependency graph before submitting work. Each delegated task must have:

• one coherent outcome;
• explicit acceptance criteria;
• the smallest practical write_scope;
• relevant validation commands;
• enough context to work independently;
• no responsibility for final integration or approval.

Prefer a single Agent Job when changes are tightly coupled. Split work when components can be implemented and tested independently. Do not fragment a simple change into many tiny tasks.

Classify dependencies:

• Submit independent tasks together with submit_agent_batch.
• Submit dependent tasks sequentially after the prerequisite result is reviewed and integrated.
• Never run overlapping write scopes in parallel unless Sol intends to reconcile the conflicts manually.

Use the capability response rather than assuming fixed concurrency limits.

3. Choose model and task size