eljulians/skillfile

Component: crates/sources (sync.rs) | Severity: High | Status: Reproduced CLI help: "--dry-run - Show planned actions without fetching or installing". In reality only the unlocked cache-miss path checks dry_run; when a locked SHA short-circuits SHA resolution (or sha_cache supplies one), execution falls straight into fetch_store_github, downloading content and transactionally replacing the cache (content + .meta). A dry-run against a cache holding a newer sha than the lock even replaces it with older locked content. Where: crates/sources/src/sync.rs:515-521 (locked-sha return precedes the dry-run check at :528); :656-662 / :986-996 (fetch path has no dry-run guard). Repro (observed live): # locked github entry, then: rm -rf .skillfile/cache skillfile install --dry-run # output: "Syncing 1 entry [dry-run]... re-fetching (locked sha=...) ... -> ./.skillfile/cache/..." find .skillfile/cache -type f # .meta + content - cache recreated by a "dry" run Expected: no network I/O, no disk mut

Component: crates/core (parser.rs) + SPEC.md | Severity: Low-Medium | Status: Code-traced (unit-replicable) SPEC §Quoting claims "POSIX shell quoting rules (shlex)" and §Inline Comments claims a # inside a quoted field is never a comment. The implementation: Only double quotes are recognized; single-quoted fields keep their quotes (then fail name validation or become literal path chars). strip_inline_comment runs AFTER quotes are stripped and drops any field that starts with # - so local skill x "#drafts/skill.md" loses the path field (treated as a comment), violating the SPEC rule. SPEC's own example line local skill "my skills/git commit.md" is rejected at parse time: the inferred name "git commit" contains a space → "invalid name … skipping". The spec example cannot work as written (explicit-name variants do). Where: crates/core/src/parser.rs:53-71 (split_line), :73-79 (strip_inline_comment), :36-41 + :342-359 (name validation applied to the inferred spaced name); SPEC.md §

Component: crates/cli (format.rs) | Severity: Medium | Status: Reproduced Beyond the quoting corruption (separate issue), format loses content in a committed file: A standalone comment directly above an entry is preserved only if the raw entry line matches the regenerated canonical line; any spacing difference (single spaces, tabs) breaks the match and the comment is deleted. Inline comments (entry … # note) are always deleted. Lines with unknown first words - the SPEC's forward-compatibility mechanism ("old parsers warn and skip the line. No breakage") - are silently dropped, and the parse warnings that would have mentioned them are discarded by cmd_format. Where: crates/cli/src/commands/format.rs:85-106, :117-121 (comment matching keyed on raw line text), :182-185 (warnings discarded); serializer via :24-31. Repro: printf '# IMPORTANT: pinned on purpose\nlocal skill s skills/s.md\nfuturetype skill x extra\n' > Skillfile skillfile format cat Skillfile # comment gone (entry was s

Component: crates/cli (config.rs) | Severity: Medium (settings data loss) | Status: Code-traced (unconditional path) read_config_from returns Config::default() on ANY parse error (reads degrade gracefully, so a TOML typo goes unnoticed). But every config write path (write_config_token, write_gitlab_config_token_to, write_user_targets_to) reads via the same function and rewrites the whole file from what it got - i.e. from an empty default. One skillfile init that saves a GitHub token replaces the user's config with only that token; their gitlab_token, gitlab_host, and all [[install]] entries are silently destroyed. write_config_to also uses plain fs::write (truncate-then-write), so a crash mid-write leaves a truncated file - which the next write then treats as empty (same wipe). Where: crates/cli/src/config.rs:161-166 (parse error → default), :224-237, :253-260, :146-158 (writers), :169-178 (non-atomic write). Repro: put gitlab_token = "x" plus a syntax error in ~/.config/skillfile/co

Component: crates/deploy (paths.rs, install.rs) | Severity: High (forward-compat promise broken) | Status: Reproduced The project's own test suite documents that unknown adapters must be skipped gracefully ("lets new platform names be added to a Skillfile without breaking existing installs") and plain install does warn-and-skip. But the shared path helpers propagate adapter_for(target)? errors, so with install shiny-new-tool local present alongside install claude-code local: skillfile install --update exits 1 with "unknown adapter 'shiny-new-tool'" before syncing anything (via the auto-pin pass). skillfile info <name> exits 1 with the same error. skillfile status shows installed entries as [not installed] (per-target errors collapse the installed-path set) and silently disables drift detection. A teammate on a newer skillfile version adding a new platform to the shared manifest thus breaks older clients' core commands. Where: crates/deploy/src/paths.rs:45 and :80 (let adapter = adapt