agent-starters
Use when creating, refreshing, packaging, inspecting, promoting, or deprecating a named per-seat starting point — Agent Starter manifest authoring, the 6-state lifecycle (captured → named → inspectable → used → promoted → deprecated), provenance honesty, and refusal rules. NOT a
Install
npx skills add https://github.com/mvschwarz/openrig/tree/main/skills/_canonical/core/agent-starters
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install mvschwarz-openrig@llmmart
git clone https://github.com/mvschwarz/openrig.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole mvschwarz/openrig collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Agent Starters
A named, reusable per-seat starting point. Composes an agent role, startup context, optional native session source, and provenance into something a user or rig can choose when creating, refreshing, or packaging a seat.
This registry-backed startup context is distinct from the rig agent-image
surface and from a VM image. See the current behavior below before treating
optional session provenance as an executable native session source.
Use this when
- Creating a new seat from a known-good starting context.
- Refreshing a seat with
rig expandandstarter_ref. - Authoring a new starter (registry entry).
- Inspecting an existing starter's provenance, freshness, or recommended status.
- Promoting / deprecating starters in the registry.
- Composing a starter with a Composable Priming Pack (record manifest id/version, runtime, source session id or transcript path, ready-check evidence, freshness state).
Don't use this when
- You want VM-style deterministic state capture. Starters don't capture VM state.
- You want to copy provider auth material into a starter. Starters refer to session sources and context; they do NOT copy credentials.
What makes a starter valuable
A starter is valuable when it is functional — it carries the context the seat needs to do its task well. Functional is the only measure of a good starter. Size is not: a smaller starter is not a better one, and a bigger one is not worse. Whatever it took for the seat to become genuinely capable at its job is the right starter — 80K tokens or 800K.
Capture the seat as it naturally is at a functional, proven point. Don't pad it with context the seat doesn't use, and — just as important — don't strip context out to make it smaller. Size is an outcome of what the seat needed, never a target.
Never compact, summarize, or shrink a seat in order to make or "lean" a starter. There is nothing valuable in "smaller," and compaction is lossy — you would trade away the exact capability the starter exists to preserve. (Compaction is a separate last-resort step for a seat genuinely near its context limit, with its own before/after plan — never part of capturing a starter.)
Authoring lifecycle — 6 conceptual states
- Captured — a useful seat/session/context pattern is identified.
- Named — it becomes an Agent Starter with stable id and owner.
- Inspectable — runtime, context inputs, session source, and provenance are visible.
- Used — a rig member or
rig expandoperation starts from it. - Promoted — evidence shows it is recommended for a role or bundle.
- Deprecated — replaced, stale, unsafe, or incompatible.
Failure modes (5)
- Overclaiming image semantics — UI/docs imply deterministic VM-style state capture. Say "starter," name what's included, show provenance.
- Hidden provenance — users can't tell what session, context, or spec a starter came from. Refuse promotion until provenance is inspectable.
- Stale starter — points at outdated doctrine, missing files, or invalid native session source. Inspect must report staleness honestly.
- Secret leakage — starter packages or displays provider auth material. Refuse. Refer to session sources and context, never copy credentials.
- Runtime mismatch — starter used with unsupported runtime. Refuse with a clear error.
Registry entry and current behavior
Save one entry as <registry-root>/reviewer-v1.yaml. The resolver selects an
explicit root or OPENRIG_AGENT_STARTER_ROOT; absent those, it checks the home
registry ~/.openrig/agent-starters and a configured fallback.
starter_id: reviewer-v1
role: Review the assigned change against its stated outcome.
context: Read the current task and the source needed to judge it.
The current resolver checks the entry shape and credential boundary, then
delivers this YAML itself as one required guidance_merge startup file on a
fresh start. It does not interpret arbitrary context refs, load a native
conversation from this example, or seal an image. A RigSpec member combining
starter_ref with session_source.mode: fork is currently rejected; use a
separate supported session-source path when native continuity is the outcome.
Member usage:
members:
- id: reviewer
starter_ref:
name: reviewer-v1
When a starter points at a primed session produced from a Composable Priming Pack, record:
- manifest id/version
- runtime
- source session id or transcript path
- ready-check evidence
- freshness state
Proof matrix
| Surface | Test type | Authority |
|---|---|---|
| Registry schema accepts minimal starter | unit | daemon or config-layer prototype |
| Inspect shows provenance and included context | unit / snapshot | daemon or CLI |
Member can use starter_ref |
integration | daemon |
| Unsupported runtime or stale source refuses honestly | unit + integration | daemon |
| No secret material copied into starter artifact | grep / fixture | tester |
| Bundle can include or reference starter | package inspection | bundle layer |
Dependencies on other primitives
- Separate path:
session-source-fork— native conversation-source continuity; currently not composable withstarter_ref - Firm:
specification-system— declarative starter and member references - Soft:
rig-bundles-and-shareable-artifacts— shareable starter packaging - Soft:
context-engineering-and-retrieval— richer declarative context assembly - Soft:
seat-continuity-and-handover— refresh and swap workflows over starters
Required-before-RSI
Agent Starters need queryable provenance and honest inspect output before RSI loops can rely on them for seat refresh. A workflow must be able to answer: "what starter did this seat use, what source session or context was included, and is that starter still recommended?"
See also
session-source-forkskill — low-level fork primitive that makes native session-based starters possiblecomposable-priming-packsskill — manifest-driven layer for producing primed sessions starters reference
Files (openrig)
-
SKILL.md 6.9 KB
--- name: agent-starters description: Use when creating, refreshing, packaging, inspecting, promoting, or deprecating a named per-seat starting point — Agent Starter manifest authoring, the 6-state lifecycle (captured → named → inspectable → used → promoted → deprecated), provenance honesty, and refusal rules. NOT a VM image; a managed starting point composed from agent role + startup context + optional native session source + provenance. metadata: openrig: stage: factory-approved sibling_skills: - claude-compaction-restore - mental-model-ha - scope-recovery - session-compaction-and-restore - agent-startup-and-context-ingestion - composable-priming-packs - session-source-fork - seat-continuity-and-handover - claude-compact-in-place - pre-maintenance-agent-preservation --- # Agent Starters A named, reusable per-seat starting point. Composes an agent role, startup context, optional native session source, and provenance into something a user or rig can choose when creating, refreshing, or packaging a seat. This registry-backed startup context is distinct from the `rig agent-image` surface and from a VM image. See the current behavior below before treating optional session provenance as an executable native session source. ## Use this when - Creating a new seat from a known-good starting context. - Refreshing a seat with `rig expand` and `starter_ref`. - Authoring a new starter (registry entry). - Inspecting an existing starter's provenance, freshness, or recommended status. - Promoting / deprecating starters in the registry. - Composing a starter with a Composable Priming Pack (record manifest id/version, runtime, source session id or transcript path, ready-check evidence, freshness state). ## Don't use this when - You want VM-style deterministic state capture. Starters don't capture VM state. - You want to copy provider auth material into a starter. **Starters refer to session sources and context; they do NOT copy credentials.** ## What makes a starter valuable A starter is valuable when it is **functional** — it carries the context the seat needs to do its task well. Functional is the *only* measure of a good starter. Size is not: a smaller starter is not a better one, and a bigger one is not worse. Whatever it took for the seat to become genuinely capable at its job is the right starter — 80K tokens or 800K. Capture the seat as it naturally is at a functional, proven point. Don't pad it with context the seat doesn't use, and — just as important — don't strip context out to make it smaller. Size is an *outcome* of what the seat needed, never a target. Never compact, summarize, or shrink a seat in order to make or "lean" a starter. There is nothing valuable in "smaller," and compaction is lossy — you would trade away the exact capability the starter exists to preserve. (Compaction is a separate last-resort step for a seat genuinely near its context limit, with its own before/after plan — never part of capturing a starter.) ## Authoring lifecycle — 6 conceptual states 1. **Captured** — a useful seat/session/context pattern is identified. 2. **Named** — it becomes an Agent Starter with stable id and owner. 3. **Inspectable** — runtime, context inputs, session source, and provenance are visible. 4. **Used** — a rig member or `rig expand` operation starts from it. 5. **Promoted** — evidence shows it is recommended for a role or bundle. 6. **Deprecated** — replaced, stale, unsafe, or incompatible. ## Failure modes (5) 1. **Overclaiming image semantics** — UI/docs imply deterministic VM-style state capture. Say "starter," name what's included, show provenance. 2. **Hidden provenance** — users can't tell what session, context, or spec a starter came from. **Refuse promotion until provenance is inspectable.** 3. **Stale starter** — points at outdated doctrine, missing files, or invalid native session source. **Inspect must report staleness honestly.** 4. **Secret leakage** — starter packages or displays provider auth material. **Refuse.** Refer to session sources and context, never copy credentials. 5. **Runtime mismatch** — starter used with unsupported runtime. **Refuse with a clear error.** ## Registry entry and current behavior Save one entry as `<registry-root>/reviewer-v1.yaml`. The resolver selects an explicit root or `OPENRIG_AGENT_STARTER_ROOT`; absent those, it checks the home registry `~/.openrig/agent-starters` and a configured fallback. ```yaml starter_id: reviewer-v1 role: Review the assigned change against its stated outcome. context: Read the current task and the source needed to judge it. ``` The current resolver checks the entry shape and credential boundary, then delivers this YAML itself as one required `guidance_merge` startup file on a fresh start. It does not interpret arbitrary context refs, load a native conversation from this example, or seal an image. A RigSpec member combining `starter_ref` with `session_source.mode: fork` is currently rejected; use a separate supported session-source path when native continuity is the outcome. Member usage: ```yaml members: - id: reviewer starter_ref: name: reviewer-v1 ``` When a starter points at a primed session produced from a Composable Priming Pack, record: - manifest id/version - runtime - source session id or transcript path - ready-check evidence - freshness state ## Proof matrix | Surface | Test type | Authority | |---|---|---| | Registry schema accepts minimal starter | unit | daemon or config-layer prototype | | Inspect shows provenance and included context | unit / snapshot | daemon or CLI | | Member can use `starter_ref` | integration | daemon | | Unsupported runtime or stale source refuses honestly | unit + integration | daemon | | No secret material copied into starter artifact | grep / fixture | tester | | Bundle can include or reference starter | package inspection | bundle layer | ## Dependencies on other primitives - **Separate path**: `session-source-fork` — native conversation-source continuity; currently not composable with `starter_ref` - **Firm**: `specification-system` — declarative starter and member references - **Soft**: `rig-bundles-and-shareable-artifacts` — shareable starter packaging - **Soft**: `context-engineering-and-retrieval` — richer declarative context assembly - **Soft**: `seat-continuity-and-handover` — refresh and swap workflows over starters ## Required-before-RSI Agent Starters need queryable provenance and honest inspect output before RSI loops can rely on them for seat refresh. A workflow must be able to answer: "what starter did this seat use, what source session or context was included, and is that starter still recommended?" ## See also - `session-source-fork` skill — low-level fork primitive that makes native session-based starters possible - `composable-priming-packs` skill — manifest-driven layer for producing primed sessions starters reference
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.