hr-staffing

name	hr-staffing
description	Build staffing plans for pure-soul agents, mixed soul+skill agents, and skill attachments
audience	HR planner subagent
license	MIT
compatibility	opencode >= 0.1
metadata	{"domain":"agent-staffing","version":"1.0"}

HR Staffing Protocol

Purpose

Produce a staffing plan that is advisory, explicit, and downstream-compatible with Agent Hub composition.

Prerequisites

This skill must not be invoked until the parent HR agent has completed Stage 1 - REQUIREMENTS and the user has confirmed the requirements summary. If requirements are still ambiguous, return that gap to the parent instead of pretending the plan is ready.

Output Files

Write the latest plan to:

• $HR_HOME/state/staffing-plans/latest.json
• $HR_HOME/state/staffing-plans/latest.md

Required Plan Structure

Every staffing plan must include:

• schema_version
• task_summary
• recommended_team
• alternatives
• composition
• required_skills
• required_tools
• draft_names (draft agent names and draft profile name for user review)
• risks
• team_size_advisory (included when recommended team exceeds four agents)
• next_action

Compact Summary Shape

Keep latest.md compact and field-based. Use this shape:

recommended:
- role: ... | source: ... | agent_class: ... | model: ...
alternatives:
- ...
composition:
- ...
draft_names:
- seat: ... | proposed_agent_name: ... | reason: ...
- profile: ... | reason: ...
required_skills:
- skill: ... | why: ...
risks:
- ...
team_size_advisory: <omit if ≤4 agents; otherwise: "Recommend one to two primary agents with remaining agents as subagents.">
next_action: ...

Composition Rules

For each recommended entry, specify:

• asset_kind: agent or skill
• agent_class: pure-soul, mixed-soul-skill, or not-applicable
• deployment_role: primary-capable, subagent-preferred, or skill-attachment
• compatibility: native-ready, needs-adaptation, or skill-only

Decision Rules

• At least one staffing-plan entry must have deployment_role: primary-capable.
• Prefer the smallest team that can cover planning, sourcing/exploration, implementation, audit, verification, and documentation.
• If the recommended team has more than four agents, include a team_size_advisory noting that the team should be structured around one to two primary agents with the remaining agents deployed as subagents. Do not recommend more than two primary-capable agents unless the user explicitly requests it.
• When multiple candidates can cover the same seat, prefer a pure-soul agent with attached skills over a mixed soul+skill agent. Use a mixed soul+skill agent only when the specialized workflow cannot be cleanly separated, the source is tightly fused, or the user explicitly wants that mixed form.
• Prefer local worker cards from $HR_HOME/inventory/workers/ with inventory_status = available.
• Treat draft worker cards as sourcing inputs that still need review or explicit operator acceptance.
• Exclude retired worker cards from recommended staffing compositions.
• Treat user-supplied model names as advisory. Model confirmation happens during staging via opencode environment availability probing, not during staffing planning. If a user-supplied name looks syntactically invalid, note that, but do not attempt catalog-based validation here.
• If multiple valid compositions exist, present them as options rather than pretending one is certain.
• If a skill host is unresolved, say so plainly.
• Draft names must be treated as proposals only. The parent HR agent must show them to the user and get confirmation before adaptation starts.