メニュー
Use when admin requests creating a team, importing a team, managing team composition, adding/removing workers from a team, or delegating tasks to a Team Leader.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | team-management |
| description | Use when admin requests creating a team, importing a team, managing team composition, adding/removing workers from a team, or delegating tasks to a Team Leader. |
A Team consists of 1 Team Leader + N Workers. The Team Leader is a special Worker with management skills that handles task decomposition and assignment within the team. Manager delegates tasks to Team Leaders, not directly to team workers.
# 1. Create team via hiclaw CLI
hiclaw create team \
--name <TEAM_NAME> \
--leader-name <LEADER_NAME> \
--leader-model <MODEL> \
--workers <w1>,<w2>
# 2. @mention the Leader in Leader Room to assign task
After creation, the Leader is online in the Leader Room (Manager + Global Admin + Leader). @mention the Leader there to delegate the task — the Leader will decompose it and coordinate with team workers in the Team Room.
Full workflow: read
references/create-team.md
If admin asks for CPU or memory requests/limits, use a YAML Team manifest with leader.resources and/or workers[].resources, then apply it with hiclaw apply -f. The simple hiclaw create team / hiclaw update team flags do not expose resource tuning. Changing member resources recreates the affected member container, so confirm the team is not mid-task.
--team-admin not specified--delegated-to-team — so heartbeat knows to check with Leader, not workersruntime: copaw for all team members — omit runtime from team creation| Admin wants to... | Read | Command |
|---|---|---|
| Create a new team | references/create-team.md | hiclaw create team |
| Understand team lifecycle | references/team-lifecycle.md | — |
| Delegate task to team | references/team-task-delegation.md | — |
| Add/remove worker from team | references/team-lifecycle.md | hiclaw get team |
| Delete a team's containers | references/team-lifecycle.md | scripts/lifecycle-worker.sh (per worker) |
Discover and call MCP Server tools via the mcporter CLI. Use when your coordinator notifies you about new MCP tools, or when you need to call external APIs. Includes workflow for generating skill documentation for new MCP servers.
Use when TEAMS.md Communication Contract needs detailed routing: Channel / Room Selection Protocol, Requester Report Delivery Protocol, or Message Tool Protocol. It resolves current session vs Team Room vs assignment room vs requester reply_route vs external channel, and explains when to use the message MCP tool. Do not use it to choose Quick Task or Project Work, create rooms, delegate tasks, check results, or accept project state.
Use for TeamHarness shared workspace paths, explicit filesync operations, and shared project/task artifact boundaries.
Use to understand TeamHarness team roles, responsibility boundaries, and who owns project, task, runtime, and control-plane work.
Use only after Project Work mode is selected, before TeamHarness projectflow calls, project DAG or Loop planning, ready-node resolution, iteration recording, project files, result acceptance, or project progress updates.
Use only after Project Work mode is selected, when a TeamHarness Leader delegates ready project nodes, writes task specs, checks Worker results, and routes completion or blocker messages.