Problem
groundwork init embeds skills/skills.toml at compile time via include_str!. When skills are renamed, removed, or added in the repo, previously compiled binaries silently generate broken agents.toml entries. There is no mechanism to detect or recover from this.
Observed behavior
Ran groundwork init in a project. The installed binary was compiled before the next-issue → begin rename (PR #80). It generated agents.toml with next_issue = { path = "skills/next-issue" }, which no longer exists on GitHub. sk sync then failed:
ERROR [detection] Package path does not exist: .../skills/next-issue
The binary also shipped stale upstream obra/superpowers skills that have since been replaced by groundwork-native versions. No warning or error from the binary itself — the failure only surfaced at sk sync time, after a broken agents.toml was already written.
Structural gap
- No runtime freshness:
read_manifest() only reads the compiled-in constant. The CLI already shells out to gh and git for other network operations, but the manifest is never fetched from GitHub at runtime.
- No staleness detection:
groundwork doctor checks tool availability but never compares the embedded manifest against the current repo state. sha2 is already a dependency.
- Silent failure mode: The binary produces a plausible-looking
agents.toml with no indication that its manifest is outdated. The user discovers the problem only when sk sync fails — with an error message that doesn't point to the root cause.
Relevant code
main.rs:22 — const SHIPPED_SKILLS_TOML: &str = include_str!("../../../skills/skills.toml");
main.rs:761-764 — read_manifest() parses only the embedded constant
main.rs:451-534 — run_doctor() has no staleness check
Acceptance criteria