Claude Skill

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

LLM Mart · 0 points · 14 views 17 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download mvschwarz-openrig-skills__canonical_core_agent-starters-bda26cb.zip · 3 KB
Part of mvschwarz/openrig — 47 skills

Install

skills CLI npx skills add https://github.com/mvschwarz/openrig/tree/main/skills/_canonical/core/agent-starters
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install mvschwarz-openrig@llmmart
Git 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 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.

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 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
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.

No comments yet.

Reviews (0)

No reviews yet.

Related