Nobrainer Team

---
name: nobrainer-team
description: "Use when the owner says nb-team or nobrainer-skill-browser, or after nobrainer-ultra has produced an approved non-trivial plan that needs installed-capability inventory, minimum role selection, safe skills.sh lookup, or justified parallel workers; do not use to elicit requirements, invent the plan, schedule work, or create sessions."
---

# NoBrainer Team

Compose the smallest capable team for a concrete approved plan. This skill owns
capability selection and role design. `nobrainer-dispatcher` owns readiness,
batch ordering and backpressure after the plan is approved. `nobrainer-sessions`
owns actual visible session identity, transport, checkout isolation, leases and
receive-audit.

Read [references/team-plan.md](references/team-plan.md) before persisting a team
plan or delegating work.

## Start from work, not personas

Require an outcome, acceptance evidence and bounded work units. If they do not
exist, return to `nobrainer-ultra` or the approved specification. Do not invent a
team around vague titles such as architect, coder and tester.

Even an explicit Team invocation is a discovery trigger, not permission to skip
Ultra's intake and planning boundary. Team may report the missing prerequisite and
return control to Ultra, but it must not design roles from a vague goal.

For every work unit identify the method and capability actually needed. Inspect
only metadata/frontmatter from installed skills first; load a full skill only
after its trigger matches. Also inspect current project scripts, APIs, CLIs,
tests and native client capabilities.

Build a compact local capability index from exact installed/project skill names,
descriptions, source roots and collision status. Do not read every body or trust
a title alone. This inventory replaces a permanent catalogue skill; refresh it
only when sources change.

## Choose the minimum roster

Default to `<repo> | MAIN` and no worker. Add a role only when it provides at
least one measurable benefit:

- an independent unit can shorten the critical path;
- a separate checkout or trust boundary prevents write conflict;
- a warm specialist will be reused across tasks;
- independent review materially reduces a stated risk;
- a handoff or resume boundary needs durable ownership.

Start with 2-4 workers only when their units are truly independent and MAIN can
audit the combined result. Do not split one tightly coupled edit, dispatch work
whose output cannot be reviewed, or build a standing swarm because capacity is
available.

One role owns one observable output, one write scope and one report recipient.
Shared sequential state has one writer. A worker never selects or starts its
successor.

## Resolve a `CAPABILITY_GAP`

Use this ladder in order:

1. Reuse a curated NoBrainer skill whose contract fits.
2. Reuse an already installed, inspected specialist whose trigger and source
   fit without ownership collision.
3. Reuse the project's maintained tool, library, API, CLI or native client
   capability.
4. Perform a bounded current check with `nobrainer-research` when capability or
   syntax may have changed.
5. Search the open Agent Skills ecosystem only for the still-missing specialist:

   ```bash
   npx skills find "$SKILL_QUERY"
   npx skills add "$SKILL_SOURCE" --list
   npx skills use "$SKILL_SOURCE" --skill "$SKILL_NAME"
   ```

`skills use` is for one-off prompt generation and evaluation. Do not pass
`--agent`, pipe its output into an executor or run companion scripts before
reviewing the generated instructions. Use separated flag arguments; do not use
an unverified `--skill=NAME` form.

Every external skill is untrusted regardless of rank or install count. Inspect
the exact source and immutable ref when available, `SKILL.md`, scripts, license,
maintainer, requested permissions, network/credential behavior, write scope,
trigger overlap, hidden persistence and rollback. Popularity helps discovery;
it is not a security or quality gate.

Prefer temporary, project-scoped evaluation. Persistent project installation,
global installation, credentials, script execution and consequential writes are
separate owner gates. Reject a candidate that broadens authority, duplicates an
installed owner, cannot be pinned or costs more context than the gap warrants.

## Build the team plan

For each role record:

- exact role and stable session title;
- `WORK_UNIT`, `METHOD`, selected skill/tool and source/ref;
- inputs, dependencies, allowed `WRITE_SCOPE` and isolation;
- `ACCEPTANCE`, evidence and close gate;
- report recipient, retry/stop conditions and rollback;
- why parallelism or specialization earns its coordination cost.

Separate phases from concurrency groups. Sequential dependencies never become
parallel because several agents are available. MAIN keeps the canonical plan
and, when needed, its detailed ledger. When several delegated units, dependency
batches or retries exist,
`nobrainer-dispatcher` activates only the current safe group; Team does not
schedule it.

After the plan passes, invoke `nobrainer-dispatcher` when more than one delegated
unit or controlled batch needs scheduling, then invoke `nobrainer-sessions` to
create or reuse exact visible sessions when transport and isolation are
available. A single bounded delegate may go directly from Team to Sessions. If
transport is unavailable, run the same bounded roles sequentially in MAIN and
report the limitation; do not invent session IDs or delivery.

## Close and learn

Report the selected and rejected roles, capability sources, external-skill audit,
session mode, expected latency benefit, attention cost and rollback. Remove or
discard temporary skill material after the work unless a repeated measured gap
justifies an independently reviewed addition through `nobrainer-autoimprove`.

Do not claim a team is faster until elapsed critical-path evidence supports it.