skills
CLAUDE.md3 starsChanged 21 days agoApache-2.0View on GitHub
This is the Linggen skills repository — the standalone source of truth for the skills that ship with Linggen. Most are app skills (SKILL.md + a web UI under scripts/ served at /apps/<name>/). Edit HERE first, commit and push, then bring the other two surfaces up to that commit: 1. skills/<name>/… — this repo (standalone source of truth) 2. ~/.linggen/skills/<name>/… — what the running daemon serves. Install ONLY with scripts/install-skill.sh <name> after pushing — never copy files by name. It…
In this repository7 other files it gives its agents.
- apple-shifuSkill
- cfoSkill
- djSkill
- healthSkill
- lingjingSkill
- pulseSkill
- shared-memorySkill
The file
We split this CLAUDE.md into the rules it gives an agent
4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Very specific: line 14
Never edit ~/.linggen or vendor/skills directly.
- Very specific: line 22
Before committing: ./scripts/check.sh (CI runs the same on every push) — or piecemeal, node --test tests/*.test.mjs at the repo root (every …
- Distinctive: line 26
Don't trust the model for mechanical invariants (ids, schema fields, timestamps) — derive them page-side at ingest.
- Very specific: line 33
Before pushing: git fetch + git rebase origin/main, then ./scripts/check.sh.
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 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.
Files
Claude Code Instructions
This is the Linggen skills repository — the standalone source of truth for the skills that ship with Linggen. Most are app skills (SKILL.md + a web UI under scripts/ served at /apps/<name>/).
Edit workflow — three synced surfaces
Edit HERE first, commit and push, then bring the other two surfaces up to that commit:
skills/<name>/…— this repo (standalone source of truth)~/.linggen/skills/<name>/…— what the running daemon serves. Install ONLY withscripts/install-skill.sh <name>after pushing — never copy files by name. It installs the whole skill fromorigin/main(--ref HEADfor a local commit), refuses if any JS failsnode --checkor imports a name its neighbour doesn't export, never touches user state, and reloads skills when SKILL.md changed (then a NEW chat to bind). Page changes: reload the app iframe.--checkshows drift (prunable vs untracked extras);--dry-runwhat would change. Prune (default;--no-pruneskips): removes an install file only if it's gone from the ref, was once tracked under<skill>/, is byte-identical to a blob git held, and isn't user state — never-tracked or edited files stay.linggen/linggen-app/vendor/skills— git submodule of this repo. After pushing here:git pull origin maininside the submodule, then commit the pointer bump in linggen-app.
Never edit ~/.linggen or vendor/skills directly.
Never rsync --delete (or rm-and-copy) into ~/.linggen/skills/<name>/ — the install holds user state git never has (config.json, data/, state/). One such sync on 2026-09-10 wiped Pulse's config and six skills' data; copying by name blanked Lingjing twice on 2026-09-25 (a file landed without the neighbour it imports). install-skill.sh exists for both.
Conventions
- Syntax-check JS with
node --checkbefore committing (install-skill.sh refuses otherwise); there is no build step — files are served as-is. - Live-check Lingjing with ?save=test; never open the plain page in a check.
- Before committing:
./scripts/check.sh(CI runs the same on every push) — or piecemeal,node --test tests/*.test.mjsat the repo root (every SKILL.md frontmatter in the engine's shape; every script parses, every.shpassesbash -n, every page's local assets exist), plus the skill's ownnode --test <skill>/tests/*.test.mjs. - Skill JS runs in a sandboxed iframe: no
window.confirm/prompt(silent no-ops in the app shell) — use the shared dialog helpers. - Files written via
/api/bashmust end with a trailing newline (sentinel-strip gotcha). - Chat panels mount through the engine's
/shared/chat-bridge.js(LinggenUI.mount); sessions, models and cloud calls come from/shared/api.js, and/shared/app-mode.jsdrives the shell's Settings overlay. Don't copy these into a skill — keep only calls that are the skill's own in a local module (pulse-api.js,memory-api.js). App pages get?app_mode=1, and&in_launcher=1when hosted inside the unified launcher. - Don't trust the model for mechanical invariants (ids, schema fields, timestamps) — derive them page-side at ingest.
- Tool
cmd:template args keep their position: an omitted (or null) arg becomes its declareddefault:, else an empty quoted word''— so a script reads empty as "not given" and defaults it itself. Only a placeholder whose name isn't declared underargs:survives literally ({{max}}); declare every placeholder. - Never
sq()a path containing$HOME— single quotes kill expansion, and the command then writes to a literal'$HOME'dir under the bash cwd instead of failing. Resolve the home dir once viahome()(bash.js) and build absolute paths (this silently ate every DJ thumbnail until 2026-08-04).
Parallel work
- One worktree per session or agent (
git worktree add ../skills-wt-<topic> origin/main); nobody edits in the shared checkout. - Before pushing:
git fetch+git rebase origin/main, then./scripts/check.sh; a rejected push means rebase again — never--force, never copy files from an old worktree onto a new base (that silently reverted accepted work on 2026-10-21). Regenerate generated files (bundles, tables) after a rebase instead of merging them. - Install (
scripts/install-skill.sh) only what is pushed to origin/main — the live install is shared.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

