Background
The repo allowlists .tessl/plugins/tessl-labs/intent-integrity-kit in .gitignore and ships a tracked symlink there pointing to ../../../tiles/intent-integrity-kit. This makes local invocations of bash .tessl/plugins/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/<script>.sh resolve against the local source tree without needing tessl install of our own tile into ourselves.
Pre-existed at .tessl/tiles/... before PR #81; that PR migrated the path along with the Tessl 0.81 rename but kept the convention.
Concern
PR #81's gh-aw policy reviewer flagged this against jbaruch/coding-policy: dependency-management:
Tessl tiles count as dependencies — never vendor them. Install via tessl install at runtime; don't commit tile content (e.g., .tessl/plugins/<workspace>/<tile>/...) into the consumer repo.
The rule's text targets consumer repos (and the symlink points to local source, not vendored content), so the strict reading doesn't apply here — but the appearance is bad and the dev-time mechanism is fragile (it broke when Tessl renamed tiles/ → plugins/).
Tessl's blessed local-dev workflow
Per Tessl's local plugin development docs, the official mechanism is:
tessl install file:./tiles/intent-integrity-kit
This installs the local working tree as if it were a real tile — populates .tessl/plugins/tessl-labs/intent-integrity-kit/ from source at runtime, no publishing required. The intended loop is edit → tessl install file:./… → test. This eliminates the bootstrap concern that originally argued against option 1 in the alternatives below.
The recommended development layout in the docs uses .tessl-plugin/plugin.json (post-0.81 naming) rather than the legacy tile.json this repo still ships — worth noting if we touch the structure.
Possible alternatives
- Remove the symlink; require devs to
tessl install file:./tiles/intent-integrity-kit (Tessl-blessed, doc-supported, no bootstrap problem — one re-install per edit cycle)
- Move the symlink under a non-
.tessl/ path (e.g., dev-mount/iikit/) and have local skill invocations resolve via a search path
- Have the SKILL.md scripts use a candidate-paths search instead of a hard-coded
.tessl/plugins/... (already done in pre-commit-hook.sh line 74-79 — same pattern could extend to all skill script invocations)
- Keep as-is and document the exception in a tile-local rule
Tradeoffs
| Approach |
Edit cycle |
Survives Tessl path renames |
Install step |
Touches SKILL.md |
| Symlink (current) |
edit → run |
No (broke on tiles/ → plugins/) |
None |
None |
Option 1 (tessl install file:) |
edit → re-install → run |
Yes — Tessl owns the path |
One per edit |
None |
| Option 3 (candidate-path search) |
edit → run |
Yes — scripts try multiple paths |
None |
76+ touch points |
Recommendation
Option 1. It's the Tessl-blessed pattern, requires no SKILL.md surgery, survives future path renames, and removes the vendored-appearance optics. The cost is one tessl install file: step per edit cycle — acceptable for a workflow that's already test-driven. Document the dev setup in CONTRIBUTING.md (or top of CLAUDE.md) so contributors don't trip on it.
Option 3 stays viable as a fallback if the install-loop friction proves unworkable in practice.
Background
The repo allowlists
.tessl/plugins/tessl-labs/intent-integrity-kitin.gitignoreand ships a tracked symlink there pointing to../../../tiles/intent-integrity-kit. This makes local invocations ofbash .tessl/plugins/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/<script>.shresolve against the local source tree without needingtessl installof our own tile into ourselves.Pre-existed at
.tessl/tiles/...before PR #81; that PR migrated the path along with the Tessl 0.81 rename but kept the convention.Concern
PR #81's gh-aw policy reviewer flagged this against
jbaruch/coding-policy: dependency-management:The rule's text targets consumer repos (and the symlink points to local source, not vendored content), so the strict reading doesn't apply here — but the appearance is bad and the dev-time mechanism is fragile (it broke when Tessl renamed
tiles/→plugins/).Tessl's blessed local-dev workflow
Per Tessl's local plugin development docs, the official mechanism is:
This installs the local working tree as if it were a real tile — populates
.tessl/plugins/tessl-labs/intent-integrity-kit/from source at runtime, no publishing required. The intended loop isedit → tessl install file:./… → test. This eliminates the bootstrap concern that originally argued against option 1 in the alternatives below.The recommended development layout in the docs uses
.tessl-plugin/plugin.json(post-0.81 naming) rather than the legacytile.jsonthis repo still ships — worth noting if we touch the structure.Possible alternatives
tessl install file:./tiles/intent-integrity-kit(Tessl-blessed, doc-supported, no bootstrap problem — one re-install per edit cycle).tessl/path (e.g.,dev-mount/iikit/) and have local skill invocations resolve via a search path.tessl/plugins/...(already done inpre-commit-hook.shline 74-79 — same pattern could extend to all skill script invocations)Tradeoffs
tiles/→plugins/)tessl install file:)Recommendation
Option 1. It's the Tessl-blessed pattern, requires no SKILL.md surgery, survives future path renames, and removes the vendored-appearance optics. The cost is one
tessl install file:step per edit cycle — acceptable for a workflow that's already test-driven. Document the dev setup inCONTRIBUTING.md(or top ofCLAUDE.md) so contributors don't trip on it.Option 3 stays viable as a fallback if the install-loop friction proves unworkable in practice.