History RFC 009 Roles and Skills

RFC 009: Roles & Skills

A team is staffed from reusable role and skill libraries, bound per project, context and task.

Authors: the project's founder, with Claude (Opus 4.8)

Accepted 2026-10-08 by TeamCLI's board (founder's vote). Four reviewers from four labs — GPT Sol 6, Kimi, Gemini, Grok, none the author's lab — stood behind this text unanimously after six rounds (009 was the first to reach unanimity). The review record is kept with the project. The internal design (the neutral role/skill format, the harness adapter contract, the conflict detector, the delivery receipt) follows now that it is accepted.

1. The promise

A team staffs itself from libraries, not copy-paste. A role says how a seat behaves; a skill says what it can do. Both are generic, versioned. A project picks roles, binds skills for its context, and adds its own specifics — it never re-writes what a reviewer is.

2. Why — the gaps this closes

Every team file re-states each role's rules inline: duplication, leakage (names people/paths), no source of truth (a local git-ignored file + an ephemeral copy, a separate description that drifts), and roles aren't capable (a reviewer is never told how to review).

3. What it promises

1. A roles library and a skills library — generic, versioned, reusable, naming no person/path/company.
2. A project references roles and binds skills, then overlays its rules and identity.
3. Skills bind per project, context, or task — never baked into a role.
4. One version-controlled source of truth (the libraries + the project's own config, pinned together in the agreement record); the generated per-seat file is throwaway output.
5. A role's constraints are never weakened by a skill, an overlay or a binding (§8).
6. Harness-agnostic, through an adapter with a shared, observable contract.

4. The three layers

• Role = rules — how a seat behaves. Generic; names no person or path.
• Skill = capability — how to do something the seat is already allowed to do. Contains no constraint — no "may not", no "must", no permission (§8).
• Binding = which skills attach to which seat — by the project, the context, or the task. "Context" is a declared trigger: a phase, a file-kind the work touches, or a label — named in the team file, not inferred.

A seat's standing rules = role (rules) + project overlay + bound skills, composed at launch, with the seat's identity supplying its name and signature (identity signs; it does not add or remove limits). Precedence for constraints is in §8.

5. The shape

• Libraries: defaults shipped with team cli, an optional project-pointed library, per-project overrides. The library revisions and the project's config are pinned together by content in the agreement record; an upgrade is reviewed and re-agreed like any change.
• Reference, don't restate: role: reviewer pulls the library's rules; skills: (or a task's needs:) binds; the project's rules:, paths and identity overlay.
• Per-task skills, bound to the agreement and deliverability-enforced: a task's needs: loads those skills for that task — but needs may name only skills the owner agreed that seat may receive; a need outside that agreed set is escalated, not silently granted (the task record's needs metadata grants nothing the agreement did not — this is the 009 side of RFC 008's scope check). Within the agreed set: on a harness with a skills mechanism they load live; on a rules-file-only harness, the seat launches with an allow-list, and a task (or a mid-session context change) needing an agreed skill outside the allow-list makes the seat restart with it, or refuse the task and say so — never proceed without.
• Deliverability — required refuses, optional reports. If a skill the agreed seat or task binding requires cannot be delivered to a harness at all, the seat does not launch / the task is refused (not "role only, silently") — note this is a property of the binding, not of the role: a role carries no skill dependency (§3), so "required" always means required by the agreed seat or task binding. An explicitly optional skill a harness cannot take is reported as undelivered, and work continues. The same split governs a skill carrying a script the harness cannot run: if the skill is required, it refuses; if it is explicitly optional, it is reported undelivered — never a silent no-op either way.

6. Delivery is harness-specific — through one observable contract

A role/skill is defined once, in a neutral format (not any one lab's). A harness adapter renders it natively. Every adapter satisfies the same observable contract: what the seat is shown, where it is written, how the team verifies the seat received it, and — when a harness cannot take a binding — that it says so and refuses where §5 requires, rather than dropping it silently.

7. Source of truth, and neutral names

• The libraries + the project config are the version-controlled, co-pinned source; the generated per-seat file is throwaway.
• Role definitions are organisation-neutral: they reference identity.owner, identity.orchestrator, the project's trunk — never a specific person or local path.

8. The authority boundary, and the rule-vs-skill test

• Role constraints win. An overlay may add a limit; a skill adds none. Neither ever removes a limit, and a skill never grants or waives authority.
• Composition precedence for constraints (most-binding first): role constraints → project-overlay constraints. Skills carry no constraints, so they are not in this chain; identity carries none either (it signs). A conflict between a limit and a looser rule resolves to the more restrictive. But two incompatible positive duties — two "must"s that cannot both be satisfied (e.g. a role's "must merge on green" vs an overlay's "must hand every merge to a second seat" when none exists) — cannot be resolved by "more restrictive"; composition then fails with a visible error naming the conflicting rules, and the seat does not launch (or the task is refused) rather than silently honouring one. The exact conflict detector is internal design; the visible failure is the public promise.
• The discriminator. A line is a rule if it says what a seat may not or must do (role or overlay). A line is a skill if it says how to do something already allowed. A mandatory step splits: the "must" is a rule; the skill carries only the how. "A review must run the checks" is a role rule; the code-review skill is how to run them. A would-be skill containing a "must"/"may not"/permission is rejected by the library's check.
• Worked example (reviewer). Role: "reviews only the folder it is given; writes only its verdict; never merges, never approves; a review must cite the exact commit." Skills: code-review, security-review — how to review well. They make the reviewer better; they cannot make it able to merge, because that is a role constraint and skills never touch authority.

Where it sits

A team model (roles + default skill bindings + config) is the layer above. Delivery leans on Harness (007); per-task needs meets Planning (008); the authority boundary is Security (001).

What is still open

1. Library distribution and layering, in detail.
2. The exact neutral format and the adapter translation.
3. The full set of declared context triggers; the task-start delivery receipt (an internal-design detail of "verify the seat received it").

Costs and what it does not cover

• A harness that cannot deliver a required skill cannot run that seat; optional skills it cannot take are reported undelivered.
• Pinning means no improvements until a team re-agrees an upgrade.
• Skills raise capability, not authority; doing more means changing the role — a reviewed, re-agreed change (Foundation Part 2), not a skill.

What would change our mind

• If the rule-vs-skill discriminator proves ambiguous, skills become a typed, capability-only format the library checks mechanically, with no free text.
• If no neutral format survives translation to every harness, the canonical form drops to a plain rules file.

What is true today

Nothing of this is built. Roles are re-stated inline in each team file; there is no library, no skills, no binding, no adapter.

Review

Public RFC: at least three reviewers from three different labs, none of them the author's lab (Foundation Part 3), in rounds until all stand behind it, then the board votes. Rounds 1–6 (2026-10-08), accepted: GPT Sol 6, Kimi, Gemini, Grok. The internal design follows on acceptance.