Imported from hoinv-prv/hermes_agent_team (AGENTS.md). Install upstream with npx skills add hoinv-prv/hermes_agent_team. Copyright stays with the author.

Global Agent Team Hub

This directory is the coordination source of truth for multi-agent work across repos, Hermes profiles, and infrastructure/runtime tasks.

Core rule

Global hub owns coordination. Repo-local workspaces own repo rules, code artifacts, run evidence, and optional mirrors.

Paths

Registered agents

Registered teams

Team-specific mandatory rules

Stock Trend Prediction Dev Team

For any contract naming board stock-trend-prediction-dev-team or an STP-* mission, load and follow:

/home/hoinv/work/agent_team_hub/teams/stock-trend-prediction-dev-team/skills/stock-trend-prediction-team-flow/SKILL.md

The team manifest is the shared-membership authority. Keep Global profile identities and generic routing unchanged. Phase 1 has no cron, monitor, controller, autonomous dispatch, or real Stock pipeline execution.

Team VuHoi execution

For any task whose repo.name is vuhoi-team or whose repo.root is beneath /home/hoinv/work/agent_team_hub/teams/vuhoi-team, every Leader, Advisor, and worker must read and follow:

/home/hoinv/work/agent_team_hub/teams/vuhoi-team/TEAM_EXECUTION_SCRIPT_POLICY.md

The policy is mandatory before command execution. It requires an approved hash-pinned reusable script to be preferred over inline Python; absent one, assess and normally create/test a narrow script for HUMAN approval rather than defaulting to python3 -c or a Python here-document. A script approval never bypasses task authority or Hermes terminal policy.

Mandatory contract fields

Every task contract must include:

repo:
  name: <repo_name>
  root: /absolute/path/to/repo-or-runtime
  type: <code-repo|knowledge-repo|hermes-profile-runtime|source-repo|none>
agent_team_root: /home/hoinv/work/agent_team_hub
inbox:
  worker: /home/hoinv/work/agent_team_hub/inbox/<assigned_agent>
  leader: /home/hoinv/work/agent_team_hub/inbox/leader_agent
requested_by:
  agent: <leader_agent|delegating_agent>
  inbox: /home/hoinv/work/agent_team_hub/inbox/<delegating_agent>
report_to:
  agent: <agent_that_must_receive_handoffs>
  inbox: /home/hoinv/work/agent_team_hub/inbox/<agent_that_must_receive_handoffs>
  reason: <leader_origin|delegated_by_<agent>|other>

Workers must verify repo.root and read repo rules before editing or running commands. Workers must also verify report_to.agent + report_to.inbox before writing started, done, blocked, or approval_required messages. Do not assume handoffs always go to leader_agent: delegated tasks must report back to the delegating/reporting agent named in report_to. If report_to is absent or ambiguous, stop and request clarification from the assigner instead of guessing. Global task state is leader-owned unless explicitly delegated.

Legacy repo-local agent-team trees

Existing <repo>/.ai-work/agent_team/ directories are legacy/adapters. Use them only for historical tasks, repo metadata, optional mirrors, and repo-local evidence. Do not create new tasks there unless the user/leader explicitly says this is a legacy repo-local task.

Message naming

TASK-YYYYMMDD-...__started_<agent>.md
TASK-YYYYMMDD-...__done_<agent>.md
TASK-YYYYMMDD-...__blocked_<agent>.md
TASK-YYYYMMDD-...__approval_required_<agent>.md

Messages must be short, dense, complete, and clear. Send them to the report_to.inbox declared by the task contract, not blindly to inbox/leader_agent/.

Task dispatch (Kanban)

Kanban cards are the preferred dispatch envelope for new small/bounded tasks. The gateway auto-dispatches ready tasks to workers — no manual inbox polling.

Use Kanban for:

• Small, bounded implementation tasks with clear scope and allowed writes
• Child cards split from a parent plan/task graph
• Tasks where the full contract fits in --body

Use file inbox contracts for:

• Dense contracts needing detailed multi-section specs
• approval_required gates
• Review packages needing durable artifacts
• report_to handoff files (started/done/blocked/approval_required)
• Workers/profiles not activated through Kanban dispatch

Kanban does NOT replace:

• Parent task graphs and multi-agent governance
• requested_by / report_to declaration
• approval_required gates
• Task snapshots for pause/resume
• Dense review artifacts

Each Kanban card must carry:

• repo.name + repo.root
• requested_by + report_to
• Scope, allowed writes, verification gates

⚠️ Known caveat: Notification delivery via notify-subscribe is not yet proven. Workers should still send done/blocked handoffs to report_to.inbox as fallback until notifications are verified reliable.

Operating baseline and templates

For new bounded Kanban work, also follow AGENT_TEAM_OPERATING_BASELINE.md and use templates/kanban-card-contract.md for dense contracts. It adds explicit runtime/retry bounds, typed-block discipline, dispatch proof, and evidence-first leader acceptance without assuming untested watchdog or direct-to-member behavior. Record acceptance evidence with templates/leader-review.md.

Kanban dispatch commands (reference):

hermes kanban create --assignee <agent> --priority 1 --body '<contract>' '<title>'
hermes kanban show <task_id>
hermes kanban runs <task_id>
hermes kanban notify-subscribe <task_id> --platform telegram --chat-id <id> --notifier-profile codex_assistant