lidessen Setup lidessen skills
Principle expression
Primary: P11 Supporting: P09, P12
Operational deployer for the lidessen skills collection. The lidessen methodology lives in the Principle Sequence and its individual skill expressions; this skill does the wiring to land a selected L1 expression in a target project — detect the host tool, write to the right harness file, and inject the cross-cutting guidance that spans multiple skills.
Position relative to harness
harness (and any general-purpose harness skill) teaches how to think about agent context — portable methodology, applies to any project regardless of skill collection. This skill is the lidessen-specific operational layer that applies harness-style structure to a project adopting the lidessen collection. Read harness for the why; run this skill to do the wiring.
Boundary — what this skill does and doesn't
Does:
- Detect host tool (Claude Code / Codex / Cursor / other) by config-file presence
- Create or update the project's harness config with a delimited "Lidessen" section
- Inject the canonical L1 projection from
references/cross-cutting-principles.md - Maintain a version marker so subsequent
sync/auditruns can detect drift
Doesn't:
- Define or evolve the Principle Sequence (the sequence and
principle-cultivationown that) - Copy or install skill files (use clone / symlink / your package manager)
- Modify per-skill content (each skill is its own concern)
Tool detection
Detect host tool in priority order before any subcommand writes:
CLAUDE.mdexists at project root → Claude CodeAGENTS.mdexists at project root → Codex.cursor/directory exists → Cursor- None of the above → ask the user explicitly which tool they're configuring
The detected tool determines the target file:
| Tool | Target file |
|---|---|
| Claude Code | CLAUDE.md |
| Codex | AGENTS.md |
| Cursor | .cursor/rules/lidessen.md (created if missing) |
| Other | ask the user where to write |
If multiple host configs are present, prefer the one the user names; fall back to priority order.
Delimited section format
The lidessen-managed content lives inside paired markers so reruns can replace cleanly without disturbing surrounding content:
<!-- lidessen-setup:begin v=<N> -->
... lidessen-managed content ...
<!-- lidessen-setup:end -->
Invariant: content outside the markers belongs to the user and must never be touched. Content inside the markers is wholly owned by this skill and is replaced on every sync. Users who need to override a principle should do so outside the markers — typically by adding a contrary note in their own section that consumers of CLAUDE.md will read alongside.
Subcommands
Dispatch by argument:
init— Scaffold the lidessen section in a project that doesn't yet have one. Seecommands/init.md.sync— Replace the lidessen section with the current canonical L1 projection; bumps version. Seecommands/sync.md.audit— Read-only drift check; never writes. Seecommands/audit.md.
If invoked with no argument, default to audit — it is the safe read-only operation and surfaces enough information for the user to decide whether they want init or sync.
Principal contradiction (this skill)
Per the sequence — the load-bearing decision in this skill is what gets injected (the canonical L1 projection in references/cross-cutting-principles.md). Tool detection, marker format, subcommand split are all secondary; getting them wrong is locally repairable, but injecting the wrong content propagates into every consumer project. Treat the projection with the discipline due a public API.