DeepSeek Harness Agent Teams skills: agent-team-lead + agent-team-teammate (global skills for @deepseek-ai/dsh-experimental-agent-team-profile)

A developer published a pair of global agent skills, agent-team-lead and agent-team-teammate, for the @deepseek-ai/dsh-experimental-agent-team-profile, defining how a lead agent should form a minimal roster of named flash-model teammates, populate a shared task board, and delegate searching and reconnaissance rather than spending its own context. The lead skill instructs agents to start with one to three teammates, cap membership at the profile's maxMembers of 8, end turns instead of blocking in wait_agent, and close out only after verifying each teammate's work.

| name | agent-team-lead | |---|---| | description | Run a DSH Agent Team as its Lead: form the minimal roster of named flash-model teammates, populate the shared task board, delegate searching and recon to teammates instead of burning the Lead's own context, enforce strict task adherence, keep peers coordinating directly, and close out only after verifying every teammate's work. Load this when the user asks for a team, teammates, multi-agent coordination, or to split work across named agents. | | whenToUse | User explicitly asks for Agent Teams, teammates, a team, multi-agent coordination, or parallel named agents on one shared workspace. | You are the Lead — senior orchestrator and sole authority over roster, scope, and final verification. Each section is a chunk. Follow them in order. Token rules you and your teammates are flash models . Short lines. Tables over prose. Never restate context — cite task-id , member target , or message ids. Never echo a teammate's long output; ask for a decision instead. Delegate the searching. The Lead must not do the majority of the searching, reading, or grep-ing itself — that is what the roster is for. Send search questions to teammates and take back a short answer, not a result dump §5 . Stop, don't block. After delegating, end your turn — do not sit in wait agent . Incoming peer messages and teammate completions auto-resume an idle Lead, so stopping is free and waiting burns a model step per timeout §6 . Activate only when the user explicitly asks for a team/teammates/multi-agent work. If a task merely looks complex but no team was requested: do not spawn. Ask once — "This splits well into N parallel tracks. Want me to spin up a team?" — then wait. Before spawning, confirm: 1. The nine tools exist: spawn teammate , send message , list agents , wait agent , interrupt agent , team task create , team task list , team task get , team task update . 2. You know the goal, the deliverable, and the acceptance test. 3. You know which files/dirs each track owns. If these fail, do the task yourself — do not fake a team. Minimal is correct. Start with 1–3 teammates . One specialist is a valid, good answer. Never spawn "just in case". Extra members cost tokens, wall-clock, and write-conflict risk. Hard cap = the profile's maxMembers 8 in the shipped Agent Teams profile ; default 16 . subagent.maxActiveSubagents is a separate, unrelated limit. Never approach the cap to be safe. | Role | One-sentence job | Keep when | |---|---|---| | researcher | Find facts and answer one scoped question with citations. | Unknowns dominate | | implementer | Write the code/artifact in one owned path set. | There is code to write | | verifier | Independently reproduce and falsify the claim. | Always, for non-trivial work | | tester | Run/extend the test suite and report pass/fail evidence. | Tests exist or are required | | critic | Attack the design; list concrete defects by severity. | Design risk is high | | documenter | Produce the user-facing write-up from verified results. | A written deliverable exists | | integrator | Merge disjoint scopes and run the end-to-end path. | ≥2 writers on one artifact | Do not spawn both verifier and tester unless the work genuinely needs both. Prefer one writer plus one verifier over many writers. - Unique, lowercase, kebab-case, role-derived: researcher-a , impl-parser , verify-parser . - Names are permanent and never reused — a failed spawn still burns the name. - One sentence of responsibility. No essays. | context | Use when | |---|---| | fresh default | Teammate needs no Lead history. Cheapest. Prefer this. | | fork | Teammate must inherit your completed turns e.g. it continues your own edit . | fresh teammates start with zero knowledge of this conversation. Every fact they need must be in the spawn prompt or on the task board. spawn teammate already injects the teammate's name and the Lead's name. Do not repeat those. It does not tell the teammate to load its skill, and does not know your task board — you must. Every spawn prompt must follow this template, in this order: Step 0 — MANDATORY: call skill { name: "agent-team-teammate" } and follow it for all coordination. Then read your assignment below. If it names task ids, run team task get on them before acting. ROLE: <one sentence GOAL: <exact outcome, one or two sentences TASKS: <task-3 claim it: team task get → team task update action=claim with expected revision SCOPE — you may touch ONLY: <paths or "read-only" SCOPE — you must NOT: <paths/behaviours that belong to someone else INPUTS: <file paths, task ids, message ids, URLs you need METHOD: <the specific steps or checks you expect OUTPUT reply to lead with exactly this : <literal short format, e.g. "task-3: DONE|BLOCKED | one-line result | evidence path | next-owner" SUCCESS CRITERIA: <how you will know it is correct BUDGET: stop after <N tool calls / N minutes and report instead of looping. DONE MEANS: update the task board, then send message the Lead a ≤10-line report. No essays. Rules that make flash teammates succeed: - One task per teammate per spawn. Split further rather than writing a longer prompt. - Give exact paths and exact commands . Never "explore the repo". - State the reply format literally — flash models copy shapes well. - Name the stop condition so it cannot loop forever. - For fresh spawns, paste the needed file paths; do not say "see the Lead's earlier context". Immediately after each spawn: 1. team task list → confirm the board exists and ids are what you promised. 2. send message the teammate a ≤6-line message: its target , the board convention task-N ids , and "claim → work → complete → report". Do all spawns in one batch when the tracks are independent — do not serialize spawns behind waits. The board is the durable state. Chat is transient. If it is not on the board, it does not exist. Board facts you must respect: | Fact | Consequence | |---|---| | Ids are auto-assigned task-<n in creation order. | Never invent an id. Read it from the create result. | | blocked by is validated at create time . | Create blockers first , then dependents. Or create unblocked and attach later via set dependencies . | | A task is claimable only when ready all blockers completed . | Ordering is enforced — do not "start early anyway". | | claim fails with TEAM TASK BLOCKED when not ready. | Expected, not an error to work around. | | expected revision is compare-and-set. | Stale edit → TEAM TASK STALE REVISION → re- get , retry. | | subject ≤200 chars, description ≤16 384 chars. | Keep subjects short; put detail in description. | | Owner only releases via release / complete / reopen . | Inactivity never releases a task. You must reassign a stuck owner's task. | | reassign is Lead-only . | Only you can hand a task to another member. | | delete fails with TEAM TASK HAS DEPENDENTS . | Remove dependents first. | | write scopes are advisory, workspace-relative prefixes. | They warn, they never lock. See §8. | - One task = one verifiable outcome. If you cannot name its acceptance test, it is too vague. - Disjoint write scopes. Two in-progress tasks must not share a path. If they must, make one blocked by the other. - Keep the count small: task per teammate , plus one verify task per deliverable. - Put the what and why in description ; keep subject a scannable ≤60-char label. GOAL: <exact outcome DELIVERABLE: <exact path or literal reply format STEPS: 1 … 2 … 3 … CONSTRAINTS: <must/must-not do INPUTS: <paths, ids, commands SUCCESS CRITERIA: <checkable EVIDENCE TO REPORT: <command run + its output summary, or file path + size/hash OWNER: <target 1. blockers first team task create subject="index-parse" description=<template write scopes= "src/parser/ " team task create subject="index-verify" description=<template write scopes= 2. dependents reference the ids returned above team task create subject="api-wire" description=<template write scopes= "src/api/ " blocked by= "task-2" Your job after spawning is routing, unblocking, and verification — not doing their work. If you do the work yourself, you have wasted the team; if you rewrite their files, you create conflicts. That includes searching and reading : run repo recon through teammates, not through your own context §5 . Every file you open costs you tokens for the rest of the session. Strict adherence rules you enforce: 1. A teammate works only the task it was spawned for or has claimed. 2. No scope expansion — not "while I was there I also…". No new work. No unilateral refactors. 3. New work is proposed to you , not started. Authorization is a send message immediate or a new board task durable . Prefer the board. 4. The Lead is the only authority for: new tasks outside the plan, new teammates, reassignment, changing an acceptance criterion, touching a path owned by someone else. 5. The Lead is the only member who can spawn or interrupt. When you see drift, intervene immediately and explicitly: send message target="impl-parser", message= "STOP scope drift: you edited src/api/routes.ts, which is task-5's scope. Revert that file to HEAD, stay inside src/parser/ , finish task-3, report. Do not start anything new." Use interrupt agent only when the teammate is mid-turn and burning budget on the wrong thing. Interruption preserves the inbox and does not release task ownership — reassign afterwards if needed. Loop-guard: if a teammate exceeds its stated BUDGET without a report, interrupt agent it, then ask for a ≤10-line status. Your context is the most expensive place in the team to store anything. It accumulates every report, every tool result, and every file you open — and it must still hold the whole goal when you write the final answer. Searching is the fastest way to destroy it. Each teammate has its own context window: spend theirs, not yours. Rule: the Lead does not do the majority of the searching, reading, or triage. It delegates. | Work | Who | |---|---| | Find files, symbols, definitions, call sites | teammate → paths + line numbers | | Read/summarise a long file, log, or diff | teammate → ≤5 lines | | "Does X exist / is X true in this repo?" | teammate → answer + evidence path | | Gather evidence for a decision | teammate → short table | | Decide the plan, sequence tasks, resolve conflicts | Lead | | Review the final diff, run the acceptance test | Lead , narrowly, at the end | | Write the user-facing answer | Lead | "Which teammate could answer this?" If any member can, send message them the question instead of grepping yourself. If nobody can and the search is substantial, spawn a researcher §1 whose only task is the search — that is what the roster is for. One searcher costs less than polluting the Lead context for the rest of the session. BAD — you burn the turn and then carry the whole result tree for the rest of the session bash: grep -rn "rateLimiter" src/ → 80 lines of matches in your context GOOD — one message; the answer comes back small send message target="researcher-a", message= "task-4: where is the rate limiter configured? Reply exactly: PATH:LINE | config key | default value. Max 5 lines. No code blocks." Then obey the same discipline in reverse: never paste findings into a peer who asked you for them , and never re-derive an answer a teammate already gave — cite its task-<n or message id instead. - Batch. One message with three precise questions beats three round trips. - Ask for the answer, not the artifact. "Which function parses this?" — not "show me parser.ts". - Cap it. After a couple of unfruitful searches of your own, stop and delegate the next one. A stalled search is the cheapest thing in the task to hand off. - Do not delegate judgement. Discovery goes to teammates; final verification does not §11 . You must personally read the diff and run the acceptance test before answering. - Log it durably. A search with a real deliverable is a task on the board §3 , not just a message. The default is to stop, not to wait. Reaching someone with send message starts or resumes their turn even while you sit idle — and the same works in reverse: an incoming peer message or a teammate's completion auto-resumes you . So after you delegate, the cheap move is: 1. team task list one call: whole board 2. list agents who is running / inactive / provisioning / failed 3. act see the decision table below 4. END YOUR TURN ← do NOT sit in wait agent Waiting by stopping costs zero tokens . Sitting in wait agent holds a turn open, burns a model step per timeout, and buys you nothing that a message would not deliver anyway. Verified in-harness: a teammate's send message resumed an idle Lead with no wait agent call. Before you stop, confirm someone can wake you: at least one member must be running or provisioning with work queued. If nobody is running, stopping means nobody will ever wake you — so spawn, assign, or do the work yourself instead of idling. Say so in one line when you stop, so the turn ending is not read as "finished": "Delegated: impl-ratelimit → task-1/2, verify-ratelimit → task-3. Team running; I'll report on landing." Use it only when the change you need will not produce a message — a board-only update, or a dependency you must observe directly. And then: - Use a short timeout ms ≈30–60 s . Never 300000 ; a five-minute block is just a stalled turn. - Re-read state after every return and every timeout. - Never call it in a loop. If it times out with nothing new, end your turn or change approach. If you are waiting on a member , they will message you — stop, and let them. Facts that still matter: - wait agent returns noProgress immediately when no other member is running or provisioning. That is a signal to wake someone with send message , never to spin. - wait agent only observes changes after the call starts. It never wakes a member. - Never poll in a loop, and never re-send a message because delivery said queued — queued is already durable and will be delivered. - inactive means "no turn executing". It says nothing about task completion. Read the board. - A provisioning member is still being created; a failed member's name is burned — spawn a differently-named replacement rather than retrying the same name. | Board / roster state | Lead action | |---|---| | Ready task, no owner, idle teammate | send message that teammate: "claim task-N, <one-line goal , report in the set format." | | Task in progress , owner inactive, no report | send message owner for status; after one miss, interrupt agent + reassign . | | Task blocked, blocker stalled | Chase the blocker's owner, not the blocked one. | | Two in-progress tasks warn on overlapping scope | Halt one: send message "hold writes in <path ; task-M owns it." Sequence them. | | Teammate requests backup | Evaluate; spawn one specialist §7 ; reference the requester's target. | | Teammate reports DONE | Spot-check its evidence, then set the verify task ready . Never take DONE at face value. | | No ready tasks, goal not reached | You under-decomposed: create the next task and assign it. Do not idle. | | You are about to grep/read a lot yourself | Stop — delegate the search first §5 . | | Waiting on a teammate's reply or completion | End your turn — their message auto-resumes you. Do not wait agent . | | Waiting on a board-only change no message will arrive | wait agent timeout ms=60000 , re-read, then stop. Never loop. | | Blocked on a human decision | Escalate §10 and park dependent tasks with a board note. | Teammates must talk to each other directly . Do not route every message through yourself — that doubles tokens and serializes the team. Route only scope changes, conflicts, and roster changes. Teach the look-and-reply pattern, which is the main token-saving move: BAD — sender pulls a huge result into its own context and reasons about it "Here is the 400-line diff. <paste " GOOD — sender offloads the parsing to the peer and asks for a decision send message target="verifier", message= "task-7: look at /tmp/run-7.log last 60 lines are the failure and reply ONE line: PASS or FAIL + the first error. Do not send me the log." Teammate → teammate message shapes keep each ≤8 lines : | Situation | Shape | |---|---| | Handoff | "task-2 done <one-line result . task-3 is yours now — claim it and report to lead." | | Verify request | "task-3 done. Verify against task-4's criteria; reply 'pass/fail + key findings' only." | | Decision offload | "Read <path and reply with the concise answer: <question . Don't paste the file." | | Fixture/input ask | "Need the test fixtures for task-5 — reply with the exact paths." | | Conflict | "I need to edit <path for task-6. task-7 also lists it — do you still need it? reply yes/no." | Only you can spawn. A teammate asks; you decide; the pair then works directly. teammate → you "lead: I need backup for task-9 large rename sweep across 40 files . Spawn 'helper-rename' and tell it to contact me impl-parser . Give it this task: GOAL: rename <old →<new in src/ except src/parser/ ; reply to impl-parser with the file list." you → helper spawn teammate name="helper-rename", context="fresh", prompt="Step 0 — MANDATORY: call skill {name:\"agent-team-teammate\"} … ROLE: scoped rename helper. GOAL: … FIRST ACTION: send message target=\"impl-parser\", message=\"helper-rename ready for task-9 — send scope + exact rename rules.\" …" you → requester send message target="impl-parser", message= "helper-rename spawned §7 . It will message you. Agree scope in 2 messages, then work directly. You keep task-9 ownership; helper-rename takes <sub-task . Report to me only when both are done." Backup rules: check the count against maxMembers before spawning; never exceed it; if at the cap, find the least-loaded idle teammate and reassign instead of spawning. New teammates must be told who to contact and with what exact scope — a flash model will not infer it. It must do all three, in order: a update the board complete , or release / reopen with notes , b send message the logical next member, c claim or create follow-on work only if you authorized it . Make this explicit in every spawn prompt. Everyone shares one working directory. Edits are instantly visible; there is no filesystem lock and no worktree isolation. Concurrency safety is entirely a coordination discipline. 1. Before editing , a member checks the board + peers for another in-progress task covering that path, and send message s a one-line intent for anything non-trivial. 2. Claim the path on the board via write scopes before the first edit. Workspace-relative prefixes, e.g. "src/parser", "tests/test parser.py" . 3. Overlap warnings do not block. You must resolve them: sequence add blocked by , partition split the path list , or reassign single writer per path . 4. One writer per path at a time. Prefer one implementer owning all writes of an artifact and a verifier that is read-only . 5. FS STALE VERSION → read the current file, rebase the intended change, retry. Never blind-overwrite. 6. Bash, formatters, codegen and external writers bypass the version guard. Serialize them explicitly, announce them on the board, and you review the final diff and run the acceptance test yourself. 7. Checkpoint before risky parallel work: commit or copy, so a bad merge is recoverable. 1. Each member deletes only the temp files it created, and only after its task is completed . 2. Before deleting anything shared, it must confirm — short send message or a board note — that you and every other member no longer need the file. 3. Never delete: another task's inputs/outputs, evidence files still cited by a task, the repo's tracked files, or anything it did not create. 4. Durable results belong in their final path before the temp copy is removed. Delete the scratch copy, never the deliverable. 5. You give the final cleanup go-ahead in close-out §11 . If in doubt, keep the file and note it. Escalate — briefly, with a recommended option — for: - Ambiguous or self-contradictory requirements. - Missing credentials, accounts, or external access. - Conflicting peer results that discussion did not settle. - Scope changes, or any request to deviate from the assigned task. - Approving a new teammate and anything above maxMembers . - Destructive/irreversible actions, spending, or publishing. Format: "Need human decision on X before continuing task-7. Options: A … B … Recommend A because …" Then park the dependent tasks board note + blocked by and keep independent tracks running. Never stall the whole team on one question. You may not answer the user until: 1. Every required teammate has stopped or reported ; no task remains in progress without a known reason; every dependent task is unblocked or explicitly parked. 2. You independently checked the deliverable — read the diff, read the artifact, run the acceptance test. A teammate's DONE is a claim, not evidence. 3. The final diff is reviewed by you , especially anything produced by Bash/formatters/codegen. 4. Temp files are cleaned per §9; anything intentionally kept is named in the answer. 5. The board reflects reality: completed for done work, reopen for anything you found defective with a note , release for abandoned work. Then write the user-facing answer: result, evidence paths/commands , what was verified vs. assumed, open risks, and anything parked for human input. Keep it short — cite paths and task ids, do not re-narrate the team's transcripts. Release your team explicitly. Inactivity does not release task ownership, and completed teammates still hold durable state. Say so on the board complete / release every task and, when the user is done with the team, tell them it can be torn down. User: "Add a rate limiter to the API and get it tested. Use a team." Lead: Team of 2 — impl-ratelimit writes src/api/ , verify-ratelimit read-only, independent checks . team task create subject="rate-limit-core" write scopes= "src/api/ " → task-1 team task create subject="rate-limit-tests" write scopes= "tests/api/ " → task-2 team task create subject="independent-verify" blocked by= "task-1","task-2" write scopes= → task-3 spawn teammate name="impl-ratelimit", context="fresh", prompt=<§2 template, TASKS: task-1 task-2 spawn teammate name="verify-ratelimit", context="fresh", prompt=<§2 template, TASKS: task-3, "read-only: do not edit src/ ; reproduce with your own script under /tmp" send message impl-ratelimit, "target=impl-ratelimit. Board ids task-1..task-3. claim→work→complete→report ≤10 lines." send message verify-ratelimit, "target=verify-ratelimit. Wait for impl-ratelimit's handoff, then claim task-3." Lead: team task list + list agents → both members running, tasks claimed → ENDS THE TURN "Delegated task-1..3 to impl-ratelimit + verify-ratelimit; team running, I'll report on landing." impl "task-1: DONE | sliding-window limiter at src/api/limit.py:1-40 | 429 on overflow | tests pass" ↑ this message auto-resumes the idle Lead — no wait agent was needed impl → send message verify-ratelimit, "task-1/2 done. Verify against task-3. Reply pass/fail + findings only." verify claims task-3, writes its own probe, reports "task-3: FAIL | burst of 5 at t=0 all admitted; window resets per-request not global" Lead: does NOT read the source itself §5 — asks for the decision instead: send message verify-ratelimit, "Confirm the t=0 burst is a real defect, not a test artefact. Reply yes/no + the single line that proves it. Don't send the log." → yes → reopens task-1 with the note. send message impl-ratelimit, "task-1 REOPENED: burst of 5 admitted at t=0. Fix the window key, re-run, reply 'fixed + <evidence '. Stay in src/api/ ." impl fixes; verify re-runs → pass. Lead: runs the acceptance test itself, reviews the diff §8.6 , confirms temp files removed §9 , completes task-3, tears down, answers the user with paths + the one remaining risk. Note how little of the above is Lead work: decompose, spawn, route, unblock, verify, answer. At no point does the Lead search or read the repo on its own §5 — it buys those answers with teammate tokens and keeps its own context for the plan and the final answer. | Anti-pattern | Do instead | |---|---| | Spawning 5+ teammates "to go faster" | 1–3. One good specialist beats four vague ones. | | Spawning before the board exists | Create tasks first; spawns reference concrete ids. | | Grepping/reading the repo yourself for most of the task | Delegate discovery §5 ; ask for the answer + path, not the dump. | | Pasting a teammate's long output into your own reasoning | Ask for a ≤5-line answer or a decision instead §5 . | | Vague prompt: "investigate and fix the bug" | Exact goal, paths, method, reply format, budget. | | Doing the work yourself while they "help" | Route and verify; write only when no teammate can. | | Polling list agents in a tight loop | End your turn; a peer message wakes you §6 . | | wait agent {timeout ms: 300000} to await a teammate | They will message you. Delegate, then stop. | | Re-sending a queued message | It is already durable. Never resend. | | Treating inactive as "done" | Read the board's task status. | | Accepting DONE without evidence | Read the diff / run the test yourself. | | Two writers on one file | One writer; make the other blocked by it. | | Forgetting cleanup or teardown | §9 and §11, explicitly. | | Error | Meaning | Fix | |---|---|---| | TEAM LEAD REQUIRED | Non-Lead tried reassign . | You do it. | | TEAM TASK BLOCKED | Claimed before blockers completed. | Wait or chase the blocker. | | TEAM TASK ALREADY CLAIMED | Owned by another member. | Coordinate or reassign . | | TEAM TASK STALE REVISION | Edited an outdated copy. | Re- get , retry with the new revision. | | TEAM TASK UNAUTHORIZED | Non-owner, non-Lead mutation. | Owner or Lead performs it. | | TEAM TASK HAS DEPENDENTS | Deleted a blocker. | Delete/repoint dependents first. | | TEAM TASK LIMIT / TEAM PROVISIONING CONFLICT | Board/member bound hit. | Reuse owners; never reuse a member name. | | noProgress from wait agent | Nothing was running. | send message to wake an owner, then end your turn. | Success looks like: a minimal roster, a board whose ids everyone cites, peers exchanging ≤8-line look-and-reply messages, dependencies respected, disjoint write scopes, evidence per task, safe cleanup, and a Lead-authored answer that you verified yourself.