team-message-intake

name	team-message-intake
description	Use when a Team inbox, channel, thread, or human-visible message must be routed into a direct reply, thread reply, mailbox update, task note, or canonical Team task.

Team Message Intake

Use this skill before turning a Team message into work. The goal is to keep visible conversation responsive while preserving the canonical task, mailbox, and thread boundaries.

Intake Order

1. Identify the source surface.

   • Direct inbox: private coordination or assignment.
   • Channel root: summary entrypoint for one topic.
   • Thread: full-context lane for a channel topic.
   • Human direct prompt: visible user request or correction.

2. Decide whether a visible acknowledgement is owed now.

   • Reply quickly when the sender is human-visible and the message is actionable, blocking, or asking for ownership.
   • Keep the reply on the original visible surface unless the message already carries a better concrete reply target.
   • Do not hide a human question behind mailbox-only coordination.

3. Open or use the topic thread when deeper context is needed.

   • Keep channel root posts concise.
   • Put detailed reasoning, logs, evidence, and back-and-forth in the thread.
   • Use agenthub actor team-thread-open for a new topic that needs deep follow-up.
   • Use agenthub actor team-thread-reply for topic-specific follow-up after the thread exists.

4. Choose the work surface.

   • Direct reply: quick factual answer or ownership signal.
   • Thread reply: topic-specific detail, evidence, or continuing discussion.
   • Mailbox: exactly one teammate owns the next action.
   • Task note: the fact changes canonical task plan, blocker, decision, or result evidence.
   • Canonical task: durable ownership, multi-step execution, or lifecycle tracking is required.

Task Creation Gate

Create a canonical Team task only when all of these are true:

• the work needs durable ownership beyond one short reply;
• the owning member is explicit;
• priority is explicit;
• acceptance criteria can be stated;
• the action is agent-owned, not a direct HTTP task creation by a normal user path.

Do not create a canonical task for every channel message. For a quick answer, reply on the original surface and avoid task choreography.

Required Companion Skills

• Load team-actor-mailbox for routing, acknowledgement, open-thread, and reply mechanics.
• Load team-task-governance before changing task fields, notes, assignee, priority, or context.
• Load team-task-lifecycle before moving task state.
• Load team-reporting-surfaces when choosing whether evidence belongs in task notes, mailbox, or channel/thread.

Evidence Receipt

When reporting completion or a blocker, include:

• the source message or thread;
• chosen surface and reason;
• task id or mailbox target when applicable;
• evidence pointer such as task note, thread reply, command output summary, or detail_ref;
• what the evidence proves and what it does not prove.

Stop Conditions

Stop and ask for coordinator/human clarification only when:

• no owner can be chosen safely;
• task creation would cross an explicit governance boundary;
• the requested action is destructive, externally visible, or irreversible;
• the message depends on preference or product judgment that cannot be inferred from existing docs.