Skip to content

Resync standalone scanner/fixer skills onto the current modular engine lib #5

Open

Description

@clawgenti

Re-filed from rossoctl/agent-skills#51 (originally opened by @rubambiza) after RepoMan was cloned into this repo. Original discussion/history lives there.

Still applies in repoman: skills/{link-health,dep-bump}-{scanner,fixer}/scripts/program-lib.sh are the 662–663-line monolith, while skills/repoman/ and skills/automation-health-dashboard/ carry the 20-line aggregator. scripts/vendor-engine.sh (now in this repo) is the natural mechanism. Related: the dashboard-copy parity issue (#6).


Problem

The standalone link-health-scanner/-fixer and dep-bump-scanner/-fixer skills
bundle a 662-line monolithic program-lib.sh (last meaningfully updated Jun 2026).
The current engine in rossoctl/automation uses a 20-line aggregator program-lib.sh
that sources refactored-out modules (core.sh, github-api.sh, fork.sh, org.sh,
repoman-requirements.sh). These are architecturally different files, not old-vs-new
versions of one file.

The standalone scanners/fixers themselves have also diverged (e.g. link-health-scanner.sh
397 lines standalone vs 622 lines in automation; dep-bump-scanner.sh 597 vs 705).

Why a one-file update is unsafe

Overwriting the standalone program-lib.sh with the engine aggregator would break the
standalone scanners at source-time: the functions they call (setup_workspace,
gh_with_backoff, ensure_fork, create_fork_pr, write_report_latest, …) now live in
the sibling modules, which the standalone skill dirs do not contain.

Scope

Full resync of each standalone skill dir onto the current engine, from automation as
source of truth:

  • the modular lib set: program-lib.sh (aggregator) + core.sh + github-api.sh +
    fork.sh + org.sh + repoman-requirements.sh
  • the diverged standalone scanners/fixers

Priority / context

Deferred out of the RepoMan v0.1.0 release (scope discipline). The standalone
link-health/dep-bump skills are not currently being invoked, so the divergence is not
actively biting. Once the release's vendor script exists, it is the natural mechanism to
converge these dirs. Related: the dashboard-copy parity guard (#47).

Assisted-By: Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions