← Corpus / lossless-monorepo / agent-skill
Public skills, private config — and the first skill to prove it
Some skills only work if they know who they're working for, which is exactly what a public repo can't hold. The answer is a gitignored config/private.json read at runtime by instruction rather than by templating, an example file that serves as the contract, and an audit grep that has to come back empty before you push. The CRM interface guidelines are the first skill built to that shape.
- Path
- agent-skills/changelog/2026-08-14_01.md
- Authors
- Michael Staton
- Augmented with
- Claude Code on Claude Opus 5
- Tags
- Agent-Skills · Conventions · CRM
Why Care?
This repo is public, and the discipline is that every Lossless skill lives here. That works fine for skills whose whole content is method — how to structure a changelog, how to name a branch, how to lay out a context-v/. It breaks for skills that only function when they know particulars: which firms the operator carries a mandate for, which CRM workspace is the default write target, which relationships change a routing decision. Inline those and the skill can’t be published. Strip them and the skill stops working.
The resolution is to split the two by kind rather than by degree. Method stays in SKILL.md and stays public. Particulars move to a gitignored config/private.json that the skill instructs the agent to read at the top of a session. Neither file is useful alone, and that is the point — the public half is honest about what it doesn’t know instead of quietly guessing.
What’s New?
-
The pattern, documented in the README. Directory shape, the instructional-resolution-over-templating argument (no build step, no preprocessor, and the agent can reason about a missing config where a templater would silently emit an empty string), five rules that keep it honest, an upgrade path to a secrets manager or a config-serving MCP server, and a five-step recipe for converting an existing skill.
-
lossless-crm-interface-guidelines, the first skill built to the shape. An operating manual for the Twenty CRM estate — instance routing across three non-sharing workspaces, the custom object model (Investment, Deal Source, Deal Prospect, Thesis, Thesis Fit, Events), a forced-choice 0–5 scoring standard with no neutral midpoint, the two-tier profile-links architecture, and the MCP pitfalls worth knowing before the first write. Its §1 is a config contract rather than a roster: it names theoperatorandaffiliationsblocks, mapsaffiliationskeys onto the Deal ProspectMy Rolefield, and instructs the agent to say so and ask when the config is absent rather than backfill from model knowledge. -
config/private.example.jsonas the contract. The template documents every key the skill reads — operator identity, affiliation tiers with anotesblock for relationships that are self-appointed or brokered rather than mandated, CRM instances with per-instance schema caveats, key relationships, vehicles, and behavioural preferences. Rule 2 of the pattern: if a skill starts reading a new key, the example documents it in the same commit. -
Gitignore rules that make the boundary structural.
*/private.json,config/private.json, and**/config/private.json— so the real file cannot be staged from any nesting depth, and the protection doesn’t depend on remembering.
Notes
The audit grep from README rule 5 — build a pattern from the real config’s names and firms, grep the public file, require empty output — was run against SKILL.md before this shipped and came back clean. It’s cheap enough to be reflexive, and it’s the only check that actually catches the failure mode this pattern exists to prevent.
The same pass moved §3.6’s list of observed name corrections out of the public file. Eight real people in the operator’s network, published next to their misspellings, taught nothing the failure-mode description doesn’t teach on its own.