[Enhancement]: Version and help checks should never rewrite skill files #4545

Request

Please make informational invocations such as graphify --version, graphify -v, graphify version, graphify --help, graphify -h, and subcommand help read-only with respect to installed skills and integrations.

They should not replace SKILL.md, refresh references, create skill backups, or update .graphify_version, even when an installed skill is older than the package and automatic refresh is otherwise enabled.

Confirmed observation

Environment: graphifyy==0.9.92, Python 3.14, macOS on Apple Silicon.

An existing Graphify skill for Gemini CLI had a .graphify_version marker of 0.9.91. During package verification, running graphify --version printed graphify 0.9.92 but also automatically refreshed that skill and its version marker, preserving the old skill in SKILL.md.bak.

In this particular case, the instruction-file difference was harmless: two backticks were removed around graphify update in a code comment. I am not claiming functional damage or settings corruption. The concern is that merely inspecting the package version performed writes to assistant instructions.

The files were restored. A launcher that sets GRAPHIFY_NO_AUTO_REFRESH=1 now prevents the writes in our setup; the opt-out works.

Evidence boundary: the write was observed during --version. I did not run an unguarded --help against the live skill directory. Source inspection of _run_cli() in the installed 0.9.92 package shows _refresh_stale_skills() and _refresh_v1_opencode_plugins() running before the top-level version/help early returns. Help is included in the requested read-only contract, not presented as a separately reproduced live incident.

Why this matters

Version/help checks are used by diagnostics, health checks, package managers, and automation to inspect an installation. They should be safe to run without preparing an environment-variable workaround or anticipating changes to assistant instructions.

Locally customized or centrally managed skills may intentionally differ from the package. A backup is useful, but it does not make a metadata query read-only.

I understand that automatic refresh is intentional and addresses stale instructions after a package upgrade (#1805). This request is narrower: exempt informational invocations, without removing the refresh feature from normal operational commands.

Suggested implementation and regression checks

Handle version/help requests before any integration-refresh routine that can write files. Existing read-only staleness warnings could remain.

For tests, use disposable home/project directories with stale skill markers and locally modified skill text; no installer needs to run. For each informational invocation, assert that:

• Existing skill files, references, and version stamps retain their bytes.
• No backup, lock, or replacement skill/reference files are created as a side effect of auto-refresh.
• Normal version/help output and exit behavior remain intact.
• This holds without GRAPHIFY_NO_AUTO_REFRESH=1, including when its inherited value is 0.
• Representative Claude Code, Codex, and Gemini skill destinations are covered.

Related issues

• Package upgrade leaves installed skill stale — version-mismatch warning never reaches the agent that consumes the skill #1805: why stale-skill detection/refresh is valuable.
• install: --platform X never writes .graphify_version (permanent upgrade warning), and install silently overwrites a modified SKILL.md #3144: preserving customized skills during installation; related concern, but this request concerns informational commands rather than an explicit install.
• Bug: Inconsistent help-flag handling across graphify subcommands #821: earlier help-flag execution behavior; this request specifically concerns integration auto-refresh before informational early returns.

No changes to graph schemas, extraction behavior, cache semantics, or the content of generated skills are requested.