create-teammate

# 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
1. Create the teammate record first with `teammates_create`.
2. Keep `teammates_create` focused on teammate metadata only:
   - `name`
   - durable `instructions`
   - `capability_profile`
3. Create teammate-local skills separately with `teammate_skills_create`.
4. Teammate-local skills live under `teammates/<teammate-id>/skills/<skill-id>/`.
5. 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
1. 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.
2. 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.
3. 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.
4. 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.
5. 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`
6. Call `teammates_create`.
7. 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.
8. 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
1. The skill must have a valid `SKILL.md` with frontmatter:
   - `name: <skill-id>`
   - `description: <one-line summary>`
2. Keep `SKILL.md` concise.
3. Put detailed reference material into `references/` instead of bloating `SKILL.md`.
4. Put deterministic helpers into `scripts/`.
5. Put templates or static resources into `assets/`.
6. If the skill needs tool or command widening, declare them in `holaboss.granted_tools` and `holaboss.granted_commands`.

## Example Sequence
1. Inspect the roster and determine whether `Twitter Researcher` is a durable new role or overlaps an existing researcher.
2. Check whether the workspace has the required X/Twitter integration. If not, ask the user to connect it.
3. Call `teammates_create` with durable instructions and capability tags for the role.
4. Create a teammate-local `twitter-research` skill with:
   - `skill_markdown`
   - any reusable scripts the role needs
   - references such as sourcing policy, evaluation heuristics,