SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsoil-delegate

oil-delegate

Agents & models

View repository

Updated 11-03 12:52

About this skill

oil-delegate

SKILL_DIR refers to the absolute directory of the current Skill;<python> refers to Python 3.10+ (on macOS/Linux usually python3, on Windows usually py -3）；DELEGATE is shorthand for <python> "$SKILL_DIR"/scripts/delegate.py .

Core rules

  • The user only speaks natural language; the current Agent runs the wrapper and does not require the user to open another terminal.
  • Delegate only one well-scoped task at a time; a runner named by the user takes priority, otherwise use the default, and do not switch runners automatically.
  • Reuse each CLI's model, provider, and login; do not pass or store keys, and do not write keys into prompts.
  • The caller is responsible for scope, permissions, and final acceptance; an external Agent's self-reported results cannot replace workspace checks and real tests.
  • By default, external Agents are prohibited from running git add, commit, push, releases, and unrelated modifications; when the user explicitly requests otherwise, follow the current host's authorization process.

Choose a mode first

Mode When it applies Path Default stopping point
First-time Onboarding run returns NEEDS_ONBOARDING, or the user requests reconfiguration Read-only scan → user confirms enabled pool and defaults → save Report configuration, then wait for a task
New task Hand a single analysis, review, or modification to an external Agent Assemble delegation contract → run → read results and accept Report conclusions and verification evidence
Continue task Follow up on or rework the previous round's results with the same CLI Verify runner and session ID → run --session Report changes in this round
Configuration and diagnostics Inspect the environment, preview permissions, or handle failures onboard --scan、config、run --dry-run Give clear next steps

Delegation contract

The prompt should concisely cover:

  1. Goal and boundaries: what to find out or modify, and explicitly what must not be changed.
  2. Completion criteria: expected behavior, edge cases, and the results that must ultimately be delivered.
  3. Entry clues: use --file to provide 1–4 confirmed files; let the external Agent explore the rest.
  4. Verification: confirm the real test, check, or build commands from the repository configuration; do not write vague "run tests".
  5. Final report: changes and reasons, affected files, verification commands and results, and unfinished items.

If repository facts are missing, look them up first; do not guess. Diagnostics and reviews require citing files and line numbers, and must distinguish facts from inferences.

Workflow

1. Onboarding and runner selection

On first use or when NEEDS_ONBOARDING is received:

  1. The first run has already automatically completed a silent scan and returned detected/installed runners; the user does not need to run any commands. To refresh, run DELEGATE onboard --scan. The scan does not write configuration, read credentials, call models, install, or log in.
  2. Show installed runners, versions, sources, capabilities and aliases, clarifying that "installed" does not mean "authenticated". Before first-time configuration, read Runner adapter reference, and explain clearly the read/write permission differences, external service costs, and that task text will be handed to the corresponding provider.
  3. Ask which runners to enable, and whether to use a default one or ask each time. Only save after receiving an answer: 
    DELEGATE onboard --enable <claude,workbuddy,antigravity,codex,opencode,dsh,grok,kimi> --default-runner <runner|ask>

Names are case-insensitive; aliases such as cc（claude）、wb（workbuddy）、agy（antigravity）、dsh、grok-build、kimi-code can be used; enabling, default selection, delegation and binary path configuration all go through the same resolution, and are uniformly converted to the official runner name when saved.

When no runner is specified and there is no default value,run returns NEEDS_RUNNER_CHOICE. Ask for the choice this time; only run DELEGATE config --set-default-runner <runner>。

to view configuration or specify a non-standard binary path when the user agrees to persist the preference:

DELEGATE config
DELEGATE config --set-bin <runner>=<可执行文件绝对路径>

2. Dispatch a new task

  • By default omit --mode, using write and the highest permissions of each CLI; analysis, exploration and review are also not automatically downgraded.
  • Use --mode readonly when the user explicitly requests read-only, plan, or restricted permissions. Kimi's non-interactive mode comes with auto permissions and cannot guarantee read-only, so reject read and do not pretend to support it.
  • By default the current working directory is used; for cross-project cases explicitly specify --workspace。
  • Invocation:
DELEGATE run --runner <名称> \
  --workspace "<项目绝对路径>" \
  --file "<相对入口文件>" \
  --prompt "<目标、边界、完成标准与真实验证命令>"

Omit --runnerwhen a default runner is configured. Append --dry-runwhen parameters need to be verified before launch; preview does not start an external Agent.

3. Continue the original session

Read the session_idfrom the previous round's output, and only continue with the same runner:

DELEGATE run --runner <原 runner> \
  --workspace "<原工作区>" \
  --mode <read|write> \
  --session <session_id> \
  --prompt "<本轮新发现、追问或修正要求>"

Continuation sends only the new information for this round, not the entire task again. Session IDs cannot be reused across runners; when a second opinion is needed, start a new task and add the necessary background. DSH continuation must use the original cwd; if its ownership, preset or cwd validation fails, report it truthfully and do not bypass it.

4. Acceptance and failure recovery

  1. Read the summary of output_path ; when the exit code, session ID or error structure is needed, read result_path, and read events_path。
  2. only for raw protocol diagnostics. Check whether workspace changes are out of scope, check whether tests have been deleted, skipped or weakened, and then re-run the real verification commands.
  3. When rework is needed, continue the original session and send only the new findings and correction requirements.
  4. After a non-zero exit, protocol error or timeout, do not retry blindly. First fix the configuration, login state, task scope or permissions based on the error, then decide whether to start a new task or continue.
  5. When the CLI or login is missing, stop and provide the corresponding official entry point; installation and login must be separately authorized by the user.

Output and stopping conditions

On success the script outputs status、session_id、runner、output_path、result_path、events_path and elapsed. Each run has a separate directory containing the prompt, condensed Markdown, structured result, raw stdout/stderr and event log.

The final reply retains only the conclusions the user needs, actual changes, verification evidence, unfinished items and the necessary session ID. Stop after completing the current delegation and acceptance; do not expand into multi-topic management, and do not automatically generate a dashboard.

Resource navigation

  • references/runners.md: read the relevant Runner section only during first-time configuration, explicit read-only, troubleshooting a specific CLI, or maintaining an adapter; daily highest-permission delegation does not require reading it.
  • scripts/delegate.py: deterministic tools for scanning, configuration, invocation, parsing and run artifacts; there is no need to read the source code when using the Skill.
  • tests/test_delegate.py: Regression tests for eight Runners; read the relevant sections only during development or remediation.