Feishu Parallel Dispatch

Use this skill when working in Feishu and the user may send another prompt
before the current task is done.

Pair it with feishu-progress-heartbeat or the equivalent heartbeat pattern so
long-running child tasks can send automatic progress updates about every 3
minutes while they are still active.

Goal

Keep the main Feishu chat responsive.

Do not let one long task occupy the foreground session when the work can be
offloaded to a spawned sub-agent.

Core Rule

For any substantial Feishu request, prefer:

1. 1. quick acknowledgement in the current chat
2. immediate INLINECODE1
3. end the current turn
4. let the child task announce its own result later

For substantial tasks, staying in the foreground without a spawned child is a
failure mode, not an acceptable fallback.

This keeps the foreground session free so the next user prompt can create its
own child task instead of waiting behind the previous one.

When To Spawn

Spawn a child task when the request is likely to need any of these:

• - web search or verification
• file creation or document generation
• multiple tool calls
• coding or debugging
• multi-step planning
• anything likely to take more than about 5-10 seconds
• any task where the user asked for periodic progress updates
• any task where the user expects the work to continue until fully complete

Do not spawn for tiny answers that can be completed immediately.

One Prompt, One Child

Treat each substantial user prompt as its own work item.

• - If task A is still running and the user sends task B, spawn another child

• - Do not wait for A to finish before starting B.
• Do not merge unrelated prompts into one child task unless the user clearly

Agent Choice

Pick the child agent with the clearest fit:

• - research: current facts, comparisons, source-backed analysis
• INLINECODE3: team planning, meeting outputs, shared project coordination
• INLINECODE4: personal planning, solo execution, personal review work
• INLINECODE5: family-shared tasks only
• INLINECODE6: couple-shared tasks only
• INLINECODE7: explicit multi-agent discussion
• current agent: when the task belongs to the same specialist context

Foreground Reply Pattern

Use short Feishu-friendly acknowledgement text, for example:

• - INLINECODE8
• INLINECODE9
• INLINECODE10

After this acknowledgement, spawn and stop. Do not stay in the foreground
session doing the heavy work.

If the spawn fails, retry once immediately with a narrower label or a more
obvious specialist. If it still fails, tell the user plainly that the
background handoff failed and what fallback path you are taking.

Do not narrate the spawn mechanics, raw action payloads, or internal command
objects to the user.

Completion Behavior

Each child task should report back independently when it finishes.

• - Do not wait for all child tasks to finish before replying
• Do not bundle unrelated task results into one final message
• If a child task fails, report the failure for that task only
• If a child task keeps running, let it produce short 3-minute progress updates with estimated percentages instead of going silent
• If a child task disappears before the user-visible deliverable is complete,

Progress Queries

If the user asks:

• - INLINECODE11
• INLINECODE12
• INLINECODE13
• INLINECODE14

Then:

1. 1. use sessions_list with tree visibility to find active child sessions
2. use session_status if needed
3. reply with a short per-task status list

Do not answer with a plan like "我先检查一下". Perform the status inspection
first and reply only with the result.

If the inspection shows no active child but the last explicit request is still
unfinished, immediately recreate a bounded continuation child for the missing
next step before replying.

Labeling

When spawning, use a short label so later status replies are readable.

Good labels:

• - INLINECODE18
• INLINECODE19
• INLINECODE20
• INLINECODE21
• INLINECODE22

If helpful, choose labels that make progress checks easier to read later.
Prefer short noun phrases over vague labels like 任务 or 处理中.

Boundaries

• - This is a dispatch pattern, not an excuse to over-spawn
• Keep one child per meaningful user request, not one child per tiny sub-step
• Do not spawn from a spawned sub-agent
• If the user explicitly wants one synchronous answer, honor that
• For long Feishu work, never let the task exist only as a foreground promise;