| name | create-teammate |
| description | Provision a production-ready teammate only after its stable responsibilities, prerequisites, and reusable operating guidance are understood. |
Create Teammate
Use this skill when the workspace needs a new teammate identity, usually followed by one or more teammate-local skills and any prerequisite integration setup.
Responsibility Discovery Gate
Do not create a teammate from a job title alone.
Before you call teammates_create, make sure you understand the stable remit:
- what work this teammate should own by default
- what it should explicitly not own
- how it differs from the current roster
- what recurring situations should route to it
- what integrations, references, or recurring workflows the role depends on
- what durable local skill bundle is needed for the role to be effective immediately
If any of that is still vague, overlapping, or one-off:
- inspect the current teammate roster first, preferably with
teammates_list
- infer what you can from the user's request and current workspace context
- ask only for the concrete missing responsibility details that block a durable definition
- do not create the teammate yet
Production Bootstrap Rule
Do not stop at a thin teammate profile.
When a new specialist teammate is warranted, provision it so it can do real work immediately:
- identify required integrations or connected apps
- ask the user to connect missing prerequisites instead of silently accepting a crippled setup
- synthesize a durable operating playbook from the role request and available workspace context
- create teammate-local skills when the role needs repeatable workflows, references, scripts, assets, or structured operating rules
Core Rules
- Create the teammate record first with
teammates_create.
- Keep
teammates_create focused on teammate metadata only:
name
- durable
instructions
capability_profile
- Create teammate-local skills separately with
teammate_skills_create.
- Teammate-local skills live under
teammates/<teammate-id>/skills/<skill-id>/.
- Use teammate-local skills for reusable specialization that should follow that teammate across delegated runs. Do not create a skill for a one-off task brief.
Workflow
- Decide whether a new teammate is warranted.
- Create a new teammate only when the role has a stable remit that is meaningfully different from existing teammates.
- If the behavior is temporary, task-specific, or already covered by an existing teammate, do not create a new one.
- Capture the stable remit before creation.
- Identify responsibilities, boundaries, default work, and non-goals.
- Compare that remit against the existing roster so you do not create an overlapping teammate.
- Use
teammates_list for the authoritative live roster instead of guessing from file layout or stale memory.
- If the remit is not durable enough to survive beyond the current task, stop and do not create the teammate.
- Inspect prerequisites before creation.
- Identify which integrations, connected apps, files, references, or workspace capabilities this teammate will rely on.
- If the role depends on an integration that is missing or disconnected, ask the user to connect it before finalizing the teammate.
- Do not pretend the teammate is production-ready if a critical prerequisite is still absent.
- Synthesize the operating playbook.
- Turn the role request into durable operating guidance, not just a title and a sentence.
- Decide what should live in standing
instructions versus a teammate-local skill bundle.
- Default toward creating at least one teammate-local skill for specialist roles with repeatable workflows.
- Define the teammate metadata.
name: concise role label
instructions: durable standing remit, not a one-off task
capability_profile.summary: one-line routing summary
capability_profile.capabilities: short stable tags such as research, frontend, implementation, ops
- Call
teammates_create.
- Decide whether the teammate also needs a local skill bundle.
- For specialist roles, the answer is usually yes.
- Add a skill when the teammate needs repeatable workflow guidance, bundled scripts, references, assets, or structured operating rules.
- If needed, call
teammate_skills_create.
- Prefer
skill_markdown for the canonical SKILL.md
- Add
sidecar_files for scripts/, references/, assets/, agents/openai.yaml, or other text files
- Add
directories only when an empty directory is intentionally needed
Teammate Quality Bar
- The remit must be specific enough that another agent could predict when this teammate should or should not get the work.
instructions should explain ownership, boundaries, default behavior, and readiness expectations.
- Avoid copying the same sentence into
instructions, summary, and the skill body.
- Capabilities should be routing hints, not paragraphs.
- Prefer one strong teammate over several overlapping vague teammates.
- If the role depends on a missing integration or missing local workflow guidance, do not present it as finished.
Skill Quality Bar
- The skill must have a valid
SKILL.md with frontmatter:
name: <skill-id>
description: <one-line summary>
- Keep
SKILL.md concise.
- Put detailed reference material into
references/ instead of bloating SKILL.md.
- Put deterministic helpers into
scripts/.
- Put templates or static resources into
assets/.
- If the skill needs tool or command widening, declare them in
holaboss.granted_tools and holaboss.granted_commands.
Example Sequence
- Inspect the roster and determine whether
Twitter Researcher is a durable new role or overlaps an existing researcher.
- Check whether the workspace has the required X/Twitter integration. If not, ask the user to connect it.
- Call
teammates_create with durable instructions and capability tags for the role.
- Create a teammate-local
twitter-research skill with:
skill_markdown
- any reusable scripts the role needs
- references such as sourcing policy, evaluation heuristics, and output expectations
Anti-Patterns
- Do not create a teammate before you understand its stable responsibilities.
- Do not create a teammate from a vague label like
researcher or builder without defining ownership and boundaries.
- Do not ship a specialist teammate that obviously needs an integration but has no path to that integration.
- Do not stop at a one-paragraph teammate profile when the role needs reusable workflow guidance.
- Do not stuff a one-off task brief into teammate creation.
- Do not create a teammate-local skill when a plain instruction block is enough.
- Do not put teammate-local skills under shared workspace
skills/.
- Do not overload the teammate with multiple overlapping skills when one coherent bundle will do.