lossless-grouplossless-group/lossless-agent-skills/CLAUDE.md

lossless-agent-skills

CLAUDE.md4 starsChanged 3 months agoMITView on GitHub

This repo is the shared skill library for The Lossless Group — one directory per skill, each with a top-level SKILL.md following the Agent Skills spec. It is public, and it is mounted into the anchor pseudomonorepo at context-v/skills/. Claude Code only discovers a skill when it has its own direct-child symlink at ~/.claude/skills/<name>. A symlinked parent directory does not expose the skills nested inside it, so an authored-but-unlinked skill is invisible to every session. Run it at session start…

We split this CLAUDE.md into the rules it gives an agent

3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Run it at session start (picks up skills added since last session) and again after authoring or editing any skill — newly-linked skills …
line 18
Very specific:
Never inline a config value back into a SKILL.md.
line 38
Distinctive:
Prefer accessibility snapshots over screenshots — raster is token-expensive.
line 69

≈ “Common” is an estimate: at least 1 in 5 of the 25,680 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

CLAUDE.md

Agent instructions for `lossless-agent-skills`

This repo is the shared skill library for The Lossless Group — one directory per skill, each with a top-level SKILL.md following the Agent Skills spec. It is public, and it is mounted into the anchor pseudomonorepo at context-v/skills/.

Symlink sync — opening & closing habit

Claude Code only discovers a skill when it has its own direct-child symlink at ~/.claude/skills/<name>. A symlinked parent directory does not expose the skills nested inside it, so an authored-but-unlinked skill is invisible to every session.

bash ./sync-skills-symlinks.sh

Run it at session start (picks up skills added since last session) and again after authoring or editing any skill — newly-linked skills load in the next session, not the current one. Idempotent; never clobbers a non-symlink.

Two things that break discovery and are easy to miss:

The directory name must match the skill's frontmatter name:. A mismatch loads the skill without its description, so it never triggers.
Renaming a skill directory leaves a broken symlink behind. The sync script adds the new link but does not remove the stale one. Check with find ~/.claude/skills -maxdepth 1 -xtype l.

Public skills, private config

Skills here are published. Operator-specific particulars — firm names, workspace URLs, key relationships — live in a gitignored <skill>/config/private.json, documented by a committed config/private.example.json, and are read at runtime by instruction rather than by templating. lossless-crm-interface-guidelines/ is the reference implementation. Full pattern, including the pre-push audit grep, is in README.md.

Never inline a config value back into a SKILL.md. The moment a firm name or an instance URL lands in the public file, the skill has stopped being publishable.

Vendored upstream submodules — do not overlay them

chroma-agent-skills/ is pinned from chroma-core/agent-skills. We have READ permission only. Anything committed inside it can never be pushed, and a local commit there would leave this repo's gitlink pointing at a SHA that exists on no remote — the loss scenario the pseudomonorepos HARD STOP guards against.

So: Lossless conventions do not get injected into vendored repos. The tree-wide  rollout reached 16 CLAUDE.md files including that one; the copy inside the submodule has been reverted and lives here instead. If a future rollout script walks the tree writing CLAUDE.md, exclude vendored submodules.

Browser-drive verification (Playwright MCP + Claude Chrome)

Agents verify UI work by driving a real browser BEFORE asking a human to walk the surface. Two tiers:

Codified (default): Playwright MCP — navigate/click/type, accessibility-tree snapshots, DOM assertions; headless-capable, runs unwatched. Wire it per repo at project scope (config lands in the committed .mcp.json):
```
claude mcp add -s project playwright -- npx @playwright/mcp@latest
```
Interactive: claude --chrome (or /chrome → enable by default) — Claude drives the operator's real Chrome while they watch; screenshots/GIFs + console and network logs.

Rules that make it safe and cheap:

Newly added MCP servers load in the next session, not the current one (same rule as skills symlinks).
Prefer accessibility snapshots over screenshots — raster is token-expensive; use it only for visual questions (layout, theme).
Browser-driven reads are unrestricted; writes only against the repo's designated safe target — never mint test entities in shared/canonical data.
The drive's click-path is named in the phase plan before implementation; a drive that lives only in a session transcript is not codified.
A browser drive proves the buttons work; the human walk-through still judges whether the surface is usable. It augments the human rung, never replaces it.

Full pattern: context-v/blueprints/Browser-Drive-Verification-For-Agent-Sessions.md at the anchor monorepo root (kit rollout draft: ai-labs/context-vigilance-kit/context-v/blueprints/). Loop integration proven in ai-labs/augment-it/context-v/loops/.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free