Skip to content

fix(cli): embedded skills manifest goes stale with no runtime freshness check #112

@pentaxis93

Description

@pentaxis93

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-issuebegin 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

  1. 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.
  2. No staleness detection: groundwork doctor checks tool availability but never compares the embedded manifest against the current repo state. sha2 is already a dependency.
  3. 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:22const SHIPPED_SKILLS_TOML: &str = include_str!("../../../skills/skills.toml");
  • main.rs:761-764read_manifest() parses only the embedded constant
  • main.rs:451-534run_doctor() has no staleness check

Acceptance criteria

  • groundwork init / groundwork update use a fresh manifest when network is available, embedded as fallback
  • groundwork doctor warns when the embedded manifest differs from the current repo version
  • Offline operation remains fully functional (embedded fallback)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions