agents

Recipe card from the charly-internals plugin (Development — contributor internals).

This card has additional detail pages:

Agents, Workflows & Teams

Overview

OpenCharly is built to be driven from multiple agent harnesses’ multi-agent primitives. This skill is the authoritative reference for the primitives per harness, the charly agent roster, the shipped workflows, the default multi-agent execution model, the bed-scoped parallel-testing discipline, and the hooks/lifecycle rules that hold an autonomous run together.

The one rule that binds every reference below: a bed run is R10-class — the commit is gated on a full final-code bed test (pasted), but beds run freely throughout to verify (see references/parallel-bed-testing.md “The binding rule”). The project rulebook is AGENTS.md, the single harness-neutral rulebook carrying R0–R10; this skill never restates it, only points to it.

Index

Topic	Reference
Primitives per harness (Claude Code / Codex / Kimi); when to use a sub-agent vs. dynamic workflow vs. agent team; the charly agent roster (executors/enforcers); the shipped workflows (`/audit-deploy-configs`, `/triage-check-failure`, `/verify-status`); the agent-team primitive setup	`references/agent-roster.md`
The default multi-agent execution model: orchestrator/teammate model-tier split, maximum parallelization, the slot budget, concurrent landing, the orchestrator’s bidirectional verification duty, architectural-integrity ownership, the responsibility matrix and tie-breakers	`references/orchestration-model.md`
Program-wide alignment: the north-star protocol, the IOU register, per-merge measurement, migration-ledger discipline, crossed-ruling reconciliation, brief verification and stop-and-respawn, whack-a-mole escalation	`references/program-discipline.md`
Bed-scoped parallel real-deployment testing: the concurrency ceilings (store lock, exclusive-resource tokens, long-bed ownership, in-tree build artifacts, per-worktree binaries) and their fixes; the charly binary in a multi-worktree setup; the binding rule for running a bed; implementation-workflow shape; speed levers	`references/parallel-bed-testing.md`
Delegation as fresh context; teammate context lifecycle; the nine sub-agent operational invariants; the hooks doctrine (current hook inventory); agent lifecycle hygiene; the universal PR-gate audit; worktree/validator lifecycle	`references/hooks-and-lifecycle.md`

Cross-References

/charly-check:check — the bed surface these agents/workflows drive (charly check run/image/live, the disposable check-bed inventory, exit codes).
/charly-internals:disposable — why disposable: true is the sole destroy authorization.
/charly-internals:git-workflow — the R10-gated landing the executors feed.
/charly-internals:skills — agent/skill discovery and the signpost convention.
The project rulebook’s “Agents, Workflows & Teams”, R10 / “Hard Cutover by Default”, and AI Attribution sections.

When to Use This Skill

Invoke before authoring or invoking an charly sub-agent / dynamic workflow / agent team, before wiring agent-lifecycle or commit/push gate hooks, and whenever deciding which primitive should drive the charly check beds for a given verification.

Every delegated worker MUST read the relevant skill before its first tool call (R1 2026-09-07)

No sub-agent / dynamic-workflow child may start working without reading the SKILL.md(s) the task triggers. The parent brief must name the skill(s) AND the worker must load them (their SKILL.md + the referenced reference docs) BEFORE its first tool call - this is a hard precondition, not a suggestion. Measured failures this rule exists for: a worker chose charly check live (verify-only, skips every mutating step) over charly check run for an R10 proof because it never read the check skill, producing 26 skipped mutating steps + 43 downstream failures; a worker pushed four un-gated heads (gofmt-dirty, stale worktree replace) because it never loaded the git-workflow skill’s gate-before-push rule. A parent that fails to name the skill, or a worker that proceeds without loading it, commits an R1 violation - STOP and load it before continuing.

And every worker MUST run the pre-validator self-audit before its FIRST push. The parent brief MUST embed the pre-validator self-audit checklist from the /charly-internals:git-workflow skill’s pre-validator self-audit reference, and the worker MUST run that preflight against its own head before pushing. It classifies the change from the diff (never from intent), pastes only commands actually executed on this head, accounts for every applicable rule, and refuses to surface a failure it cannot own - the pass that turns a BLOCK→BLOCK→PASS cycle into a first-try PASS (umbrella #286). Full checklist: the /charly-internals:git-workflow skill’s pre-validator self-audit reference.

The harness-adapter CONFIG mechanism (layer-charly-internals#49)

Harness adaptation lives in the per-harness config at the repo root, never in the rulebook: a shared, byte-identical core of gate scripts (drift-checked by charly task harness) plus deliberate per-harness forks and a clone-level git hook installed with charly task hooks. The two halves coexist by classification - each surface is identical-by-design, umbrella-only, or deliberately-forked - so a shared file is never copied into a fork and a fork is never silently re-synced. This skill documents the mechanism; the rulebooks stay harness-neutral.