Loomworks — Companion Skill Customization Verification Response — v0.1

Version. 0.1 Date. 2026-07-04 Status. Canonical verification response. Answers loomworks-cc-brief-companion-skill-customization-verification-v0_1. Findings are Claude Code's, against the live seed, manifest, and governing standing note — not re-derived by Claude.ai. Author. Claude Code (findings); Claude.ai (formatting into canonical record). Operator: Marvin Percival. Sources read (by CC). Seed: loomworks-candidate-seed-v0_12.md (confirmed highest in candidate-seeds/loomworks/). Manifest: current-status-manifest-v0_72.md, §672 ("'Skills' terminology three-way distinction — SETTLED 2026-06-11"). Governing standing note v0.6.

The conflict, stated first

The brief this document answers repeatedly sought seed authority for a Companion-customization model — "the seed's Companion-naming/configuration section (Phase 41)." That authority does not exist. The seed has no Companion-naming section and no Phase 41; those are engine constructs. The seed mentions "Companion" once, as a methodology noun, and "skill" zero times. The governing authority for everything this brief asked about is standing note v0.6 plus manifest §672 — not the seed. Any document built on this arc's Companion-customization concept should cite the standing note, not claim seed grounding.

Answers to the four questions

Q1 — Does the seed's four-rooms section support a Memory-versus-Shape/Render split for Companion-carried skills? No. The four-rooms section describes pipeline operations, not Companion skills — it is silent on the topic entirely. The split is real, but it is a standing-note construct, not a seed one. What the seed does support: the rooms are distinct operations, so the underlying claim that Memory-side and Render-side mechanisms differ is architecturally consistent — it just isn't framed there as "Companion skills."

Q2 — Is a Companion's skill set first-class configuration per Phase 41, or is customization naming/personality only? The premise is false at the seed level — no Phase 41, no Companion-naming section exists there. companion_name and ActorRef(kind="companion") are engine constructs absent from the seed. At the seed level, Companion is only a named methodology role (the faithful-clerk persona). The first-class customization model lives entirely in the standing note: the personal side is invariant, bound to the person's UUID, and follows across every Companion; method and vertical are optional specialization laid over it. Skills-as-configuration is treated as first-class — but by standing-note settlement, not seed commitment.

Q3 — Is there seed vocabulary that should replace "skill pack"? Yes. The settled term is method, not "skill pack." Per the standing note: a method is not a primitive, it is a bundle — composed of capability families, conversational voice/register, and one or more skills (Sense-1 bounded transforms). A vertical is a method aimed at a domain and sold. "Skill" itself is reserved for a bounded engine transform, not for the bundle. Correction: the Legacy Systems Companion's "skill pack" becomes a method — a vertical, specifically, since it's a domain-aimed, sold configuration.

Q4 — Does the render-type registry already contain a pathway/variable-mapping or bridge-/rebuild-specification grammar? No. The seed's five declared shape-types and thirteen declared render-types are all methodology/project artifacts (phase execution context, project state, methodology narrative, discovery trajectory, commons education; methodology document, project state manifest, phase CR, scoping note, handoff, standing note, engagement seed, concept reference, contributor guide, and others). Nothing resembles a legacy-code pathway, variable map, bridge-specification, or rebuild-specification grammar. The seed's Mode B mechanism could host such a grammar — a Mode B addition requires defining the specification grammar — but none is declared. These remain net-new proposals from this arc's documents, not registry entries.

The corrected split

Substantively right in shape, wrong in vocabulary, and wrong in one important structural claim:

• Not seed-grounded. Cite the standing note and manifest §672, not the seed.
• The canonical axis is different, and more precise. A method drives two surfaces, not two skill categories: an interaction surface (the method applied at install — how the Companion listens, asks, confirms, recalls, drawn from capability families and conversational voice) and a production surface (the method named at Shaping — how a render is produced, drawn from shaping logic and render specialists). This is the brief's Memory-versus-Shape/Render split, restated on the correct axis.
• Unified, not separate. Both the Memory-side extraction mechanism and the Shape/Render-side shaping/materializer mechanism are legitimately Sense-1 "skills" — different mechanisms in different rooms, which the brief had right — but they are not two unrelated categories. They are the interaction-components and production-components of one method. The brief's "category error" caution was valid; its implied separateness was too strong.

What this corrects going forward

loomworks-legacy-systems-companion-concept-v0_1 used "skill pack" and a Memory-room-versus-Shape/Render-room framing throughout. Both are superseded by this finding — see loomworks-legacy-systems-companion-concept-v0_2, produced alongside this document. Other arc documents referencing "skill pack" informally (Build Requirements, the consolidated queued-direction entry) should be corrected to method / vertical at the next pass over those documents — not done in this response, named here so the correction isn't lost.

If the seed should eventually carry a Companion-customization commitment, that is a seed-amendment decision for the Operator — the seed has not absorbed the standing note's model, and this document does not propose that it should.

DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — Companion Skill Customization Verification Response — v0.1 — 2026-07-04